Closed gromit1811 closed 5 days ago
Thanks for your detailed message. Can your share the content to conf.iface ? Can you try to set it to veth0a if not alteady set to this interface?
It's "lo" by default:
>>> conf.iface
<NetworkInterface lo [UP+LOOPBACK+RUNNING]>
>>>
If I set it to "veth0a", the warnings disappear and I get proper source addresses for the MLD packet.
Thanks for your answer! I was expecting this result.
Scapy uses conf.iface
to build Packets, while the send()
function iface
argument is used to specify the output interface. With IPv6 and link-local addresses, it is mandatory to setup both conf.iface
and iface
to the same value to get the desired result, as Scapy cannot find which interface to use for link-local communications. Previous defaults were not satisfactory and we change the previous default behavior.
Currently, get_working_if()
is the culprit and returns the loopback interface when no default IPv4 route is found.
We could add some IPv6 logic but it will be tricky for link-local address and only work fine with a single network interface when no IPv4 route exists:
Thanks for your explanation! And thanks a lot for such a useful tool, BTW!
I wasn't aware of the different purposes of conf.iface
and sendp(iface=XXX)
. It's clear that the sendp()
argument is used for the actual transmission, but I assumed that this would also be used to build the packet, because with IPv6 link-local traffic, there's no way you can build a correct packet without taking the actual outgoing interface into account. I guess if I would have had a default route on an interface other than veth0a
, scapy wouldn't have complained but would have silently built a packet with the wrong source address, right?
May I suggest to mention this important difference in the docs (in Usage/Sending Packets and possibly also in the API reference)? And if I understand correctly, send()
is affected as well. Just gave it a try and there I even don't see a packet being transmitted without setting conf.iface
properly. So I guess conf.iface
should be much more prominent in the docs. :wink:
BTW, I also gave scapy 2.4.4 another try: There it picked veth0b
as its default interface, so it used the wrong source for sending on veth0a
as well. But it didn't look as wrong an "all 0s" address, so the IP stack accepted it.
Brief description
I'm trying to generate an IPv6 MLD query using scapy. With scapy 2.4.4 (in Debian 11) it works as expected. With 2.5.0 (Debian 12) and current git a05013cf source address selection is weird. If I'm not specifying IPv6 and MAC source addresses explicitly, they're both all 0s. With scapy 2.4.4, I got the IPv6 link-local address of the sending interface (and the associated MAC address) as expected.
In addition, I'm getting 3 of these warnings:
True, there is no default route (and also no global IPv6 address), but I don't see why I'd need one - MLD query is a link-local multicast packet, so the source address should be link-local as well.
BTW, this might be related to #4304 (I'm seeing the same warning messages), but in this case here, functionality is impacted, so it's not just a warning that can be safely ignored.
Scapy version
2.5.0.dev300
Python version
3.11.2
Operating system
Debian bookworm 12, kernel 6.6.13-1~bpo12+1
Additional environment information
Tested in a Linux network namespace with only a veth pair, completely isolated from the rest of the network stack. The environment I noticed this originally was also in a netns, but with a few more interfaces and a bridge.
How to reproduce
Use this script to create a "testns" namespace, set up a veth pair, run scapy and monitor packets with tcpdump:
Actual result
Note the bogus source addresses in the tcpdump output.
Expected result
This is with the same script and scapy 2.4.4:
I can get a result like this also with scapy 2.5.0 if I explicitly specify source addresses in
Ether()
andIPv6()
, but I don't think that should be necessary.Related resources
Note that this is from a different run (scapy git a05013cf again), so addresses are different: