Re: OpenWrt 21.02 status
Hi Hauke, > Could you please try this patch: > https://patchwork.ozlabs.org/project/openwrt/patch/20210531195732.522580-1-dqf...@gmail.com/ > I do not see this problem with this patch any more, I am not sure which > change exactly fixed it or if I am unable to reproduce it any more. > > I have some wireshark dumps of the problem with unmodified OpenWrt 21.02. > Before the flow handling: offload-ipv6-problem2-wifi.pcapng > On the PC receiving the stream: offload-ipv6-problem2-pc.pcapng > Some packets of this TCP stream are not forward. I've just tested a build of 21.02-rc3 with that patch, and I'm still seeing the same problem unfortunately. If I get a minute, I'll have a look at your traces and see if I can capture them too. cheers, Andy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SSH/MTU Issues in OpenVPN tunnel on OpenWRT 21.02 RC3
Hi Federico, Le sam. 31 juil. 2021 à 20:33, Federico Capoano a écrit : > > Hi everyone, > > I wrote about this issue in the forum and I was advised to post here > as well so I'm following the advice. > (Forum discussion: > https://forum.openwrt.org/t/ssh-mtu-issues-on-openvpn-on-openwrt-21-02-rc3-linux-kernel-5-4-132/102686). > [...] > > OpenVPN version on clients with new firmare: > > OpenVPN 2.5.3 mipsel-openwrt-linux-gnu [SSL (mbed TLS)] [LZ4] [EPOLL] > [MH/PKTINFO] [AEAD] > library versions: mbed TLS 2.16.10 > Originally developed by James Yonan > Copyright (C) 2002-2021 OpenVPN Inc openvpn-mbedtls is now build without lzo support, you can: 1) disable lzo on the server (actually the best thing to do IMO) 2) enable it in your build 3) use openvpn-openssl package More discussion here: https://github.com/openwrt/packages/issues/15854 Best Etienne > OpenVPN version on clients with older firmware: > > OpenVPN 2.5.3 mipsel-openwrt-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] > [EPOLL] [MH/PKTINFO] [AEAD] > library versions: mbed TLS 2.16.10, LZO 2.10 > Originally developed by James Yonan > Copyright (C) 2002-2021 OpenVPN Inc > [...] > > Best regards > Federico Capoano ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
SSH/MTU Issues in OpenVPN tunnel on OpenWRT 21.02 RC3
Hi everyone, I wrote about this issue in the forum and I was advised to post here as well so I'm following the advice. (Forum discussion: https://forum.openwrt.org/t/ssh-mtu-issues-on-openvpn-on-openwrt-21-02-rc3-linux-kernel-5-4-132/102686). I upgraded a few devices which were running a custom build based on OpenWRT 21.02 (commit febf6db0d0) to the RC3 (Kernel 5.4.132) today and suddenly I can't SSH into the devices through the management openvpn tunnel anymore. I tried also upgrading to commit https://github.com/openwrt/openwrt/commit/2d5ee43dc6390d84620807c741d2cb0e272b49ce which bumps the kernel to 5.4.137, same issue. Trying "ping -M do -s 1400" on some devices with the old OpenWRT 21.02 build (kernel 5.4.128) works. The same on devices with new build (Kernel 5.4.132) doesn't work. On the new build, the max size that passes through the tunnel is 297: ping -M do -s 297. Anything higher than that doesn't work. I did not change anything in the configuration, only upgraded the firmware. The same happened a while ago while testing in a different installation in which we were also using wireguard so we just switched to wireguard, but now that this has happened twice in a row while upgrading devices I think there's a problem somewhere and I wonder if anybody else is suffering of the same issue? Can anyone shed some light on what is going on here? >From the research I have done, all is pointing to an MTU issue. Server conf: auth SHA1 ca ca.pem cert cert.pem cipher none comp-lzo adaptive dev tun0 dev-type tun dh dh.pem duplicate-cn group nogroup keepalive 10 120 key key.pem log /var/log/openvpn/tun0.log mode server mssfix 1450 mtu-disc no mute 3 mute-replay-warnings persist-key persist-tun port 1194 proto tcp-server reneg-sec 3600 script-security 1 server *** 255.255.0.0 status /var/log/openvpn/tun0.status status-version 1 tls-auth ta.key 0 tls-server tls-timeout 2 topology p2p user nobody verb 1 Client conf: config openvpn 'tun0' option auth 'SHA1' option auth_nocache '1' option ca '/etc/x509/ca-1-openwisp-vpn-ca.pem' option cert '/etc/x509/client-ecea0196e4644edb9857b684f33e3d4b.pem' option cipher 'none' option comp_lzo 'adaptive' option dev 'tun0' option dev_type 'tun' option enabled '1' option fast_io '0' option float '0' option fragment '0' option group 'nogroup' option keepalive '10 120' option key '/etc/x509/key-ecea0196e4644edb9857b684f33e3d4b.pem' option log '/var/log/tun0.log' option mode 'p2p' option mssfix '1400' option mtu_test '0' option mute '3' option mute_replay_warnings '1' option nobind '1' option persist_key '1' option persist_tun '1' option proto 'tcp-client' option pull '1' option reneg_sec '3600' option resolv_retry 'infinite' option script_security '2' option tls_auth '/etc/x509/ta-management.key 1' option tls_client '1' option tls_timeout '2' option user 'nobody' option verb '1' list remote '** 1194' OpenVPN version on clients with new firmare: OpenVPN 2.5.3 mipsel-openwrt-linux-gnu [SSL (mbed TLS)] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] library versions: mbed TLS 2.16.10 Originally developed by James Yonan Copyright (C) 2002-2021 OpenVPN Inc OpenVPN version on clients with older firmware: OpenVPN 2.5.3 mipsel-openwrt-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] library versions: mbed TLS 2.16.10, LZO 2.10 Originally developed by James Yonan Copyright (C) 2002-2021 OpenVPN Inc (only LZO 2.10 changes). OpenVPN version on the server: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 27 2021 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Originally developed by James Yonan Copyright (C) 2002-2018 OpenVPN Inc Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no SSH
Re: OpenWrt 21.02 status
On 7/31/21 9:05 AM, Andy Botting wrote:
Thank you for the link and the description on how to reproduce this:
while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
'%{time_total}'\n" -H 'Host: www.6connect.com'
https://[2607:fae0:a000::9]; sleep 1; done
I see this problem once every 250 tries, but I got a wireshak capture.
A TCP package is lost and we get the next one after 6 seconds. I would
have expected a retransmission much earlier.
I have to check that I do not see this without the offloading and then
also capture before the device.
Thanks for looking into it. I've just had a look on my setup, and I
can easily reproduce it, so if there are some specific scenarios you'd
like me to capture, let me know.
cheers,
Andy
Hi Andy,
Could you please try this patch:
https://patchwork.ozlabs.org/project/openwrt/patch/20210531195732.522580-1-dqf...@gmail.com/
I do not see this problem with this patch any more, I am not sure which
change exactly fixed it or if I am unable to reproduce it any more.
I have some wireshark dumps of the problem with unmodified OpenWrt 21.02.
Before the flow handling: offload-ipv6-problem2-wifi.pcapng
On the PC receiving the stream: offload-ipv6-problem2-pc.pcapng
Some packets of this TCP stream are not forward.
Hauke
offload-ipv6-problem2-pc.pcapng
Description: application/pcapng
offload-ipv6-problem2-wifi.pcapng
Description: application/pcapng
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: set CONFIG_RCU_FANOUT=64 for 64bit targets
On 30/07/2021 20:56, Stijn Tintel wrote: The generic config has CONFIG_RCU_EXPERT=y, which exposes CONFIG_RCU_FANOUT. This is set to 32 in the generic config, but the default for 64bit kernels is 64. This causes a warning during boot: [0.00] rcu: CONFIG_RCU_FANOUT set to non-default value of 32. Set CONFIG_RCU_FANOUT=64 in kernel configs of 64bit targets, unless the target config has disabled CONFIG_RCU_EXPERT. Alternatively we could disable CONFIG_RCU_EXPERT entirely. Not sure why it was enabled in the first place. If anyone knows, please do share. Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
> Thank you for the link and the description on how to reproduce this:
> while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
> '%{time_total}'\n" -H 'Host: www.6connect.com'
> https://[2607:fae0:a000::9]; sleep 1; done
>
> I see this problem once every 250 tries, but I got a wireshak capture.
>
> A TCP package is lost and we get the next one after 6 seconds. I would
> have expected a retransmission much earlier.
>
> I have to check that I do not see this without the offloading and then
> also capture before the device.
Thanks for looking into it. I've just had a look on my setup, and I
can easily reproduce it, so if there are some specific scenarios you'd
like me to capture, let me know.
cheers,
Andy
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
