Fallback to IPv6 default routes for network interface detection

[guedou]

This PR improves the selection of the default interface in an IPv6-only environment. See #4304 for context

To maintainers: shoud I add unit tests?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.53%. Comparing base (ac3d5bb) to head (6a4d90a).
Report is 49 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4321      +/-   ##
==========================================
- Coverage   82.20%   78.53%   -3.67%     
==========================================
  Files         353      354       +1     
  Lines       83529    92937    +9408     
==========================================
+ Hits        68662    72985    +4323     
- Misses      14867    19952    +5085     

Files	Coverage Δ
scapy/interfaces.py	96.80% <100.00%> (+0.20%)	⬆️
scapy/route6.py	86.26% <100.00%> (-2.14%)	⬇️

... and 66 files with indirect coverage changes

[gpotter2]

I would argue this needs tests considering it's already a regression.

Also you need to rebase ;p

[gpotter2]

This makes me kinda wonder why we deprecated conf.iface6.

[guedou]

I always found conf.iface6 confusing. It makes sense to use it to control how IPv6 packets are built, but fe80::/64 and multiple interfaces break its usefulness. However, for sending with high-level functions or SuperSocket, it adds complexity and non-standard behavior. When iface= is not specified by the user, shall Scapy use conf.iface6, conf.iface or both ? It gets even more complicated if we consider that sr*() can receive a list of IP and IPv6 packets that must be sent to different interfaces.

[oskar456]

Hey, I only noticed this after I opened my own PR #4380.
According to my tests, it is not going to work because conf.route6 is not populated by the time get_working_if() is called. This can be fixed by calling conf.ifaces.reload() at the end of route6.py.
Also I think it would be better to consider only default or generic enough routes. When someone has for instance an IPv6-only machine with a VPN that pushes route say 10.0.0.0/8, then the interface with IPv6 default route should be preferred over the VPN interface with /8 IPv4 route.

[guedou]

@oskar456 sorry for the delay. I slightly modified this PR and it should now work as expected. Do you have time to test it?

[oskar456]

Hey, thanks a lot! I can confirm that this PR fixes #4304.

[gpotter2]

So we have to discuss a bit regarding this.
It's a good idea to have a better default selection when no IPv4 is available, however I disagree with the added documentation regarding iface and conf.iface.

Regarding link-local / multicast destinations, #4461 should properly add a route on interfaces that support multicast, so that should supposedly also fix the OP's question (as they only have a single interface with multicast). It also allows for a much more flexible behavior, which aims at avoiding to have to change conf.iface or iface.

[gpotter2]

Yeah I disagree with that now that we have Scoped IPs.
The PR is still useful though, I think having a better default conf.iface is good, especially for L2 functions. (e.g. sniff)

[gpotter2]

That's a bit crappy. We only need to reload the default interface, not the entire interface list