netdev - A linux route cache (flush) irregularity...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CANP3RGc15v262aev2ZSo3PG9dOmKiJ0-57XjKiOmO29dbt94=w@mail.gmail.com>
Date:   Mon, 26 Dec 2022 04:26:56 -0800
From:   Maciej Żenczykowski <zenczykowski@...il.com>
To:     Linux NetDev <netdev@...r.kernel.org>
Cc:     Jean Chalard <jchalard@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: A linux route cache (flush) irregularity...

I can't seem to explain the following...
without there being some part/aspect of the route cache that 'ip route
flush cached' doesn't actually flush...
(ping output below slightly trimmed to make this log shorter)

This is on a 5.19.11-1rodete1-amd64 debian (or ubuntu?) based gLinux
kernel (I don't *think* there's any special gLinux hacks in it that
would be relevant though)
on a laptop connected via wifi to a cellular hotspot with 1460 mtu
path to the internet.

# ip route flush cached
# ip route show cached

# ping -c 1 -s $[1500-28] 8.8.8.8
>From 10.0.0.200 icmp_seq=1 Frag needed and DF set (mtu = 1460)

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache expires 86396sec mtu 1460

# ping -c 1 -s $[1460-28] 8.8.8.8
76 bytes from 8.8.8.8: icmp_seq=1 ttl=113 (truncated)

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache expires 86390sec mtu 1460

# ping -c 1 -s $[1460-28] 1.1.1.1
1440 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=39.0 ms

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache expires 86381sec mtu 1460

# ip route flush cached
# ip route show cached

# ping -c 1 1.1.1.1
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=26.9 ms

# ping -c 1 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=50.0 ms

# ip route show cached
8.8.8.8 via 10.0.0.200 dev wlp0s20f3
    cache

Up until this spot I could explain everything, but why is there now an
entry for 8.8.8.8 but not 1.1.1.1?

The only explanation I can think of is that *some* part of the route
cache has actually remembered that a per-ip override for 8.8.8.8 needs
to be generated, but not for 1.1.1.1...

No, this doesn't really matter, but I'm the curious sort...
[side note: it also appears that 'ip route flush cached' and/or 'ip
route show cached' might be asynchronous...]

- Maciej