arp-scan unter FreeBSD arm64

berni51

Open-Net-FreeBSD user
Für diverse kleine Tests und auch in Scripten nehm ich gern arp-scan, egal unter welchem OS. So auch unter FreeBSD auf dem RaspberryPi.
Aber da bekomme ich quasi keine vernünftige Ausgabe. Das klassische arp-scan -l liefert mir das hier:

Code:
root@raspi2:~ # arp-scan -l
Interface: genet0, type: EN10MB, MAC: e4:5f:01:0f:56:3d, IPv4: 192.168.0.117
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)

542 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 3.347 seconds (76.49 hosts/sec). 0 responded

Ein arp -a sagt aber, da ist Leben im Netz:
Code:
root@raspi2:~ # arp -a
raspi1.fritz.box (192.168.0.77) at dc:a6:32:c4:b9:77 on genet0 expires in 521 seconds [ethernet]
fritz.box (192.168.0.1) at e8:df:70:80:01:67 on genet0 expires in 1189 seconds [ethernet]
raspi2.fritz.box (192.168.0.117) at e4:5f:01:0f:56:3d on genet0 permanent [ethernet]

Ifconfig ist für mich unauffällig:
Code:
root@raspi2:~ # ifconfig genet0
genet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=68000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    ether e4:5f:01:0f:56:3d
    inet6 fe80::e65f:1ff:fe0f:563d%genet0 prefixlen 64 scopeid 0x1
    inet6 2003:dd:ff48:dc00:e65f:1ff:fe0f:563d prefixlen 64 autoconf
    inet 192.168.0.117 netmask 0xffffff00 broadcast 192.168.0.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Da frage ich mich, warum die Rechner im Netz nicht antworten.

Dieses Verhalten habe ich ausschliesslich mit FreeBSD (13.1) auf den Raspberries.
Irgend eine Idee?

Berni
 
Für diverse kleine Tests und auch in Scripten nehm ich gern arp-scan, egal unter welchem OS. So auch unter FreeBSD auf dem RaspberryPi.
Aber da bekomme ich quasi keine vernünftige Ausgabe. Das klassische arp-scan -l liefert mir das hier:

Dieses Verhalten habe ich ausschliesslich mit FreeBSD (13.1) auf den Raspberries.
Irgend eine Idee?
FreeBSD 13.1 aus den packages sollte man noch nicht benutzen.
Wenn Du es schon hast, dann versuch mit arpdig, statt arp-scan.
Mit FreeBSD 13.0 funktioniert beides auf dem PI:
Code:
:~ # arp-scan -I ue0 192.168.178.0/24
Interface: ue0, type: EN10MB, MAC: b8:27:eb:75:36:60, IPv4: 192.168.178.40
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.178.1    3c:a6:2f:d3:0a:d6    (Unknown)
192.168.178.22    48:02:2a:17:62:b4    B-Link Electronic Limited
192.168.178.13    b8:27:eb:62:3c:ae    Raspberry Pi Foundation

532 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 5.103 seconds (50.17 hosts/sec). 3 responded
Code:
:~ # arpdig -i ue0 192.168.178.0/24
Digging ue0:0.0.0.0 for 192.168.178.0/24
192.168.178.1 3c:a6:2f:d3:0a:d6 (fritz.box)
192.168.178.13 b8:27:eb:62:3c:ae ######.fritz.box)
192.168.178.22 48:02:2a:17:62:b4 (yxyxyx.fritz.box)
 
Danke, @morromett. Leider tut auch arpdig nicht, was es soll, kriegt scheinbar auch kein response aus dem Netz. Und Du hast Recht: Unter 13.0 hat beides noch ordentlich funktioniert.
Dabei ist doch 13.1 ein offizielles Release, woher kommt dein Wissen, dass man es nicht benutzen sollte?
 
Leider tut auch arpdig nicht, was es soll, kriegt scheinbar auch kein response aus dem Netz.
Dabei ist doch 13.1 ein offizielles Release, woher kommt dein Wissen, dass man es nicht benutzen sollte?
Dann versuch mal ein arping auf die IP-Adresse:
Code:
pkg install arping
arping -c 3 -I genet0 192.168.0.1
Bei mir funktioniert auch Wireguard nicht, mit 13.1-R auf amd64 und auf arm64 nicht.
 
arping klappt ebenfalls nicht: timeouts. Der stack blockiert alle Antworten, echt schräg.
Einzig das gute alte arp liefert Ergebnisse.

Ach ja: Auf den amd64-Systemen laufen all die arp-tools unter 13.1 einwandfrei, gerade nochmal getestet.
 
arping klappt ebenfalls nicht: timeouts. Der stack blockiert alle Antworten, echt schräg.
Einzig das gute alte arp liefert Ergebnisse.
Dann schau mal ausreichend lang (z. B. eine Stunde) mit tcpdump auf deinem PI, ob arp-requests und -replies gesehen werden und via welches Interface/MAC-Adresse:
Code:
tcpdump -c 200 -vvven arp
Evtl. auch von einem anderen Gerät in deinem (W)LAN einen arp-scan machen um zu schauen, ob der von tcpdump auf deinem PI, gesehen/wahrgenommen wird.

EDIT:

Wie ist auf deinem PI die Ausgabe von:
Code:
sysctl -a | grep -i arp
ifconfig
netstat -4nr
?
BTW: Benutzt Du IPv6 mit deinem PI?

EDIT 2:

Benutzt Du evtl. WireGuard (... wireguard-kmod aus den packages) auf amd64 mit 13.1-R?
 
Ich lass den tcpdump jetzt mal laufen.

Und ja, das gesamte Netz läuft mit IPv4+6. Wireguard benutze ich überhaupt nicht, ist auch nicht installiert.

Hier die Ausgaben:
Code:
root@raspi2:~ # sysctl -a|grep -i arp
net.link.ether.inet.log_arp_permanent_modify: 1
net.link.ether.inet.log_arp_movements: 1
net.link.ether.inet.log_arp_wrong_iface: 1
net.link.ether.inet.garp_rexmit_count: 0
net.link.ether.arp.log_level: 6
net.netdump.arp_retries: 3
net.debugnet.arp_nretries: 3
root@raspi2:~ # ifconfig
genet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=68000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    ether e4:5f:01:0f:56:3d
    inet6 fe80::e65f:1ff:fe0f:563d%genet0 prefixlen 64 scopeid 0x1
    inet6 2003:dd:ff48:dc00:e65f:1ff:fe0f:563d prefixlen 64 autoconf
    inet 192.168.0.117 netmask 0xffffff00 broadcast 192.168.0.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
root@raspi2:~ # netstat -4nr
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.0.1        UGS      genet0
127.0.0.1          link#2             UH          lo0
192.168.0.0/24     link#1             U        genet0
192.168.0.117      link#1             UHS         lo0
root@raspi2:~ #
 
Hab die letzten Stunden vor dem Bildschirm mit laufendem tcpdump entsprechend dem Tipp von @morromett verbracht. Das sah für mich jetzt alles ehr ordentlich aus:
Die regelmässigen Anfragen der Fritzbox, gezielte arp-Anfragen vom Raspi selbst oder von einem anderen Rechner im Netz - alles wird erkannt.
Bin schon wieder ratlos. Oder immer noch.
 
Die regelmässigen Anfragen der Fritzbox, gezielte arp-Anfragen vom Raspi selbst oder von einem anderen Rechner im Netz - alles wird erkannt.
Versuch mal den arping mit dem Interface im promiscious mode und mit der gid 0:
Code:
arping -c 3 -p -g 0 -i genet0 192.168.0.1
Poste mal die Ausgabe.
 
Da kommt nur
Timeout
Timeout
Timeout
3 packets transmitted, 0 packets received, 100% unanswered (0 extra)
 
3 packets transmitted, 0 packets received, 100% unanswered (0 extra)
Du hast in deinem LAN einen 2. PI (mit der IP-Adresse 192.168.0.77). Starte mal auf diesem 2. PI:
Code:
tcpdump -c 300 -vvven arp and host 192.168.0.117
Wie ist die Ausgabe von tcpdump, wenn Du jetzt auf deinem 1. PI:
Code:
arping -c 3 -i genet0 192.168.0.77
ausführst?
 
Vielleicht hängt das damit zusammen:


General Network​

The handling of the lowest address on an IPv4 (sub)net (host 0) has been changed so that packets are not sent as a broadcast unless this address has been set as the broadcast address. This makes the lowest address usable for a host. The old behavior can be restored with the net.inet.ip.broadcast_lowest sysctl. See https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ for background information. 3ee882bf21af

Ich vermute das man mit
Code:
sysctl net.inet.ip.broadcast_lowest=1
das umschalten kann

Der Commit enthält noch nützliche Infos:


Change lowest address on subnet (host 0) not to broadcast by default.
The address with a host part of all zeros was used as a broadcast long ago, but the default has been all ones since 4.3BSD and RFC1122. Until now, we would broadcast the host zero address as well as the configured address. Change to not broadcasting that address by default, but add a sysctl (net.inet.ip.broadcast_lowest) to re-enable it. Note that the correct way to use the zero address for broadcast would be to configure it as the broadcast address for the network. See https:/datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/ and the discussion in https://reviews.freebsd.org/D19316. Note, Linux now implements this.
 
Dieses Verhalten habe ich ausschliesslich mit FreeBSD (13.1) auf den Raspberries.
Was für Raspberries (raspi1 und raspi2) sind das? ... PI3 und/oder PI4?

Hm, ... mit amd64 und 13.1 geht es ja. Warum sollte der default-Wert für "net.inet.ip.broadcast_lowest", bei arm64(13.1) anderes sein als bei amd64(13.1)?
 
@morromett: Das Ergebnis ist wie vorher: Timeouts.
Auf dem 2. Pi läuft auch kein FreeBSD sondern ein Debian (wegen Xeoma), und da funktionieren die arp-tools einwandfrei.

Ganz schräg wurde es durch den Hinweis von @schorsch_76. Der Parameter net.inet.ip.broadcast_lowest stand auf 0, den hab ich auf 1 gesetzt, was nichts geändert hat. Dann zurück auf 0 gesetzt, und arp-scan hat zum ersten (und leider auch letzten) mal ein Ergebnis geliefert.

Code:
root@raspi2:~ # arp-scan -l
Interface: genet0, type: EN10MB, MAC: e4:5f:01:0f:56:3d, IPv4: 192.168.0.117
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.0.1    e8:df:70:80:01:67    AVM Audiovisuelles Marketing und Computersysteme GmbH

522 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 3.332 seconds (76.83 hosts/sec). 1 responded

Das Ergebnis ist zwar unvollständig, aber immerhin kam überhaupt mal was. Leider ist die Aktion nicht reproduzierbar, war also ein bisher einmaliges Ereignis.

PS: Sind beide PI 4 mit 8 GB.

PPS: Wenn ich net.inet.ip.broadcast_lowest nur abfrage und so parallel wie möglich dann arp-scan -l aufrufe, dann ist die Antwort mit Erkennung der Fritzbox ab und zu doch reproduzierbar-
 
PPS: Wenn ich net.inet.ip.broadcast_lowest nur abfrage und so parallel wie möglich dann arp-scan -l aufrufe, dann ist die Antwort mit Erkennung der Fritzbox ab und zu doch reproduzierbar-
Abfrage heißt immer (als root oder nicht root?):
Code:
sysctl net.inet.ip.broadcast_lowest
? ... und auf welchen Wert ist/bleibt "net.inet.ip.broadcast_lowest" dann immer konfiguriert? 0 oder 1?

EDIT:

... Timeouts beim Test mit dam anderen PI und tcpdump, bedeutet, dass die arp-requests den anderen PI4 gar nicht erreichen, oder?
 
Bleibt immer auf 0 (mach ich als root).

EDIT: Genau, da kommt von den arp-tools am 2. Pi nichts an. Eine "normale" arp -a Anfrage dagegen schon.
 
EDIT: Genau, da kommt von den arp-tools am 2. Pi nichts an. Eine "normale" arp -a Anfrage dagegen schon.
"arp -a" ist keine Anfrage (d. h. kein arp-request), sondern lediglich die Ausgabe des arp-cache-Eintrags (betr. IPv4) von dem Gerät auf dem es gerade ausgeführt wird. Vergleich z. B. für IPv6, die Ausgabe des neighbor-Cache-Eintrags (mit "ndp -a").

D. h., dass nach dem booten oder irgendwann in regelmäßigen Zeitabständen (weil der arp-cache-Eintrag bei dir ja nicht statisch/permanent konfiguriert ist), wird dein PI4 mit FreeBSD13.1-R schon arp-requests ins LAN senden (die dann auch beantwortet werden, mit arp-replies) um seinen arp-cache-Eintrag zu erneuern.
Merkwürdig ist es schon, warum die absichtlich gesendeten arp-requests (mit arping, arp-scan, arpdig) die anderen Geräte im Subnetz der FritzBox nicht zuverlässig erreichen.
Sind deine PIs direkt mit der FritzBox verbunden oder benutzt Du einen Switch (oder gleichwertig)?
 
Hast natürlich recht mit den arp-requests. Als Autodidakt kommen bei mir leider öfter solche Unschärfen vor.

Und ja, das Netz hängt komplett hinter einem Switch.

Hab gerade mal schnell eine weitere SSD mit jungfräulichem FreeBSD 13.1 erstellt - ist aber das gleiche Spiel.
 
Es kann auch sein das das irgendwas mit arm64 / der pi-nic etc zu tun hat - hast du ne chance das mit nem 13.1 und ner x86_64 Büchse zu testen?
 
... - hast du ne chance das mit nem 13.1 und ner x86_64 Büchse zu testen?
Lt. Beitrag #5 hat der TE das gemacht und es hat funktioniert:
Ach ja: Auf den amd64-Systemen laufen all die arp-tools unter 13.1 einwandfrei, gerade nochmal getestet.
EDIT:

BTW: Es sollte noch präzisiert werden, ob die amd64-Systeme (mit 13.1) auch per Switch oder direkt, mit der FritzBox verbunden sind/waren.
 
Ich würde mal vermuten das irgendwas unter arm64 geändert wurde was das verursacht, ich bin noch immer weit weg davon FreeBSD experte zu sein aber mal so aus der Hüfte geschossen

-> Was am Paket selber (imho eher unwahrscheinlich)
-> Etwas was im Kernel oder nah-verwandtes geändert wurde und nur unter arm64 zum tragen kommt.
-> Etwas was am Pi4 genet-ethernet-treiber verändert wurde und das problem verusacht - imho am wahrscheinlichsten.

Hast du die Chance das ganze mal per WLAN oder nen externen USB-Adapter mit anderen Chipsatz zu testen? Dann könnt mans etwas weiter eingrenzen

/edit Ich hab schon die seltsamsten Netzwerkfehler gehabt, hätte aber so Pauschal den Switch erstmal als sehr unwahrscheinlich empfunden, wenns da generelle ARP-Probleme geben würde, würde man das sehr schnell auch an anderen stellen merken und selbst einfachste soho-switche haben da nur selten irgendwie Probleme
 
@CommanderZed Hab gerade eine USB Netzwerkkarte angeschlossen. Hier geht der arp-scan. Damit wäre meine Vermutung: der genet Treiber.

Code:
dmesg
ugen0.3: <Moschip Semiconductor USB-MAC Controller> at usbus0
mos0 on uhub1
mos0: <Moschip Semiconductor USB-MAC Controller, rev 2.00/1.00, addr 2> on usbus0

sudo arp-scan -l --interface=ue0
Interface: ue0, type: EN10MB, MAC: 00:13:3b:39:0a:71, IPv4: 192.168.160.68
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.160.1   3c:a6:2f:6a:b1:af       (Unknown)
192.168.160.22  dc:a6:32:be:c3:6d       Raspberry Pi Trading Ltd
 
Zurück
Oben