After power cycling Fritz and Libero [1], Libero starts obtaining addresses starting at x.20 again.
ARP table
? (192.168.178.20) at 80:7d:3a:c2:de:44 on en1 ifscope [ethernet]
? (192.168.178.22) at 80:7d:3a:c2:de:44 on en1 ifscope [ethernet]
? (192.168.178.24) at 80:7d:3a:c2:de:44 on en1 ifscope [ethernet]
? (192.168.178.26) at 80:7d:3a:c2:de:44 on en1 ifscope [ethernet]
? (192.168.178.29) at 80:7d:3a:c2:de:44 on en1 ifscope [ethernet]
? (192.168.178.31) at 80:7d:3a:c2:de:44 on en1 ifscope [ethernet]
? (192.168.178.33) at 80:7d:3a:c2:de:44 on en1 ifscope [ethernet]
TIMING AND PERFORMANCE:
Options which take <time> are in seconds, or append 'ms' (milliseconds),
's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
-T<0-5>: Set timing template (higher is faster)
--min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes
--min-parallelism/max-parallelism <numprobes>: Probe parallelization
--min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies
probe round trip time.
--max-retries <tries>: Caps number of port scan probe retransmissions.
--host-timeout <time>: Give up on target after this long
--scan-delay/--max-scan-delay <time>: Adjust delay between probes
--min-rate <number>: Send packets no slower than <number> per second
--max-rate <number>: Send packets no faster than <number> per second
Outcome
Host probing by ping scan
$ sudo nmap -sn --min-parallelism 128 -oG - 192.168.178.0/24
Warning: Your --min-parallelism option is pretty high! This can hurt reliability.
# Nmap 7.70 scan initiated Thu Jul 4 15:51:00 2019 as: nmap -sn --min-parallelism 128 -oG - 192.168.178.0/24
Host: 192.168.178.1 (fritz.box) Status: Up
Host: 192.168.178.34 (andromeda.fritz.box) Status: Up
Host: 192.168.178.35 (fritz.repeater) Status: Up
Host: 192.168.178.53 () Status: Up
Host: 192.168.178.101 (offgrid.fritz.box) Status: Up
# Nmap done at Thu Jul 4 15:51:01 2019 -- 256 IP addresses (5 hosts up) scanned in 0.68 seconds
Port probing, with Host discovery
$ nmap -p 23 --min-parallelism 128 -oG - 192.168.178.0/24
Warning: Your --min-parallelism option is pretty high! This can hurt reliability.
# Nmap 7.70 scan initiated Thu Jul 4 15:52:32 2019 as: nmap --min-parallelism 128 -p 23 -oG - 192.168.178.0/24
Host: 192.168.178.1 (fritz.box) Status: Up
Host: 192.168.178.1 (fritz.box) Ports: 23/closed/tcp//telnet///
Host: 192.168.178.35 (fritz.repeater) Status: Up
Host: 192.168.178.35 (fritz.repeater) Ports: 23/closed/tcp//telnet///
Host: 192.168.178.55 () Status: Up
Host: 192.168.178.55 () Ports: 23/open/tcp//telnet///
Host: 192.168.178.101 (offgrid.fritz.box) Status: Up
Host: 192.168.178.101 (offgrid.fritz.box) Ports: 23/closed/tcp//telnet///
# Nmap done at Thu Jul 4 15:52:33 2019 -- 256 IP addresses (4 hosts up) scanned in 1.27 seconds
Isn’t this a function of DHCP? We can recommend to assign always the same IP. This is possible in the Fritzbox settings, but of cause no general solution.
May I humbly ask @MKO, @clemens or @tonke to check whether this will work on a WSL2’ed Debian/Ubuntu and tell me about its outcome? I’m actually interested in success and speed. Thanks already!
P.S.: If this works and you feel adventurous, you might want to try speeding things up:
#! /usr/bin/env python
import sys
from scapy.all import *
def arp_monitor_callback(pkt):
if ARP in pkt and pkt[ARP].op in (1,2): #who-has or is-at
print(pkt.sprintf("%ARP.hwsrc% %ARP.psrc%"))
sys.stdout.flush()
sniff(prn=arp_monitor_callback, filter="arp", store=0)
Sorry to hear that. arpmon.py for Scapy feels reasonably snappy for me, so you might want to try that route. I am looking at this as we can integrate it into our tooling more seamlessly than having to parse output of any other command line tool.
sorry for the misunderstanding.
I mean, my ping in a loop on all ip. With this command:
for /l %i in (1,1,255) DO @ping 192.168.178.%i -n 1 | find “Bytes=”
Arp works fast on Windows command
arp -a | find “80-7d-3a”
All good, no misunderstanding at all. Following regular ICMP ping requests will always be a magnitude slower, especially when doing that sequentially from userspace.
Right, that’s why I would favor it over actually scanning the network. The Python thing is just that: Watching the network for ARP events. If we could get the basic version work on Windows, I would gain more confidence in going down that route.
I also like this as it will read ARP discovery packages directly from the network probably without touching the operation system’s ARP table at all which sometimes confuses me.
Unfortunately I do not have enough time now, but I’ll see if I can fix it.
Under Windows directly, I seem to have a damaged installation of python. I will try it there again.
