Hi ofthecentury,
Thank you for submitting this bug report. We are unable to help you
further or fix this bug without further information, as Peter Hansteen
requested in the other thread you referenced from misc.
Specifically we need the output of the following commands (the $ is the
prompt and not part of the command):
$ dmesg
$ cat /etc/hostname.athn0
$ grep athn0 /var/log/messages
Once you provide this info, the developers will have more ability to
help you.
Let us know and thanks,
Kevin
On 3/30/24 9:23 AM, ofthecentury wrote:
I been trying to troubleshoot wifi issues on the misc list.
Seems like this might be a bug, so I hope you can take a
look.
A wifi driver athn0 in hostap mode and with "stayauth" flag
for surety deauthenticates an already authenticated client
(giving reason 6 deauthentication reason code) upon receipt
of a class 2 frame, versus just re-associating the client.
---------- Forwarded message ---------
From: ofthecentury <[email protected]>
Date: Sat, Mar 30, 2024 at 8:59 PM
Subject: Re: wifi hotspot workaround
To: Peter N. M. Hansteen <[email protected]>
Cc: <[email protected]>
And now something else happened, which seems like a big
bug.
athn0 sent a reason 6 deauthentication to my wifi client
after I cycled the athn0 wifi interface!
Reason 6 death is class 2 frame received from a nonauthenticated
station. Correct me if I'm wrong, but this sounds like a major
bug in the driver. It's basically the wifi driver deauthenticates
a client who is AUTHENTICATED but just not associated at the
moment of receipt of that class 2 frame? The logical thing would
be for the driver/AP to re-associate the client because it's already
authenticated, versus what it's doing now - deauthenticating
an already authenticated client. I don't even understand why
the athn0 hostap wouldn't just re-associate the already authenticated
client, especially since I have the nwflag "stayauth" turned on
on the interface.
On Sat, Mar 30, 2024 at 8:30 PM ofthecentury <[email protected]> wrote:
Ok, I also just got reason 16 deauth happen. It says it was
sending msg 1/2 of the group key handshake to my wifi client,
it repeated it twice, and then the reason 16 deauth happened.
Then it says deauth to the wifi client and then wifi client was
purged from node cache. And now, the network SSID does not
show up in the list of wireless network on my wifi client!
athn0 appears as "UP" in ifconfig.
THEN, I cycle athn0 down/up, and then the wifi client finds
the network immediately and reconnects.
What is going on here??
On Sat, Mar 30, 2024 at 7:47 PM Peter N. M. Hansteen <[email protected]> wrote:
On Sat, Mar 30, 2024 at 05:44:32PM +0500, ofthecentury wrote:
On Sat, Mar 30, 2024 at 5:29 PM Peter N. M. Hansteen <[email protected]> wrote:
why?
I got "disassoc"s events in the log.
disassociations can happen for a number of different reasons. The event
should log a reason code, which you can look up with a simple web search.
In order to debug properly it would likely help to have ifconfig debug
output from both sides (access point and client both).
I would suspect banal radio interference by such things as improperly
shielded equipment somewhere close by, but with no actual data it's
only guesswork from here.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
