arp-scan unter FreeBSD arm64

Zur Klärung:
  • Das gesamte Netz hängt am Switch, an der Fritzbox selbst hängt nur dieser Switch.
  • Die 4 amd64 Maschinen mit FreeBSD 13.1 am Netz arbeiten ausnahmslos einwandfrei.
  • Weitere amd64 Maschinen (OpenBSD, NetBSD, OpenIndiana, Devuan Linux arbeiten einwandfrei.
  • Eine amd64 Maschine mit OmniOS zeigt aber das gleiche Verhalten wie die Pi's.
  • Vor einigen Monaten gab es das gleiche Verhalten auf einem OpenIndiana, das war aber mit dem nächsten pkgsrc-upgrade erledigt.

Abegesehen von diesen arp-Problemen arbeiten sämtliche Netzwerkanwendungen auf allen Rechnern perfekt. Das Netz läuft rund, es gibt schnellen Zugriff auf die nfs-Server, Inter- und Intranet sind problemlos.

Der Verzicht auf die arp-tools führt also nicht zu greifbaren Problemen.

Und zum Schluss: Der Switch war's auch nicht, hab einen Raspi mal ne Stunde direkt an die FB geklemmt und alles nochmal durchgespielt - keine Änderung gegenüber dem Anschluss am Switch.
 
Nach der Erkenntnis von @schorsch_76 sofort in der Wuschelkiste gewühlt und einen USB-LAN-Adapter namens Edimax gefunden. Und wahrhaftig: Damit läufts rund.

Code:
root@raspi2:~ # arp-scan -l ; arp -a
Interface: ue0, type: EN10MB, MAC: 00:50:b6:0c:17:fd, IPv4: 192.168.0.61
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
192.168.0.60    62:ff:4d:8d:8d:5b    (Unknown: locally administered)
192.168.0.60    62:ff:4d:8d:8d:5b    (Unknown: locally administered) (DUP: 2)
192.168.0.77    dc:a6:32:c4:b9:77    Raspberry Pi Trading Ltd
192.168.0.95    ac:6f:bb:67:32:5f    TATUNG Technology Inc.
192.168.0.110    ac:63:be:b4:45:ee    Amazon Technologies Inc.
192.168.0.52    30:ff:f6:51:85:00    HangZhou KuoHeng Technology Co.,ltd
192.168.0.88    3a:81:c4:b2:a8:50    (Unknown: locally administered)
192.168.0.51    00:27:15:5d:04:2d    Rebound Telecom. Co., Ltd
192.168.0.54    28:ad:3e:1d:b3:18    Shenzhen TONG BO WEI Technology CO.,LTD
192.168.0.51    00:27:15:5d:04:2d    Rebound Telecom. Co., Ltd (DUP: 2)

536 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 3.328 seconds (76.92 hosts/sec). 11 responded
raspi1.fritz.box (192.168.0.77) at dc:a6:32:c4:b9:77 on ue0 expires in 1199 seconds [ethernet]
firestick.fritz.box (192.168.0.110) at ac:63:be:b4:45:ee on ue0 expires in 1199 seconds [ethernet]
fritz.box (192.168.0.1) at e8:df:70:80:01:67 on ue0 expires in 1198 seconds [ethernet]
waspnet-repeater1750.fritz.box (192.168.0.88) at 3a:81:c4:b2:a8:50 on ue0 expires in 1199 seconds [ethernet]
waspnet-repeater1160.fritz.box (192.168.0.60) at 62:ff:4d:8d:8d:5b on ue0 expires in 1199 seconds [ethernet]
raspi2.fritz.box (192.168.0.61) at 00:50:b6:0c:17:fd on ue0 permanent [ethernet]
? (192.168.0.95) at ac:6f:bb:67:32:5f on ue0 expires in 1199 seconds [ethernet]
oukitelC16.fritz.box (192.168.0.51) at 00:27:15:5d:04:2d on ue0 expires in 1200 seconds [ethernet]
wifi-ip-cam.fritz.box (192.168.0.52) at 30:ff:f6:51:85:00 on ue0 expires in 1199 seconds [ethernet]
sygonix.fritz.box (192.168.0.54) at 28:ad:3e:1d:b3:18 on ue0 expires in 1199 seconds [ethernet]

Da bleibt wohl ausser dem genet-Treiber nicht viel übrig.

Super, besten Dank für die wunderbare Hilfe hier. :)

Der Adapter ist übrigens kaum langsamer als genet. Die theoretischen 100Mbit erreicht er zwar nicht, aber gute 90 kriegt er hin.
 
Ich bin ja leider blutigster FreeBSD anfänger, villeicht villeicht könnte @Yamagi ja uns einen tip geben ob es sinnvoll ist einen Bugreport einzureichen und wenn ja wie? Bzw. könnnte man vorher mal schauen obs villeicht schon einen gibt?
 
Hab noch etwas durch das Interface gestöbert und nur eines festgestellt: Der genet Treiber hat einen Hardwarefilter.

Code:
static uint8_t ether_broadcastaddr[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };

static void
gen_setup_rxfilter_mdf(struct gen_softc *sc, u_int n, const uint8_t *ea)
{
    uint32_t addr0 = (ea[0] << 8) | ea[1];
    uint32_t addr1 = (ea[2] << 24) | (ea[3] << 16) | (ea[4] << 8) | ea[5];

    WR4(sc, GENET_UMAC_MDF_ADDR0(n), addr0);
    WR4(sc, GENET_UMAC_MDF_ADDR1(n), addr1);
}

static u_int
gen_setup_multi(void *arg, struct sockaddr_dl *sdl, u_int count)
{
    struct gen_softc *sc = arg;

    /* "count + 2" to account for unicast and broadcast */
    gen_setup_rxfilter_mdf(sc, count + 2, LLADDR(sdl));
    return (1);        /* increment to count */
}

und

Code:
static void
gen_setup_rxfilter(struct gen_softc *sc)
{
    struct ifnet *ifp = sc->ifp;
    uint32_t cmd, mdf_ctrl;
    u_int n;

    GEN_ASSERT_LOCKED(sc);

    cmd = RD4(sc, GENET_UMAC_CMD);

    /*
     * Count the required number of hardware filters. We need one
     * for each multicast address, plus one for our own address and
     * the broadcast address.
     */
    n = if_llmaddr_count(ifp) + 2;

    if (n > GENET_MAX_MDF_FILTER)
        ifp->if_flags |= IFF_ALLMULTI;
    else
        ifp->if_flags &= ~IFF_ALLMULTI;

    if ((ifp->if_flags & (IFF_PROMISC|IFF_ALLMULTI)) != 0) {
        cmd |= GENET_UMAC_CMD_PROMISC;
        mdf_ctrl = 0;
    } else {
        cmd &= ~GENET_UMAC_CMD_PROMISC;
        gen_setup_rxfilter_mdf(sc, 0, ether_broadcastaddr);
        gen_setup_rxfilter_mdf(sc, 1, IF_LLADDR(ifp));
        (void) if_foreach_llmaddr(ifp, gen_setup_multi, sc);
        mdf_ctrl = (__BIT(GENET_MAX_MDF_FILTER) - 1)  &~
            (__BIT(GENET_MAX_MDF_FILTER - n) - 1);
    }

    WR4(sc, GENET_UMAC_CMD, cmd);
    WR4(sc, GENET_UMAC_MDF_CTRL, mdf_ctrl);
}

Wenn ich der Maintainer wäre, wäre das mein erster Ansatz ob hier evtl. der ARP irgendwie weggefiltert wird.

EDIT: Beim Blick in den MOS Treiber (der USB Karte) ist mir sowas gar nicht aufgefallen.
 
Allerdings gibt es nur vier Änderungen zwischen 13.0 und 13.1 in dem Treiber, die letzten 4 Commits: https://cgit.freebsd.org/src/log/sys/arm64/broadcom/genet/if_genet.c?h=releng/13.1 Keiner davon sieht auf den ersten Blick kritisch aus. Es kann also auch das Zusammenspiel zwischen Netzwerkstack und Treiber sein, etwas hat sich im Netzwerkstack geändert und damit einen vorhanden Bug im Treiber sichtbar gemacht. Oder in die Richtung.
 
Wenn ich der Maintainer wäre, wäre das mein erster Ansatz ob hier evtl. der ARP irgendwie weggefiltert wird.
ARP wird auf dem PI4 mit 13.1-R nicht gefiltert. Beim booten des PI4 (mit 13.1-R) wird der arp-cache-Eintrag mit der MAC- und IP-Adresse des Routers vervollständigt. Man sieht auch im (W)LAN der FritzBox, dass der PI4 richtigerweise einen arp-request (als broadcast) bzgl. den Daten des Routers macht/sendet und vom Router per arp-reply, die richtige Antwort bekommt.
Wenn man sich dann aus dem (W)LAN der FritzBox, per ssh mit dem PI4 verbindet, sieht man auch das arp-request (als broadcast) des PI4 bzgl. den Daten (MAC- und IP-Adresse) des ssh-Clienten, zum Eintrag in den arp-cache des PI4.

arp-requests erreichen auch korrekt den PI4 und arp-replies (als Antwort) vom PI4 erreichen die Geräte im (W)LAN der FritzBox.
Das was nicht funktioniert, sind die arp-requests vom PI4, die mit den arp-tools (arping, arpdig, arp-scan und gleichwertig) generiert werden und an die Geräte (inkl. FritzBox) im (W)LAN der FritzBox gerichtet/adressiert sind.
 
Bei mir:
Code:
sysctl -a | grep -i dev.cpu.0.temp
dev.cpu.0.temperature: 52.5C
Denke nicht das es ein Temperaturproblem ist.
 
Denke nicht das es ein Temperaturproblem ist.
Nein, kein Temperaturproblem. Ich habe nur gefragt, weil die Temperatur auf meinem PI4 mit FreeBSD13.1-R (auf USB3-Stick) bei ca. 62°C ist.
Im Vergleich zu meinen anderen:
PI4 mit bullseye auf SD-Karte:
Code:
:~# vcgencmd measure_temp
temp=52.5'C
PI4 mit OpenBSD6.9 auf USB3-Stick:
Code:
hw.sensors.bcmtmon0.temp0=52.58 degC
PI3B+ mit FreeBSD13.0-R auf SD-Karte:
Code:
:~ % sysctl -a | grep -i dev.cpu.0.temp
dev.cpu.0.temperature: 53.1C
 
Zurück
Oben