openwrt dropbear ssh timeout

[yuhongwei380]

last time,we use dropbear
2020.81-3 version,we can ssh to my remote openwrt across ipsec-vpn; but this time ,i upgrade my openwrt, and fine the dropbear version is update to 2022.82 ;we can't ssh to my remote openwrt ;but between remote sever and remote openwrt , it can work ;so i think maybe IPQos influences this ?

[mkj]

I haven't had any reports of this, though it's possible. As far as I know AF21 (used by dropbear) is fairly normal though.
Can you send logs of the ssh client getting stuck?

You should be able to disable the qos if you run on the openwrt device:
nft add rule inet filter output ip dscp set cs0

A packet capture with wireshark/tcpdump might have some clues too.

[yuhongwei380]

like this ; when i want to ssh my remote openwrt(dropbear 22.82) over ipsec-vpn; it is hanged and noticed time out ; i try to switch my old version (20.81-3) ,it is work well , i can ssh my remote openwrt over ipsec-vpn ;
Looking forward to your reply，Thank you！

[yuhongwei380]

i am sure it is AF21 influenced this ssh problem samed as openssh 8.0 ; In OpenSSH version 8.1+ a DSCP value of AF21 is appended by default. This seems to break communication in some environments.
so how can i revise the default dscp setting on openwrt ;

it does not work ,may this command is wrong?

[yuhongwei380]

i find it AF21 in the dropbear 2022.82 release-note

[mkj]

OK yep, seems likely AF21 is the cause if OpenSSH 8.1 shows the same thing.
Do you know which ipsec vpn software/hardware is being used? It might be worth seeing if it can be fixed there, given newer OpenSSH will have trouble too.

AF21 is hardcoded for Dropbear, you can disable it by commenting out (or setting to 0 instead)

dropbear/netio.c

Line 397 in 9d320a7

val = 0x48; /* IPTOS_DSCP_AF21 */

I'll make it a setting for localoptions.h in future.

I'm not sure why that nft line didn't work, I tested the commandline here on my laptop. Is your openwrt system using iptables or nft? If it's iptables it will need a different command.

[yuhongwei380]

my openwrt may used iptables ; i can find iptables;

[yuhongwei380]

my ipsec-vpn is on the firewall device ; two huawei USG device ; i did not setting any qos in the ipsec-vpn

[yuhongwei380]

yeap, i try to find any problem or setting in my firewall device ; but in remote ubuntu ; ssh version is 8.0; but it works well . So i am so confused ; last time we met this problem is in my remote centos8 linux server ; we add IPQos=thoughout in sshd_config .

[mkj]

Debian (which Ubuntu follows) patched their OpenSSH to use the old IPQoS=cs1 setting , see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879#17

Perhaps it's a bug in the Huawei USG device, a few other things like vmware were also incorrectly handling DSCP.

For iptables this might work?
iptables -t mangle -A OUTPUT -j DSCP --set-dscp 0

[yuhongwei380]

[mkj]

Ah, not sure about the iptables dscp syntax. That's what the manpage seemed to document.

[ynezz]

I'll make it a setting for localoptions.h in future.

FYI for openwrt/openwrt#10405 I've created following workaround.

[mkj]

FYI for openwrt/openwrt#10405 I've created following workaround.

Thanks @ynezz , I hadn't seen those problems - I'd assumed OpenSSH had already shaken out any wonky network equipment!

[yuhongwei380]

so i suggest next dropbear version should be the default ?