[Automaton] add ability to work with multiple interfaces

[matsievskiysv]

This PR adds support for multiple listening and sending interfaces for Automaton. Its syntax is similar to sniff's syntax:

• when creating new Automaton instance, iface argument accepts an interface name or a list of interface names;
• Automaton.my_send has an optional argument iface that specifies an interface or a list of interfaces to send a packet to;
• ATMT.receive_condition can access packet's sniffed_on field to learn on which interface it was received.

Rationale:

Some protocols like ERPS require PDUs to be sent and received on more than one interface. Their state machine logic requires information about the port from which the packet was received.

This PR adds support for multiple interface state machines.

This PR is related to #3636.

[codecov[bot]]

Codecov Report

Merging #3642 (2341c3c) into master (b26f228) will decrease coverage by 1.61%. The diff coverage is 63.63%.

@@            Coverage Diff             @@
##           master    #3642      +/-   ##
==========================================
- Coverage   86.21%   84.60%   -1.62%     
==========================================
  Files         296      296              
  Lines       67079    62101    -4978     
==========================================
- Hits        57831    52538    -5293     
- Misses       9248     9563     +315     

Impacted Files	Coverage Δ
scapy/automaton.py	72.87% <63.63%> (-1.48%)	:arrow_down:
scapy/contrib/isotp/isotp_scanner.py	18.18% <0.00%> (-74.42%)	:arrow_down:
scapy/contrib/cansocket_python_can.py	59.37% <0.00%> (-23.13%)	:arrow_down:
scapy/layers/kerberos.py	70.93% <0.00%> (-12.62%)	:arrow_down:
scapy/arch/common.py	66.66% <0.00%> (-10.00%)	:arrow_down:
scapy/layers/llmnr.py	87.50% <0.00%> (-9.28%)	:arrow_down:
scapy/contrib/automotive/gm/gmlan_ecu_states.py	91.30% <0.00%> (-8.70%)	:arrow_down:
scapy/contrib/automotive/uds_ecu_states.py	85.71% <0.00%> (-7.39%)	:arrow_down:
...apy/contrib/automotive/scanner/staged_test_case.py	84.87% <0.00%> (-6.28%)	:arrow_down:
scapy/contrib/automotive/scanner/executor.py	79.63% <0.00%> (-4.66%)	:arrow_down:
... and 58 more

[matsievskiysv]

Failed unit test is irrelevant because the same test for the same commit succeeded in my copy of the repo.

[polybassa]

LGTM. Please do a rebase and push to trigger a new CI build.

[matsievskiysv]

@polybassa Done. One pipeline failed because of some obscure error. It doesn't seem to be related to automaton.

[p-l-]

I like your PR! Quick question: in my_send(), you have two loops for socket in self.send_socks (depending on whether or not an interface has been explicitly set or not). My question is, once an interface has been found and the packet sent, should we stop the loop with a break? That's a true question (meaning, I don't have the answer but would like to start a discussion on that). I'm calling @guedou @gpotter2 @polybassa who might have an opinion (and of course you, @matsievskiysv). What do you think?

[matsievskiysv]

AFAIK, my_send is not documented anywhere. I don't really understand its purpose and use cases.

[p-l-]

Well since your PR touches this function a lot (that's where you implement the logic of your proposed change), I suppose you do have a little idea of what it does!

[matsievskiysv]

I suppose you do have a little idea of what it does!

I mean, I don't know its original purpose, since there's no documentation or examples.

My question is, once an interface has been found and the packet sent, should we stop the loop with a break?

Therefore, I cannot really say how it should behave in this case.

[gpotter2]

my_send is a very useful function. It's how you send packets when inside a network automaton. You would use receive_condition conditions to listen, and my_send to send packets back.