New Build - 05/09/2021 - r46604

Post new topic   Reply to topic    DD-WRT Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.)
Goto page Previous  1, 2
Author Message
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1445
Location: Appalachian mountains, USA

PostPosted: Wed May 12, 2021 22:31    Post subject: Reply with quote
o2bad455 wrote:
An Apple device with second MAC digit of "C" indicates an actual (non-randomized) Apple MAC, FWIW. Assuming an updated MacOS, Private Address was probably turned off in that Mac's wifi settings for the particular SSID.

Are you suggesting that these newer builds will play nice with Apple clients that have Private Address disabled? And if not, why do we care about the second hex digit?

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Sponsor
Monza
DD-WRT User


Joined: 01 Jul 2018
Posts: 438

PostPosted: Wed May 12, 2021 23:30    Post subject: Reply with quote
I will post my niece's OS version as soon as I can since that might be helpful??

Edit: My nieces OS version: MacOS Big Sur 11.2.3


Last edited by Monza on Mon May 17, 2021 12:10; edited 1 time in total
oliver44
DD-WRT Guru


Joined: 01 Jun 2016
Posts: 504

PostPosted: Thu May 13, 2021 6:20    Post subject: Reply with quote
DD-WRTRouter Model Linksys WRT1900ACS v2
Firmware Version DD-WRT v3.0-r46604 std (05/09/21)
Kernel Version Linux 4.9.268 #2590 SMP Sun May 9 00:59:20 +07 2021 armv7l
Uptime 21:14 all ok

Browser waterfox latest version, the first partition always contains linksys firmware !

Connection Type PPPoE IPv6 Type DHCPv6 witch Prefix Delegation,
Avoid DHCP6 client release on reconnec-ON
Dhcp6s-ON

Wireless Mode-AP-AC/N-VHT80Mhz-36-UU(+6),Short Preamble,Short GI,Single User Beamformi,WPA2 Personal,CCMP-128 (AES) all OK

Wireless Mode-AP-NG,20/40Mhz,6,Upper,TurboQAM (QAM256) support,Short Preamble,Short GI,WPA2 Personal,CCMP-128 (AES)all OK

Dnsmasq-ok
Encrypt DNS-ok
Validate DNS Replies (DNSSEC)-ok

I have no errors on the wifi side, all the devices in the house connect so far everything is ok !

_________________
Internet provider https://en.wikipedia.org/wiki/RCS_%26_RDS 1Gbps
WDR3600 rev.1.5 - DD-Wrt
Linksys WRT1900ACS v.2 DD-Wrt/-OpenWrt



https://ipv6.chappell-family.com/ipv6tcptest/
https://en.internet.nl/connection/e91f490fe1c54cb2b78145c0ab0d2b5a/results
http://www.dnssec-or-not.com/
https://dnscheck.tools/#results
o2bad455
DD-WRT User


Joined: 08 Oct 2015
Posts: 252

PostPosted: Thu May 13, 2021 14:35    Post subject: Reply with quote
SurprisedItWorks wrote:
Are you suggesting that these newer builds will play nice with Apple clients that have Private Address disabled? And if not, why do we care about the second hex digit?


I don't think it's been entirely ruled out, so I was helping to interpret the results. But no, it wasn't my intention to suggest either way at this point.

Unfortunately, I don't personally own any Apple devices. As of this week, they've all now jumped ship to a stock router (I was wondering why the sudden interest in the DD-WRT router database, but now realize it was to identify a prospect that was NOT supported - LoL). Thus, I'm unlikely to have any further Apple test results for awhile.

_________________
My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1445
Location: Appalachian mountains, USA

PostPosted: Thu May 13, 2021 16:03    Post subject: Reply with quote
My iOS hanging problem appears to be solved.

Close to 100% of my iOS use is through the dd-wrt OpenVPN client, and it is looking like -- see the ongoing discussion over at http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1236563 -- the OpenVPN 2.5 code incorporated into dd-wrt awhile back may be getting its MTU calculations wrong. But you can override it.

Call the router MTU from Basic Setup wan-mtu. It's typically set to 1500, but not always.

In OpenVPN if you have "verb 4" (or a higher number) in Additional Config in the client setup, look in the log for a line like "Data Channel MTU Parms [L: XXX ..." and if there is more than one such line, focus on the last one. Call that XXX value there link-mtu. If you don't have a "verbosity" line like that in Additional Config, add one. The default verbosity level is 3.

The MTU value in the OpenVPN client page in the GUI is tun-mtu.

Leaving tun-mtu at the default 1500 is supposed to result in things being manipulated behind the scenes, in OpenVPN itself, so that this next procedure is not needed. But if you want to try overriding it, here's what to do.

You want link-mtu to be wan-mtu minus 28 for IPv4-only systems or wan-mtu minus 48 (IIRC... not my specialty) if you use IPv6. Most likely it's currently too high. It tracks up and down with tun-mtu, so you can just lower tun-mtu by the amount that link-mtu needs to come down. This amount depends on the data encryption cipher being used.

Then go one step further and add to the OpenVPN client Additional config a line "mssfix YYY" where mss value YYY is your new tun-mtu value minus 28 for IPv4 systems or 48 (?) for IPv6 systems. If you already had an mss value YYY that was lower than this calculated one, based on experience or ping tests, etc, stick with the lower number.

Let us know whether this fixes things.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
BrainSlayer
Site Admin


Joined: 06 Jun 2006
Posts: 7463
Location: Dresden, Germany

PostPosted: Fri May 21, 2021 4:46    Post subject: Reply with quote
pbphoto wrote:
Flashed my 1900ACSv1 via CLI from 44048. I did 'nvram erase && reboot' afterwards and manually reconfigured the router. No issues with the upgrade.

Test #1: I manually typed in the simplest possible config - router name, IP, GW, local DNS server, ntp server, disabled DHCP and dnsmasq, set to router operating mode etc. For WIFI, I only enabled wlan0 and kept all the defaults: mixed, auto channel, 20mhz width, no changes to advanced settings. WPA2-AES. wlan1 disabled. Within minutes, hostapd dumped with the same error people have been seeing since 46069. GUI was unresponsive afterwards. logs and dmesg attached.

Test #2: i rebooted and configured wifi as follows and rebooted again:
wlan0 - AC/N mixed, 80mhz width, channel 36+6 WPA2-AES
wlan1 - NG mixed, 20mhz width, channel 11 WPA2-AES
I kept all the advanced settings to their defaults. This time, the router ran for over an hour before hostapd dumped. During this hour, my macbook never lost wifi but two different iphones hung up several times and had to stop/start their wifi - same issue that has been happening since 44085. logs and dmesg attached.

Went back to 44048 which is the last good release if you have Apple devices in your environment. Something broke starting with 44085.

Linksys WRT1900ACSv1: router operating mode, hardwired ethernet lan to a WRT3200ACM. WIFI: 2.4ghz: NG-mixed, 20mhz channel width, channel 11, WPA2-CCMP-128. 5ghz: AC/N mixed, 80mhz channel width, channel 36+upper, WPA2-CCMP-128.

Clients: Apple MACOS x 4, IOS x 4, Apple TV, Chromecast Audio x 2, Eufy doorbells, Lutron Caseta, Axis Camera, Samsung TV, Nest thermostat, EtekCity outlets (Espressif)..


to enable better debugging, the next build will contain better symbol names, to find out where it crashes.

in general. all this mac randomization shit will just create troubles. each time you connect you get a new ip from the dhcp server. so if you have some apple devices your lease table is full very quickly since all ip's are in use and no connection works anymore. it also prevents doing sane qos, since ip and mac is different all the time. so you cannot do client specific qos. mac randomization was done to fuck up open hotspots in town, but not to fuck up your private network

_________________
"So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s


Last edited by BrainSlayer on Fri May 21, 2021 4:54; edited 2 times in total
BrainSlayer
Site Admin


Joined: 06 Jun 2006
Posts: 7463
Location: Dresden, Germany

PostPosted: Fri May 21, 2021 4:51    Post subject: Reply with quote
SurprisedItWorks wrote:
My iOS hanging problem appears to be solved.

Close to 100% of my iOS use is through the dd-wrt OpenVPN client, and it is looking like -- see the ongoing discussion over at http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1236563 -- the OpenVPN 2.5 code incorporated into dd-wrt awhile back may be getting its MTU calculations wrong. But you can override it.

Call the router MTU from Basic Setup wan-mtu. It's typically set to 1500, but not always.

In OpenVPN if you have "verb 4" (or a higher number) in Additional Config in the client setup, look in the log for a line like "Data Channel MTU Parms [L: XXX ..." and if there is more than one such line, focus on the last one. Call that XXX value there link-mtu. If you don't have a "verbosity" line like that in Additional Config, add one. The default verbosity level is 3.

The MTU value in the OpenVPN client page in the GUI is tun-mtu.

Leaving tun-mtu at the default 1500 is supposed to result in things being manipulated behind the scenes, in OpenVPN itself, so that this next procedure is not needed. But if you want to try overriding it, here's what to do.

You want link-mtu to be wan-mtu minus 28 for IPv4-only systems or wan-mtu minus 48 (IIRC... not my specialty) if you use IPv6. Most likely it's currently too high. It tracks up and down with tun-mtu, so you can just lower tun-mtu by the amount that link-mtu needs to come down. This amount depends on the data encryption cipher being used.

Then go one step further and add to the OpenVPN client Additional config a line "mssfix YYY" where mss value YYY is your new tun-mtu value minus 28 for IPv4 systems or 48 (?) for IPv6 systems. If you already had an mss value YYY that was lower than this calculated one, based on experience or ping tests, etc, stick with the lower number.

Let us know whether this fixes things.


there is no "wrong" mtu calculation. there is a tun-mtu setting. so set correct mtu. problem solved. nothing is calculated. you are responsible for setting a optimal mtu. to set mssfix. just enable the option mssfix if fragmentaton is enabled.

_________________
"So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
pbphoto
DD-WRT User


Joined: 29 Oct 2017
Posts: 258

PostPosted: Fri May 21, 2021 11:41    Post subject: Reply with quote
BrainSlayer wrote:

to enable better debugging, the next build will contain better symbol names, to find out where it crashes.

in general. all this mac randomization shit will just create troubles. each time you connect you get a new ip from the dhcp server. so if you have some apple devices your lease table is full very quickly since all ip's are in use and no connection works anymore. it also prevents doing sane qos, since ip and mac is different all the time. so you cannot do client specific qos. mac randomization was done to fuck up open hotspots in town, but not to fuck up your private network


Thanks for looking at this BS. The IOS (and MacOS) wifi hangs have been happening since 44085 which preceded mac-randomization's introduction in IOS 14 by at least 6 weeks. If the feature is working properly, it should generate one unique MAC per SSID every 24 hours, so this is not a lot of mac-address churn, It would not explain why a device is connected to wifi and working great for a few minutes, but then all traffic stops yet the wifi connection remains strong, fixed by simply disabling/reenabling wifi on the client device, which then reconnects and works again with the exact same mac address. For kicks, I've tested with the feature off and it still hangs. 44048 is the last release that did not have this problem and this was back in the IOS 13 days. Macos Catalina and Big Sur also have this hang problem (at least on my MBP 2018) and I don't believe Apple uses this feature on Macos.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1445
Location: Appalachian mountains, USA

PostPosted: Fri May 21, 2021 14:51    Post subject: Reply with quote
BrainSlayer wrote:
SurprisedItWorks wrote:
My iOS hanging problem appears to be solved.

Close to 100% of my iOS use is through the dd-wrt OpenVPN client, and it is looking like -- see the ongoing discussion over at http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1236563 -- the OpenVPN 2.5 code incorporated into dd-wrt awhile back may be getting its MTU calculations wrong. But you can override it.

Call the router MTU from Basic Setup wan-mtu. It's typically set to 1500, but not always.

In OpenVPN if you have "verb 4" (or a higher number) in Additional Config in the client setup, look in the log for a line like "Data Channel MTU Parms [L: XXX ..." and if there is more than one such line, focus on the last one. Call that XXX value there link-mtu. If you don't have a "verbosity" line like that in Additional Config, add one. The default verbosity level is 3.

The MTU value in the OpenVPN client page in the GUI is tun-mtu.

Leaving tun-mtu at the default 1500 is supposed to result in things being manipulated behind the scenes, in OpenVPN itself, so that this next procedure is not needed. But if you want to try overriding it, here's what to do.

You want link-mtu to be wan-mtu minus 28 for IPv4-only systems or wan-mtu minus 48 (IIRC... not my specialty) if you use IPv6. Most likely it's currently too high. It tracks up and down with tun-mtu, so you can just lower tun-mtu by the amount that link-mtu needs to come down. This amount depends on the data encryption cipher being used.

Then go one step further and add to the OpenVPN client Additional config a line "mssfix YYY" where mss value YYY is your new tun-mtu value minus 28 for IPv4 systems or 48 (?) for IPv6 systems. If you already had an mss value YYY that was lower than this calculated one, based on experience or ping tests, etc, stick with the lower number.

Let us know whether this fixes things.


there is no "wrong" mtu calculation. there is a tun-mtu setting. so set correct mtu. problem solved. nothing is calculated. you are responsible for setting a optimal mtu. to set mssfix. just enable the option mssfix if fragmentaton is enabled.

Yeah, I sure got that wrong, didn't I? I should have spotted that MTU for OpenVPN tunnel -- tun1 in my case -- remained at exactly what it was set to in the GUI in all cases, that there was no behind-the-scenes twiddling. It seems then that the recommendation of the OpenVPN man page to leave MTU at 1500 wasn't because of some special algorithm associated with that value but was, instead, a number that would be a natural upper limit for most systems. The idea then was apparently to encourage the user to set fragment (with a default mssfix), just as is offered in the dd-wrt GUI, to specify packet-size needs rather than trust user systems to do IP fragmentation correctly based lower, user-calculated MTU values. After all, OpenVPN is used on a bazillion types of systems, and the OpenVPN project can't evaluate/police them all (or even a shorter list of kernels) to ensure correct IP-stack fragmentation. Instead, if fragment is used, the OpenVPN project only has to ensure their own algorithm gets it right. Taking their approach has the advantage as well of requiring the user to get one number correct, the fragment parameter, rather than both MTU and the mssfix parameter.

But all that said (and maybe mis-said), when I actually tried this, an error appeared in my OpenVPN-client log saying

Fails: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented

which was quite a deterrent to me thinking further in that direction!

I've seen many online postings asserting that fragment is only useful when specified by both server and client, so I assumed the error here was because the (AirVPN) server didn't implement it. Was I correct or again confused? Does the client config need to somehow push a request to the server to use fragment with a similar parameter? Or are we mere low-info users better off setting MTU and mssfix and not using fragment at all?

Thanks again for chiming in, @BS. We were in need of some authoritative input, as a little knowledge can be a dangerous thing.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Goto page Previous  1, 2 Display posts from previous:    Page 2 of 2
Post new topic   Reply to topic    DD-WRT Forum Index -> Marvell MVEBU based Hardware (WRT1900AC etc.) All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum