It's 71MB out of 75MB Available (as in: free) space for the overlay. The fact that 75MB - 200kB != 71MB is due to UBIFS overhead and reserved blocks. So LuCI shows the free space correctly.
You actual read-only rootfs (squashfs on /dev/root) got 11MB.
As things are dynamically sized, the read-only rootfs can be up to ~100MB, so you still got some megs for overlay read-write storage.
I've gone through this thread. I just go the belkin variant. This replacing an ap not router. at the moment i have it in stock firmware and getting nice speed. on 1 gig transfer getting 70/megs a second. i picked up another on the way off ebay for low price. that i may use for router. If i have something wrong with following, please let me know.
Best practice would be to follow daniel's guide on git and do full backup first.
if i do that and then try the non ubi route by flashing kernel then ssh to install non ubi image. since device is a/b layout like android phone, will i still be able to go back to stock easily by force boot to other partition ?
if i go ubi route, again following guide on the git, can i then go back to stock by a full write back of the backup done beforehand.
I had the same debate as you did. I am using 3 of the e8450 as just dumb access points(got them as a great ebay score!)
First off, these are a great piece of hardware for the money. I set mine up with stock firmware as they were just going to be dumb access points.the stock firmware was terrible. I decided that openwrt was a better option and just decided to go the UBI direction making full backups.
The important thing is to read the guide a few times and follow it to the letter. If you do that it goes without a hitch. I had all 3 fully backed up and converted in 30 minutes. The thing is, why would I ever go back to stock?
So far openwrt on these has been very stable and these perform great as cheap AX access points.
thanks, for the reply. yes i have never seen stock firmware with so few options. i hesitated because of really good speeds i was getting. plus i had serveral tp-link c2600 units and always had wifi problems in openwrt. (atheros chipsets). so that is why for the ap i am hesitant. i separate the wireless from my router and use a separate ap, mostly because of the problems i had with the c2600's crashing. i have another coming from ebay and i will likely go the ubi route on that. thanks again
I am using my Belkin RT3200 at 160mhz on the 5ghz channel. While this is working fine for my Laptop with an AX 160mhz WiFi chipset, it's giving me some issues with two AC 80mhz WiFi Android phones.
Whenever my laptop is connected (just connected, no actual load), my phone only gets 100-200 Mbit instead of the 500 Mbit it pulls when my laptop is not connected.
Regardless of whether my laptop is connected, the phones seem to strongly prefer the 2.4ghz band, switching even when the 5ghz connection still has good strength and never switching back to 5ghz, even when right next to the AP. This worked fine with my previous AC router.
Does anyone experience issues, and if so, did you get the AP and 80mhz AC phones to play nice with each other?
After reading your post I tried moving mine from 80 to 160 but the radio would not come up at all. What channel are you on? Can you post your /etc/config/wireless?
Please note that it takes a little over a minute for the channel to come up due to DFS scanning, so please be patient when you utilize a DFS channel (which I think is true by default for 160mhz channels due to how wide they are). Config below:
Nice video to watch so thank you for sharing it. I not not understanding why the software flow offloading is a bad thing. Is it because it uses closed source blobs?
I reset the channel to auto and found that it selected 100 and did actually come up. When I did some speed tests from my phone, I found 160 MHz was no faster than 80 MHz.
I don't think it's a fair comparison though because the tests at 20, 40, and 80 MHz were on channel 149 which uses a high value for transmit power (27 dBm) whereas channel 100 uses 23 dBm. I could not get 160 MHz to work on channel 149 or any other channel. Is this to be expected?
Does your phone even support 160mhz channel width? Not many phones do. You can check this on the Wireless page in Luci. It will list whether devices are connected with a 80mhz or 160mhz channel width. If you phone connects with 80mhz because it doesn't support 160mhz, not seeing an improvement is to be expected.
This is expected. It needs a block of 160mhz wide to be able to come up. There is only room for a 80mhz block, it won't be able to come up. This picture explains this pretty well:
Yes, and I must point out that Felix said all that in 2015 (the RC3 2021 logo is just media.ccc.de channel logo, the video is more than 6 years old!) and the MediaTek Chipset he was working on at the time was MT76x2E. Now 6 years later, we actually do find plenty of devices with wireless chips which run very well with that driver and it's the best we have. I mean, we are all here in this thread because we are using a rather recent MediaTek-based device for which we are able to build really almost everything from (of course, open-)source, apart from DDR3 RAM calibration at boot and the very small mt76 uC firmware Felix mentions in that video (ok, it did get a little bit bigger over time, but still nothing compared to ath11k). And with that we manage to get close to a gigabit/s over the air.
No, generally there is nothing wrong with flow offloading imho. The talk is about a WiFi driver and mentions the hell of WiFi MAC offloading QCA introduced into their WiFi chipsets and the fact that you have to use all that to even use the hardware at all.
Hardware flow offloading doesn't require proprietary firmware, but just uses the hard-wired offloading functionality of the chip (the blueprint of the chip is, of course, proprietary, but that's true for all hardware we currently support). To the paranoid: I consider it extremely unlikely to find hardware backdoors there, because that kinda of backdoor would not be fixable in case it is discovered by the public, and if needed, there could also be hidden backdoors in the Ethernet controller or switch IC (and those you can't just turn off to be safe and still use the device). So even if some intelligence agency managed to corrupt developers to hide some bugs in there, that would just be the wrong place to do so and there are (unfortunately) much better places to do that.
I think what @elan wanted to point out is that even if hardware flow offloading may crash and forces you to use software flow offloading (or no offloading) instead, this is still so much better than QCA where you got those huge firmware blobs doing basically everything and our little open source Linux system just sits there to configure the hardware and provide the Web-UI.
You can partially though My phone doesn't support 160mhz either, but the second issue I am experiencing is that the phone will prefer 2.4ghz over 5ghz. It will connect to 5ghz initially, but switch to 2.4ghz quite often, and remain connected the 2.4ghz, even when the signal strength for 5ghz is fine.
It could be that enabling 160mhz channel width is making devices connecting with 80mhz width less stable.
Yes, this observation is true. The higher the channel bandwidth, the less range at the same power. Simply because the same amount of energy is now spread over a larger amount of spectrum.
In case of MT7915E chip using 160Mhz channels also reduces RX diversity to 2 chains instead of 4 when using 80MHz (or less) channel bandwidth, so RX sensitivity is also lower when operating at 160MHz.
That makes sense. And a 160mhz AP cannot use the majority of the power for just the 80mhz part that is being used to communicate with a 80mhz client?
I know the downside of only being able to use 2 spatial streams when running in 160mhz mode with this device, but I don't have a single device that is able to use more than 2 spatial streams, so the downside of only being able to use 2 spatial streams is rather limited for me. Furthermore, enabling 160mhz gives a very nice speedup for my 160mhx AX device over just running 80mhz. It would be a shame if I had to disable 160mhz just for the sake of keeping 80mhz clients happy.
You would still benefit from RX diversity (resulting in better sensitivity and hence more range) when using 4 RX chains intead of 2, even if the device connected it 1T1R.
I just bought my first Belkin RT3200, and was considering using it in mesh mode with Deco P9's running my own image. What sort of performance are you getting via the mesh? The Deco proprietary mesh was much faster than using 802.11s when I tried, so I am curious what your experience has been.
I cannot help to confirm your findings.
My phone doesn't support 160mhz either, but the second issue I am experiencing is that the phone will prefer 2.4ghz over 5ghz. It will connect to 5ghz initially, but switch to 2.4ghz quite often, and remain connected the 2.4ghz, even when the signal strength for 5ghz is fine.