Skip to content
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

ARPingResult of subnet is incomplete and missing results when comparing with tcpdump #4168

Open
stijnh92 opened this issue Nov 2, 2023 · 4 comments

Comments

@stijnh92
Copy link

stijnh92 commented Nov 2, 2023

Brief description

When performing the arping function of a /24 subnet, the returned ARPingResult is not complete.
When taking a tcpdump in the background, we can see that we receive results from a .1 up until a .254 address (with some IPs in between that do not report anything, but that is expected). If we loop over the ARPingResult object returned from the arping method, we get inconsistent results. Sometimes it's up until a .185 address, sometimes a .187 or best case a .190 address.

Scapy version

2.5.0

Python version

3.11.2

Operating system

Debian 6.1.55-1

Additional environment information

No response

How to reproduce

import sys, os
import contextlib

from scapy.layers.l2 import arping, Ether, ARP

def perform_arping(destination, interface):
    data = list()
    result, _ = arping(destination, iface=interface, verbose=False)
    for _, r in result.res:
        data.append((r[Ether].src, r[ARP].psrc))

    return data

for mac, ip in perform_arping(sys.argv[1], sys.argv[2]):
    print(mac + ',' + ip)

Actual result

Last three lines of the response:

00:50:56:95:ec:ea,10.8.81.188\n
00:50:56:95:ec:ea,10.8.81.189\n
00:50:56:95:ec:ea,10.8.81.190\n

Expected result

Last three lines of the simultaneous running tcpdump process:

10:29:30.468975 ARP, Reply 10.8.81.246 is-at 6c:13:d5:e6:ad:6b (oui Unknown), length 46
10:29:30.483812 ARP, Reply 10.8.81.251 is-at 00:50:56:95:ec:ea (oui Unknown), length 46
10:29:30.494336 ARP, Reply 10.8.81.254 is-at 00:00:0c:9f:f6:55 (oui Cisco), length 46

Related resources

No response

@gpotter2
Copy link
Member

gpotter2 commented Nov 3, 2023

Hi. Did you try increasing the timeout ? timeout=5 in arping.

@stijnh92
Copy link
Author

stijnh92 commented Nov 6, 2023

@gpotter2 yes, no difference in result when modifying the timeout (even tried increasing it to 60 without result)

@gpotter2
Copy link
Member

gpotter2 commented Feb 19, 2024

What about with threaded=True. That should most likely make a much bigger difference.

Very sorry for the delay btw.

@stijnh92
Copy link
Author

Hey @gpotter2, no problem. We have made our own implementation by starting a tcpdump process before executing the arping function and then processing that file when it's done. I will test with the threaded parameter later. But iirc, we already tried with the same unsuccessful results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants