Bekabeld : geen ip adres

[Indira]

Sinds kort gebruiken we een Unifi UDM
Dit hangt aan een proximus bbox, dus dubbel NAT op dit moment

nu is echter een merkwaardig probleem:
Computers en AppleTV’s die bekabeld aangesloten worden krijgen geen ip adres (enkel een eigen 169.254.xxx.xxx)

Maar: de controller geeft aan dat de toestellen wel een ip adres uit de dhcp range is toegewezen.

Het probleem is vandaag voorgevallen, voorheen geen probleem

Via wifi werkt alles zoals van in het begin, dus tijdelijk alles naar wifi omgezet.

Wat zou dit probleem veroorzaken?

[Joe de Mannen]

Pool opgebruikt ?

[bitbite]

Maar: de controller geeft aan dat de toestellen wel een ip adres uit de dhcp range is toegewezen.

Ben je zeker dat je een IP toegekend ziet aan de bedraade interface van die toestellen? Of zie je in de logs gewoon wat over wifi gaat?

[CCatalyst]

Niets veranderd in de config sinds gisteren?

In de eerste plaats zou ik denken aan de switch port profiles, een VLAN aangeduid die geen DHCP pool heeft.

Mogelijks ook DHCP Guarding in Site > Settings > Networks.

Check de Events en de Alerts tab eens voor eventuele meldingen.

Als je de computer een manueel IP adres in het correcte subnet geeft (dat nog niet in gebruik is) en een DNS server, heb je dan connectiviteit of niet?

[Indira]

Pool opgebruikt ?

netwerk staat ingesteld op 192.168.2.1/24

Dhcp range is 192.168.2.10 tot 192.168.2.254

Maar: de controller geeft aan dat de toestellen wel een ip adres uit de dhcp range is toegewezen.

Ben je zeker dat je een IP toegekend ziet aan de bedraade interface van die toestellen? Of zie je in de logs gewoon wat over wifi gaat?

Op het dashboard kwam voor de apple tv effectief het ipadres samen met het ethernet mac adres.
Zonet nogmaals verbonden, nu geen connectie zichtbaar

Niets veranderd in de config sinds gisteren?

Neen, is overdag gebeurd tijdens het werken

In de eerste plaats zou ik denken aan de switch port profiles, een VLAN aangeduid die geen DHCP pool heeft.

Er zijn geen vlan geconfigureerd voor zover ik weet.
Algemene firewall rules niets aan gewijzigd.
Degene die er in staan kunnen niet verwijderd worden

Mogelijks ook DHCP Guarding in Site > Settings > Networks.

Dhcp gaurding staat uit

Check de Events en de Alerts tab eens voor eventuele meldingen.

Geen foutmeldingen zichtbaar

Als je de computer een manueel IP adres in het correcte subnet geeft (dat nog niet in gebruik is) en een DNS server, heb je dan connectiviteit of niet?

Zonet geprobeerd met een andere laptop: geen connectie, ook geen ping mogelijk.

Maar:de laptop verschijnt bij het overzicht met ip 192.168.1.2 (foutief dus)
Zelfs als ik de laptop in de controller manueel een vast ip adres geef met het juiste adres en de laptop interface dezelfde adres: geen connectie.

Hierbij viel de wifi ook volledig weg voor alle toestellen,
Nadat kabel uitgetrokken werd, kwam de wifi connectie weer terug voor alle toestellen

[rapidgorgon]

Mocht je een snelle oplossing nodig hebben, dan kan je eventueel de Proximus modem als gateway en DHCP server gebruiken. Zo heb je misschien wat minder kopzorgen voor het thuiswerken morgen, en kan je dit weekend wat meer tijd spenderen om ook o.a. de PPPoE verbinding te configureren.

Hiervoor zou je de DHCP server op de Dream Machine moeten uitschakelen en de verbinding naar de modem op één van de LAN poorten steken (of op de centrale switch). Dan zal de Proximus-modem je apparaten voorzien van een IP-adres, maar kan je nog altijd de Unifi WiFi gebruiken. Als je deze configuratie wil proberen, test dan zeker dat de UDM DHCP-server uitgeschakeld is. Dit kan door de modem nog niet aan te sluiten en via WiFi te proberen verbinden. Normaal mag je dan geen IP-adres krijgen. Eens je de modem op het LAN aansluit, zou dit wel terug moeten lukken.

Mocht je het vanavond al opgelost krijgen, des te beter natuurlijk

[CCatalyst]

Die laptop, is die zowel via wireless als via kabel verbonden? Indien ja, kan je wireless uitschakelen en kijken of het probleem nog voorkomt?

Als het probleem dan nog voorkomt: heb je Android toestellen in gebruik? Kan je die eens volledig uitschakelen, en dan DHCP proberen op de laptop?

Indien geen lease, kan je manueel een IP toekennen aan de laptop en zien of je dan connectiviteit hebt en of het netwerk voor de rest weer wegvalt (nog steeds met Android toestellen uit)

[Indira]

na mijn vorige reactie heb ik letterlijk de stekker eruit getrokken (reset knop deed niets)

Daarna op de UDM opnieuw de wizard doorlopen.
Aangezien ik toch geen eigen configuratie had gedaan had ik weinig te verliezen.

Nu krijgen alle bekabelde toestellen weer een dhcp IP in de correcte range én hebben ze connectiviteit.
Afwachten voor hoelang?

Mocht je een snelle oplossing nodig hebben, dan kan je eventueel de Proximus modem als gateway en DHCP server gebruiken. Zo heb je misschien wat minder kopzorgen voor het thuiswerken morgen, en kan je dit weekend wat meer tijd spenderen om ook o.a. de PPPoE verbinding te configureren.

Hiervoor zou je de DHCP server op de Dream Machine moeten uitschakelen en de verbinding naar de modem op één van de LAN poorten steken (of op de centrale switch). Dan zal de Proximus-modem je apparaten voorzien van een IP-adres, maar kan je nog altijd de Unifi WiFi gebruiken. Als je deze configuratie wil proberen, test dan zeker dat de UDM DHCP-server uitgeschakeld is. Dit kan door de modem nog niet aan te sluiten en via WiFi te proberen verbinden. Normaal mag je dan geen IP-adres krijgen. Eens je de modem op het LAN aansluit, zou dit wel terug moeten lukken.

Mocht je het vanavond al opgelost krijgen, des te beter natuurlijk

Als het morgen opnieuw gebeurd volg ik je advies als tijdelijke oplossing.
In het weekend zal ik de pppoe opzoeken en instellen

Die laptop, is die zowel via wireless als via kabel verbonden? Indien ja, kan je wireless uitschakelen en kijken of het probleem nog voorkomt?

Als het probleem dan nog voorkomt: heb je Android toestellen in gebruik? Kan je die eens volledig uitschakelen, en dan DHCP proberen op de laptop?

Indien geen lease, kan je manueel een IP toekennen aan de laptop en zien of je dan connectiviteit hebt en of het netwerk voor de rest weer wegvalt (nog steeds met Android toestellen uit)

Bij de gebruikte werk laptop zet ik wireless altijd uit (in het windows tegel menu) voor ik de kabel insteek.
Anders geeft dit conflicten met bepaalde bedrijf software.

We hebben inderdaad ook een Android toestellen, als het opnieuw voorvalt zal ik de testen doen met die smartphone uitgeschakeld.

Zijn android toestellen gekend voor dit soort problemen te veroorzaken?

[CCatalyst]

Zijn android toestellen gekend voor dit soort problemen te veroorzaken?

Er is een bug met interactie tussen Android toestellen en Apple toestellen op hetzelfde LAN. Android toestellen kunnen een bizar ICMP pakket uitsturen dat op L3 gericht is aan het IP van de default gateway maar op L2 een broadcast is (ff:ff:...) waardoor elk toestel in het LAN dat pakket ontvangt.

Apple toestellen die in slaapstand staan (een slapende Macbook of Apple TV bv) zijn zich na het verstrijken van hun DHCP lease niet meer bewust van wat hun L3 IP adres is. Aangezien zij dit ICMP pakket van het Android toestel ontvangen, gaan zij er dan van uit dat het L3 adres waaraan het gericht is - het IP van de default gateway - hun eigen IP adres is. Vervolgens gaan zij antwoorden door een ICMP terug te sturen naar het Android toestel gesourced met L3 het IP van de gateway en L2 het MAC-adres van het Apple toestel. Bovendien kan het Apple toestel dan ook tijdelijk ARP requests voor het IP van de gateway beginnen antwoorden. Dat kan er dan toe leiden dat het slapende Apple toestel als de gateway aanzien wordt op het LAN en dan is het meteen gedaan met de connectiviteit.

Dat het probleem hier in kwestie beperkt is tot de toestellen die wired zijn is wellicht omdat de Dream Machine "domme" wired switch-chip die het pakket van de slapende wired Apple TV ontvangt, geen controles doet en zal "leren" dat het IP van de default gateway toebehoort aan de Apple TV die op een van zijn poorten zit, ook al zit de werkelijke default gateway in de Dream Machine zelf. De eerste controles op een rogue gateway gebeuren wellicht pas voor het eerst verder upstream, buiten de switch-chip, en ik ben er vrij zeker van dat ze ten laatste op de AP's gedropt worden. Toestellen die wired verbonden zijn kunnen zo geen connectiviteit hebben met de echte default gateway, terwijl wireless nog steeds werkt.

Dit verklaart ook waarom het probleem zich pas na een tijd voordoet, het betrokken Apple toestel moet eerst in slaapstand terecht komen, vervolgens moet de DHCP lease nog vervallen (default = 1 dag), en dan moet er nog een Android toestel zijn die dat bizar ICMP-pakket stuurt alvorens aan de voorwaarden voldaan is.

Als dit het probleem is, zou het uitschakelen van de Android toestellen of de Apple toestellen in slaapstand aan de wired ports een oplossing moeten zijn. Daarna wel nog eens de Dream Machine herstarten, en dan nagaan of het probleem nog terugkomt.

Iig ook zeker zijn dat de laatste versie van Unifi en van de Dream Machine firmware geinstalleerd is.

[rapidgorgon]

Die interactie tussen Android en Apple toestellen klinkt echt als een hele hoop niet-standaard gedrag...

Dat wil dan ook zeggen dat mijn voorstel om tijdelijk de Proximus gateway te gebruiken (vermoedelijk) ook maar zal werken tot de interactie die CCatalyst beschrijft ook daar alles in de war brengt.

[Indira]

Iig ook zeker zijn dat de laatste versie van Unifi en van de Dream Machine firmware geinstalleerd is.

Volgens de controller is alles up to date.

Zijn android toestellen gekend voor dit soort problemen te veroorzaken?

Dit verklaart ook waarom het probleem zich pas na een tijd voordoet, het betrokken Apple toestel moet eerst in slaapstand terecht komen, vervolgens moet de DHCP lease nog vervallen (default = 1 dag), en dan moet er nog een Android toestel zijn die dat bizar ICMP-pakket stuurt alvorens aan de voorwaarden voldaan is.

Als dit het probleem is, zou het uitschakelen van de Android toestellen of de Apple toestellen in slaapstand aan de wired ports een oplossing moeten zijn. Daarna wel nog eens de Dream Machine herstarten, en dan nagaan of het probleem nog terugkomt.

Iets langer dan 1 dag later was het probleem er weer...
Dus: Android toestel van het netwerk verwijderd en de UDM herstart.
We zijn alvast benieuwd naar de situatie in de komende dagen.

Opmerkelijk: bij de herinstallatie kreeg de werkcomputer een correct dchp ip (controle via ipconfig) en was er internet connectie
maar: in het controller dashboard werd deze vermeld met een 169.254.x.x adres

[ITnetadmin]

Dus, maw, het apple toestel heeft geen IP adres meer door het verstrijken van zijn DHCP lease, en ipv een nieuwe Discover uit te sturen, krijgt ie een ICMP pakketje binnen met een destination IP en op L2 aan iedereen gericht, en is ie zo dom om aan te nemen dat dit dan maar zijn adres moet zijn.
Wow, da's een bug van formaat.

[Indira]

Tot op heden niet meer voorgevallen
Vanop het moment dat de android smartphone enkel op 4G connectie maakt en niet op wifi zijn geen problemen meer met bekabelde verbindingen.
Zowel de apple tv als de laptops (allen windows) krijgen van op dat moment een correct dhcp ip adres, ook na release en renew met ipconfig

Aangezien dit pas ontstaan is sinds de UDM en nooit voorviel op de bbox: hoe kan ik deze bug documenteren en melden bij unifi?
En een ook melding te maken bij android/google?

bestaat er een work around? (Fixed ip voor de apple tv?)
Want alle android toestellen weigeren op de wifi is, na de lockdown, onbegonnen werk...

[rapidgorgon]

Is het een optie om voor de Android toestellen een gescheiden VLAN aan te maken met bijhorend SSID (WiFi-netwerk)? Het vraagt vast wat configuratiewerk (zie bv. deze infopagina), en de Android-apparaten zullen niet zomaar meer met de rest kunnen communiceren, maar zo kan je wel voorkomen dat die L2 broadcasts naar je Apple-apparaten verzonden worden.

[CCatalyst]

Aangezien dit pas ontstaan is sinds de UDM en nooit voorviel op de bbox: hoe kan ik deze bug documenteren en melden bij unifi?

Zij kunnen er niet echt iets aan doen denk ik, zeker als de switch-chipset niet in staat is de controles uit te voeren hierop. Waar het wel mogelijk is, bv op de AP's, doen ze wel de controles hierop en droppen ze de pakketten van de "rogue gateway". Ook op de "echte" Unifi managed switches kunnen ze dit controleren. Maar in de UDM daarentegen, waar sterk op wireless wordt ingezet met een high-end 4x4 802.11ac Wave 2 AP, zit er volgens mij alleen een eenvoudige "domme" switch-chipset voor die 4 poortjes, dat is altijd een beetje het nadeel van die "all-in-one" soort devices.

En een ook melding te maken bij android/google?

Ze weten dit beiden al meer dan een jaar. De ene steekt het op het "non-standard gedrag" van de andere, en dat is waar, beiden doen iets wat niet echt koosjer is volgens de regels en de combinatie daarvan zorgt voor het probleem. Het is overigens Android die het meest recent dat ICMP-pakket geintroduceerd heeft, waardoor Apple in het bijzonder geen redenen ziet om iets aan te passen dat ze al jaren doen.

Want alle android toestellen weigeren op de wifi is, na de lockdown, onbegonnen werk...

Het voorstel van rapidgorgon is een goede oplossing.

Nog mogelijkheden:

Kan je de Apple toestellen die wired zitten op de switch niet wireless verbinden?

Wat je ook kan proberen is die wired Apple toestellen allemaal een static IP te geven, (niet alleen) in de Unifi controller maar vooral geconfigureerd in het Apple toestel zelf. Dan gaat ie in principe altijd weten wat z'n IP is, maar ik heb persoonlijk niet getest of dat het probleem oplost. Default DHCP pools in Unifi beginnen pas vanaf x.6 dus x.2-x.5 kan je eventueel toewijzen hiervoor. Zonee moet je de pool wat korter maken en de IP's die vrijkomen gebruiken. Uiteraard ervoor zorgen dat elk toestel een uniek vast IP heeft - geen overlaps!

Een andere oplossing zou kunnen zijn om ICMP broadcasts (op L2) te filteren maar geen idee of de Unifi firewall dit kan.

[Yazin]

Hier een gelijkaardig voorval met een UDM, maar dan in volledige afwezigheid van een android device
Is het bij u opgelost?

Ik merk op de historiek van de apple tv giga veel connects om de paar minuten als deze in slaapstand zit

De apple tv hebben we nu een vast ip gegeven.
Afwachten of die in slaapstand weer zoveel (dis)connects gaat doen, want ik vrees dat daardoor de udm vastloopt op zn switch

Wel een fout in de udm software:
In het overzicht van connecties blijft de apple tv vermeld met het dhcp adres
Ookal heeft die nu een vast ip buiten de dhcp range
In de setting van het device zelf staat wel de correcte vaste ip adres

[DarkV]

Welke firmware/controller versies draaien jullie ?

[Yazin]

Hier is het (momenteel) in orde met het vaste ip adres.

Na een herstart van de udm machine is deze vaste ip adres ook zichtbaar in de controller

Volgens de software is alles up to date

[DarkV]

Volgens de software is alles up to date

Dat was de vraag niet... welke versie draai je ?

[Yazin]

De versie is 5.12.30 van het ik kan vinden

[Yazin]

Weer is het geweest te gebeuren

AppleTV had geen connectie,
ip adres stond wel nog zoals ingezet op de vaste nummer

UDM reboot gedaan, appleTV reboot gedaan

Nu weer terug goed, afwachten!

[DarkV]

De versie is 5.12.30 van het ik kan vinden

Ondertussen zit men aan 5.13.32 (onderdeel van 1.7.3-rc1).