# wpa_supplicant and infinite authentication loop

## sirlark

Hi, perhaps I should have added 'yet another' in front of the topic

So anyway, I'm trying to log on to my university's wireless network, which shows up as

 *Quote:*   

> 
> 
> root@hephaestus ~ # iwlist eth1 scanning     
> 
> eth1      Scan completed :
> ...

 

When I try to connect, using the following command, I get this

 *Quote:*   

> 
> 
> root@hephaestus ~ # wpa_supplicant -c /etc/wpa_supplicant.conf -D wext -i eth1
> 
> Trying to associate with ##:##:##:##:##:## (SSID='######' freq=0 MHz)
> ...

 

etc... etc... ad infinitum, and never actually logging me on.

The department I'm in runs mandriva on their macines, and all the laptops with wireless have exactly the same problem as me, except the one used by the departmental sysadmin (which is Suse, and works). I have upgraded to them same version of openssl as suse uses (0.9.8b) but to no avail. I use ipw2200, and have my settings givn to me by the sys admin here, which are the saem as thoseon the Suse laptop...

/etc/wpa_supplicant.conf

 *Quote:*   

> 
> 
> ctrl_interface=/var/run/wpa_supplicant
> 
> ctrl_interface_group=0
> ...

 

/etc/conf.d/net

 *Quote:*   

> 
> 
> config_eth0=( "dhcp" )
> 
> dhcpcd_eth0="-t 3"
> ...

 

/etc/conf.d/wireless

 *Quote:*   

> 
> 
> essid_eth1="any"
> 
> mode_eth1="auto"
> ...

 

output from 'emerge --info'

 *Quote:*   

> 
> 
> >>> cfg-update-1.8.0-r3 : Building checksum index... (takes a few seconds)  done!
> 
> Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r9 i686)
> ...

 

I don't use madwifi, and I'm not booting using initng

Any and all help appreciated

----------

## UberLord

What version of wpa_supplicant is he running and what version are you running?

----------

## sirlark

I'm running 0.4.9, he is running 0.4.8... I tried with 0.4.8 before upgrading.

The two laptops are identical from a hardware perspective (same brand/model). IPW2200 drivers don't seem to be the issue either.

Is anyone else having this problem?

----------

## UberLord

Have you tried the 0.5.x branch? It's proving very reliable

----------

## sirlark

Just unmasked at updated wpa_supplicant, no change...

Tried with fast_reauth turned off too, no luck though  :Sad: 

----------

## UberLord

Maybe there's some other security that's stopping you from associating like MAC address filtering. I mean if his is the ONLY laptop that connects then get HIM to fix it - lol

----------

## sirlark

Would love to, but even he doesn't know what Suse has done different... on top of that, the laptop was only just this morning wiped and given over to someone else for use... so I can't even check the settings myself

 :Sad: 

----------

## NoControl

Could it be that the beacon interval of your access point(s) is too high? I had a similar problem.

(This would of course mean that Suse somehow patched that up, which I think is unlikely.)

----------

## sirlark

Hmm, have looked into the problem, and it seems that the beacon interval may indeed be the problem, except that I have an Intel PRO Wireless card, and iwpriv doesn't give me the option to set/get beacon intervals. Is there another way that I can access this info about my card? Or should this be set on the wireless access point itself...

----------

## NoControl

The beacon interval is a property of the access point.

An AP sends out a 'beacon' every x milliseconds letting anyone who receives it know it's there, and what its name is. (It can be switched off on most APs (so you have to know it's there and what its name is before you can connect), but then wpa_supplicant can't connect at all - at least not when I tested it a few weeks ago.) I think that, when the beacons are too far apart (> 500ms), wpa_supplicant thinks the access point was gone for a while, and tries to reauthenticate. Lowering the beacon interval solved my reauthentication loop.

But if this is the problem, and someone using Suse does manage to get a stable connection, that would mean Suse somehow patched up their wpa_supplicant.

----------

## pholthau

what if there is no possibility to lower the interval of the access point?  :Sad: 

----------

## sirlark

Hi, I have the same problem, in that there is no option on my home wireless router to set the beacon interval. At work, I got the sysadmin to change the beacon interval to about 200ms, and I still had the same problem with the infinite authentication loop...

I'm stumped!

----------

## Darknight

It seems that a delay of 50 makes my laptop happy...

I also changed the transmission band so I can't honestly say what's (finally) making it work reliably, maybe both help. 4th successful handshake in a row with ultra-fast times...

Thank you for the heads up.

----------

## merlinux

Hi!

I think i have the same problem of sirlark.

I can connect to the access point , but after few minutes (and sometimes seconds!) the connection falls down and begin another time the phase of authentication.

The problem is that the AP is not mine....is the university's AP and i can't access to it.

Is it possible to make something working with wpa_supplicant?

Thank you

----------

## tarpman

If anyone with this problem is using the iwlwifi drivers from the package, try upgrading to a 2.6.24 kernel and using the in-kernel iwlwifi driver instead.

----------

## jcat

I've had great success with iwlwifi and wpa_supplicant.  Although I did have some issues to start with, they all turned out to be interference related.  The issue sounds kinda similar, I would get connected, then it would drop etc..

Scan for all WiFi networks using wireless-tools where you're trying to use the WiFi, you should be able to get a list of all networks in range and the channels that they use.  Then you need to try and pick a channel that is no where near the neighbouring APs range.

Most WiFi channels overlap in "squewed clusters" of 5, so 1 2 3 4 5 all overlap slightly, 6 7 8 9 10, and 11 12 13 14 15 etc, and these cluster overlap slightly as well.  I found a great diagram of this the other day, but I can't seem to find it now.

Basically if you have a neighbouring AP on channel 6, the use with 1 or 11 on your AP.  If the neighbouring AP is on channel 7 then use either 2 or 12, if they're  on 3 use either 8 or 13.  Hopefully you get the idea   :Smile: 

Obviously if you have more than one neighbouring AP then you need to just do your best find a compromise that works, maybe with a little trial and error.

When WiFi works it's great, but when it's dodgy (due to surrounding building of interference or whatever) it's a nightmare!

I realise that you had one guy that didn't have any issues connecting, but that might have been due to his location, did he always sit in the same spot?

Cheers,

jcat

----------

