--- author: email: rafl@fsfe.org keyid: 742f2a428e635a5e name: Florian Ragwitz categories: - Hacking comments: [] date: 2006-03-27T11:02:03Z guid: 56d21ce4-b97f-4ad4-ae25-949cd5b7f4dc modified: 2006-03-27T11:02:03Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nHave you ever been bitten by a problem that resets all wifi settings like mode,\nessid and whatnot just some seconds after you set them? A certain mister\nL suggest to simply\nL\non that machine if it is running, as it always resets such settings to be able\nto receive all packets from all access points.\n\nSo, after doing so I now know why my wifi access point, which is just a normal\nDebian box, wasn't working for the last couple of months. For some reason\nwpa_supplicant was installed and running.. I just can't remember to have\ninstalled it as it hardly makes sense to me. Anyway, after I could set the wifi\nsettings again I thought it wouldn't be much of a problem to get hostapd with\nWPA-EAP working again. B!\n\nwpa_supplicant on the client side somehow thought it was authenticated, but it\nactually wasn't. So I checked the debug output of hostapd which said something\nlike that:\n\n ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long\n\nand after that line it said the it deauthenticated the client because of a\nlocal request, so I thought that's the problem. It pretty much looks like a\nbinary incompatibility to me. I updated the madwifi drivers before in an\nattempt to to fix the essid reset problem, so hostapd, which needs to be\ncompiled against the madwifi headers didn't work properly anymore. So I tried\nto recompile it and things got even worse:\n\n ioctl[unknown???]: Operation not supported\n\nI had no idea what to do about that, so I joined #madwifi on freenode. I have\nbeen told that I'll need at least hostapd 0.4.whatnot to make it run with\nmadwifi-ng. Unstable has 0.5.0, so I downloaded that package, which contains\nmadwifi-ng includes do build against, and compiled it on my sarge box. Almost\nexactly in the moment I was done I found out that I would need hostapd 0.5.2 to\nmake it work with madwifi-ng and WPA2. B...\n\nSo I compiled it again, installed it and everything should have run fine. For\nsome reason it didn't. After a while starting and stopping it to take a look at\nthe debug output it somehow started to work and it keeps working up to now. I\nhave actually no idea what could have caused that problem. Stijn Tintel on\n#madwifi could think of re-keying at the wrong moment or something like that,\nbut isn't quite sure about that.\n\nAnyway, wifi is up and working again and that makes me happy. :-)\n\n=cut\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\n\niD8DBQFGCP+ndC8qQo5jWl4RAnd7AJ0YxjDryJxHv7RP7HcIaCkckDoQ8QCfaSaX\n5FfUsBmxvZNtf6Pol4dvZjE=\n=uuD6\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " Have you ever been bitten by a problem that …" tags: [] text: " Have you ever been bitten by a problem that resets all wifi settings\n like mode, essid and whatnot just some seconds after you set them? A\n certain mister Dreker suggest to simply shut down wpa_supplicant on\n that machine if it is running, as it always resets such settings to\n be able to receive all packets from all access points.\n\n So, after doing so I now know why my wifi access point, which is\n just a normal Debian box, wasn't working for the last couple of\n months. For some reason wpa_supplicant was installed and running.. I\n just can't remember to have installed it as it hardly makes sense to\n me. Anyway, after I could set the wifi settings again I thought it\n wouldn't be much of a problem to get hostapd with WPA-EAP working\n again. Wrong!\n\n wpa_supplicant on the client side somehow thought it was authenti-\n cated, but it actually wasn't. So I checked the debug output of\n hostapd which said something like that:\n\n ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long\n\n and after that line it said the it deauthenticated the client be-\n cause of a local request, so I thought that's the problem. It pretty\n much looks like a binary incompatibility to me. I updated the mad-\n wifi drivers before in an attempt to to fix the essid reset problem,\n so hostapd, which needs to be compiled against the madwifi headers\n didn't work properly anymore. So I tried to recompile it and things\n got even worse:\n\n ioctl[unknown???]: Operation not supported\n\n I had no idea what to do about that, so I joined #madwifi on freen-\n ode. I have been told that I'll need at least hostapd 0.4.whatnot to\n make it run with madwifi-ng. Unstable has 0.5.0, so I downloaded\n that package, which contains madwifi-ng includes do build against,\n and compiled it on my sarge box. Almost exactly in the moment I was\n done I found out that I would need hostapd 0.5.2 to make it work\n with madwifi-ng and WPA2. Grr...\n\n So I compiled it again, installed it and everything should have run\n fine. For some reason it didn't. After a while starting and stopping\n it to take a look at the debug output it somehow started to work and\n it keeps working up to now. I have actually no idea what could have\n caused that problem. Stijn Tintel on #madwifi could think of re-key-\n ing at the wrong moment or something like that, but isn't quite sure\n about that.\n\n Anyway, wifi is up and working again and that makes me happy. :-)\n" title: Wireless fun type: pod uri: http://perldition.org/articles/Wireless%20fun.pod xhtml: "
\n

Have you ever been bitten by a problem that resets all wifi settings like mode,\nessid and whatnot just some seconds after you set them? A certain mister\nDreker suggest to simply\nshut down wpa_supplicant\non that machine if it is running, as it always resets such settings to be able\nto receive all packets from all access points.

\n

So, after doing so I now know why my wifi access point, which is just a normal\nDebian box, wasn't working for the last couple of months. For some reason\nwpa_supplicant was installed and running.. I just can't remember to have\ninstalled it as it hardly makes sense to me. Anyway, after I could set the wifi\nsettings again I thought it wouldn't be much of a problem to get hostapd with\nWPA-EAP working again. Wrong!

\n

wpa_supplicant on the client side somehow thought it was authenticated, but it\nactually wasn't. So I checked the debug output of hostapd which said something\nlike that:

\n
ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long\n
\n

and after that line it said the it deauthenticated the client because of a\nlocal request, so I thought that's the problem. It pretty much looks like a\nbinary incompatibility to me. I updated the madwifi drivers before in an\nattempt to to fix the essid reset problem, so hostapd, which needs to be\ncompiled against the madwifi headers didn't work properly anymore. So I tried\nto recompile it and things got even worse:

\n
ioctl[unknown???]: Operation not supported\n
\n

I had no idea what to do about that, so I joined #madwifi on freenode. I have\nbeen told that I'll need at least hostapd 0.4.whatnot to make it run with\nmadwifi-ng. Unstable has 0.5.0, so I downloaded that package, which contains\nmadwifi-ng includes do build against, and compiled it on my sarge box. Almost\nexactly in the moment I was done I found out that I would need hostapd 0.5.2 to\nmake it work with madwifi-ng and WPA2. Grr...

\n

So I compiled it again, installed it and everything should have run fine. For\nsome reason it didn't. After a while starting and stopping it to take a look at\nthe debug output it somehow started to work and it keeps working up to now. I\nhave actually no idea what could have caused that problem. Stijn Tintel on\n#madwifi could think of re-keying at the wrong moment or something like that,\nbut isn't quite sure about that.

\n

Anyway, wifi is up and working again and that makes me happy. :-)

\n\n\n
"