When conf.use_pcap is set, the function sr() does not select proper
outgoing interfaces, so it gets zero answers.

In the following example, the proper interface for the network
192.168.168.0/24 is veth0. However, sr() sends ICMP packets to the
default inteface 'ens3' when conf.use_pcap is set:
-----BEGIN CLI-----
Network        Netmask        Gateway   Iface  Output IP      Metric
0.0.0.0        0.0.0.0        10.0.2.2  ens3   10.0.2.15      0
10.0.2.0       255.255.255.0  0.0.0.0   ens3   10.0.2.15      0
127.0.0.0      255.0.0.0      0.0.0.0   lo     127.0.0.1      1
192.168.168.0  255.255.255.0  0.0.0.0   veth0  192.168.168.1  0
'ens3'
True
Begin emission:
Finished sending 1000 packets.
.......................................................................
.......................................................................
......................................................
Received 196 packets, got 0 answers, remaining 1000 packets
(<Results: TCP:0 UDP:0 ICMP:0 Other:0>,
 <Unanswered: TCP:0 UDP:0 ICMP:1000 Other:0>)



# tcpdump -ni ens3 -c10 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol
decode
listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144
bytes
22:22:28.165580 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 1, length 8
22:22:28.167091 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 2, length 8
22:22:28.168075 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 3, length 8
22:22:28.169068 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 4, length 8
22:22:28.169988 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 5, length 8
22:22:28.170900 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 6, length 8
22:22:28.171933 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 7, length 8
22:22:28.172917 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 8, length 8
22:22:28.174020 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 9, length 8
22:22:28.174913 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id
0, seq 10, length 8
10 packets captured
94 packets received by filter
0 packets dropped by kernel
-----END CLI-----



The problem gets resolved when the proper 'iface' is set globally or
supplied to the sr() function:

-----BEGIN CLI-----
'ens3'
iface='veth0')
Begin emission:
Finished sending 1000 packets.
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
******
Received 1000 packets, got 1000 answers, remaining 0 packets
(<Results: TCP:0 UDP:0 ICMP:1000 Other:0>,
 <Unanswered: TCP:0 UDP:0 ICMP:0 Other:0>)
'veth0'
Begin emission:
Finished sending 1000 packets.
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
******
Received 1000 packets, got 1000 answers, remaining 0 packets
(<Results: TCP:0 UDP:0 ICMP:1000 Other:0>,
 <Unanswered: TCP:0 UDP:0 ICMP:0 Other:0>)
-----END CLI-----


The problem was fixed in the upstream by calling the missing function
_interface_selection() as part of general sr1() cleanup [1] for the
reported issue 3583 [2].


Considering that the upstream commit
50e867aa9ee9061e79890e5f535eb5ccb6e2a7f3 does a bit more than just
fixing the sr() function, probably just adding the missing function in
sr() might be the safest way to backport the fix to 2.4.4.

I have attached a debdiff patch that basically adds the missing
function without refactoring the related sr1() function.

Below is the result of using the updated package:

-----BEGIN CLI----
# dpkg -s python3-scapy | grep Ver
Version: 2.4.4-5
True
'ens3'
Begin emission:
Finished sending 1000 packets.
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
***********************************************************************
******
Received 1000 packets, got 1000 answers, remaining 0 packets
(<Results: TCP:0 UDP:0 ICMP:1000 Other:0>,
 <Unanswered: TCP:0 UDP:0 ICMP:0 Other:0>)
-----END CLI----


To replicate the network configuration I used for the test, the
following commands can be used:

-----BEGIN CLI----
ip net add scapy
ip link add type veth
ip link set veth1 netns scapy
ip link set veth0 up
ip addr add 192.168.168.1/24 dev veth0

ip netns exec scapy ip link set lo up
ip netns exec scapy ip link set veth1 up
ip netns exec scapy ip addr add 192.168.168.2/24 dev veth1
-----END CLI----


Please note that the requirement to set 'conf.use_pcap' is necessary in
my environment to overcome the recently found issue [3] with the native
super sockets.

Thank you.

Regards,
Garri

[1] https://github.com/secdev/scapy/pull/3610
[2] https://github.com/secdev/scapy/issues/3583
[3] https://github.com/secdev/scapy/issues/4531

Hi, Garri,

Humm, for the version, I can tell you are running Debian oldstable and
it has a older version of scapy. My sugestion is that you upgrade to
Debian bookworm which is the current stable release and has this bug
fixed. If you can't upgrade, you can build the package locally with the
fix as you proposed.

Sorry I can't help, but we don't backport fixes for minor bugs like
these, only for major ones and security vulnerabilities. Even so, we
only officialy do for oldstable for a year after the new stable has been
released and we are over that for bullseye.

Cheers,
Charles

Hi Charles,

Thank you so much for your explanation. It seems I misunderstood the
purpose of the LTS team and assumed that in LTS phase minor bug fixes
are also accepted. Also, I got an impression that LTS bugs can be
submitted to submit@bugs.debian.org. Now, after rereading the pages
DebianReleases and LTS, I have full understanding of how the Debian
maintenance process is organised.

I fully agree that building and maintaining a local package is a good
option until we upgrade to Debian 12.

Regards,
Garri