Owning Authpuppy server - The DD-WRT side

Bug #1042358 reported by Andrei
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AuthPuppy
New
Undecided
Unassigned

Bug Description

First, i labeled it as a bug, but in fact, this is the only way for me to published it to many more peoples here.

Having Authpuppy server working with DD-WRT is pretty simple. But if there one of the basic facts missing, nothing will work and there will no easy way out.

It is not the more secured plan but it is certainly one of the most effective as i experienced until now. As i see it now i didn't expect to write as many lines as there is now, but each lines mean something to be explained.

So how it is done ...

First : The Authpuppy server configuration.

For the purpose of this example, i'll use wifi network cards and i'll use the acronym "WNC" to talk about it. Yes there are WLAN# and ETH# words used for these instances but it may be confusing sometimes, so i'll go on with WNC. Everything is made under Ubuntu, as long as Debian is painful and far from being ready to work with these long time used WNC whatever the brand is.

I'll use the acronym "AP" to talk about Access Points, gateway, routers running DD-WRT firmwares. And i'll use the acronym "ASE" to talk about a proprietary authpuppy server, meaning a server that someone owned.

As much we have nodes, as much we have AP. As much we have nodes, as much we have WNC. I assumed that the ASE is up and running. We have to add new nodes to finish the work and having this same ASE accessible and fully running.

First, each newer node will have a separated unique gw id. Gw id is the most important part of the ASE node's configuration A gw id is used to make a link with a WNC. Assuming that a WNC is already connect and recognizable by the OS (Ubuntu), in the OS Network Configuration we have to get and copy the mac address of the given WNC. A mac address is a unique hardware signature, it is made of hexadecimal numbers separated with ":" (for example 00:1E:2I:25:5D:9C is a unique mac address).

Now, this mac address will be the Gw id of the newly made node. For example, one of my WNC is a Ubiquiti Wifistation-ext usb network card. This card is part of my actual pc server , and i use it for a specific node. In the network configuration of Ubuntu, i got his mac address from the "network config". I copy it and paste it in the gw id part of my first node. Filling up the necessary fields of this newly made node is easy, it is not necessary to explain it here.

For the moment that's all we need to do in the Authpuppy server configuration.

=====>>But i'll get back later with a further OS Network configuration of the WNC

Second : The AP configuration.

As i said before this sample is based on DD-WRT firmware. These firmwares are mostly free, and in the www.dd-wrt.com website , there is a router database section where we can download a firmware specifically made for our own AP. Everything's explain on this site on how to flash a router with these specifics firmwares.

Getting in the DD-WRT firmware configuration, there's is a service tab, leading to the Hotspot tab, and finally to the wifidog configuration section of our AP. You'll noticed that there is also a gw id item among those parts of this section. The same Gwid used in the APS node config will be used in this field. For all the other fields here's what we'll have :

Web Server Name : Any words can be written here as long as they do not have special characters.
Port : 2060
Max Users : 10
Check Interval (in sec.) : 60
Client Timeout : 5
Trusted MAC List : Leave this field empty (blank).

====>> AuthServer Hostname : Very important. This will be explained later for the moment leave it empty.

AuthServer SSL Available : Disabled
AuthServer HTTP Port : 80
AuthServer Path : /
HTTP Server Authentication Support : Disabled
HTML Message File for Wifidog : Leave this field empty (blank)
Firewall Ruleset : Leave this fields empty.

(This sample configuration above may change on how must be the purpose of your needs)

Third : The OS configuration.

Remember the "further OS Network configuration" noticed above as something to be configured. That's where we are now. Each node stand for a single network. A network is designed by having is own local ip address, a gateway address (who is in fact the local ip address of the AP), and a broadcast address (that's not necessary to understand here). Again i'll explained it with an example.

My first AP have a 192.168.10.1 gateway address, and a subnet mask defined has 255.255.255.0 (that's the default subnet mask by the way). Network knowledge are necessary to understand this part. So, knowing that my AP have these addresses, we already know that the network address of this AP will be 192.168.10.0. My gateway will be able to have a maximum range of 253 hosts (PC, Smartphone, laptop, etc) from 192.168.10.2 to 192.168.10.254. These lines were written in a pure knowledge purpose, it is not necessary to understand all these concepts.

What's important to know, is that my WNC will be link to this specific AP. And as necessary his mac adress is, explained above, it need also a single network address. So all the communications between my AP and my WNC wil be made on a single local address. For this example, i'll use 192.168.10.125 standing for this "communication channel" between my AP and my SERVER. (Notice that on some router we have to make sure that local ip reservation must be made but it remain a simple notice here).

In my OS (Ubuntu here) i have to change the network configuration of my WNC, to manually assigned a local ip address. In my case, it is 192.168.10.125. As long as my WNC will be used to have a link between my AP and my server, this address will always be the same for this WNC. In the network configuration of my WNC, i'll change the automatic option, by manual option, and i'll use these parameters :

Network address : 192.168.10.125
Subnet mask : 255.255.255.0
Gateway address : 192.168.10.1 (the adress of my ap)
DNS adress : 192.168.10.1

Now my network card is configured and ready to be used by my APS. One thing remain :

====>> AuthServer Hostname as i mention earlier.

In the wifidog configuration of my ap, i have to assigned the AuthServer Hostname as : 192.168.10.125. That was the remaining point of the wifidog configuration of my AP.

From now on, my AP will established a link with my authpuppy server first node. I forgot to mention that my AP must have a SSID (in the wifi configuration parameters of DD-WRT and the security must be set to none). This SSID will be used for the customers to link to my hotspot.

Finally every nodes stand for a network. I have two nodes on my server. The first, as i take it for example here, is made for a 192.168.10.0/24 network while the other stands for 192.168.20.0/24. The third one who is on progress now will stand for a 10.0.100.0/8 network (a classfull "A" network). Each node have his own network card link to his own AP. The process to made them up and running is as it is explained before.

I'll get back later with Ubiquiti devices.

Revision history for this message
jackson (neojack34-isf) wrote : Re: [Bug 1042358] [NEW] Owning Authpuppy server - The DD-WRT side
Download full text (16.0 KiB)

est ce que en fait ce message est la doc que je t'ai demandé ?
tu peux me l'envoyer directement stp, on corrigera et postera ça sur le wiki

mais il y a une petite erreur dans ta compréhension

terminologie authpuppy :
- 1 node, c'est un point d'accès avec wifidog installé dessus et par défaut
son ID (GWID dans wifidog.conf) c'est son adresse mac.
tu n'a pas besoin de modifier quoi que ce soit dans wifidog.conf pour que
le gwid soit reconnu. si tu met la valeur par défaut, wifidog va
communiquer l ádresse mac du node à authpuppy, et autpuppy l'enregistrera
dans la fenetre de configuration du node (dans manage node)

- carte reseau WiFi, c'est un client. un usager qui se connecte sur un
point d'accès. Donc 1 carte réseau WiFi ce n'est pas un node

pour le reste, pas trop le temps de lire, mais je ne peux pas accéder à ton
serveur depuis 2 semaines.
Fais fonctionner ça et on progressera, ensuite je testerai les images que
tu m'as envoyé. je pourrais même t'en faire si t'es patient

Cordialement
Jackson JOSEPH-EUGENE
Coordinateur technique et des bénévoles Ile Sans Fil

2012/8/27 Andrei <email address hidden>

> Public bug reported:
>
> First, i labeled it as a bug, but in fact, this is the only way for me
> to published it to many more peoples here.
>
> Having Authpuppy server working with DD-WRT is pretty simple. But if
> there one of the basic facts missing, nothing will work and there will
> no easy way out.
>
> It is not the more secured plan but it is certainly one of the most
> effective as i experienced until now. As i see it now i didn't expect to
> write as many lines as there is now, but each lines mean something to be
> explained.
>
> So how it is done ...
>
> First : The Authpuppy server configuration.
>
> For the purpose of this example, i'll use wifi network cards and i'll
> use the acronym "WNC" to talk about it. Yes there are WLAN# and ETH#
> words used for these instances but it may be confusing sometimes, so
> i'll go on with WNC. Everything is made under Ubuntu, as long as Debian
> is painful and far from being ready to work with these long time used
> WNC whatever the brand is.
>
> I'll use the acronym "AP" to talk about Access Points, gateway, routers
> running DD-WRT firmwares. And i'll use the acronym "ASE" to talk about a
> proprietary authpuppy server, meaning a server that someone owned.
>
> As much we have nodes, as much we have AP. As much we have nodes, as
> much we have WNC. I assumed that the ASE is up and running. We have to
> add new nodes to finish the work and having this same ASE accessible and
> fully running.
>
> First, each newer node will have a separated unique gw id. Gw id is the
> most important part of the ASE node's configuration A gw id is used to
> make a link with a WNC. Assuming that a WNC is already connect and
> recognizable by the OS (Ubuntu), in the OS Network Configuration we have
> to get and copy the mac address of the given WNC. A mac address is a
> unique hardware signature, it is made of hexadecimal numbers separated
> with ":" (for example 00:1E:2I:25:5D:9C is a unique mac address).
>
> Now, this mac address will be the Gw id of the newly made node. For
> example, one of my...

Revision history for this message
Andrei (andrei-halle-deactivatedaccount) wrote :

Salut Jackson,

Je n'avais jamais produit cette doc avant de m'assurer que tout était parfaitement fonctionnel.

Mes routers étant configuré DD-WRT n'utilise pas le wifidog.conf mais une section qui le configure.

Mes routeurs ne sont pas connectés filaire avec le serveur mais en wifi. J'ai trois cartes wifi sur mon serveur, et l'interaction se fait oui par l'adresse exact de la mac adresss de chacune des cartes sinon d'aucune façon ça ne fonctionnera pas. Je sais ce que tu cites lorsqu'on install une nouvelle borne, en Openwrt c'est ainsi que ça fonctionne, automatiquement toujours au niveau de la mac.

ce qui précède est exactement ce qui fonctionne ici. Chaque borne d'accès a son propre SSID, le client se connecte, Windows 7 arrive avec un message disant que des informations supplémentaires seront nécessaires pour se connecter. Le Splash screen apparait à l'écran et dépendemment de la borne d'accès, les politiques associées seront en action. Le client sera redirigé par la suite vers sa page internet par defaut.

Tout ce qui a été écrit précédement est exact, et non, pas de fichier wifidog.conf. Je te reviendrai pour la suite car je suis pressé,

Merci Jackson !

Revision history for this message
Andrei (andrei-halle-deactivatedaccount) wrote :

De plus ....

Les bornes d'accès communiquent en Wifi avec le serveur avec une carte usb wifi qui leur est dédiée. Donc toute communication avec le serveur est en sans fil. Aucun lien filaire dans ce qui précède tout est fait wifi. Ce qui donne la possibilité d'éliminer le plus de filage possible. Par contre, oui il est possible d'avoir par exemple trois cartes réseau filaires et de les connecter au bornes d'accès. Ce sera le même processus sauf que la mac utilisée sera celle de la carte réseau filaire.

Voilà ....

Revision history for this message
Andrei (andrei-halle-deactivatedaccount) wrote :

Jackson prend le temps de lire tout ce qui précède car ce que tu explique vas à contre-sens et ce n'est pas la méthode utilisée en DD-WRT. C'est bien important. Car en DD-WRT c'est un tout autre monde. Pour ce qui est de l'utilisation des bornes Ubiquiti je n'en ai pas encore parlé. Mais oui je sus ouvert à wifidog.conf qui sera fonctionnerl bien sur. Mais des mots écrits de toi, ça ne fait que mêler un peu le processus DD-WRT. Juste à regarder ce qui suit :

Quand je dis WNC je parle de Wifi Network Card, les cartes réseau sans fil usb du serveur j'en ai trois Jackson. Dans ce qui suit je parle de la première :

.... i have to change the network configuration of my WNC, to manually assigned a local ip address. In my case, it is 192.168.10.125. As long as my WNC will be used to have a link between my AP and my server, this address will always be the same for this WNC. In the network configuration of my WNC, i'll change the automatic option, by manual option, and i'll use these parameters : ....

Network address : 192.168.10.125
Subnet mask : 255.255.255.0
Gateway address : 192.168.10.1 (the adress of my ap)
DNS adress : 192.168.10.1

C'est hyper important de lire le tout sinon ça peut devenir extrêment confus.

Revision history for this message
Max Maier (regnor) wrote :

I've tried to configure Authpuppy for a DDWRT-AP running the Wifidog client and everything is working fine, except that I wont get a connection to the internet; after the login I'm getting the Message "Access Denied".
The interesting thing is, that every login is successfully authenticated according to the statistics and the "connection counter" increases.

Does anyone have an idea what the problem could be?
I've allready looked into the error.log (nothing there), reinstalled the server and accesspoint and tried an older version of Authpuppy.

Authpuppy is running on an Ubuntu12.04 Server.
The AP is wired to the network card of the Ubuntu Server and redirection works.

Revision history for this message
Max Maier (regnor) wrote :

After everything what I've tried the solution was so simple; I just had to kill the wifidog deamon and restart ist...and now it works...

Revision history for this message
Andrei (andrei-halle-deactivatedaccount) wrote :

Glad to know that it has been solved. I've experienced this situation where the default page was not showing. But, i was able to have a new browser tab and typing whatever the url was, and it worked. But yes, in the way you tell it, this the best thing to do.

Thanks for the words !

Revision history for this message
Robin Jones (robin-networkfusion) wrote : RE: [Bug 1042358] Re: Owning Authpuppy server - The DD-WRT side
Download full text (8.4 KiB)

Andrei,

Why don't you add this information to the wiki, it seems a much better place for it, and with enough detail, will help others in the future. I added screenshots to the windows server instructions, which added some better context. If you wanted to do the same, I think you may have to ask Geneviève.

Robin.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Andrei
Sent: 30 August 2012 04:02
To: Robin Jones
Subject: [Bug 1042358] Re: Owning Authpuppy server - The DD-WRT side

Glad to know that it has been solved. I've experienced this situation where the default page was not showing. But, i was able to have a new browser tab and typing whatever the url was, and it worked. But yes, in the way you tell it, this the best thing to do.

Thanks for the words !

--
You received this bug notification because you are subscribed to AuthPuppy.
https://bugs.launchpad.net/bugs/1042358

Title:
  Owning Authpuppy server - The DD-WRT side

Status in AuthPuppy authentication server for Wifidog networks:
  New

Bug description:
  First, i labeled it as a bug, but in fact, this is the only way for me
  to published it to many more peoples here.

  Having Authpuppy server working with DD-WRT is pretty simple. But if
  there one of the basic facts missing, nothing will work and there will
  no easy way out.

  It is not the more secured plan but it is certainly one of the most
  effective as i experienced until now. As i see it now i didn't expect
  to write as many lines as there is now, but each lines mean something
  to be explained.

  So how it is done ...

  First : The Authpuppy server configuration.

  For the purpose of this example, i'll use wifi network cards and i'll
  use the acronym "WNC" to talk about it. Yes there are WLAN# and ETH#
  words used for these instances but it may be confusing sometimes, so
  i'll go on with WNC. Everything is made under Ubuntu, as long as
  Debian is painful and far from being ready to work with these long
  time used WNC whatever the brand is.

  I'll use the acronym "AP" to talk about Access Points, gateway,
  routers running DD-WRT firmwares. And i'll use the acronym "ASE" to
  talk about a proprietary authpuppy server, meaning a server that
  someone owned.

  As much we have nodes, as much we have AP. As much we have nodes, as
  much we have WNC. I assumed that the ASE is up and running. We have to
  add new nodes to finish the work and having this same ASE accessible
  and fully running.

  First, each newer node will have a separated unique gw id. Gw id is
  the most important part of the ASE node's configuration A gw id is
  used to make a link with a WNC. Assuming that a WNC is already
  connect and recognizable by the OS (Ubuntu), in the OS Network
  Configuration we have to get and copy the mac address of the given
  WNC. A mac address is a unique hardware signature, it is made of
  hexadecimal numbers separated with ":" (for example 00:1E:2I:25:5D:9C
  is a unique mac address).

  Now, this mac address will be the Gw id of the newly made node. For
  example, one of my WNC is a U...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.