I'm using latest bleeding-edge of gargoyle with my fonera to connect to my main wireless router. I set fonera as gateway and in wireless mode I choose Client+AP. In the second virtual interface ( the AP) I set a wpa2 key. I have problems because fonera disconnects me every few seconds. This is the log from logread command:
I have uploaded new firmware and I believe this problem is solved.
This issue had less to do with Gargoyle modifications and more to do with which version of the OpenWrt 8.09 branch it was using. Using the latest code seems to fix the problem. Please let me know if you're still having problems with this.
Jun 20 13:43:42 OpenWrt daemon.info dnsmasq[3828]: DHCPREQUEST(br-lan) 192.168.1.136 00:1f:3c:30:0d:fb
Jun 20 13:43:42 OpenWrt daemon.info dnsmasq[3828]: DHCPACK(br-lan) 192.168.1.136 00:1f:3c:30:0d:fb Cris-PC
Jun 20 13:43:57 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:43:57 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-00000003
Jun 20 13:43:57 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:44:11 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:44:11 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-00000004
Jun 20 13:44:11 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:44:13 OpenWrt authpriv.info dropbear[4213]: Child connection from 192.168.1.136:50996
Jun 20 13:44:22 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:44:22 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-00000005
Jun 20 13:44:22 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:44:23 OpenWrt authpriv.notice dropbear[4213]: password auth succeeded for 'root' from 192.168.1.136:50996
Jun 20 13:44:42 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:44:42 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-00000006
Jun 20 13:44:42 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:44:55 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:44:55 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-00000007
Jun 20 13:44:55 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:45:06 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:45:06 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-00000008
Jun 20 13:45:06 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:45:09 OpenWrt authpriv.info dropbear[4213]: exit after auth (root): error reading: Connection reset by peer
Jun 20 13:45:17 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:45:17 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-00000009
Jun 20 13:45:17 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:45:18 OpenWrt authpriv.info dropbear[4221]: Child connection from 192.168.1.136:51001
Jun 20 13:45:29 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:45:29 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-0000000A
Jun 20 13:45:29 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:45:31 OpenWrt authpriv.notice dropbear[4221]: password auth succeeded for 'root' from 192.168.1.136:51001
Jun 20 13:45:42 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:45:42 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-0000000B
Jun 20 13:45:42 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
Jun 20 13:46:05 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb IEEE 802.11: associated
Jun 20 13:46:05 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb RADIUS: starting accounting session 00000164-0000000C
Jun 20 13:46:05 OpenWrt daemon.info hostapd: ath1: STA 00:1f:3c:30:0d:fb WPA: pairwise key handshake completed (RSN)
If using no encryption all is OK, but when using WPA or WPA2 compare problem of reassociation.
I think it's openwrt related, but we need a solution to this because it's not good to have a unsecured wifi
Looking at your log, I just realized you're connecting with WPA2 RADIUS instead of WPA2 PSK. It works for WPA2 PSK, which is why I originally thought it was corrected.
I think this is related to this bug., which is, in a way, the opposite of what you report. AP+Client mode doesn't seem to work properly when no encryption is set, but with WPA or WPA2 PSK it seems to work. I guess that doesn't extend to WPA or WPA2 RADIUS.
I've been pulling my hair out all weekend trying to figure out what's going on with this bug, but it's nothing obvious. I'll do what I can but the problem may be buried deep in kernel driver code that I'm not particularly familiar with (at least not yet). This may end up being a "known issue" for some time.
Update, further characterization of the problem: It seems that it fails if you have both the AP and the client with the same type of encryption or lack thereof. So both wpa2 will fail, both open will fail while if you have ap=wpa2 and sta=open, it works.
I'm not using wpa radius, but I selected wpa tkip. In log messages there are infos about an accounting radius session, but I did not set anything about radius, so I don't know why this strange message id displayed.
I tried with the following config:
main ap: wpa (1) tkip
client ap: connects to wpa (1) tkip and ap is wpa2 aes (tried also wpa1 tkip).
But the problem is present also.
The only thing I think is that I never read about this "bug". I tried Gargoyle, but problem is present also in kamikaze ( branch and trunk). The latest working version (for me) is based on a revision of the 7 november 2008. I don't know why anyone has notified this bug before.
I tried also compiling kamikaze with old version of hostapd like 0.6.4, but no luck. I don't know what's the problem, but this bug exists from november 2008 and as you said this may end up being a "known issue" for a very long time.
Eric wrote:Update, further characterization of the problem: It seems that it fails if you have both the AP and the client with the same type of encryption or lack thereof. So both wpa2 will fail, both open will fail while if you have ap=wpa2 and sta=open, it works.
I'm not at home now and I can't make more tests. I have an idea: start hostapd by console with debug ( very verbose) enabled and see if we can find why reassociation is repeated every 10 seconds.
