Open jeffsilverm opened 2 weeks ago
ctsdownloads
commented
5 days ago Ah ha! I was bound to miss a use case scenario. Appreciate it. Confirming, there are two network interfaces on this unit? You title "The WiFi diagnostic does not work if there is another operational network interface" indicated there may be? Ethernet? I can adapt the script accordingly, but just wanted to clarify.
Appreciate it. :)
jeffsilverm
commented
4 days ago Don't feel bad. I'll bet that it never occurred to the guys who designed the 737 MAX that the angle of attack sensors would fail. That oversight led to the deaths of 384 people. Funny, sometimes, how the real world breaks our software.
In my case, the WiFi is broken. I have a USB to Ethernet adapter that looks like an Ethernet and that is working. The WiFi looks like a WiFi in a place where is no WiFi, none at all. It thinks it's working, but it isn't. So it depends on your definition of "operational". The WiFi think it is working, but because the RF side is broken, it isn't/
One way to test the WiFi is to run the iw dev wlp2s0 scan | fgrep SSID: command. If it sees 2 or more SSIDs, then the WiFi is probably working. Similarly, if the ip --stats link list command shows that the counters are incrementing in, say, 10 seconds, then the Ethernet is probably good. The ip link list command will also tell you if the NIC sees a carrier.
I hope this answers your question. I'd love to beta test it for you.
Jeff
On Thu, Oct 31, 2024 at 6:26 PM Matt Hartley @.***> wrote:
Ah ha! I was bound to miss a use case scenario. Appreciate it. Confirming, there are two network interfaces on this unit? You title "The WiFi diagnostic does not work if there is another operational network interface" indicated there may be? Ethernet? I can adapt the script accordingly, but just wanted to clarify.
Appreciate it. :)
— Reply to this email directly, view it on GitHub https://github.com/FrameworkComputer/linux-docs/issues/41#issuecomment-2451122023, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEGDBYRZD3H5SPA4XG2L7DZ6LKEZAVCNFSM6AAAAABQIKVT76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJRGEZDEMBSGM . You are receiving this because you authored the thread.Message ID: @.***>
My WiFi controller is dead. I am fairly confident that this is so:
jeffs@frmwrk16:~/nbmdt$ ip --stats link show dev wlp1s0 3: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DORMANT group default qlen 1000 link/ether fc:b0:de:18:10:61 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 0 0 0 jeffs@frmwrk16:~/nbmdt$Framework customer suggested I run the WiFi diagnostic tool to see what happens. Why not? Nothing else I've tried has fixed or even identified the problem. So I ran it.Integrated Wi-Fi Diagnostic Script
I thought that maybe the pings and other things were going in and out the ethernet. Since my WiFi is dead, I have a kludged an Ethernet connection. So I pulled the plug on the USB and tried again.
Please do not feel bad about this. I am working on a network boot monitor and diagnostic tool (https://github.com/jeffsilverm/nbmdt) (except I haven't made a commit in 5 years) and it would have the same flaw that your scripts have. So this has been a teachable moment for me. Thank you from the bottom of my heart.
The solution for the ping command is to use the -I option to the ping command. For the other tests, verify that the WiFi interface is working, and then and only then disable the other interface(s). Use the trap bash command to catch any errors and enable the other interface(s).