Posted: Wed May 01, 2019 17:20 Post subject: one device doesn't work with channel 11 on my routers
It would be easy to just blame the device, but a "warranty" replacement of that device also doesn't work, and that device does work on channel 11 of a laptop running as a hotspot.
I have 10 or 12 wifi devices running on my Netgear wndr3700v4 build 39230 configured NG-mixed. They all work fine on channel 11 and the several other channels I've used. Laptops, phones, IP cameras, FireTV, and several IOT devices.
Along comes this new device (mac 64:DB:A0:xx:xx:xx) and when the router is running channel 11, this device stops working right. It connects OK to the SSID on the Netgear's wifi and transmits data so I can see it with tcpdump on my main (wired-only) router. The main router sends data back to this device, but then the device acts like it doesn't receive anything. E.g., the device sends DHCP request, the router sends DHCP reply, then the router requests ARP a few times, no reply from the device is seen; then the device sends another DHCP request. So it's as if the device can transmit on 11, but can't receive. On channel 9 or 10, everything looks normal.
Replacing the device with a new one under warranty shows the same behavior. Replacing the router with a tp-link tl-wdr3600 (dd-wrt build 38159) shows the same behavior. Placing the routers and device 8 feet apart shows the same behavior. For kicks, I briefly changed the regulatory domain to allow the higher channels, just to see if some RF filter would get relaxed. Nope.
So I set up a hotspot on a Windows PC, with a 5GHz wifi connection to my Netgear router, and exposing 2.4 GHz as the hotspot. Restarting the (Windows) hotspot a few times got it to cycle through 1 and 6 and finally offer channel 11. Now the device works normally on the laptop's channel 11!
I realize the flaw in trying the two routers is that they both use the same chipset and almost the same software. The only conclusion I can think of is some kind of incompatibility between the hardware of this device and the two routers. Router configuration is a remote possibility, but all my other devices are OK with it.
Does someone with extensive wifi experience have some insight to offer suggestions? Naturally, my workaround is don't use channel 11. But sometimes channel 11 is the best available (crowded neighborhood & some are using multiple channels). _________________ dd-wrt on TP-Link Archer A7 v5
@jerrytouille : I've been waiting to hear of any build that is said to improve 2.4 wireless. I think my current build was a step down from something back in the 33000's. When I skip a lot of builds I rebuild my config. Mixed mode ok next round of experiments.
@tatsuya46 : It's selectcomfort which is a bed. U.S. product. (I gave the mac in case anyone was extremely curious.)
@Per Yngve Berg : I use HT20.
Thanks everyone for taking an interest.
Another factoid: the customer service for this company says they have some "known issue" with Comcast/xfinity. I can't get a straight story about it though. It varies from some "wifi conflict maybe with 5GHz" to something about xfinity's "X5 modem/router" to something about the xfinity network itself. I'm not using xfinity wifi at all. I called the company a while back to make them completely disable their extra invisible 5GHz signal. And when my router is on channel 11, the device doesn't make it all the way into my local network, much less xfinity's cable modem.
And I haven't been enabling my own 5GHz at all until I tried the Windows hotspot experiment, which did get the device working on channel 11.
Another factoid: my total 2.4GHz bandwidth usage is very low when I am testing channel 11, like < 20Kbps in and out. (The cameras only run when the grandbabies are sleeping.) _________________ dd-wrt on TP-Link Archer A7 v5
@jerrytouille : I switched to mixed mode as you suggested. After a while, the device did come up on channel 11.
The writeup I've found on this device suggests that it can run in 'n' mode on 2.4GHz [ "The ... system is a single–band device that requires a 2.4GHz frequency to connect. We recommend a single n–band 2.4GHz or a simultaneous dual–n band router." ]. However, it does not run on channel 11 when the router is configured as NG mixed or N-only.
In trying the Windows hotspot (as I mentioned in post #1), I don't think I could find a setting for the wireless mode for 2.4GHz, so it may well have been running in mixed mode.
Once the device has connected, is there a way I can tell what mode it connected with? Here is 'iw':
Code:
# iw dev ath0.1 station dump|more
Station 64:db:a0:xx:xx:xx (on ath0.1)
inactive time: 120 ms
rx bytes: 23750827
rx bytes compressed: 0
rx packets: 111428
rx packets compressed: 0
tx bytes: 9547185
tx bytes compressed: 0
tx packets: 99992
tx packets compressed: 0
tx retries: 5155
tx failed: 110
rx drop misc: 357
signal: -63 [-63, -77] dBm
signal avg: -62 [-62, -75] dBm
tx bitrate: 11.0 MBit/s
rx bitrate: 72.2 MBit/s MCS 7 short GI
rx duration: 6763715 us
avg ack signal: -6 dBm
expected throughput: 4.394Mbps
authorized: yes
authenticated: yes
associated: yes
preamble: short
WMM/WME: yes
MFP: no
TDLS peer: no
Compression: no
DTIM period: 2
beacon interval:101
CTS protection: yes
connected time: 28772 seconds
Radio Name:
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Sat May 04, 2019 19:49 Post subject:
bvideo wrote:
@jerrytouille : I switched to mixed mode as you suggested. After a while, the device did come up on channel 11.
The writeup I've found on this device suggests that it can run in 'n' mode on 2.4GHz [ "The ... system is a single–band device that requires a 2.4GHz frequency to connect. We recommend a single n–band 2.4GHz or a simultaneous dual–n band router." ]. However, it does not run on channel 11 when the router is configured as NG mixed or N-only.
In trying the Windows hotspot (as I mentioned in post #1), I don't think I could find a setting for the wireless mode for 2.4GHz, so it may well have been running in mixed mode.
Once the device has connected, is there a way I can tell what mode it connected with? Here is 'iw':
Code:
# iw dev ath0.1 station dump|more
Station 64:db:a0:xx:xx:xx (on ath0.1)
inactive time: 120 ms
rx bytes: 23750827
rx bytes compressed: 0
rx packets: 111428
rx packets compressed: 0
tx bytes: 9547185
tx bytes compressed: 0
tx packets: 99992
tx packets compressed: 0
tx retries: 5155
tx failed: 110
rx drop misc: 357
signal: -63 [-63, -77] dBm
signal avg: -62 [-62, -75] dBm
tx bitrate: 11.0 MBit/s
rx bitrate: 72.2 MBit/s MCS 7 short GI
rx duration: 6763715 us
avg ack signal: -6 dBm
expected throughput: 4.394Mbps
authorized: yes
authenticated: yes
associated: yes
preamble: short
WMM/WME: yes
MFP: no
TDLS peer: no
Compression: no
DTIM period: 2
beacon interval:101
CTS protection: yes
connected time: 28772 seconds
Radio Name:
its supporting N mode fine, "MCS #" means its using N, G and lower doesnt have MCS rates _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
its supporting N mode fine, "MCS #" means its using N, G and lower doesnt have MCS rates
That is very interesting if this device will never work on channel 11 when the router is set to 'NG-mixed' or 'N-only', but it will work in N-mode when the router is set to 'mixed'!! Actually, in NG-mixed mode it does connect and successfully transmit, but doesn't seem to be able to receive.
I do notice some anomalies in iw for the different stations. Some don't report MCS for both directions. (This is in 'mixed' mode.)
Code:
device under discussion:
tx bitrate: 11.0 MBit/s
rx bitrate: 72.2 MBit/s MCS 7 short GI
other devices on ath0.1:
tx bitrate: 65.0 MBit/s MCS 6 short GI
rx bitrate: 6.0 MBit/s
tx bitrate: 86.7 MBit/s MCS 12 short GI
rx bitrate: 144.4 MBit/s MCS 15 short GI
tx bitrate: 115.6 MBit/s MCS 13 short GI
rx bitrate: 78.0 MBit/s MCS 12
Does that have any significance? In particular, the bad device does not show MCS in the transmit direction, which is the direction (to the device) that I suspect is not working on channel 11.
When set to N-only on channel 9, this device works fine and shows:
Code:
tx bitrate: 65.0 MBit/s MCS 6 short GI
rx bitrate: 72.2 MBit/s MCS 7 short GI
(Is there a MCS=0 rate that is not displayed?)
P.S. I started on updating to more recent f/w, but VAP is missing recently and I need it. _________________ dd-wrt on TP-Link Archer A7 v5
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Sat May 04, 2019 21:54 Post subject:
bvideo wrote:
tatsuya46 wrote:
its supporting N mode fine, "MCS #" means its using N, G and lower doesnt have MCS rates
That is very interesting if this device will never work on channel 11 when the router is set to 'NG-mixed' or 'N-only', but it will work in N-mode when the router is set to 'mixed'!! Actually, in NG-mixed mode it does connect and successfully transmit, but doesn't seem to be able to receive.
I do notice some anomalies in iw for the different stations. Some don't report MCS for both directions. (This is in 'mixed' mode.)
Code:
device under discussion:
tx bitrate: 11.0 MBit/s
rx bitrate: 72.2 MBit/s MCS 7 short GI
other devices on ath0.1:
tx bitrate: 65.0 MBit/s MCS 6 short GI
rx bitrate: 6.0 MBit/s
tx bitrate: 86.7 MBit/s MCS 12 short GI
rx bitrate: 144.4 MBit/s MCS 15 short GI
tx bitrate: 115.6 MBit/s MCS 13 short GI
rx bitrate: 78.0 MBit/s MCS 12
Does that have any significance? In particular, the bad device does not show MCS in the transmit direction, which is the direction (to the device) that I suspect is not working on channel 11.
When set to N-only on channel 9, this device works fine and shows:
Code:
tx bitrate: 65.0 MBit/s MCS 6 short GI
rx bitrate: 72.2 MBit/s MCS 7 short GI
(Is there a MCS=0 rate that is not displayed?)
P.S. I started on updating to more recent f/w, but VAP is missing recently and I need it.
when idle, most devices utilize rate reduction power save. or if signal is too weak fall back to non mcs rates is automatic. longs as at least one direction is using MCS, its in N mode.
the radio in the device could have some poorly made drivers, demanding some or all B rates as basic rates (means they are mandatory), even if they are unused as its an N device..
try setting ng-mixed on the radio the device uses, go to wifi security page, under the interface u will see a large box named custom config, try putting these in and applying settings.
basic_rates=60
to go back to default ng-mixed, remove it and apply again _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
when idle, most devices utilize rate reduction power save. or if signal is too weak fall back to non mcs rates is automatic. longs as at least one direction is using MCS, its in N mode.
the radio in the device could have some poorly made drivers, demanding some or all B rates as basic rates (means they are mandatory), even if they are unused as its an N device..
try setting ng-mixed on the radio the device uses, go to wifi security page, under the interface u will see a large box named custom config, try putting these in and applying settings.
basic_rates=60
to go back to default ng-mixed, remove it and apply again
Thanks for your help and all that info. In ng-mixed mode I put the basic_rates=60 in the custom config under ath0.1. Then went back to wireless->basic settings and I think you meant switch to some other mode and apply then back to ng-mixed and apply. Also I restarted the device.
As before, I see the following repeated endlessly (tcpdump on the main router):
Code:
IP device -> router DHCP request
IP router -> device DHCP reply w/IP assignment etc.
[3 times:]
ARP router -> broadcast who has that IP? tell router
[pause]
So again, tx from the device can be received, but tx from the router apparently doesn't get to the device.
Code:
# iw dev ath0.1 station dump
...
Station 64:db:a0:..... (on ath0.1)
inactive time: 8010 ms
rx bytes: 21977
rx bytes compressed: 0
rx packets: 216
rx packets compressed: 0
tx bytes: 35030
tx bytes compressed: 0
tx packets: 355
tx packets compressed: 0
tx retries: 957
tx failed: 189
rx drop misc: 0
signal: -62 [-62, -80] dBm
signal avg: -58 [-58, -75] dBm
tx bitrate: 6.5 MBit/s MCS 0
rx bitrate: 72.2 MBit/s MCS 7 short GI
rx duration: 5220 us
avg ack signal: -106 dBm
authorized: yes
authenticated: yes
associated: yes
preamble: short
WMM/WME: yes
MFP: no
TDLS peer: no
Compression: no
DTIM period: 2
beacon interval:101
CTS protection: yes
connected time: 1012 seconds
Radio Name:
(A lot of tx retries and tx failed)
Sampling the bitrates for that device a few more times I got:
Code:
(once)
tx bitrate: 43.3 MBit/s MCS 4 short GI
rx bitrate: 72.2 MBit/s MCS 7 short GI
(usually)
tx bitrate: 6.5 MBit/s MCS 0
rx bitrate: 72.2 MBit/s MCS 7 short GI
(once)
tx bitrate: 26.0 MBit/s MCS 3
rx bitrate: 72.2 MBit/s MCS 7 short GI
P.S. Builds 39654 and 39715 don't have VAP on the tp-link 3600 I am using to try out f/w changes. And build 39572 crashes hard and needs complete reset after I put in 60% of the config. _________________ dd-wrt on TP-Link Archer A7 v5
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Sun May 05, 2019 2:26 Post subject:
try disabling short preamble, and what is the ack timing set to? if that router has wpa3 as an option, and management frame protection, make sure they are disabled. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
try disabling short preamble, and what is the ack timing set to? if that router has wpa3 as an option, and management frame protection, make sure they are disabled.
OK. No change when disabling short preamble.
Ack timing is 450, but I've tried 2000.
wpa3 & mgmt frame protection have not been enabled. _________________ dd-wrt on TP-Link Archer A7 v5
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Sun May 05, 2019 4:37 Post subject:
does the device have a firmware or any update option? make sure its on the latest, if it does. also try enabling multicast to unicast setting on the interface it connects to _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers