In 7.22.3 and 7.23.3 it’s no longer possible to ssh to RUTX1 using IPv6. This used to work, so it’s a regression.
This seems connected to the “Access Control” feature, and introduction of inetd-ubus which binds to 0.0.0.0 (IPv4 only) instead of binding to [::]. It also seems inetd-ubus command line “-p” doesn’t even support IPv6 syntax.
/usr/bin/inetd-ubus -h
Usage: /usr/bin/inetd-ubus [options] [– ]
Options:
–port [address:]
On which ports should TCP connections be listened on
By default binds on the 0.0.0.0 address, but can be overridden
Can be passed multiple times, to listen on multiple ports
At start, it only binds to 0.0.0.0:22 which is IPv4 only.
@mabra Hello, inter-ubus appears to be OpenWRT specific GPL-2.0-or-later licensed and not from official GNU-project. However the source is available from their source repo, check the link below. But if you plan to compile yourselves now a stopgap replacement till Teltonika gets this fixed. I suggest you take it from their devkit instead, just incase they’ve done some changes that matter.
I found that source using Google search using: "ubus-inetd" source
The quotation above marks were because Google treats minus as a special character.
Then when I got reply that it’s openwrt stuff, I changed search to: openwrt "ubus-inetd" source github and got straight link to that source file.
It’s closed proprietary Teltonika code. Then there isn’t much you can do about it before they will fix your issue. I’m sorry about inconvenience my mistake caused to you.
Quickly searching closed source packages under ./package/teltonika subdirectories $ find . -name Makefile -print0 | xargs -0 grep "PKG_LICENSE:=Teltonika-closed" | wc -l 97
Genuinely I didn’t expect quite that many. But anyway, nothing much we can do ourselves about it. Just need to wait Teltonika issue the fix.
While you ask them to fix it, you also propose developement add a simple test to check that this would not repeat again in future.
Test run from shell
# netstat -lt | grep ‘:ssh’ | wc -l
need to return 2, when ssh listens both IP protocols.
Software regressions are well known problem that can bite later especially if development is using many codebases or if for any reason for some reason old codebase without patches was reverted after refactoring that was started caused unexpected issues etc. reasons.
Apologies for any inconvenience this issue may have caused.
Our RnD team has confirmed that this is a known issue, and a fix is planned for the 7.25 firmware release.
As a temporary workaround, you can modify the /etc/init.d/dropbear script to pass --port :::22 --port 0.0.0.0:22 to inetd-ubus.
The ubus-inetd package is licensed under the Teltonika-closed license. Therefore, not all packages included in the SDK are required to have their source code published. However, all packages licensed under the GPL do include the patches and modifications we have made.
Thanks. But I’ve seen this IPv6 omission happening again and again, before this it was bgp support.
You need to, internally, drive home for all features that they need to work for IPv4 AND IPv6. This needs to be in the checkbox for when the feature is signed off as completed, that it’s been tested for both IPv4 and IPv6. There seems to be an IPv4-only mentality within Teltonika, and it seems you need proceedures to handle this.
riku