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) https://github.com/mkj/dropbear/blob/9d320a73be068deb11e1014a561709e57ee02edc/netio.c#L397

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 https://github.com/openwrt/openwrt/issues/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 ?

[ynezz]

so i suggest next dropbear version should be the default ?

Well, this is not an issue in dropbear, its just exposing broken QoS support on your device, so IMO you've following options:

• disable the QoS in dropbear by using above suggested workarounds
• fix QoS support on your target/device

[mkj]

I think I'll leave the default as AF21, that is the proper way so cake shaper etc can prioritise interactive SSH sessions when traffic is heavy.

I'll add the runtime option to let it be disabled in problematic networks/devices.

In the case of mt76 it looks like it was an unrelated driver bug that happened to trigger with AF21? https://github.com/openwrt/mt76/commit/5ec78e1ec43d1e39edfea1efb9fd4541fa004af0

[ynezz]

I'll add the runtime option to let it be disabled in problematic networks/devices.

Its your call :) I've not prepared PR for this simply because we've decided, that dropbear is critical element in the network infra, so any such bloat might has negative influence on its security.

In the case of mt76 it looks like it was an unrelated driver bug that happened to trigger with AF21?

Correct.

[mkj]

Its your call :) I've not prepared PR for this simply because we've decided, that dropbear is critical element in the network infra, so any such bloat might has negative influence on its security.

Yeah, normally I'd be reluctant to add workarounds for broken things, but the history of TOS/DSCP flag handling is messy and there are probably a few other broken network devices that are harder to change. It shouldn't add too much size.

[yuhongwei380]

I think I'll leave the default as AF21, that is the proper way so cake shaper etc can prioritise interactive SSH sessions when traffic is heavy. I'll add the runtime option to let it be disabled in problematic networks/devices. In the case of mt76 it looks like it was an unrelated driver bug that happened to trigger with AF21? openwrt/mt76@5ec78e1

so ,thats mean , you can provide a option to setting default when we met those ipqos problem?

[mkj]

Yes, I'll add a flag that can be added to dropbear and dbclient.

[yuhongwei380]

Thank you very much！Looking forward the next version of dropbear~ Now we can use the old version