UDM PRO Probleme mit DHCP

Es gibt 34 Antworten in diesem Thema, welches 12.488 mal aufgerufen wurde. Der letzte Beitrag () ist von HammF.

  • Hallo, ich bin noch relativ neu was das Unifi-Equipment angeht, daher kann auch dort der Fehler liegen.

    Zum Aufbau:


    FritzBox 7590 (Internet läuft und ich habe auch überall Zugang)

    UDM-PRO (1.10.0 mit Network 6.2.26)

    USW-24-PoE (5.64.8)

    5x USW-Flex-Mini (1.8.4)

    2x U6-Lite (5.60.9)

    Raspberry als Pi-Hole


    Am Anfang hatte ich alles in Netzwerk LAN (so wie es bei dem "alten" Equipment auch war. Den UDM-Pro DHCP hatte ich direkt deaktiviert, da mein Pi-Hole diese Funktion inne hatte.)

    Dann habe ich den Pi-Hole DHCP deaktiviert und den im UDM-Pro aktiviert.

    Danach musste ich erst mal den UDM-Pro Rebooten, da er keine IP vergeben.

    Nach dem Reboot lief alles sauber. (Zumindest ist mir nix aufgefallen, allerdings war der Zustand auch nur von kurzer Dauer, da es ja weiter an die VLAN ging),


    Es wurden zwei VLAN erstellt mit jeweils DHCP aktiviert.

    VLAN 10 mit 192.168.10.0/24 (für IoT-Geräte)

    VLAN 20 mit 192.168.20.0/24 (für das Solarzeugs)


    Habe einen Laptop an einen USW-Flex-Mini Port gehangen und den Port auf das entsprechende VLAN gestellt, allerdings auch hier dann keine IP. Egal welches VLAN.

    Alle anderen Ports sind auf "ALL".

    Die Zuweisung der IP hat erst nach einem Neustart des UDM-Pro stattgefunden.

    Danach habe ich angefangen die Geräte in die entsprechenden VLAN zu verschieben.

    Das Solarzeugs mit Zuweisung des Ports, IoT überwiegend mit einem VLAN-Wifi.

    Soweit läuft auch alles nur ab und an werden keine IP-Leases mehr vom DHCP verteilt und dann steht das Netz sozusagen.

    Solar ist unkritisch, da Arbeite ich mit Static-IP. Im LAN geht es auch noch aber im IoT Bereich ist es nervend (vor allem wenn man Kinder hat und Chromecast nicht mehr geht)


    Meine aktuelle Lösung ist den Pi-Hole als DHCP für LAN und einen Orange-Pi Zero als DHCP im VLAN der IoT Geräte.

    Die Lösung funktioniert aber bei dem Preis des Unifi Equipments, kann dies auf keinen Fall die Finale-Lösung sein.

    Kennst sonst jemand noch das Verhalten des DHCP im UDM-Pro?

    Hat jemand einen Rat?

    Wenn etwas an Infos fehlt bitte Fragen.


    Grüße


    Frank

  • Hallo Frank,


    ich hatte das Thema, dass ich ein bestehendes Netzwerk. Ist Clients und Servern in Betrieb habe.

    Der AD Server macht DHCP. Ich habe in der UDMPro auf dem Netzwerk LAN eine DHCP Weiterleitung auf den DHCP Server des AD-Servers eingetragen.

    Im WAN Netzwerk habe ich beimDNS Server die 8.8.8.8 und 1.1.1.1 eingetragen.


    Vielleicht hilft Dir das ja ein wenig weiter.

    UDMPRO, 8Port PoE 150 Watt, AP-ACPro, Flex Mini 5Port Switch

  • Hat jemand einen Rat?

    Ich sag mal so - ich bin froh, meine Absicht UDM Pro zu kaufen revidiert zu haben.


    Warum lässt Du DHCP nicht komplett von Deinem Raspi machen? Damit weißt Du zwar immer noch nicht warum UDM nicht wirklich läuft, hast aber Problem "gelöst".


    Haben die Kisten keine Logs wo man was finden kann?

  • Dann habe ich den Pi-Hole DHCP deaktiviert und den im UDM-Pro aktiviert.

    Danach musste ich erst mal den UDM-Pro Rebooten, da er keine IP vergeben.

    Zeigt mal deine Konfiguration LAN, VLAN, WLAN, und bitte aus der Classic-Ansicht.


    Hast du nach Ändern des DHCP-Server einen DHCP-Release am Client gemacht, notfall Netzwerkkabel gezogen oder rebootet ?

    DHCP-Server vergeben IP-Adressen nur auf Anfrage vom Client, der Client muss das also antriggern und nach einem DHCP-server im Netz fragen und ihm dann um eine IP-Adressen bitten.

    Ein Reboot der UDM hilft da nicht wirklich


    Solange er keine neue Anfrage stellt, behält er die IP die er hat bis zum Ablauf der Leasetime, meist 12 oder 24h.


  • Hier mal die Konfiguration von LAN, WLAN und einem VLAN, bei dem anderen VLAN sind die Clients alle Static.

    Das verwunderliche ist ja am Anfang (z.B. Neuverbindung eines WLAN-Gerätes) bekomme ich direkt eine IP aber nach einiger Zeit (Unbestimmter Zeitraum von ein paar Stunden bis einem Tag) werden die Leases nicht mehr erneuert.

    Ich kann mich via WLAN nicht mehr mit dem Netzwerk verbinden und Kabelgebunden bekomme ich keine IP zugewiesen und Windows nimmt dann die Standard IP (169.254.0.0-169.254.255.255)

    Fällt halt bei den Geräten die oft ein und ausgeschaltet (TV, Google Chromecast) werden schnell auf.

    Einmal editiert, zuletzt von HammF ()

  • Vielleicht habe ich die Konfiguration nicht ganz verstanden - Du verwendest für WLAN keine VLAN, sondern nur das Default "lan". Ist das so richtig und gewollt?


    Und bei dem "fast-roaming" - ich bilde mir ein hier im Forum oder vielleicht doch woanders gelesen zu haben, dass man da aufpassen soll. Es soll Geräte/ Konfigs geben die damit perfekt funktionieren und andere die nur Ärger haben.

  • - fast roaming ausschalten - das ist noch im Beta status, lass das sein, selsbt der Unif Support rät das abzuschalten

    - IGMP Snooping ausschalten

    - WPA3 ausschalten, die Warnmeldung spring ja schon ins Auge :smiling_face:

    - wenn du zwei VLan's auch über WLAn haben willst, muss du auch zwei WLan anlegen mit den entsprechenden Einstellungen.


    Bist du sicher, das kein weitere DHCP-Server im Netz aktiv ist ?

    Die Konfig sieht sonst soweit gut aus.

  • So habe mal ein paar Einstellungen geändert:


    - fast Roaming ist aus (Die Fehlermeldung kommt nur bei einem Wifi-Netzwerk, bei dem anderen wird diese nicht angezeigt, verstehe wer möchte)

    - IGMP Snooping ist auch mal aus (war Standard an)

    - WPA3 (Support WPA3 connections) bleibe ich dabei

    - Mit den VLAN ist klar. Ich habe ein Wfifi-Netz für "IoT" mit dem VLAN "IoT" und ein Wifi-Netz für das Haus mit dem VLAN "LAN".

    Liegt aber auch dran, da ich für die "restlichen" Geräte im Haus aktuell das untagged LAN verwende, bin noch am überlegen ob ich dies in eine eigenes VLAN verschiebe.


    Ansonsten ist kein DHCP im Netz aktiv.

    Was mich ja wundert ist, dass die DHCP vergabe in allen VLAN und dem LAN gleichzeitig aufhören, daher habe ich das VLAN für Energie ja schon mit static IP ausgestattet, nur bei den IoT Geräten geht dies ja meist nicht und die wanderden Geräte (Handy, Tablet, Latop) ist auch blöd, da kommt ja einiges zusammen. Da finde ich einen DHCP schon angenehmer.


    Dann harren wir mal der Dinge und schauen was passiert.

  • - WPA3 (Support WPA3 connections) bleibe ich dabei

    Na ja, dann solltest Du die AP updaten, denn die Meldung gilt für Deine AP.



    Was mich ja wundert ist, dass die DHCP vergabe in allen VLAN und dem LAN gleichzeitig aufhören,


    Wie gesagt die UDM kenne ich nicht. Ich fürchte aber ohne einen Netzwerktrace wird es schwierig. Als was Du brauchst wäre ein Gerät (Windows, Linux) was den Traffic mitschneiden kann (wireshark - Windows, tcpdump Linux/ Unix).

    Was Du natürlich auch schon gucken kannst - einen Rechner (Windows, Linux) und schauen, nach dem dieser eine IP bekommen hat - stimmen wirklich alle Sachen die, die UDM verschickt. Zumindest was Du schreibst - wäre von der Idee - die Geräte wissen nicht von wem sie die IP bekommen haben und deswegen funktioniert kein "Renew" oder aber die wissen es und eine der FW Regeln verbietet den Kontakt

  • Hast du ne Linux-Kiste laufen, da führe dort mal eines der drie Kommanods aus und zeig mal was das llefert ( das zeigt die Datend es DHCP-Request mehr oder weniger umfangreich an )


    dhcpdump -i eth0
    dhcpcd -T eth0

    nmap --script broadcast-dhcp-discover


    ( eth0 ggf. mit dem Name der Netzwerkkarte ersetzen )


    Alternativ auf einem Mac mit:


    ipconfig getpacket en0



    Bei Windows:


    dhcptest.exe


    ( aber da hab ich keine Erfahrung mit mangels Windows )

  • @Tuxtom007 Habe mal die Kommandos laufen lassen.

    Zur Info, gestern Abend auf den DHCP des UDM-Pro umgestellt und soweit lief alles. Heute morgen meinten die Mobilgeräte dass sie keine IP bekommen auch der PC nach dem Neustart.

    Hier mal die Ausgaben nach einem Neustart des UDM-Pro. Es folgen noch welche wenn der Fehler wieder auftritt.


    Dump beim verbinden meines Telefons:


    NMAP zeigt ja, dass die Anfrage soweit funktioniert. Man bekommt eine IP zugewiesen.

    Dann warte ich mal!

  • new_broadcast_address='192.168.177.251'

    Das ist aber bei einem /24 Netz nicht richtig.


    Und viel wichtiger wären eben die tcpdumps wenn der Rechner kein Renew machen kann. Mit dhcpdump siehst Du wenig. Heißt bei tcpdump siehst Du ob der Klient die Anfrage zum Server schickt und ob eine Antwort kommt oder eben nicht.

    Einmal editiert, zuletzt von RobiWan ()

  • new_broadcast_address='192.168.177.251'


    jepp, die stimmt schon mal nicht, da muss .255 hin


    Ich sehe in den Screenshot aber nicht, wo die herkommen soll.

    Das kann dein Problem sein, der DHCP-Client schickt als erstes eine Anfrage an die Broadcast-Adresse und vorhandenen DHCP-Server würden darauf antworten. Die Anfrage würde aber ins leer laufen.

  • Die Broadcast Adresse habe ich mal "gefixt", mit ner DHCP-Option


    Wobei die Broadcast-IP für das Netzwerk ja richtig bestimmt wird. :thinking_face:


    Schon mal Danke für den Hinweis, bisher läuft es auch stabil, was mich wundert.

  • Das kann dein Problem sein, der DHCP-Client schickt als erstes eine Anfrage an die Broadcast-Adresse

    Das stimmt nur bedingt. Die Clients schicken nur beim ersten mal Broadcast. Später also beim Renew geht gezielte Anfrage an definierten Server. Richtig ist die Broadcast Adresse aber dennoch nicht.

    Ich würde fast vermuten, dass entweder dhcpdump hier "Mist" zeigt oder so ein Wirwarr verschickt wird, dass es ein versuch ist daraus etwas zu interpretieren.

  • RobiWan Habe auch mal mit Wireshark nachgesehen. Die Anfrage sollte korrekt bearbeitet worden sein. Aber aktuell läuft es ja auch :face_with_open_mouth:

  • Bisher läuft es mal stabil, für den untagged LAN Anteil.

    Ich werde jetzt mal die anderen VLAN mit dazunehmen und es im Auge behalten.


    Vielen Dank!

  • Zu früh gefreut.

    Laut Wireshark antwortet der DHCP nicht mehr.


    Der dhcpdump ist auch nichtssagend:

    Ebenso:

    Code
    orangepipcplus:~:# dhcpcd -T eth0
    dhcp6_listen: Address already in use
    eth0: IAID 14:
    eth0: rebinding lease of 192.168.177.83
    eth0: soliciting an IPv6 router
    eth0: probing for an IPv4LL address
    eth0: DHCP lease expired


    Ich würde mal sagen hängt wohl am DHCP.

    Bin noch nicht zum ändern gekommen, da ich noch am Arbeiten war.

  • eth0: DHCP lease expired


    Der Client will eine neue IP haben, weil die Leasetime abgelaufen, aber bekommt keine Antwort von einem DHCP-Server.


    Hast du zwischenzeitlich mal "IGMP Snooping" abgeschaltet, das hat mir letztens sogar der Unifi Support geraten.


    Kontrolliere bitte auch mal die Einstellungen deines PiHole, ob da noch irgentwas Richtung DHCP aktiv ist und dann reboote den danach mal durch.


    Danach gehe mal auf die UDMPRo und führe den Befehl aus:


    cat /mnt/data/udapi-config/dnsmasq.lease


    der sollte alle DHCP-Adressen auflisten, welche von der UDM vergeben wurden.


    Mir ist immer noch schleierhaft, wo deine komische Broadcastaddresse herkommt, nehme die DHCP-Option dafür auch mal wieder raus.


    Schaue auf direkt mal mit


    ifconfig


    über die "br" Interface, ob da die Einstellungen da passen

    ( inet addr: x.x.x.x Bcast:0.0.0.0 Mask:255.255.255.0 )