Wi-Fi 802.11ac 1.7 Gbps (160MHz channels) advisory

Hello and welcome to a thread dedicated to 802.11ac Wi-Fi and specifically to questions and issues related to 160 MHz channels.
802.11ac standard has been with us for a while now and so were - in theory - 160 MHz channels, however there were no Wi-Fi cards capable of 160Mhz channels until Intel 9260 came along, so that part is new.

As such people are not aware of specific issues that arise only or mostly when those channels are used.

Let's get through some of the basics:

1. How 160 MHz channels came to be?

These channels are either two continuous 80MHz channels bonded together (usually designated as 160) or two separate (not continuous) 80 MHz channels working together (usually designated as 80+80).

The second type - 80+80 is far better for a couple of reasons - one is that it's hard to find a clear/free 160MHz of 5GHz band but it's much easier to find free 80MHz, so one could use two free channels to form one super-channel
Secondly one could use two non-DFS channels to form 160MHz channel i.e. one from the lower part of spectrum (channels 36-48) and one from the upper part (149-165) omitting the middle part where DFS is required.

This all sounds great but not all of the routers support 80+80 and moreover we are not sure that Intel 9260 and its twin Killer 1550 even support that.

2. What the hell is DFS?

DFS is Dynamic Frequency Selection - it's goal is to stop routers and other 5GHz devices interfering with weather radars (see this file if you're interested in details - PDF).

The idea is that the router will detect specific radar patterns and will switch channels to avoid causing interference.
Also once the router is booted up, before the 5 GHz radio starts it's going to scan the channel to make sure it can be used without causing interference to any radar installations.

On most channels that scan takes 1 minute and in that time it might seem like 5GHz radio is not working, but on some channels it takes 30 minutes (I don't have a source for that but it seems on upper channels)
See this for details.

Oh and the channel the radar got detected on gets blacklisted for 30 minutes.

3. On what channels is DFS required?

That depends on where you live - as usually rules are different all around the world.
In the US DFS requirement starts from channel 52 (lower boundary is 5250 MHz) and goes all the way to and including channel 144 (upper boundary 5730 MHz).

As a result in the US non-DFS frequencies are 5170 MHz to 5250 MHz (that's 80MHz wide) and 5735 MHz to 5835MHz (100MHz wide).

As you see there is no way to for a continuous 160MHz channel on any of non-DFS frequencies.


4. What's wrong with DFS?

Almost everything, really. What happens is that once the router discovers what it thinks is a radar (based on the characteristics hard coded in the driver for your wireless chipset that are supposed to recognize radar patterns) your device has 10 seconds to vacate the premises.

It does so in an elegant and sophisticated manner - by dumping any and all connected devices and switching to another channel. And I mean that literally - it disassociates all wireless client immediately regardless of whether any data is transmitted. Also there is no roaming here, so clients do not get moved to another frequency/channel.

Before the router can establish new network on a new channel it has to scan it - which as mentioned above takes no less than a minute.

As a result your wireless connection might get dropped at any minute stopping any transmission and possibly damaging data and then there will be no SSID to connect for another minute.

Mind you once the wireless connection is reestablished you're not out of the woods yet. Any backups you might have had going are down at this point, any secure connections that require authentication will requite re-authentication (often manual) and anything you've been doing - streaming, downloading, VoIP is down at this point.

5. I don't live near the airport so radars are not a problem for me. Why should I care?

First of all what is near? According to this source "near" is defined in DFS documentation as anything within 35km (21 miles) of a radar installation. That does not really sound like "near", does it?

If you live in a city your chances of being within 21 miles of an airport are rather large - welcome to DFS zone

Secondly I very much doubt this patterns are correctly recognized. My router drops 160 MHz connection on multiple 5GHz channels roughly twice a day. Does it sound plausible that the weather radar would be switched on twice a day? Are the electricity bills that high?

I seriously doubt that whatever my router discovers is a radar. While I do live within 21 miles of an airport I do live in a large city and I do not live in a skyscraper. Basically I live on a low floor of a building some 8/9 miles from the airport and between me and the airport there are lots of tall buildings and skyscrapers.

As such I suspect my router is not picking up any radars - more like something on 5GHz operated by one of my neighbors.

6. Why not disable DFS, than?

This can't be done - it's built in the driver and as such if it's deployed by the manufacturer of the wireless chip, it can't be disabled.
What's more if you've managed to disable scanning somehow, you wouldn't be able to connect to any 5GHz networks anyway because DFS scan has to be complete before SSID can be created. Remember that 1 minute wait I mentioned before - that's when the scan takes place and unless it's finished SSID won't be created.

I tested that on a router that has a separate radio which seems to be only used for scanning. It seems not to have been enabled before the latest firmware, but with the latest firmware it seems to be on and once I disconnected antenna from it 5GHz radio never got enabled. To clarify 5GHz radio was a separate radio that still had its antenna connected at the time.

7. But speeds are great with 160MHz channels. 100MB/s over Wi-Fi!

That is true - it looks nice and all. On a free channel in the DFS zone I managed 96MB/s download over ftp from NAS.
Not that the connection was able to stay reliably on for 24 hours...

What would you rather have - a slower connection that's reliable or a flakey one that's insanely fast?

8. My router does not disconnect like that!

Maybe it doesn't - maybe you live far from radars and there is no interference that your router picks up and wrongly recognizes as radar interference.

Or maybe you just don't know it happens.

When a router disconnects you from 5GHz network your notebook will most likely automatically reconnect you to 2.4 GHz network (which is still working).
If that doesn't happen your 5GHz SSID will reappear on a new channel after 1 minute and your computer will re-connect to it.

And there is no point going to router settings to check the channel - UI doesn't get updated by the radio driver.
If you chose channel 36 and you ended up on channel 122 as a result of DFS intervention, your router's GUI will still show 36. The only way to check is to use a network scanning software.

9. What can I do?

Not much really but when upgrading to 160MHz router buy one that supports 80+80 MHz non continuous channels.
If this option is not available, you will not be able to avoid DFS channels.

Also make sure to research what channels are supported - 80+80 needs to consist of lower channels an upper channel to avoid DFS ones. If your router supports lower and middle channels but not the upper ones, that won't help either.

Also in some countries like Japan, Israel or Turkey upper channels are not available by law anyway.

And in case you think that you can just choose a different country from a drop-down list to circumvent that - it might not be the case. Some wireless devices ignore that setting.
I have one Wi-Fi card that completely ignores location set in driver advanced settings and goes with whatever location it has in its firmware. I also own a US bought Linksys router that will not accept the fact that I don't live in the US. Location is set in its eprom along with Wi-Fi transmission power tables and it just won't budge regardless of what you do.

While it's still not clear if Intel 9260/Killer 1550 support non-continuous 80+80MHz channels, if it does you're in luck, if it doesn't some other card will come along and replacing a $25 card is much easier than a $250 router.

Any questions, clarifications are welcome.

 

Thanks @downloads! This is very informative and I feel like it clarifies and pieces together a lot of the bits and pieces of knowledge about 160MHz that I've picked up here and there.

It's sad how we own these cards, and we don't know what it's capable of. I assume the specification doesn't state it clearly, because the 1550 is touts 160MHz as a selling point, but I guess they don't specify which type?

Let me make sure if I'm following you correctly. You're saying...
1. that if the router doesn't support continuous 160 (only 80) then as long as the wifi card supports 80+80 we can use discontinous 160
2. if the router supports some sort of discontinuous 160 then the wifi card doesn't have to support 80+80? and we can still use discontinuous 160?

Do you know if NetGear R9000 is capable of 80+80. I read in one post over at netgear forums that it does, but then why is it that the router works only at low channels? and constantly disconnects? That sounds like continuous 160

 

@nosauce

1. If the router just supports 80MHz there is no way for it to do 80+80 MHz. Radio has to be capable of doing that so older routers that just supported 80 MHz won't do 80+80 and there is nothing resembling link aggregation here.
In order to be able to use 80+80 both router and card have to be capable of explicitly that.

2. That's the same as above - if the router supports discontinuous 160 (80+80) than the card had to be able to support that as well for it to work.

Netgear is capable of 80+80 for sure but I don't know how well does that work. Typically 80+80 would be better than 160 because in theory you could do both continuous 160MHz (by choosing neighboring channels) and discontinuous 160 by choosing two 80MHz that are apart, that said I can't test that with my WRT3200ACM/WRT32X as I don't have an option to do 80+80 to begin with.

 

Continuous 160Mhz is basic, nosauce. It’s the 80+80Mhz split bonding combining uppper and lower channels (Avoids DFS at least in US) is the one that the 9260ac doesn’t seem to support. The QCA9984 supports 80+80 split bonding in addition to contiguous 160Mhz. That’s the WiFi chip in the R7800 and R9000.

 

@Aivxtla Does the R9000 support DFS channels? I seem to remember that smallnetbuilder said it did not. Is that correct or was it just some early firmware issue?

 

It does there were updated FCC permission requests by Netgear later on. Even the new R9000 revision has DFS testing (Only difference with new revision according to FCC filing is removal of unused Bluetooth chipset). However I don’t know if it’s selectable in firmware. I gave mine away after the beta.

 

Yeah I have a Bluetooth chipset in my router as well. Very useful - to the point where neither driver nor firmware for it are even present in the router's firmware

 

I wonder how much design and underlying firmware work is really done by the actual contracted manufacturers ie Delta Networks, Foxconn etc rather than the brands Netgear/Linksys etc.

Foxconn aka Hon Hai Precision (Taiwan) just bought Linksys, might actually be beneficial.

 

So I bought a router from Linksys who had been bought by Belkin who now has been bought by Foxconn that is in fact Hon Hai Precision. Yap. Crystal clear

 

That's just ... idiotic.

I've done some batch-analysis work using weather data gathered by such radars ( HDF5) and they normally operate on 5 minute intervals or less. And even if they were using 1h intervals; what's the point of re-trying the same band over and over again? That radar won't switch bands or move lock-stock-and-barrel any time soon ...

More humor from a Cisco sheet:

So let's say channel 108 and 136 both have radar interference;

1. Listens for 1m on dfs-required 108, finds radar and switches to random new channel
2. Listens for 1m on dfs-required 138, finds radar and switches to random new channel
3. Listens for 1m on dfs-required 108, finds radar and switches to random new channel
4. Listens for 1m on dfs-required 138, finds radar and switches to random new channel
5. ...

Hmm ... maybe that explains the weird 30-minute black-list ...

Do see the need for radar-avoidance though. Certain squares in our grids supposedly see excessive rainfall peaks over and over again, but these are obviously caused by interference. The trouble then is that this makes sewage load and surface drainage predictions completely unreliable for these areas. And that's just the known unknowns; the unknown unknowns have far greater consequences.

However, this DFS-scan method is an absurdly blunt instrument. These (weather) radars are known, relatively static quantities and there's not that many of them. A simple IP traceroute/ping query to a bunch of pre-set IPs (e.g., one for and at each radar location) and you'd know the rough distance of the router to the nearest radar within a second. Next, send a magic packet to that radar's IP and you'd know the frequencies to avoid and blacklist. Could make the query mandatory, if so desired, but you'd only need to do this once after the router boots; that dish isn't going anywhere. Might even force a weekly check-up, just in case a new one is being built or the nearest one switched frequencies (also for any new, changed or disused IPs). And even then you'd have a grace time; the radar operator can be required to broadcast its new frequencies in response to packet-ing for at least a week prior to actually switching over to them. No need for that stupid 10-second-disconnect rule then.

 

The hardcoded behavior of this DFS sounds like a great way to clear a channel all for yourself. Spoof one of these radar signals and force all the routers in your apartment block off your new uncongested personal channel!

 

I think I remember reading on the changelog for the most recent firmware that I'm on, that they added DFS channels. So it might be a recent addition. I'm on Channel 104 (DFS):



This is from Killer Control Center's Wifi Analyzer. What the does the circle portion mean? Maybe that the wifi card is capable of 80+80?

Is all this Radar detection, damaging and losing data only apply to 160MHz? I'm assuming it applies to 80Mhz too? I haven't noticed any disconnections but as you pointed out maybe I'm not noticing it. I have 2.4 Ghz turned off. It's consistently on channel 104 (DFS) according to the wifi analyzer. If Radar was detected and the channel was switched, shouldn't it read a different channel? Or does it drop the signal again to switch back to 104 (DFS)?

I thought being on my own channel without interference was a good thing. I mean, look at all the crap to the right and to the left! But if data is being damaged/loss on a DFS channel that's not cool. That's not cool at all.

I'm not sure exactly what @Aivxtla meant by "power limits are much lower". And despite what the graphical depiction of the wifi analyzer indicates things worked fine when I use the 149+ non-DFS channels.

So should I be using the non-DFS higher channels (149 to 161 range) instead of the DFS channel that I'm using?

 

Here is the chart showing legal power limits at various frequencies:
https://apps.fcc.gov/kdb/GetAttachment.html?id=1K3EcgPRatUcWMwkA+uROw==&desc=905462 D06 802 11 Channel Plans New Rules v02&tracking_number=27155

149-165 is least restrictive, they upped the indoor power limits on 36-48 to be the same in 2014. DFS channels still have lower power limits than both the other ranges.

If you are on CH104 and the router detected a priority frequency user on it, then it would completely kick you out of that frequency range/channel.

 

I am somewhat lost in this battle against DFS, reason being, impossible things start to happen.

I am connected via a 5GHz dongle that does not support DFS channels to my 5GHz network on channel 36 - which is confirmed by WirelessNetView.
However at the same time another notebook of mine with Intel 9260 is running Wi-Fi Scanner and the network is clearly showing on channel 106 however this notebook (Intel 9260 one) can't connect to this network, despite the fact it is perfectly capable of working on DFS channels and can detect the network".

There is a discrepancy here because WirelessNetView reports the channel that starts the bonded channel hence channel 36 while Wi-Fi Scanner reports the middle channel - hence channel 106.
In reality we are talking about 5170–5330 and 5490–5650 - as you can see these not overlap in any way.

So here is my problem - how the hell is this possible? It seems that since the dongle can't work on DFS channel and, it is definitely working than this is the channel the network is really on. However why would another notebook detect it on channel 106?

And if you think that is not enough mystery - my phone can't detect the network at all. I don't think it supports channel 106 but it sure does support 36.

I am somewhat confused.

EDIT: slightly edited for clarity (part in bold)

 

It's a little hard to follow because you use words like "this" and it could be be referring to either laptops, but I think I'm tracking.

Have you tried running both wifi detection software on both laptops? -- "WiFi Scanner" on the laptop with the dongle, and "WirelessNetView" on the laptop with the 9260. What channels do they detect?

I know you said there was a disconnect between the channel you set your router to and the actual channel but what channel did you set in your router's setting?

I have the google Pixel 1 and it picks up channel 104 (DFS) fine.

 

I will have to wait till the issue reappears to do that - I've had WiFi Scanner running on one computer as it's a trial of paid software and WirelessNetView which is free, on another. At some point when the rial runs out I won't be able to use Wi-Fi scanner on both anyway.

The channel I set on the router was 36.

As for the smartphone - it does indeed support DFS - I just tested all of the 100 series channels, so the plot thickens.

One notebook detects the wireless and connects to it at channel 36, the other detects but can't connect at channel 106 and the smartphone can't detect and because of that can't connect the network at either channel despite the fact that it should be able to do this on either one.

Next time it happens I will bring up yet another laptop that has Intel 7260 and is runnig Win 7 and as such free version of inSSIDer.

 

That's bizarre. It's gotta be an issue with your router or router setting. That's the simpler explanation. Otherwise it'd be that something's wrong with BOTH your phone and 9260 laptop which seems less likely. Reset Router? Is there a particular reason why you're using the lower channel 36, instead of the higher 149+ channels? Is this because HT160 only works on the lower channels?

 

Once you reset the router all gets back to normal meaning all devices see the network on channel 36 and connect to it.

My guess is that there is some failed DFS action here - as in the router discovers the radar (that in reality is not a radar) and then attempts to move to channel 106 or such and advertises the network as being at 106 but for whatever reason keeps broadcasting at 36.

As such the network card that was connected at 36 would still stay connected and the one that attempted to connect at 106 wouldn't be able to since there is no signal there.

But there is only so much that makes sense here - if the above was true than the device still connected at 36 wouldn't be able to reconnect if manually disconnected as it would be in the same situation as the other notebook where network is not where it's advertised to be. But I did manually disconnect the device working at 36 and it reconnected fine.

Also another problem with my theory is that the phone did not see the network at either channel (I used Wi-Fi Analyzer app) - it would have to be in one place or another and the SSID is not hidden.

As for your second question - 160MHz channels don't work in the upper channels indeed. Also I have an issue with not all devices being DFS complaint which prevents me from running the network at channel i.e. 114.
If I stick to 36, the non-DFS ones will still be able to use it in 80MHz mode and DFS-complaint ones will be able to work at 160MHz channel width.

There is an issue with those devices that I plan on starting a thread about and another one that I wasn't able to figure out for years.
I am rather good at these sort of things so, rest assured I have proper problems that won't be easy to solve.

 

The thing has happened again. This time I have some more info

1. Notebook with Intel 9260 running Wi-Fi scanner shows (graph) the network at channel 106 yet it also shows that in the advanced settings the network advertises that it is at channel 36. Notebook is unable to connect to the network.

2. Notebook with Intel 7260 running inSSIDer shows (graph) the network as running at channel 36 yet it cannot connect to the network.

3. Notebook with Edimax USB card incapable of DFS using Wi-Fi scanner shows the network running at channel 106 (on a graph) despite the fact that this card cannot detect any networks on neighboring channels to 106 (and there are networks there) it is also showing in the advanced settings the network advertises that it is at channel 36. Note that this card (Edimax) doesn't work at channel 106. The same notebook is also running WiFi Info View which shows that the network is running at channel 36.
This notebook is capable of connecting to that 5GHz network.

4. Smartphone running Wi-Fi analyzer does not detect this network at all despite the fact that it should be able to see it at either channel - 36 or 106.

There is also an interesting part of log from the router:

So it looks like radar got detected on 160 MHz channel 36, the router switched to 160MHz channel on 106 and then radar got detected on 106 so the router switch back to 36 aka 42 (same channel with 80 or 160MHz width) and instead of creating 160MHz wide channel created an 80MHz wide one o avoid DFS part.

Still, if that was the case than all of my devices would connect to 80MHz wide channel 36 aka 42 and only one did...

 

Note that Intel 7260ac has issues with HT160 enabled on routers. Every single firmware upgrade on the R7800 there is a note saying that the 7260ac has issues on routers with HT160 mode enabled and that “Intel is looking into it” since 2016 . Me and some others discovered the issue on the R7800 during test phase, I thought it was just a compatibility issue with the QCA9984 chipset but looking at yours it seems like a general issue now.

https://kb.netgear.com/000055200/R7800-Firmware-Version-1-0-2-46

 

Reading all this, I'm glad to be still using good ol' 18260 and simple yet stable 2x2 802.11ac wave 1 router. What a disappointment! Hope Intel, QCA & others won't mess up 802.11ax the same way!

 

I mean it works fine on the Netgear R7800, Synology RT2600AC and Asus BRTAC828 all of which use the trusty QCA9984 chipset. Other than not supporting 80+80 split bonding it’s reliable and provides decent boost for me at least over the 8265 by about 60-100 Mbps DL and a 100+ Mbps increase on DL basically 550-600 Mbps Down / 440-480 UP in transfers between NAS and laptop in my testing environment.

HT160 and MU-MIMO are two things that not all chipsets as created equal in. Qualcomm seems to be the best at the moment in terms of a fully functional WiFi router chipset.

 

That is not related to 7260 though - while it can't connect, neither can Intel 9260 or Broadcom BCM4339.

I think you're missing the point here. There is nothing wrong with Marvell radio chip - it's doing exactly what it should if radar was detected. 802.11ac specification is poorly thought out and anytime radar detection kicks in on 160MHz channel it's bound to disconnect you immediately and the remain unconnected for a minute. QCA can't be any better i that respect unless it's not DFS complainant.

That makes me wonder if those radar patterns that are supposed to be detected are specified by Wi-Fi alliance or are hardware manufacturers able to define them as they wish. Because if it's the latter than it one hell of an incentive to do a bad job and make your clients stay connected.

I am going to do some more testing (it's not like I have a choice in the matter) but I'm inclined to agree with @Starlight5 that VHT160 is not a good idea - it's expensive, effective range will be worse and thanks to DFS being unavoidable, there is a real chance of it being unreliable.

Side note: I will reset the router to factory settings and re-test. I did play with the config a bit under the hood and while I think I left it at default when I was done, I should make sure about that.

On another note - Intel 9260is unreliable as well. I made multiple tests transferring a 6GB file to and from NAS testing different channels and so on and I have noticed that in time transfer speeds drop significantly. Worst case scenario to mid 40s.
This is unfortunately easy to recreate so I've been able to isolate the culprit - if I disable the card in device Manager and re-enable it speeds go back to normal. So it's not the router, it's not Windows, not AV software and not NAS.

 

Yeah my apologies seems I glossed over your previous post too quickly. Thought it was the 7260ac only with the issue. If your on HT160 on lower channels it should drop down to HT80 as the 36-48 range is still non DFS, not sure why it would disconnect entirely. So HT160 should be more like a bonus rather than a loss over HT80 when available. However yes range in HT160 will be less as you are spreading the legally available power over greater amount of spectrum, not sure if I put that in the right terms.

My 9260ac drops to HT80 occasionally depending on signal conditions like it should but it never just outright drops nor do I face connectivity issues with other laptops or phones, even if a radar were detected as I said before the other half of the 1st 160Mhz band is non DFS for fallback. I still think it’s the Marvell chipset not dealing with the switch from affected DFS channels in a proper manner.

Feel free to keep correcting me if I missed something as I do that quite often .

TLDR my view is HT160 if properly implemented is kinda like Turbo Boost, Active under the right signal conditions (and no radar) and falls back to HT80 in the non-DFS section when necessary without issue. At least that’s how the QCA9984 in the R7800 works I believe when using HT160 in UNII-1 and 2A parts of the spectrum.

I saw a post by Chadster766 on Linksys forums talking about false radar detection and ch36 switchback issue on the WRT3200 on Linksys forums. BrainSlayer of DD-WRT also mentioned a weird issue where clients wouldn’t connect just like you mentioned in your post regarding HT160 on the WRT3200 and channel 36 he was comparing with the QCA9984 which seemed fine.

Something similar on OpenWRT:
https://github.com/kaloz/mwlwifi/issues/75

 

@Aivxtla Judging by the log for my system the procedure for Marvell looks like this - radar is detected on lower 160MHz channel (the one starting with ch 36) and the router attempts to move the circus to the other 160MHz channel available (the 100-and-thereabouts one) and once the radar is detected there, and there are no more 160MHz channels left, it moves back to channel 36 but changes channel width to 80MHz to stay out of DFS zone.

Whether it's optimal compared to what QCA is doing is up to debate. The obvious downside of making an attempt to keep 160MHz is that Marvell chipset will disconnect all devices when moving between channels, however it makes an attempt to preserve the channel width and therefore performance.

On the other hand what QCA does seems less obtrusive - if I understand it correctly it will change channel width from 160MHz to 80MHz to stay out of DFS zone first. This is something it can always do only on lower 160MHz channel since the other one is all in DFS zone and simply scaling down to 80MHz might not change anything if radar is detected on more than one of the of 80MHz channels it consists of. Radars do not really work within Wi-Fi channels boundaries, so it's entirely plausible that it might cover more than one channel.

Also there is another downside of QCA way which is that the channel the radar is detected on gets blacklisted for 30 minutes, so once it scales down to 80MHz it won't be able to scale up for half an hour anyway.

I would say it's debatable which of these procedures is better but certainly neither is good. The proper way would be to use 80+80 and simply move whichever 80MHz channel is in the way of radar to another channel keeping all devices connected and keeping 160MHz channel width. At least in theory...

 

Yeah I believe the attempt to keep the channel width is causing the issue. Sad part is it’s actually one of the best performing units despite being a 3x3 unit it competes with many 4x4 routers. HT160 and MU-MIMO are like an after thought for these companies. Decent chipsets but half hazardously implemented extras. These are after all novelty features nice to list on a box as they know most people won’t have supported clients.

But yeah I prefer stability of the connection which the QCA provides over attempting to maintain width for performance. 80+80 would be awesome but in that respect the 9260ac lacks support while my own router supports it. It’s like a puzzle, I really wish there were standard practices for devices labeled with HT160 support. HT160/MU-MIMO are both a mess... Hopefully ax has actual consistent standards implemented for these.

Well whatever the case I learn a lot from these discussions with people like you and the others here. Hopefully you get a fix before the router is not supported anymore lol.

 

@Aivxtla Thanks for the link to github - I do follow mwlwifi development but I didn't go through old closed issues. Apparently I mistook closed for solved - my bad.

 

It's somewhat off topic but yet on topic at the same time - and rather funny - so bear with me.

I have decided to go back to DD-WRT for testing from stock WRT32X firmware that I had cross-flashed on my WRT3200ACM via USB-TTL cable. In order to to that I had to change flash layout and change the bootloder.

Going back wasn't that smooth though - I can flash any firmware properly WRT3200ACM, OpenWRT or DD-WRT but none of them will boot automatically. Normally u-boot waits 5 seconds and boots from nand but mine does not boot at all unless you connect via USB-TTL and issue"boot" command. From then on everything is fine.

I haven't been able to figure that out yet and at 3 a.m. I gave up.

So this is how starting my router looks like now. I had to connect all wired devices and power cable, having placed the router where it normally sits but with front cover not on.
Then connected USB-TTL to serial port on the router and my notebook via 4 inch cable. Then standing with my notebook in one hand I had to switch on the router with my other hand and only then connect the USB adapter fully to USB and click "connect" in putty.
Once that was done I issued "boot" command and disconnected the whole circus and reassembled the front of the router as it was going online.

Let's hope the damn thing is stable because I've made rebooting incredibly complicated

EDIT: After three weeks I got back to it and fixed the no-nandboot-issue although I don't know how.
I used these commands:
env default -a
saveenv
and rebooted the router.

It did not help. Then I flashed new DD-WRT which again did not boot automatically and because it dropped connections I re-flashed the previous one again and now the router boots automatically.

No idea how I did it.

 

Hi, this is my first post, i saw the topic about buying notebooks and shipped vua dhl gets stuck for weeks which i currently experience in google, but could not giew anymire after registering because it was under general discusdions and off topic section, can anyone help out to allow ne to post there and eill also use it as basis so that it will ve released immediately, thanks for the help.

 

I moved you into a usergroup that allows you to see OT.

Charles

 

Thank you so much

 

Did anybody here try Bluetooth 5 on Intel 9260 with AptX or AptX HD? Searching on the web provides contradictory results. \=