From d9ae1eec022f6c9cf855cecfaface08c810e5ec6 Mon Sep 17 00:00:00 2001 From: Seth Schoen Date: Wed, 7 Oct 2020 17:30:58 -0700 Subject: [PATCH] Add test and notes for 127/8 --- tests/linux-selftest.sh | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/tests/linux-selftest.sh b/tests/linux-selftest.sh index e779816..01a53f6 100755 --- a/tests/linux-selftest.sh +++ b/tests/linux-selftest.sh @@ -50,8 +50,26 @@ pingtest 255.255.255.1 255.255.255.255 16 && result=1 # But, even 255.255/16 is OK! pingtest 255.255.3.1 255.255.50.77 16 || result=1 + # Test support for zeroth host # pingtest 5.10.15.20 5.10.15.0 24 || result=1 + +# Test support for not having all of 127 be loopback +# pingtest 127.99.4.5 127.99.4.6 16 || result=1 + +# Interestingly, the kernel is happy to assign these 127/8 addresses to veth +# interfaces, but even though there's no explicit routing table entry for +# them, the ping still gives "Invalid argument", like +# +# connect(5, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("127.99.4.6")}, 16) = -1 EINVAL (Invalid argument) +# +# (a TCP socket connect yields the same error) -- It's interesting because, +# if you give a different destination address inside of the netns where +# there's just no relevant route set, instead of EINVAL you'll get +# ENETUNREACH. So that confirms that 127/8 is being treated specially by +# the kernel, seemingly outside of routing table/FIB lookups. + + # TODO: Let's also have some prefixes other than /24 # TODO: It's slightly harder to have tests for TCP, not just ICMP, because # the ping responder is in the kernel, while answering TCP via netcat