5Ghz goes down

[sfx2000]

Sado that I am, I have been sitting watching what is happening with the Merlin Wireless Network Log in one browser window and the System Log in another and actually it's as clear as day what happens:

- iPad joins 5Ghz network and asks for an IP. Rx/Tx rate is high, say 650/650.
- After about 30-40 secs it drops to 7/650.
- After about another 30-40 secs the iPad vanishes from the 5Ghz network
- 1-2mins later the iPad rejoins and the cycle repeats.

Same SSID or two different SSID's?

Tough problem to debug, and I'm not about to go and spend 300 dollars to pick up an 87U...

There's a few fields in the Beacon's that can define some client behavior, and capturing some wireless packets would go a long way towards trying to solve it. Apple has generally used Broadcom in their iDevices (there's a couple of Marvell designs from many years ago), but all of their recent stuff...

What I can say so far, reviewing threads, is that the 87U seems be to more suspectable to this problem than the 68U or AC3200 - and the key difference is the QTN radio in the 87U...

What I do know is that iDevices will respond to many RM Capability fields in the HT/VHT section of the beacon, like channel reporting, neighbor reporting, etc... and Asus enables a lot of items in the beacon that other vendors don't - anyways, many of those reports are returned as a probe frame from the device back to the serving AP - and this likely is where the problem is, but again, without an 87U (and even if I had one, not clear how deep one can go into the QTN code/logs for that radio to sort it).

 

[Jong]

Same SSID. But the more I think about it the more we need to wait for new firmware from Asus/Quantenna to fix the iDevice disconnection/multiple DHCP requests. I'm not convinced that has anything to do with the 5Ghz crashes that are the subject of this thread. For the OP I think we may have to think some more on this:

Interesting I have discovered that I always get 2 of these BootP messages in the log when I restart my ac87u AP. So, it's possible that none of them are coming from the router, but instead from my AP, or both the AP and the Router can generate them?? No doubt however, that when they appear endlessly the 5Ghz radio on the router (not AP) falls over.

All having this problem, no chance we all have APs as well as routers is there? Probably not, but it might be another pointer to the problem.

The MAC address is registered to Quantenna, so it seems maybe, just maybe the Quantennna on the AP might be tripping up the chip on the router?? I have not seen another 5Ghz crash since I updated my AP to the same version of Merlin (previously it was on ASUSWRT 378.4950). Too early to say really, but maybe having an AP on one firmware and the router on another is not ideal??

RMerlin may look at all this and laugh! We are groping around in the dark here it is true. But slowly we may be building a picture of what causes these BOOTP messages and how the 5Ghz crash is caused.

 

[sfx2000]

Same SSID. But the more I think about it the more we need to wait for new firmware from Asus/Quantenna to fix the iDevice disconnection/multiple DHCP requests. I'm not convinced that has anything to do with the 5Ghz crashes that are the subject of this thread. For the OP I think we may have to think some more on this:

I would agree... likely the fix will have to come from QTN directly, as the RF/Baseband/SoC is kind of a walled garden that the Asus firmware sends commands to...

Keeping in mind that the 87U is essentially two AP's in one (the Broadcom Router/AP) and a loosely coupled QTN AP - the BOOTP message you're seeing in the logs is the QTN trying to obtain an internal IP for the management interface on it, and also for network layer transport to the Broadcom via the RGMII interface (which is basically ethernet without the cable)

So seeing many BOOTP messages from the QTN means either it's crashing and rebooting, or there is a watchdog process on the QTN that is causing it to try to recover from some kind of unhandled exception...

 

[Jong]

....As I understand it the Quantenna effectively sits like an AP on the network, routing though the main "router" part of the ac87. Not sure how this works when you also have an ac87 AP? I think from the single "kernel: br0: port 1(vlan1) neighbor 8000.38:2c:4a:ab:51:58 lost" message I see when I reboot the AP that the ac87 AP shows one interface to the router with the 2.4Ghz radio MAC address, but it routes the 5Ghz network over it. But it seems the 5Ghz chip of the AP is still actually is visible in some way to the router (those BOOTP messages). Confusing!

When I reboot the AP I see just 2 clean BOOTP messages in the router log. Nothing to worry about. But I hoonestly don't know now whether the stream of BOOTP messages when the radio falls over is from the AP or router! You never normally see BOOTP messages when the router is rebooted, only when the AP is. Is there a chance these 2 quantenna chips sometimes confuse the router?

 

[sfx2000]

....As I understand it the Quantenna effectively sits like an AP on the network, routing though the main "router" part of the ac87. Not sure how this works when you also have an ac87 AP? I think from the single "kernel: br0: port 1(vlan1) neighbor 8000.38:2c:4a:ab:51:58 lost" message I see when I reboot the AP that the ac87 AP shows one interface to the router with the 2.4Ghz radio MAC address, but it routes the 5Ghz network over it. But it seems the 5Ghz chip still actually is visible in some way to the router (those BOOTP messages). Confusing!

If the 87U is in AP mode, then you have two AP's - the Broadcom for 2.4GHz and the QTN for 5GHz - depending on which LAN port (assuming your connected via ethernet), one will bridge to the other...

IIRC the QTN is attached directly to LAN1, whereas BRCM controls the WAN and LAN ports 2-4

 

[Jong]

If the 87U is in AP mode, then you have two AP's - the Broadcom for 2.4GHz and the QTN for 5GHz - depending on which LAN port (assuming your connected via ethernet), one will bridge to the other...

IIRC the QTN is attached directly to LAN1, whereas BRCM controls the WAN and LAN ports 2-4

The router, as you see in my last post, only seems to report the loss of one network when the AP is rebooted. So it seems the ac87AP's Quantenna is "behind" the main Broadcom AP from the router's standpoint, but it still sees those BOOTP messages, which it doesn't report from it's own Quantenna chip.

 

[mike2h]

didn't help here the 5 radio is completely off.
In response to Jongs 'ap' question I am running a 68r as a media bridge. im going t oswitch it to 2.4 and see what happens/doesn't.

 

[mike2h]

don't know how much play the ios thing has in this- only had mini and 1 phone turned on still lost the 5 radio. anyway ygot the ea-n66 and the 68r at 2.4.
see what happens.

 

[sfx2000]

iOS 9.0.1 was released this morning - nothing in release notes about WiFi, but might be worth checking out if already on iOS 9,0

 

[Jong]

I've updated the iPad to 9.0.1. Still it disconnects from 5Ghz.

Just had another 5Ghz lockup on the router with BOOTP message flood. This time I rebooted the AP, not the router. Interestingly the BOOTP messages stopped, suggesting they are coming from the APs Quantenna chip. But the 5Ghz network on the router was still down after the AP reboot and had to be restarted.

I'm thinking of moving back to official firmware to see if I can get the 5Ghz radio to stop crashing. Never happened on 4950. Of course the problem could still be with the Asus code in 378.55 Merlin and I'm sure 8715 would bring its own problems!

 

[RMerlin]

I've updated the iPad to 9.0.1. Still it disconnects from 5Ghz.

Just had another 5Ghz lockup on the router with BOOTP message flood. This time I rebooted the AP, not the router. Interestingly the BOOTP messages stopped, suggesting they are coming from the APs Quantenna chip. But the 5Ghz network on the router was still down after the AP reboot and had to be restarted.

I'm thinking of moving back to official firmware to see if I can get the 5Ghz radio to stop crashing. Never happened on 4950. Of course the problem could still be with the Asus code in 378.55 Merlin and I'm sure 8715 would bring its own problems!

8715 causes a major power drain on mobile devices. That was the reason why 378.55 was never updated to the QTN firmware of those newer betas.

 

[Jong]

Yeah, I knew that but thought it didn't affect iDevices. Am I wrong?

 

[sfx2000]

Yeah, I knew that but thought it didn't affect iDevices. Am I wrong?

Pretty much all devices... complaints were from Android and iDevice users, but it ran the gamut...

 

[sfx2000]

I would agree... likely the fix will have to come from QTN directly, as the RF/Baseband/SoC is kind of a walled garden that the Asus firmware sends commands to...

Keeping in mind that the 87U is essentially two AP's in one (the Broadcom Router/AP) and a loosely coupled QTN AP - the BOOTP message you're seeing in the logs is the QTN trying to obtain an internal IP for the management interface on it, and also for network layer transport to the Broadcom via the RGMII interface (which is basically ethernet without the cable)

So seeing many BOOTP messages from the QTN means either it's crashing and rebooting, or there is a watchdog process on the QTN that is causing it to try to recover from some kind of unhandled exception...

I've been doing some additional packet tracing - and something I forgot was brought into focus - iDevices, since iOS7, support 802.11v (at least partially) - 11v adds additional information to the Client Probe Request/Response handshake messages in one of the HT Capabilities stanzas - specifically related to WMM and Multicast, outside of 11e - the impetus here is that an iDevice, in a multicast environment can pipeline the data as unicast since the device sleeps and could miss multicast overhead updates...

(for those who are deep into the wires(or wireless), the item is over in Octet 4 of extended capabilities) see below, I've highlighted things of interest that might be a problem with teh QTN, sending it into Crash/Watchdog state - these are unique to iDevices on iOS 8/9;

Tag: Extended Capabilities (4 octets)
Tag Number: Extended Capabilities (127)
Tag length: 4
Extended Capabilities: 0x00 (octet 1)
.... ...0 = 20/40 BSS Coexistence Management Support: Not supported
.... ..0. = On-demand beacon: Not supported
.... .0.. = Extended Channel Switching: Not supported
.... 0... = WAVE indication: Not supported
...0 .... = PSMP Capability: Not supported
..0. .... = Reserved: 0x00
.0.. .... = S-PSMP Support: Not supported
0... .... = Event: Not supported
Extended Capabilities: 0x00 (octet 2)
.... ...0 = Diagnostics: Not supported
.... ..0. = Multicast Diagnostics: Not supported
.... .0.. = Location Tracking: Not supported
.... 0... = FMS: Not supported
...0 .... = Proxy ARP Service: Not supported
..0. .... = Collocated Interference Reporting: Not supported
.0.. .... = Civic Location: Not supported
0... .... = Geospatial Location: Not supported
Extended Capabilities: 0x08 (octet 3)
.... ...0 = TFS: Not supported
.... ..0. = WNM-Sleep Mode: Not supported
.... .0.. = TIM Broadcast: Not supported
.... 1... = BSS Transition: Supported
...0 .... = QoS Traffic Capability: Not supported
..0. .... = AC Station Count: Not supported
.0.. .... = Multiple BSSID: Not supported
0... .... = Timing Measurement: Not supported
Extended Capabilities: 0x04 (octet 4)
.... ...0 = Channel Usage: Not supported
.... ..0. = SSID List: Not supported
.... .1.. = DMS: Supported
.... 0... = UTC TSF Offset: Not supported
...0 .... = Peer U-APSD Buffer STA Support: Not supported
..0. .... = TDLS Peer PSM Support: Not supported
.0.. .... = TDLS channel switching: Not supported
0... .... = Interworking: Not supported
Tag: Interworking
Tag Number: Interworking (107)
Tag length: 7
.... 1111 = Access Network Type: Wildcard (15)
...0 .... = Internet: 0
..0. .... = ASRA: 0
.0.. .... = ESR: 0
0... .... = UESA: 0​

 

[Jong]

Pretty much all devices... complaints were from Android and iDevice users, but it ran the gamut...

Don't worry, I'll limp along as is until the next beta I think. Kinda tempted to try Merlin 54_2, as ASUSWRT .4950 was just about rock solid for me. But not sure I can be bothered!

I'm pretty sure IOS9 has made things a lot worse. I was very happy with 378.55 until a week ago. But my AP seemed quite happy with IOS9 running 4950, although I know it has a simpler job. It worries me that this firmware has so many "patches" to try to fix previous issues that it's now inherently unstable and any changes to device firmware can mess things up.

 

[MarioCaires]

My 5GHz radio and LAN Port 1 crashed twice on the last 3 days...! All the other ports (2.4GHz, LAN2/3/4) were working.
And this after 60 days straight with no issues at all! No reboots...

On both crashes what I could see:
The 5GHz band wasn't visible to other devices and LED on the router was naturally off.
My PC is connected to the LAN Port 1, although the LED was blinking, no access to the webgui and no internet.

I presume the QTN interface failed completely! Unfortunately I couldn't get a log, but will be ready next time, in case it crashes again.
I don't change a setting in the router for weeks, so I'm kind of surprised how this happened twice in 3 days...
I updated my wife's iphone 6 plus and an ipad air 2 to iOS9.0 4 days ago, would be silly to think iOS 9.0 has something to do with?

 

[sfx2000]

Don't worry, I'll limp along as is until the next beta I think. Kinda tempted to try Merlin 54_2, as ASUSWRT .4950 was just about rock solid for me. But not sure I can be bothered!

I'm pretty sure IOS9 has made things a lot worse. I was very happy with 378.55 until a week ago. But my AP seemed quite happy with IOS9 running 4950, although I know it has a simpler job. It worries me that this firmware has so many "patches" to try to fix previous issues that it's now inherently unstable and any changes to device firmware can mess things up.

Worst case - use a different SSID for the 5GHz so that the iDevices camp on the 2.4GHz side for now until QTN can issue a fix - noteworthy that we're not seeing reports of 5GHz instability with the RT-AC68/AC66 and RT-AC3200 Broadcom based Router/AP's...

 

[Hydro]

Well, since implementing sfx2000's naming steps in post #50, my iPhone 6 (now on ios 9.0.1) is still going strong with a very consistently near-or-full speed 5ghz ac connection at home.

An occasional very brief wifi-connection lag when waking from sleep or first getting in range, but nothing at all on the scale of the buffoonery that was happening previously.

So I guess my plan at this point is to not ever update anything again ever!

Cheers, Chris

ETA: the 87 router's System Log looks normal too - I'm not an expert on interpreting that info, but its entries these days look pretty routine.

 

[mike2h]

just an fyi- when the 5ghz radio goes down and I go to login to reboot it takes 5-10 secs to get t0 router after password entered instead of the normal 1-2 secs. got to have some releavance I just don't know what

 

[Jong]

Been running 9110 for about 5 days on my AP and 3 days on my router and no 5ghz lockups. A bit early to be sure but this may be fixed.