Strange behavior of 'ip rule'

Installing and Using OpenWrt Network and Wireless Configuration
1 
root@:~# ip rule
0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 
root@:~# ip rule add prio 100 fwmark 1 lookup 1
root@:~# ip rule add prio 100 fwmark 2 lookup 1
root@:~# ip rule add prio 100 fwmark 2361 lookup 1
root@:~# ip rule
0:      from all lookup local 
100:    from all fwmark 0x439894 lookup 1 
100:    from all fwmark 0x439894 lookup 1 
100:    from all fwmark 0x439894 lookup 1 
32766:  from all lookup main 
32767:  from all lookup default

Has anyone encountered this problem?

2

Which ip you are using??
Dumb ip from busybox, ip-tiny or ip-full ?

3 
Package: ip-full
Version: 4.19.0-5
Depends: libc, libnl-tiny
Provides: ip
Status: install user installed
Architecture: mipsel_24kc
Installed-Time: 1542662102

There is a way to use ip from busybox if ip-full already in system?

4

Yes. Directly call /bin/busybox with ip as parameter.
See below. First ip-tiny and then busybox ip.


 OpenWrt SNAPSHOT, r8615-9808bd2799
 -----------------------------------------------------

root@router1:~# which ip
/sbin/ip

root@router1:~# ip
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
       ip [ -force ] -batch filename
where  OBJECT := { link | address | route | rule | neigh | tunnel | maddress |
                   mroute | mrule | monitor | netns | macsec | token | ila |
                   vrf | sr }
       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
                    -h[uman-readable] | -iec | -j[son] | -p[retty] |
                    -f[amily] { inet | inet6 | ipx | dnet | mpls | bridge | link                                                                    } |
                    -4 | -6 | -I | -D | -M | -B | -0 |
                    -l[oops] { maximum-addr-flush-attempts } | -br[ief] |
                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename]                                                                    |
                    -rc[vbuf] [size] | -n[etns] name | -a[ll] | -c[olor]}
root@router1:~#
root@router1:~#
root@router1:~#
root@router1:~# /bin/busybox ip
BusyBox v1.29.3 () multi-call binary.

Usage: ip [OPTIONS] address|route|link|neigh|rule [COMMAND]

OPTIONS := -f[amily] inet|inet6|link | -o[neline]
COMMAND :=
ip addr add|del IFADDR dev IFACE | show|flush [dev IFACE] [to PREFIX]
ip route list|flush|add|del|change|append|replace|test ROUTE
ip link set IFACE [up|down] [arp on|off] [multicast on|off]
        [promisc on|off] [mtu NUM] [name NAME] [qlen NUM] [address MAC]
        [master IFACE | nomaster]
ip neigh show|flush [to PREFIX] [dev DEV] [nud STATE]
ip rule [list] | add|del SELECTOR ACTION
2 Likes
5

so, is this a bug or feature?

6 
root@:~# /bin/busybox ip rule add prio 100 fwmark 1 lookup 1
root@:~# /bin/busybox ip rule
0:      from all lookup local 
100:    from all fwmark 0x1 lookup 1 
32766:  from all lookup main 
32767:  from all lookup default

Thanks, it works.

1 Like
7

It is possibly something similar incompatibility between iproute and kernel version, that cwbsw noticed in the other thread
Maybe the recent upgrade of iproute to 4.19 was too early.
"ip rule add sport" can not work as expected

8

The ip rule display fwmark issue in 4.19 is caused by upstream commit https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/lib/json_print.c?id=45ec4771d40cb367377e4148a2af22f25c20f3bf which changed unsigned int into unsigned long long
I'm surprised (or at least I could not find any related issue) that no other iproute2 users have reported this problem.
The issue will need to be reported upstream on the netdev mailing list

1 Like