AuthPuppy

Bug #1028578
Comment #14

Comment 14 for bug 1028578

Revision history for this message

Andrei (andrei-halle-deactivatedaccount) wrote on 2012-08-12: RE: [Bug 1028578] Re: Connection management problem

#14

Non pour le moment, il est toujours actuel et je n'ai pas trouvé ce qui pourrait corriger la situation. C'est une situation qui "heureusement" ne se généralise pas à tout type d'installation dans sa dernière définition.
Par contre, au niveau Debian, ce que j'explique, en ce qui concerne les topology classless et classful, est une règle des iptables (C'est une norme de la réseautique au delà de Debian). Si on ne crée pas d'exception dans les iptables, alors il peut y avoir refus de connections. Si j’utilise un adressage de type 192.168.x.x alors le masque réseau doit être de 255.255.255.0 ou /24 sinon on déroge à la règle concernant la classe C en adoptant un masque différent. C'est ce que j'ai expérimenté seulement chez moi, et à de nombreuses reprises toujours faudrait il voir si ce problème se répète ailleurs pour pouvoir le détailler.
Quant à la persistance de la connexion, elle est à problème, si par exemple, je me connecte avec nom d'usager et mot de passe. À cet effet, la persistance de la connexion fait que lorsque pour un même poste de travail, ou qu'importe, l'usager se déconnecte du SSID et qu'un autre prends sa place pour le même poste de travail, alors il n'a pas à s'identifier, il est identifier au même titre que l'usager précédant.
Je ne pourrais mieux documenter le problème. Il est tel que je le cite ci haut. Pour le reste il m'est difficile d'aller chercher des éléments qui puissent me donner davantage d'informations sur mon serveur par manque de connaissance. Si j'ai des éléments supplémentaires à signaler je le ferai dans un message subséquent.

> Date: Fri, 10 Aug 2012 19:01:44 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 1028578] Re: Connection management problem
>
> André, le bogue est réglé?
> Sinon, peux-tu fournir les nouveaux détails suite aux différentes solutions qui ont été données.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1028578
>
> Title:
> Connection management problem
>
> Status in AuthPuppy authentication server for Wifidog networks:
> New
>
> Bug description:
> Some ways to configure wifidog in DD-WRT make it works although
> there's others ways were it lead to problems.
>
> On first instance, since i made classful connections meaning that having a network topology having one of the address's type between 192.168.1.0 to 192.168.254.0 (class C) respecting mask related to class C connection which are 255.255.255.0
> (otherwise /24) help a lot and solve many problems.
>
> I discovered it cause my airport extreme router (made by Apple) is a
> class A router. This mean that adressing the mask must respect
> 255.0.0.0 network topology (in other word /8) and a 10.0.0.0 network
> type adressing topology.
>
> This may be obsolete for certain peoples, but that's not the case on
> some iptables (firewall) entries. I discover that a class C address
> with a 255.255.0.0 mask may be refused by some linux ip tables rules
> of linux based server.
>
> It may be possible to change iptables having classless adressing
> instead classful adressing.
>
> GOD ! why it is so hard to explain !!! Anyway ... in english.
>
> Now, that this problem lead me to have better results in my
> connection's problems, if in the wifidog dd-wrt configuration of my
> router i simply disable HTTP Server Authentication Support, i have
> this kind of url :
>
> https://www.nexeras.com/login/?gw_address=192.168.10.1&gw_port=2060&gw_id=2&url=http%3A//www.grc.com/
> (grc.com contains a lot of useful things by the way) .
>
> But if i enabled it everything's fine, and i have access to internet.
> But i do not have any splash page, and my server is configured to have
> splash page only connection.
>
> If i disabled AuthServer SSL Available it may lead to the same problem
> explain before. The only way to have a connection is to enable HTTP
> Server Authentification Support all the subsequent textboxes are
> blank, and having AuthServer SSL Available enabled.
>
> So if it make a difference in configuration it may be also be a bug
> ...
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/authpuppy/+bug/1028578/+subscriptions

Non pour le moment, il est toujours actuel et je n'ai pas trouvé ce qui pourrait corriger la situation. C'est une situation qui "heureusement" ne se généralise pas à tout type d'installation dans sa dernière définition. 
Par contre, au niveau Debian, ce que j'explique, en ce qui concerne les topology classless et classful, est une règle des iptables (C'est une norme de la réseautique au delà de Debian). Si on ne crée pas d'exception dans les iptables, alors il peut y avoir refus de connections. Si j’utilise un adressage de type 192.168.x.x alors le masque réseau doit être de 255.255.255.0 ou /24 sinon on déroge à la règle concernant la classe C en adoptant un masque différent.  C'est ce que j'ai expérimenté seulement chez moi, et à de nombreuses reprises toujours faudrait il voir si ce problème se répète ailleurs pour pouvoir le détailler.
Quant à la persistance de la connexion, elle est à problème, si par exemple, je me connecte avec nom d'usager et mot de passe. À cet effet, la persistance de la connexion fait que lorsque pour un même poste de travail, ou qu'importe, l'usager se déconnecte du SSID et qu'un autre prends sa place pour le même poste de travail, alors il n'a pas à s'identifier, il est identifier au même titre que l'usager précédant. 
Je ne pourrais mieux documenter le problème. Il est tel que je le cite ci haut. Pour le reste il m'est difficile d'aller chercher des éléments qui puissent me donner davantage d'informations sur mon serveur par manque de connaissance. Si j'ai des éléments supplémentaires à signaler je le ferai dans un message subséquent.

> Date: Fri, 10 Aug 2012 19:01:44 +0000
> From: 1028578@bugs.launchpad.net
> To: andrei.halle@live.com
> Subject: [Bug 1028578] Re: Connection management problem 
> 
> André, le bogue est réglé?
> Sinon, peux-tu fournir les nouveaux détails suite aux différentes solutions qui ont été données.
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1028578
> 
> Title:
>   Connection management problem
> 
> Status in AuthPuppy authentication server for Wifidog networks:
>   New
> 
> Bug description:
>   Some ways to configure wifidog in DD-WRT make it works although
>   there's others ways were it lead to problems.
> 
>   On first instance, since i made classful connections meaning that having a network topology having one of the address's type between  192.168.1.0 to 192.168.254.0 (class C) respecting mask related to class C connection which are 255.255.255.0
>    (otherwise /24) help a lot and solve many problems. 
> 
>   I discovered it cause my airport extreme router (made by Apple) is a
>   class A router. This mean that adressing the mask must respect
>   255.0.0.0 network topology (in other word /8) and a 10.0.0.0 network
>   type adressing topology.
> 
>   This may be obsolete for certain peoples, but that's not the case on
>   some iptables (firewall) entries. I discover that a class C address
>   with a 255.255.0.0 mask may be refused by some linux ip tables rules
>   of linux based server.
> 
>   It may be possible to change iptables having classless adressing
>   instead classful adressing.
> 
>   GOD ! why it is so hard to explain !!! Anyway ... in english.
> 
>   Now, that this problem lead me to have better results in my
>   connection's problems, if in the wifidog dd-wrt configuration of my
>   router i simply disable HTTP Server Authentication Support, i have
>   this kind of url :
> 
>   https://www.nexeras.com/login/?gw_address=192.168.10.1&gw_port=2060&gw_id=2&url=http%3A//www.grc.com/
>   (grc.com contains a lot of useful things by the way) .
> 
>   But if i enabled it everything's fine, and i have access to internet.
>   But i do not have any splash page, and my server is configured to have
>   splash page only connection.
> 
>   If i disabled AuthServer SSL Available it may lead to the same problem
>   explain before. The only way to have a connection is to enable HTTP
>   Server Authentification Support all the subsequent textboxes are
>   blank, and having AuthServer SSL Available enabled.
> 
>   So if it make a difference in configuration it may be also be a bug
>   ...
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/authpuppy/+bug/1028578/+subscriptions