Here is a post I sent last week with the debug from authsae. Hope this helps
-------------- I seem to run into a issue with Authsae going into LISTEN mode after a link is up (random times). I have The latest open80211s builds with Kernel 3.8.0-rc7 - iw-3.8 and authsae Running ath5k with 5Ghz radios - Also test with 900Mhz Radios using ath5k also same issue Here is my layout. 2 Nodes - Router1 and Router2 I create a mesh on both units with Authsae. The link comes up and my signal strengths are very good. -52 on both units. I can send traffic over the mesh with constant rates being shown in IPERF. After about 15 minutes Router 1 goes into LISTEN mode but Router 2 still shows ESTAB. If I restart Router 1 Authsae everything returns to normal. Now if I redo my testing everything runs perfectly. I was able to test everything for about an hour and a half when Router 2 went into LISTEN mode. This time I waited to see what would happen. After 1 Hour Router 2 came back on-line. This looks like it reset from the LIFETIME timer in authsae.conf which is set to 3600. Finding this to be coincidental I changed the LIFETIME to 300 to see if this is true. Sure enough after 20 minutes Router 2 went into LISTEN mode again and approx. 5 minutes later the link came back on-line with ESTAB. There are no errors in the dmesg or syslog showing why the link goes into LISTEN mode. In Debug mode of Authsae I see on Router 1 NL80211_CMD_FRAME (1364569888.215036) ---------- rx frame hexdump d0 00 ac 00 00 15 6d 54 6e 6b 00 15 6d 54 4f 76 00 15 6d 54 4f 76 80 03 0f 03 72 0b 6d 79 2d 6d 65 73 68 2d 39 30 30 75 06 00 00 00 00 34 00 ---------- Mesh plink: incorrect plink ie length 3 6 ----------------------------------------------------------------------------------------------------------- In Debug mode of Authsae I see on Router 2 NL80211_CMD_NEW_PEER_CANDIDATE(1364569889.195515) new unauthed sta (seq num=1364569906) NL80211_CMD_NEW_STATION (1364569889.195897) Not sure why the links would go into LISTEN mode sporadically. But it seems that after the LIFETIME timer fires they restart there handshake and reconnect. Is there a way for the ESTAB side of the link to know that a connection is in LISTEN mode on the other side? Is having the LIFETIME timer set to a low value a bad thing for traffic and or linking of multiple nodes, say over 10 node with LIFETIME set to 30. Router 2 shows this information Mesh plink timer for 00:15:6d:54:6e:6b fired on state HOLDING set plink state (seq num=1364569970) Mesh plink timer for 00:15:6d:54:6e:6b fired on state HOLDING set plink state (seq num=1364569971) While Router 1 shows this Mesh plink (peer, state, llid, plid, event): 00:15:6d:54:4f:76 HOLDING 34184 12144 7 set plink state (seq num=1364569872) Mesh plink timer for 00:15:6d:54:4f:76 fired on state LISTEN Timeout for peer 00:15:6d:54:4f:76 in state 0 Fred On Thu, Apr 4, 2013 at 2:42 PM, Thomas Pedersen <[email protected]> wrote: > Hi Fred, > > On Thu, Apr 4, 2013 at 9:01 AM, fred veldini <[email protected]> > wrote: > > Question about Toffsets and Authsae > > > > I have been doing more testing to identify why stations will randomly go > > into LISTEN Mode. > > I have noticed the Toffset state changes to a negative number and never > > resets to a positive number. > > Could this effect the negotiations between authentication after authsae > > lifetime expire? > > Is there a reason the Toffset would ever need to be a negative number? > > > > This is the state of the two units that dropped there connection. > > > > Station 00:15:6d:5d:4f:76 (on mesh0) > > inactive time: 1733 ms > > rx bytes: 22508 > > rx packets: 442 > > tx bytes: 1020 > > tx packets: 6 > > tx retries: 1 > > tx failed: 0 > > signal: -56 dBm > > signal avg: -59 dBm > > Toffset: 176566414740 us > > tx bitrate: 1.0 MBit/s > > mesh llid: 0 > > mesh plid: 0 > > mesh plink: LISTEN > > authorized: yes > > authenticated: yes > > preamble: long > > WMM/WME: yes > > MFP: no > > TDLS peer: no > > > > Station 00:15:6d:5d:6e:6b (on mesh0) > > inactive time: 652 ms > > rx bytes: 4025 > > rx packets: 42 > > tx bytes: 892 > > tx packets: 5 > > tx retries: 0 > > tx failed: 0 > > signal: -54 dBm > > signal avg: -55 dBm > > Toffset: -176566414742 us > > tx bitrate: 1.0 MBit/s > > mesh llid: 0 > > mesh plid: 0 > > mesh plink: LISTEN > > authorized: yes > > authenticated: yes > > preamble: long > > WMM/WME: yes > > MFP: no > > TDLS peer: no > > The fact that the MFP flag gets reset is pretty strange. It looks like > mac80211 will only ever do this in response to an add/set station > command, but authsae also only sets the MFP flag in conjunction with > authorized and authenticated flags. Hmm. > > Is there any interesting dmesg output when this happens? authsae logs? > > > If I restart the mesh that has the negative variable in Toffset > > every comes back online with ESTAB and traffic flows nicely. > > and of course MFP turns to yes on both units. > > > > BTW using the latest builds from git. > > > > > > Any assistance would be appreciated. > > > > Fred > > > > > > > > _______________________________________________ > > Devel mailing list > > [email protected] > > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > > > > > > -- > Thomas > _______________________________________________ > Devel mailing list > [email protected] > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel >
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
