Diffie Helmann PEM file is not needed any more as ECDH curves are used.
Of course you can still set it if you really want and yes there is a GUI element for that see picture.
key direction is set for tls-auth key, maybe you used tls-crypt key as that has no key direction?
A snippet from my openvpn.conf (which was made entirely with the GUI, no extra or manual settings):
Is ethernet 802.3az EEE supposed to work? The one time I tried it seemed not to, but could have been other things with the one device I tried.[/i]
Aha, how can you tell that it doesn't work?
BS has tested and implemented it, but he also said that the documentation of the switch chip says that the function can cause problems.
May also be difficult to measure, since 802.3az EEE reduces the current consumption when a port is UP but no data flows over it.
If all external ports are UP with a link speed of 1000baseT theoeretically up to 1W power can be saved. (assuming no data is being transmitted over the ports).
@Alozaros to enable encapsulation offloading run the following then reboot.
Code:
nvram set ath10k_encap=1
Note that it only works with ath10k devices (R7800 among them).
ho1Aetoo wrote:
encapsulation offloading can be enabled via nvram variable, but you shouldn't because it's buggy - it's disabled for a reason
Interesting, I tried it both ways and didn't notice a difference, but the linux kernel patch says it can reduce CPU consumption by 8% so I left it on. If it's known to be buggy, I'll turn it back off !
Last edited by jtbr on Fri May 19, 2023 13:49; edited 1 time in total
Diffie Helmann PEM file is not needed any more as ECDH curves are used.
Of course you can still set it if you really want and yes there is a GUI element for that see picture.
Thanks, I see that the guide recommends ECDH. Didn't realize that. As I have existing settings I'd rather not change, I prefer DH; I don't know that the elliptical curves are significantly more secure (but the link to ipfire in your guide no longer works, so maybe I'm missing something).
egc wrote:
key direction is set for tls-auth key, maybe you used tls-crypt key as that has no key direction?
A snippet from my openvpn.conf (which was made entirely with the GUI, no extra or manual settings):
I use Config as 'Text', rather than 'GUI (server)' so the option you refer to isn't shown for me. I add 'tls-auth /tmp/openvpn/ta.key 0' to my config. dh is added automatically once I set the nvram variable.
Here are my full tls settings:
P.S. I've had a chance to look more at the guide, it's very impressive! Thanks for that. I see now that if I unset the setting you posted while also using the 'GUI (Server)' setting, I can set dh.pem via GUI. Like I said though, I'm using the text option.
Last edited by jtbr on Fri May 19, 2023 22:47; edited 2 times in total
Is ethernet 802.3az EEE supposed to work? The one time I tried it seemed not to, but could have been other things with the one device I tried.[/i]
...
Both devices must be IEEE 802.3az compliant for it to work properly.
Definitely needs more testing by me. I tried one device, which may or may not support it, and found that the connection was unreliable. Could just be the device. Thanks for your feedback.
@jtbr for PPPoE WAN interface... MTU should be less than 1500, i have 1492 with no problem..
also i can see you are running quite of a setup + pppoe that takes toll on the CPU too..you can expect a bit of a load indeed...
Also new build 52596 is out, with some optimisations, prior the build you are running...give it a try...you can also reset and manually recompile, if you haven't done it for a longer time...
Out of a blue couple of previous builds back, i was in the same state.. i haven't done reset for long long time..once i did it and manually rebuilt things are all back to normal...boot speed and running smooth..
Thanks, I should try the new build too. I did do a full reset this time. The bizarro issue went away (also with the MTU change to the bridge). The slow boot remains. My CPU utilisation is normally pretty low actually. But I only have ADSL, not fiber, and the network isn't usually soo busy (also there's a tagged switch for most of the ethernet that probably helps).
Curious about your suggestion that MTU should necessarily be below 1500 for PPPoE. Is that in all cases or dependent upon outside network infrastructure?
MTU for LAN is always 1500 unless you use hardware with active jumbo frames.
PPPoE encapsulation adds an additional 8 bytes to each packet sent over the Ethernet interface, leaving only 1492 as the maximum MTU
MTU for LAN is always 1500 unless you use hardware with active jumbo frames.
PPPoE encapsulation adds an additional 8 bytes to each packet sent over the Ethernet interface, leaving only 1492 as the maximum MTU
Thanks, no jumbo frames here. That makes sense for PPPoE.
Digging in here a bit, I wanted to set my WAN MTU setting to Auto -- that's what I had set previously -- but I can't save it (or rather, it always gets re-set to Manual, 1492)...?? I'm mostly concerned about stability with this, as I am seeing unstable internet speeds and dropouts since resetting from scratch -- maybe it needs to be even lower. (One thing that's puzzling about this is that if I ask openvpn to test the MTU to the remote server it tells me:
Code:
Empirical MTU test completed [Tried,Actual] local->remote=[1604,1604] remote->local=[1556,1556]
, which seems impossible, and indeed from linux,
Code:
ping -M do -s 1464 [remote]
is the highest I can go (MTU 1492).
Concerning the MTU size for the LAN: my thought was that most traffic on one of my bridges will go out over openvpn via a high-latency and somewhat-lossy connection. The MTU there is already set below 1500, anything higher will be fragmented by openvpn or IP. So why not set the MTU lower in the bridge, so that the senders never send bigger packets in the first place. Does this make any sense?
Thanks, from that website, ICMP is working fine, and no signs MTU to the internet is lower than 1492, which is all great.
So as not to pollute this thread, I might open some other discussions under Advanced Networking. I am still investigating some instabilities (nothing to do with openvpn).
The only note then is that with this build it seems impossible to set WAN->Optional Settings->MTU to "Auto".
Joined: 25 Dec 2020 Posts: 90 Location: Toronto - Canada
Posted: Sat May 20, 2023 22:07 Post subject:
ho1Aetoo wrote:
And about the slow reboot, this is also due to the fact that several radio firmware versions are loaded.
It becomes really slow and unreliable when you use "auto-channel" then the router needs even longer to start.
I was trying to figure out why my 5Ghz network would take so long to startup. Seems I set the 2.4Ghz to auto at some point when trying to troubleshoot client connection issues. Great piece of information! Cheers!
UPDATE: I change the 2.4 to a specific channel and knocked off 30 seconds, maybe even closer to a full minute of "stable" boot up time. Sweet!
Now with longer-term testing I can confirm that wireless radios are eventually dropping all clients, usually after a couple days.
It seems to be associated with log messages below:
Code:
May 20 15:40:47 ddwrt_main daemon.info hostapd: wlan0.1: STA 6e:82:d5:91:a2:b7 IEEE 802.11: disassociated due to inactivity
May 20 15:40:48 ddwrt_main daemon.info hostapd: wlan0.1: STA 6e:82:d5:91:a2:b7 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:24 ddwrt_main daemon.info hostapd: wlan1.2: STA 98:d8:63:43:32:3c IEEE 802.11: disassociated due to inactivity
May 20 15:42:25 ddwrt_main daemon.info hostapd: wlan1.2: STA 98:d8:63:43:32:3c IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:27 ddwrt_main daemon.info hostapd: wlan1.1: STA 6e:82:d5:91:a2:b7 IEEE 802.11: disassociated due to inactivity
May 20 15:42:28 ddwrt_main daemon.info hostapd: wlan1.1: STA 6e:82:d5:91:a2:b7 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:28 ddwrt_main daemon.info hostapd: wlan1.2: STA 48:e1:e9:4b:de:4f IEEE 802.11: disassociated due to inactivity
May 20 15:42:29 ddwrt_main daemon.info hostapd: wlan1.2: STA 48:e1:e9:4b:de:4f IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:30 ddwrt_main daemon.info hostapd: wlan1: STA e8:6f:38:ba:32:dc IEEE 802.11: disassociated due to inactivity
May 20 15:42:31 ddwrt_main daemon.info hostapd: wlan1.1: STA a4:77:33:fd:04:08 IEEE 802.11: disassociated due to inactivity
May 20 15:42:31 ddwrt_main daemon.info hostapd: wlan1: STA e8:6f:38:ba:32:dc IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:32 ddwrt_main daemon.info hostapd: wlan1.1: STA 00:04:20:22:19:09 IEEE 802.11: disassociated due to inactivity
May 20 15:42:32 ddwrt_main daemon.info hostapd: wlan1.2: STA cc:50:e3:7e:9d:0c IEEE 802.11: disassociated due to inactivity
May 20 15:42:32 ddwrt_main daemon.info hostapd: wlan1.1: STA a4:77:33:fd:04:08 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:33 ddwrt_main daemon.info hostapd: wlan1.1: STA 00:04:20:22:19:09 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:33 ddwrt_main daemon.info hostapd: wlan1.2: STA cc:50:e3:7e:9d:0c IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:33 ddwrt_main daemon.info hostapd: wlan0: STA 3c:5c:c4:af:46:e8 IEEE 802.11: disassociated due to inactivity
May 20 15:42:34 ddwrt_main daemon.info hostapd: wlan0: STA 3c:5c:c4:af:46:e8 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:38 ddwrt_main daemon.info hostapd: wlan1.2: STA 24:62:ab:2f:95:04 IEEE 802.11: disassociated due to inactivity
May 20 15:42:39 ddwrt_main daemon.info hostapd: wlan1.2: STA 24:62:ab:2f:95:04 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:41 ddwrt_main daemon.info hostapd: wlan0.3: STA 74:e2:0c:46:fe:91 IEEE 802.11: disassociated due to inactivity
May 20 15:42:42 ddwrt_main daemon.info hostapd: wlan0.3: STA 74:e2:0c:46:fe:91 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:44 ddwrt_main daemon.info hostapd: wlan1.2: STA b8:2c:a0:55:4a:bc IEEE 802.11: disassociated due to inactivity
May 20 15:42:45 ddwrt_main daemon.info hostapd: wlan1.2: STA 2c:f4:32:db:cf:ae IEEE 802.11: disassociated due to inactivity
May 20 15:42:45 ddwrt_main daemon.info hostapd: wlan1.2: STA b8:2c:a0:55:4a:bc IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:45 ddwrt_main daemon.info hostapd: wlan1.1: STA a4:77:33:f5:0c:44 IEEE 802.11: disassociated due to inactivity
May 20 15:42:46 ddwrt_main daemon.info hostapd: wlan1.2: STA 2c:f4:32:db:cf:ae IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:46 ddwrt_main daemon.info hostapd: wlan1.1: STA a4:77:33:f5:0c:44 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:48 ddwrt_main daemon.info hostapd: wlan1.2: STA 8c:85:80:72:37:28 IEEE 802.11: disassociated due to inactivity
May 20 15:42:49 ddwrt_main daemon.info hostapd: wlan1.2: STA 8c:85:80:72:37:28 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
May 20 15:42:49 ddwrt_main daemon.info hostapd: wlan0.1: STA 4a:ff:7b:6a:24:e1 IEEE 802.11: disassociated due to inactivity
May 20 15:42:50 ddwrt_main daemon.info hostapd: wlan0.1: STA 4a:ff:7b:6a:24:e1 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Then no clients for the affected radio (in this case BOTH radios at the same moment) can re-authenticate to that radio. More commonly, it is just the 2.4ghz radio (wlan1) that is affected.
Killing hostapd for the affected radio and restarting fixes the problem. I don't know enough about wireless authentication to know what might be the matter here, but happy to provide more info or try testing anything out. I was running my prior build 47000 without anything similar happening, and the wireless settings are basically unchanged.
PS: this may(?) be related to an issue reported in the same build for broadcom by user fiziks
!