Many OpenWrt commands lack some necessary options, so do this

Many OpenWRT commands lack some necessary options. For example, traceroute lacks the -I option, and the date -d option cannot implement the "-n days" function. How should these problems be solved?

As the storage space on most routers is sparse, OpenWrt uses the busybox implementation of many commands. This takes significant less space, at cost of a less complete implementation.
But if you need the 'full version', in many cases there is a package for that.

5 Likes

There are indeed two versions of mini and full commands, but not all commands can be found in both versions. For example, the two commands I mentioned earlier are not found.

That is interesting case, as there used to be full traceroute apps in the iputils package.

But iputils was moved in 2019 to packages feed and the source upstream was changed at the same time. Apparently the full traceroute apps were dropped at that point.

1 Like

The issue is that the default busybox date is optimized for size and hence eaves out some options.
but OpenWrt offers the coreutils date as a replacement: opkg update; opkg install coreutils-date:

root@turris:~# date -d 'now'
Thu Jul  8 10:32:28 CEST 2021
root@turris:~# date -d '-7 days'
Thu Jul  1 10:32:34 CEST 2021

For traceroute I agree; iputils-traceroute6 exists as packet, but not iputils-traceroute (and these are two different programs).
Question: what for do you need flowlabels on traceroutes (and especially from the router?)
Personally, I stopped using traceroute mostly and use mtr instead, but that does not offer setting flow labels either as far as I know.

By default, openwrt traceroute sends udp packets. Some routers will not respond, but if you use the windows tracert command, you can respond normally. The reason is that the tracert of windows uses the ICMP protocol.

Ah, so capital "EYE" and not lower case "ELL", well mtr has you covered, as it uses ICMP by default. I like:
mtr -ezbw -c 10 8.8.8.8 a lot:

root@turris:~# mtr -ezbw -c 10 8.8.8.8
Start: 2021-07-08T11:16:45+0200
HOST: turris                                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   loopback1.0004.acln.06.ham.de.net.telefonica.de (62.52.201.201)      0.0%    10   13.8  13.4  13.2  13.8   0.2
  2. AS6805   bundle-ether11.0001.dbrx.06.ham.de.net.telefonica.de (62.53.7.108)   0.0%    10   13.8  14.0  13.8  14.2   0.1
  3. AS6805   bundle-ether1.0001.prrx.06.ham.de.net.telefonica.de (62.53.2.91)     0.0%    10   13.8  13.9  13.6  14.1   0.1
  4. AS15169  72.14.208.60 (72.14.208.60)                                          0.0%    10   14.6  13.7  13.1  14.9   0.6
  5. AS15169  108.170.253.65 (108.170.253.65)                                      0.0%    10   13.6  13.8  13.6  14.0   0.1
  6. AS15169  216.239.54.181 (216.239.54.181)                                      0.0%    10   13.3  13.5  13.3  13.9   0.2
  7. AS15169  dns.google (8.8.8.8)                                                 0.0%    10   13.6  13.6  13.4  13.9   0.2
root@turris:~# 

or an interactive on-line updated continously running invocation (stop with ^c):
mtr -ezb 8.8.8.8

OpenWrt traceroute actually accepts the "-I" argument, but I have not confirmed whether it actually send ICMP, it might just silently ignore this (but it complains about "-T"). Mmmh, traceroute -v -I 8.8.8.8 actually presents output indicating it uses ICMP (this test was on turris OS 5.2 which is derived from OpenWrt 19.07 as far as I know). Yes the "-EYE" is not documented/reported by traceroute -h but it does seem to work.

What device do you have? If you have storage space available perhaps it's worth looking at another distro that doesn't target embedded devices with very limited space? You can in theory shoehorn "anything" into OpenWrt but it's probably not worth the effort. As for traceroute itself https://github.com/diizzyy/packages/commit/3498bd686e1c05a4799289f786810169b3c877b9 might be of interest as that's the one you find in most Linux distributions.

I tried the

traceroute -v
BusyBox v1.31.1 () multi-call binary.

with -I , but it still sends UDP.

2 Likes

Mmmh:

root@turris:~# ls -all $( which traceroute )
lrwxrwxrwx    1 root     root             7 May 14 13:11 /bin/traceroute -> busybox
root@turris:~# traceroute -v -I 95.116.20.197
traceroute to 95.116.20.197 (95.116.20.197), 30 hops max, 38 byte packets
 1  dynamic-095-116-020-197.95.116.pool.telefonica.de (95.116.20.197) 46 bytes to (null)  0.011 ms
8 bytes from 95.116.20.197 to 95.116.20.197: icmp type 8 (Echo) code 0
 4: x26000045
  0.053 ms  0.009 ms
root@turris:~# 

but I did not tcpdump this.

Here is that now:

root@turris:~# traceroute -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
 1  loopback1.0004.acln.06.ham.de.net.telefonica.de (62.52.201.201)  12.907 ms  12.686 ms  12.870 ms
 2  bundle-ether11.0001.dbrx.06.ham.de.net.telefonica.de (62.53.7.108)  13.179 ms  13.078 ms  13.166 ms
 3  bundle-ether1.0002.prrx.06.ham.de.net.telefonica.de (62.53.2.129)  13.215 ms  bundle-ether1.0001.prrx.06.ham.de.net.telefonica.d
e (62.53.2.91)  13.652 ms  bundle-ether1.0002.prrx.06.ham.de.net.telefonica.de (62.53.2.129)  14.520 ms
 4  *  72.14.208.60 (72.14.208.60)  12.986 ms  12.878 ms
 5  108.170.253.65 (108.170.253.65)  13.396 ms  *  108.170.253.49 (108.170.253.49)  14.125 ms
 6  dns.google (8.8.8.8)  13.153 ms  13.030 ms  209.85.251.207 (209.85.251.207)  13.171 ms
root@turris:~# 

and from a second shell:

root@turris:/srv/persistent/captures# tcpdump -nni pppoe-wan icmp and host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
13:34:00.975238 IP 95.116.20.197 > 8.8.8.8: ICMP echo request, id 54878, seq 19450, length 64
13:34:00.988277 IP 8.8.8.8 > 95.116.20.197: ICMP echo reply, id 54878, seq 19450, length 64
13:34:07.357136 IP 8.8.8.8 > 95.116.20.197: ICMP 8.8.8.8 udp port 33450 unreachable, length 36
13:34:07.370608 IP 8.8.8.8 > 95.116.20.197: ICMP 8.8.8.8 udp port 33451 unreachable, length 36
13:34:30.975989 IP 95.116.20.197 > 8.8.8.8: ICMP echo request, id 54878, seq 19451, length 64
13:34:30.989015 IP 8.8.8.8 > 95.116.20.197: ICMP echo reply, id 54878, seq 19451, length 64
13:35:00.975454 IP 95.116.20.197 > 8.8.8.8: ICMP echo request, id 54878, seq 19452, length 64
13:35:00.988753 IP 8.8.8.8 > 95.116.20.197: ICMP echo reply, id 54878, seq 19452, length 64
13:35:30.975657 IP 95.116.20.197 > 8.8.8.8: ICMP echo request, id 54878, seq 19453, length 64
13:35:30.988755 IP 8.8.8.8 > 95.116.20.197: ICMP echo reply, id 54878, seq 19453, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

I am not 100% certain (due to the unexpected " udp port 33450 unreachable" in there) but that looks like ICMP is used, no?

Yes, in your case it is ICMP.
In my case it started immediately with UDP

root@magiatiko / > tcpdump -i pppoe-wan host 8.8.4.4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
12:39:05.112220 IP my_address.33238 > dns.google.33435: UDP, length 18
12:39:05.113650 IP my_address.33238 > dns.google.33436: UDP, length 18
12:39:05.114595 IP my_address.33238 > dns.google.33437: UDP, length 18

...

root@magiatiko / > traceroute -v -I 8.8.4.4
traceroute to 8.8.4.4 (8.8.4.4), 30 hops max, 46 byte packets
 1  gw (gw_address) 54 bytes to (null)  0.993 ms  0.849 ms  0.733 ms
 2  gw2 (gw2_address) 54 bytes to (null)  0.839 ms  0.801 ms  0.815 ms
 3  213.175.55.177 (213.175.55.177) 36 bytes to (null)  1.203 ms  1.257 ms  1.145 ms
 4  cz-prg-p1sit-hunge0-1-0-1.dialtelecom.cz (82.119.246.105) 148 bytes to (null)  4.662 ms  4.669 ms  4.765 ms
 5  cz-prg-asbr1-hunge-0-0-0-0.dialteleceom.cz (82.119.246.66) 76 bytes to (null)  4.980 ms  4.884 ms  5.117 ms
 6  72.14.220.118 (72.14.220.118) 76 bytes to (null)  6.197 ms  8.454 ms  8.310 ms
 7  *  *  *
 8  dns.google (8.8.4.4) 36 bytes to (null)  4.720 ms  4.984 ms  4.648 ms

Actually you won't be able to see UDP packets in the tcpdump, as you have condition icmp and host

I know, but I also used

oot@turris:/srv/persistent/captures# tcpdump -nni pppoe-wan udp and host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
13:38:44.580899 IP 95.116.20.197.47782 > 8.8.8.8.33435: UDP, length 10
13:38:44.594331 IP 95.116.20.197.47782 > 8.8.8.8.33436: UDP, length 10
13:38:44.607156 IP 95.116.20.197.47782 > 8.8.8.8.33437: UDP, length 10
13:38:44.620394 IP 95.116.20.197.47782 > 8.8.8.8.33438: UDP, length 10
13:38:44.633719 IP 95.116.20.197.47782 > 8.8.8.8.33439: UDP, length 10
13:38:44.648245 IP 95.116.20.197.47782 > 8.8.8.8.33440: UDP, length 10
13:38:44.661486 IP 95.116.20.197.47782 > 8.8.8.8.33441: UDP, length 10
13:38:44.675298 IP 95.116.20.197.47782 > 8.8.8.8.33442: UDP, length 10
13:38:44.688686 IP 95.116.20.197.47782 > 8.8.8.8.33443: UDP, length 10
13:38:44.702460 IP 95.116.20.197.47782 > 8.8.8.8.33444: UDP, length 10
13:38:49.708635 IP 95.116.20.197.47782 > 8.8.8.8.33445: UDP, length 10
13:38:54.712987 IP 95.116.20.197.47782 > 8.8.8.8.33446: UDP, length 10

so I saw a mix of UDP and ICMP packets.... a bit of a mess actually.
Given the number of udp and icmp packets though the actual tracing seems to happen over UDP, oh my....

Could it be that you (or some other device) are using this address for connectivity testing, hence the ICMP?
I intentionally used 8.8.4.4 for that reason. 8.8.8.8 is used very often to check connectivity.

2 Likes

Thank you, everyone! In order to maintain the portability of scripts under Linux systems, it is best to use common commands to solve them. I personally think that we should provide a mini version and a full version like vim, and users can choose to use them according to their own circumstances.

You got me, forgot about the collectd ping probe to 8.8.8.8 that is running in the background... so yes, you are right and OpenWrt's busybox is not properly working with ICMP, would not be amazed if this feature is simply not configured in by default (which also explains why it is missing in the traceroute -h output)

From build_dir/target-mips_24kc_musl/busybox-default/busybox-1.31.1/.config

CONFIG_TRACEROUTE=y
CONFIG_TRACEROUTE6=y
CONFIG_FEATURE_TRACEROUTE_VERBOSE=y
# CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set   

So yepp, ICMP traceroute is disabled.

1 Like