New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6 source address selection regression #4312
Comments
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:
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 Currently, 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 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, BTW, I also gave scapy 2.4.4 another try: There it picked |
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 a05013c 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 a05013c again), so addresses are different:
The text was updated successfully, but these errors were encountered: