[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #20 from J.R. Oldroyd --- (In reply to Jaskie from comment #19) The dmesg for the 13.1 boot does not show the "[ath_hal] loaded" message. Was the message removed in 13.1 or does this indicate that the hal is not loaded? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #21 from Jaskie --- (In reply to J.R. Oldroyd from comment #20) It was directly from dmesg output, I didn't modify anythong. If it's not there then it should mean it was not loaded during bootup. I'll check again tonight when I am around my laptop. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #22 from J.R. Oldroyd --- (In reply to Jaskie from comment #21) I see in the git log that the ath_hal message was removed and now only shown during a verbose boot. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #23 from Jaskie --- (In reply to J.R. Oldroyd from comment #22) Do I kldstat to check that or do I have to get dmesg again from a verbose boot? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #24 from J.R. Oldroyd --- (In reply to Jaskie from comment #23) If you want to verify, you'd have to do a verbose boot. But you have already told us that the 13.1 kernel works with the 13.0 userland, so not really necessary. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
Re: [Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
Hello, On Fri, 03 Jun 2022 09:31:41 + bugzilla-nore...@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 > > --- Comment #24 from J.R. Oldroyd --- > (In reply to Jaskie from comment #23) > > If you want to verify, you'd have to do a verbose boot. But you have already > told us that the 13.1 kernel works with the 13.0 userland, so not really > necessary. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug. Fixed by https://cgit.freebsd.org/ports/commit/?id=3023881d2e9b0f07aeca701e99caed5039206e06 Cheers, -- Emmanuel Vadot
Re: [Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
On Fri, 3 Jun 2022 15:58:56 +0200 Emmanuel Vadot wrote: > > Hello, > > On Fri, 03 Jun 2022 09:31:41 + > bugzilla-nore...@freebsd.org wrote: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 > > > > --- Comment #24 from J.R. Oldroyd --- > > (In reply to Jaskie from comment #23) > > > > If you want to verify, you'd have to do a verbose boot. But you have > > already > > told us that the 13.1 kernel works with the 13.0 userland, so not really > > necessary. > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > You are the assignee for the bug. > > Fixed by > https://cgit.freebsd.org/ports/commit/?id=3023881d2e9b0f07aeca701e99caed5039206e06 > > Cheers, Sorry, replied to the wrong mail :P -- Emmanuel Vadot
Re: [Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
On Fri, 3 Jun 2022, Emmanuel Vadot wrote: Hi, On Fri, 03 Jun 2022 09:31:41 + bugzilla-nore...@freebsd.org wrote: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #24 from J.R. Oldroyd --- (In reply to Jaskie from comment #23) If you want to verify, you'd have to do a verbose boot. But you have already told us that the 13.1 kernel works with the 13.0 userland, so not really necessary. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. Fixed by https://cgit.freebsd.org/ports/commit/?id=3023881d2e9b0f07aeca701e99caed5039206e06 Are you on the correct thread? -- Bjoern A. Zeeb r15:7
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238
--- Comment #25 from Jaskie ---
I did this steps in both 13.0 and 13.1:
% doas service netif stop wlan0
% doas mv /var/db/dhclient.leases.wlan0{,.bak}
% doas service netif start wlan0
% doas tcpdump -i wlan0 -w OUT.bpf -s 0
% doas ifconfig wlan0
% doas dhclient wlan0
In 13.0, network connects almost instantly. But in 13.1 it still won't connect.
Output similiar to:
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
as before.
I checked rc.conf, wpa_supplicant.conf and they're identical in both BEs. I
checked dmesg in both BEs and ath_hal was loaded, didn't know why it was not in
the file I uploaded earlier.
To use wireshark or to dig into the tcpducp outputs are beyond my capability so
I'll leave it to you as always. Thanks for all your help!
Anyways, this are the tcpdump bpf files: https://tempsend.com/skhrg
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 Bjoern A. Zeeb changed: What|Removed |Added Status|New |Open --- Comment #27 from Bjoern A. Zeeb --- In the 13.1 not-working case I see incoming TCP packets from the AP despite you not having an IP address (assumed) given DHCP discover did not get a reply. There's also incoming ARP announcement from the AP-side; that somehow means the "network" knows where to find you (with your old IP address)? Given I have no insight in how complex this network is (is it just a residential router with builtin WiFi or more components) it is hard to say where to start looking. You should probably wait at least an ARP expiry timeout before running the 2nd test. The other interesting bit would be: ifconfig wlan0 inet6 -ifdisabled accept_rtadv ping6 -n ff02::1%wlan0 ping6 -n ff02::2%wlan0 and see if you get replies in the non-working IPv4 case given there seems to be at least IPv6 link-local available on the RuiJieNe node. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #26 from Bjoern A. Zeeb --- (In reply to Jaskie from comment #25) when looking at the first dicover packets between 13.0 and 13.1 I see no obvious differences: % diff -up dhcp-discover-13.*.txt --- dhcp-discover-13.0.txt 2022-06-03 16:28:38.732111000 + +++ dhcp-discover-13.1.txt 2022-06-03 16:28:11.892156000 + @@ -1,15 +1,15 @@ No. Time SourceDestinati No. Time SourceDestination Protocol Length Info - 3 17.487743 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x2770ff8c + 2 9.494708 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0xe104ecd1 -Frame 3: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) +Frame 2: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) Encapsulation type: Ethernet (1) -Arrival Time: Jun 3, 2022 22:39:04.119281000 UTC +Arrival Time: Jun 3, 2022 22:48:38.443883000 UTC [Time shift for this packet: 0.0 seconds] -Epoch Time: 1654295944.119281000 seconds -[Time delta from previous captured frame: 17.48721 seconds] -[Time delta from previous displayed frame: 17.48721 seconds] -[Time since reference or first frame: 17.487743000 seconds] -Frame Number: 3 +Epoch Time: 1654296518.443883000 seconds +[Time delta from previous captured frame: 9.494708000 seconds] +[Time delta from previous displayed frame: 9.494708000 seconds] +[Time since reference or first frame: 9.494708000 seconds] +Frame Number: 2 Frame Length: 342 bytes (2736 bits) Capture Length: 342 bytes (2736 bits) [Frame is marked: True] @@ -50,7 +50,7 @@ User Datagram Protocol, Src Port: 68, Dst Port: 67 Source Port: 68 Destination Port: 67 Length: 308 -Checksum: 0x034c [unverified] +Checksum: 0x5c72 [unverified] [Checksum Status: Unverified] [Stream index: 0] [Timestamps] @@ -62,7 +62,7 @@ Dynamic Host Configuration Protocol (Discover) Hardware type: Ethernet (0x01) Hardware address length: 6 Hops: 0 -Transaction ID: 0x2770ff8c +Transaction ID: 0xe104ecd1 Seconds elapsed: 0 Bootp flags: 0x (Unicast) 0... = Broadcast flag: Unicast @@ -104,8 +104,8 @@ Dynamic Host Configuration Protocol (Discover) ff ff ff ff ff ff 1c 4b d6 ca 3e ac 08 00 45 10 ...K..>...E. 0010 01 48 00 00 00 00 80 11 39 96 00 00 00 00 ff ff .H..9... -0020 ff ff 00 44 00 43 01 34 03 4c 01 01 06 00 27 70 ...D.C.4.L'p -0030 ff 8c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +0020 ff ff 00 44 00 43 01 34 5c 72 01 01 06 00 e1 04 ...D.C.4\r.. +0030 ec d1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 00 00 00 00 00 00 1c 4b d6 ca 3e ac 00 00 00 00 ...K..>. 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 more in the next reply -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
Intel iwlwifi and Realtek rtw88 all MFCed to stable/13
Hi,
thanks to everyone who tried out things on main or manually
cherry-picked changes to stable/13 to try there and has sent me public
or private feedback while I was on the road!
If I am not mistaken (it seems some cluster parts are currently
undergoing maintanance) I merged all outstanding changes to stable/13.
That means:
- Intel iwlwifi driver and firmware update (given I have not heard any
worse to the version before from people on main),
- Realtek rtw88 driver (requiring the tunable set for more than 4GB of
main memory; see `man 4 rtw88`),
- net80211 changes,
- LinuxKPI 802.11 and other changes.
If you are tracking stable/13 now is the time to give this a try
without the need to do any manual cherry-picking.
The only outstanding changes I am aware off are the iwlwifi{,fw}.4 man
page updates and the related sysctl I comitted earlier which are
non-functional for users and will be MFCed early next week.
None of this will show up in 13.1-RELEASE as Errata Notice at any time
unless we find the cause for other issues and then it'll be beyond me
to make this judgement call so please do not ask me.
I have also updated the wiki pages:
https://wiki.freebsd.org/WiFi/Iwlwifi for Intel iwlwifi
and
https://wiki.freebsd.org/WiFi/Rtw88 for the Realtek rtw88 driver
for more information.
As usual thanks for all the good things should go to the FreeBSD Foundation,
bug and problem reports are on me.
Happy weekend and lots of joy,
Bjoern
--
Bjoern A. Zeeb r15:7
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #28 from J.R. Oldroyd --- The ARPs from the router are almost certainly due to the previous good 13.0 boot. I also see (using tcpdump and tshark) that the DHCPDISCOVER datagrams are the same between the 13.0 and 13.1 files. If you send a server the same request, it should respond the same way. The fact that, on 13.1, no response is received, has to indicate that the outbound DISCOVER was blocked and so the DHCP server didn't receive the request, or that it did, but the response OFFER was blocked. I suggested in email that it's firewall or something on the host that is different between 13.0 and 13.1 and blocking the traffic. But Jackie confirms that the rc.conf is the same. A DHCP server will (should) respond to repeated requests from the same host even before the lease renewal time. You can test this by booting the working 13.0, obtaining the DHCP lease, killing dhclient, removing the lease file and starting dhclient again. You'll get a new lease immediately for sure. (But, if you don't, that would point at the problem.) ARP problem? Unlikely I think, because it is the same host computer using the same MAC address talking to the same server. You can use "arp -d" to clear ARP entries on the host. If the ARP entry on the router is the problem, you'll have to wait. Cisco routers use a 4 hour cache time, I believe. Configure it for the 13.1 env, turn off, wait. After the time, boot straight into 13.1 env without booting 13.0 first. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #29 from J.R. Oldroyd --- The other obvious thing to check is, is the network working when configured manually? Use the same values you get from the 13.0 boot for the IP and router. Then boot under 13.1 and configure manually: ifconfig wlan0 10.134.138.51 netmask 255.255.128.0 route add default 10.134.255.254 Can you ping out? Can you ping the router? Can you ping anything beyond the router? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264238] WiFi stops working after upgrade from 13.0 to 13.1, AR9285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264238 --- Comment #30 from Jaskie --- I followed all your suggestions and did the tests below with a fresh biot 13.1, dhclient cache was removed beforehand: # ifconfig wlan0 10.134.138.51 netmask 255.255.128.0 # route add default 10.134.255.254 # ping bing.com ping: Unknown host # ifconfig wlan0 inet6 -ifdisabled accept_rtadv # ping6 -n ff02::1%wlan0 PING6(56=40+8+8 bytes) fe80::1e4b:d6ff:feca:3eac%wlan0 --> ff02::1%wlan0 ping6: sendmsg: No buffer space available ping6: wrote ff02::1%wlan0 16 chars, ret=-1 16 bytes from fe80::1e4b:d6ff:feca:3eac%wlan0, icmp_seq=0 hlim=64 time=0.162 ms ping6: sendmsg: No buffer space available ping6: wrote ff02::1%wlan0 16 chars, ret=-1 16 bytes from fe80::1e4b:d6ff:feca:3eac%wlan0, icmp_seq=1 hlim=64 time=0.074 ms ping6: sendmsg: No buffer space available ping6: wrote ff02::1%wlan0 16 chars, ret=-1 16 bytes from fe80::1e4b:d6ff:feca:3eac%wlan0, icmp_seq=2 hlim=64 time=0.104 ms ping6: sendmsg: No buffer space available ping6: wrote ff02::1%wlan0 16 chars, ret=-1 16 bytes from fe80::1e4b:d6ff:feca:3eac%wlan0, icmp_seq=3 hlim=64 time=0.097 ms ping6: sendmsg: No buffer space available ping6: wrote ff02::1%wlan0 16 chars, ret=-1 16 bytes from fe80::1e4b:d6ff:feca:3eac%wlan0, icmp_seq=4 hlim=64 time=0.100 ms ping6: sendmsg: No buffer space available ping6: wrote ff02::1%wlan0 16 chars, ret=-1 16 bytes from fe80::1e4b:d6ff:feca:3eac%wlan0, icmp_seq=5 hlim=64 time=0.076 ms ^C --- ff02::1%wlan0 ping6 statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.074/0.102/0.162/0.029 ms # ping6 -n ff02::2%wlan0 PING6(56=40+8+8 bytes) fe80::1e4b:d6ff:feca:3eac%wlan0 --> ff02::2%wlan0 ping6: sendmsg: No buffer space available ping6: wrote ff02::2%wlan0 16 chars, ret=-1 ping6: sendmsg: No buffer space available ping6: wrote ff02::2%wlan0 16 chars, ret=-1 ping6: sendmsg: No buffer space available ping6: wrote ff02::2%wlan0 16 chars, ret=-1 ping6: sendmsg: No buffer space available ping6: wrote ff02::2%wlan0 16 chars, ret=-1 ping6: sendmsg: No buffer space available ping6: wrote ff02::2%wlan0 16 chars, ret=-1 ping6: sendmsg: No buffer space available ping6: wrote ff02::2%wlan0 16 chars, ret=-1 ^C --- ff02::2%wlan0 ping6 statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss # ping -c 3 10.134.138.51 @9:07 PING 10.134.138.51 (10.134.138.51): 56 data bytes 64 bytes from 10.134.138.51: icmp_seq=0 ttl=64 time=0.058 ms 64 bytes from 10.134.138.51: icmp_seq=1 ttl=64 time=0.039 ms 64 bytes from 10.134.138.51: icmp_seq=2 ttl=64 time=0.047 ms --- 10.134.138.51 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.039/0.048/0.058/0.008 ms # ping -c 3 255.255.128.0 @9:07 PING 255.255.128.0 (255.255.128.0): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ^C --- 255.255.128.0 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # ping -c 3 10.134.255.254 @9:07 PING 10.134.255.254 (10.134.255.254): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available --- 10.134.255.254 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # ping 1.1.1.1
