4 ms·

This is a good insight, especially the diagram at the top. But the quesion for me is, why is a router broken say 10% of the time? I think the problem is that W

This is a good insight, especially the diagram at the top. But the quesion for me is, why is a router broken say 10% of the time? I think the problem is that WiFi is totally undebuggable. When it doesn't work, you don't see at which stage it doesn't work. - Do the frames in the air get corrupted or dropped? What portion of frames makes it through? - I see the SSID, so it can transmit something. Why can't I connect and get at least a slow connection? - What is it doing now, sending, waiting for a response, did it negotiate encryption yet? - Is the low-level connection OK, and we have a problem with DHCP? This you can detect, but the OS obscures it from you. - There is no easy way to see signal strength. You get a more or less meaningful number reported from the card, but these nice diagrams showing signal strength over frequency? Mostly fake, this is just the reported signal strength of each channel, smoothed out to look like a continuous scan. If we had a continuous scan, we could see individual sources of interference better. - Why does the connection suddenly drop out or get slow? Is the problem on my side of the router, or on the internet side? Are buffers full/empty? Is some object standing in the way, or is is a weather phenomenon? You can ping your router or modem, and some routers have nice tools to let you see graphs of upstream and downstream. But there is no coherent debugging solution.

nisa 9y ago
> why is a router broken say 10% of the time? My guess would be that WiFi drivers are kind of quirky - if you follow OpenWRT/LEDE development there a lot of issues that appear only on heavy load or under certain situations - causes range from driver bugs / chip bugs / firmware bugs - most of the stuff is NDA or closed source. You've got the problem on both sides - especially the situation on Linux is still dire for lot's of chipsets. Even my years old intel card in my notebook does not really work well with Linux und the current kernel/firmware. I blame the vendors. > Do the frames in the air get corrupted or dropped? What portion of frames makes it through? That also depends on the rate and encoding that the frames are sent. Then there is stuff like frame aggretation that sometimes work sometimes not. > I see the SSID, so it can transmit something. Why can't I connect and get at least a slow connection? SSID is send with the lowest rate (1Mbit) and with the most solid encoding - usally the transmit power and antenna sensitivity is also the strongest on the lowest rate so the SSID can be seen quite far away - often so far away that your clients wifi is able to receive the SSID beacons but unable to send something back that reaches the router. > What is it doing now, sending, waiting for a response, did it negotiate encryption yet? Wrong crypto results in no association - difficult to tell apart from low signal. > Is the low-level connection OK, and we have a problem with DHCP? This you can detect, but the OS obscures it from you. Yes. You can look at network-manager logs from Linux but sometimes it's difficult to tell - especially on Windows. > There is no easy way to see signal strength. There is also noise, antenna properties and everything depends on the rate and encoding used - it's not exactly easy. > Why does the connection suddenly drop out or get slow? Add also the rate control algorithms, the amount of clients, for certain 5GHz channels you have to obey radar then there is interference with bluetooth and microwaves. Also all that funky physics stuff with reflection and antenna positioning where moving a little bit might be just enough to cause problems for you.
- captainmuon 9y ago
  > SSID is send with the lowest rate (1Mbit) and with the most solid encoding - usally the transmit power and antenna sensitivity is also the strongest on the lowest rate so the SSID can be seen quite far away - often so far away that your clients wifi is able to receive the SSID beacons but unable to send something back that reaches the router. Thats what I mean. It would be great if you could click "debug", and it says "Receiving beacons from router, but router is not responding to frames". Maybe it would even be smart enough to do a back-of-the-envelope calculation if details about the router are known, e.g. router transmits with X watt, the recieved signal strength is Y. I can transmit with Z watt, so the router should / should not be able to hear me. Then it could suggest "You have to move closer to the router, use a better antenna, or increase power to the antenna (reduces battery life)". Nowadays you don't get anything, not even an error message. It silently stops connecting on most platforms, and the WiFi symbol slightly changes.
Kurtz79 9y ago
Wouldn't you be able to debug some of these issues using a packet sniffer ? http://www.networkcomputing.com/networking/wifi-troubleshooting-using-wireshark/1555390832 http://www.networkcomputing.com/networking/wifi-troubleshoot...
- zwieback 9y ago
  Yes, all the stuff mentioned is totally debuggable, done it many times, but it takes time to sift through the packets.
Pxtl 9y ago
This. It's incredibly frustrating on my phone to see 40 seconds of "Requesting IP address..." and then it goes back to "Connecting...". WTF was that? DHCP is the easy part!
- jrockway 9y ago
  If the packets get through, DHCP is easy. If packets are being lost, not so easy.
pixl97 9y ago
>But the quesion for me is, why is a router broken say 10% of the time? From a lot of experience, I see these issues. All in one router/wireless/NAT/switch units: Doing too much at the lowest price. The fact wi-fi has stopped working is really secondary to some memory leak in the system eating up resources causing problems with the entire unit. Solution: Separate switching, routing, and wireless access point capability. Reliability goes up (unless you buy really terrible equipment), each individual system has less responsibilities and less potential bug interaction. Access points: Wireless has the problem of trying to be everything to everyone. Just look at how many different wireless protocols are enabled at one time by default. G, N, A, AC, likely over 2 different spectrums. Individually this are complex protocols, all together it leads to stuff breaking. Even worse you're dealing with exceptionally secretive vendors (Yes, that means you Broadcom), so getting good chip information is hard. Solution: Enable only one standard and then only use one client chipset in all your clients (heh, pretty much impossible). Wireless itself: The first rule of wireless is, the less wireless you have, the better. I have clients that can pick up between 30 and 50 access points at any given time. Needless to say, wireless is useless for them. Other non wi-fi devices on the same spectrum pretty much ruin reliable transfers. Also people blasting their wireless power and over coverage. This is where I would say the article is wrong. More AP units are better, as long as there is as little overlap as possible between stations. 3 small station areas will work better than one large area with random dead spots and long distances between clients (hidden node problem). Power: Many routers/AP have crappy power input. Swapping out their power brick with something more reliable helps often, unless they have crappy caps on board.
tajen 9y ago
- Is it the DNS? 90% of my wifi problems at work and in hotels are solved with DNS 8.8.8.8., which is sad because clients have full access to internet, except it doesn't work.

nisa 9y ago

> why is a router broken say 10% of the time? My guess would be that WiFi drivers are kind of quirky - if you follow OpenWRT/LEDE development there a lot of issues that appear only on heavy load or under certain situations - causes range from driver bugs / chip bugs / firmware bugs - most of the stuff is NDA or closed source. You've got the problem on both sides - especially the situation on Linux is still dire for lot's of chipsets. Even my years old intel card in my notebook does not really work well with Linux und the current kernel/firmware. I blame the vendors. > Do the frames in the air get corrupted or dropped? What portion of frames makes it through? That also depends on the rate and encoding that the frames are sent. Then there is stuff like frame aggretation that sometimes work sometimes not. > I see the SSID, so it can transmit something. Why can't I connect and get at least a slow connection? SSID is send with the lowest rate (1Mbit) and with the most solid encoding - usally the transmit power and antenna sensitivity is also the strongest on the lowest rate so the SSID can be seen quite far away - often so far away that your clients wifi is able to receive the SSID beacons but unable to send something back that reaches the router. > What is it doing now, sending, waiting for a response, did it negotiate encryption yet? Wrong crypto results in no association - difficult to tell apart from low signal. > Is the low-level connection OK, and we have a problem with DHCP? This you can detect, but the OS obscures it from you. Yes. You can look at network-manager logs from Linux but sometimes it's difficult to tell - especially on Windows. > There is no easy way to see signal strength. There is also noise, antenna properties and everything depends on the rate and encoding used - it's not exactly easy. > Why does the connection suddenly drop out or get slow? Add also the rate control algorithms, the amount of clients, for certain 5GHz channels you have to obey radar then there is interference with bluetooth and microwaves. Also all that funky physics stuff with reflection and antenna positioning where moving a little bit might be just enough to cause problems for you.

captainmuon 9y ago
> SSID is send with the lowest rate (1Mbit) and with the most solid encoding - usally the transmit power and antenna sensitivity is also the strongest on the lowest rate so the SSID can be seen quite far away - often so far away that your clients wifi is able to receive the SSID beacons but unable to send something back that reaches the router. Thats what I mean. It would be great if you could click "debug", and it says "Receiving beacons from router, but router is not responding to frames". Maybe it would even be smart enough to do a back-of-the-envelope calculation if details about the router are known, e.g. router transmits with X watt, the recieved signal strength is Y. I can transmit with Z watt, so the router should / should not be able to hear me. Then it could suggest "You have to move closer to the router, use a better antenna, or increase power to the antenna (reduces battery life)". Nowadays you don't get anything, not even an error message. It silently stops connecting on most platforms, and the WiFi symbol slightly changes.

Kurtz79 9y ago

Wouldn't you be able to debug some of these issues using a packet sniffer ? http://www.networkcomputing.com/networking/wifi-troubleshooting-using-wireshark/1555390832 http://www.networkcomputing.com/networking/wifi-troubleshoot...

zwieback 9y ago
Yes, all the stuff mentioned is totally debuggable, done it many times, but it takes time to sift through the packets.

Pxtl 9y ago

This. It's incredibly frustrating on my phone to see 40 seconds of "Requesting IP address..." and then it goes back to "Connecting...". WTF was that? DHCP is the easy part!

jrockway 9y ago
If the packets get through, DHCP is easy. If packets are being lost, not so easy.

pixl97 9y ago

>But the quesion for me is, why is a router broken say 10% of the time? From a lot of experience, I see these issues. All in one router/wireless/NAT/switch units: Doing too much at the lowest price. The fact wi-fi has stopped working is really secondary to some memory leak in the system eating up resources causing problems with the entire unit. Solution: Separate switching, routing, and wireless access point capability. Reliability goes up (unless you buy really terrible equipment), each individual system has less responsibilities and less potential bug interaction. Access points: Wireless has the problem of trying to be everything to everyone. Just look at how many different wireless protocols are enabled at one time by default. G, N, A, AC, likely over 2 different spectrums. Individually this are complex protocols, all together it leads to stuff breaking. Even worse you're dealing with exceptionally secretive vendors (Yes, that means you Broadcom), so getting good chip information is hard. Solution: Enable only one standard and then only use one client chipset in all your clients (heh, pretty much impossible). Wireless itself: The first rule of wireless is, the less wireless you have, the better. I have clients that can pick up between 30 and 50 access points at any given time. Needless to say, wireless is useless for them. Other non wi-fi devices on the same spectrum pretty much ruin reliable transfers. Also people blasting their wireless power and over coverage. This is where I would say the article is wrong. More AP units are better, as long as there is as little overlap as possible between stations. 3 small station areas will work better than one large area with random dead spots and long distances between clients (hidden node problem). Power: Many routers/AP have crappy power input. Swapping out their power brick with something more reliable helps often, unless they have crappy caps on board.

tajen 9y ago

- Is it the DNS? 90% of my wifi problems at work and in hotels are solved with DNS 8.8.8.8., which is sad because clients have full access to internet, except it doesn't work.