die Unix User Group Rhein-Neckar ist einmal im Monat zu Gast im Seminarraum im Dezernat 16. Zunächst einmal vielen Dank für die in den letzten Monaten durchgeführten Verbesserungsmaßnahmen. Besonders die Installation des Ubiquity-Ufos im Seminarraum (MAC-Adresse 82:2A:A8:15:E3:14) hat die Verfügbarkeit drastisch verbessert, und seit der Switch repariert wurde ist auch die Anbindung nach draußen besser geworden.
Aktuell gibt es allerdings schon seit Monaten anhaltende Probleme mit IPv4: Es kommt regelmäßig vor, dass auf die DHCP-Requests unserer Clients einfach kein DHCP-Server antwortet. IPv6 funktioniert, das RA von fe80::5054:ff:fe3c:b702 kommt durch, eine IPv6-Adresse aus 2a01:4f8:171:fcff/64 wird gewürfelt und man kann pingen. Und es steht sogar ein DNS-Server drin und es ist jetzt meine Aufgabe herauszufinden warum mein NetworkDamager das ignoriert…
Wenn man IPv4 braucht, muss man sich disconnecten und so oft wieder connecten bis man eine IPv4-Adresse zugewiesen bekommt. Aber auf die Dauer ist es wenig schön, dass man regelmäßig zehn Minuten braucht bis man endlich auch mit legacy IP online ist.
Ist das Problem bekannt? Woran liegt es? Sind Aktionen dagegen geplant?
Danke für alle Hilfstellungen.
Grüße
Marc
(zum Suchen in Logs: Clientadresse 00:24:d7:d0:5a:dc um 2018-01-05 19:40)
kann ich so direkt nicht nachvollziehen, erhalte bei jedem connect direkt eine IPv4 Adresse.
Es läuft jedoch womöglich trotzdem etwas schief, ich bekomme nämlich keine IPv6 Adresse.
HD-Dezernat16 ist aktuell mit gw05 verbunden, mein ffrn-msu mit gw08, eventuell liegt es daran?
Hier noch meine logs:
ping 8.8.8.8
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=21ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=21ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=20ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=20ms TTL=58
Ping-Statistik für 8.8.8.8:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 20ms, Maximum = 21ms, Mittelwert = 20ms
dass die Technik des Freifunk Rhein-Neckar grundsätzlich in der Lage ist, mit einer gewissen Verlässlichkeit IPv4-Adressen auszugeben, steht außer Frage.
Das Problem mit den nicht ausgegebenen IPv4-Adressen tritt allerdings seit mehreren Monaten auf, und immer im Dezernat 16. Ich würde vermuten, dass der Fehler irgendwo dort zu suchen ist.
Ich habe in den letzten Wochen an verschiedenen Punkten im Freifunknetz immer einmal wieder das Problem auf dem Android Smartphone gehabt, dass ich das Telefon entsperrt habe, das WLAN sich verbunden hat und dann keine Verbindung zum Internet zu stande kam. Erst wenn ich das WLAN deaktiviert habe, habe ich nach dem Reaktivieren eine Verbindung ins Internet bekommen.
Ich hatte es nur festgestellt und jeweils keine Zeit gehabt zu recherchieren mit welchem Router und welchem Gateway ich verbunden bin. Von 10x passiert mir das sechsmal, dass ich ierst das WLAN deaktiviere.
Wäre super wenn jemand das die nächsten Tage nochmal überprüfen konnte.
Durch die Wartung sollte sich das Verhalten geändert haben.
Wenn möglich schreibt vorher mal hier rein, sodass eventuell jemand auf der Infrastruktur gegenprüfen kann.
Meine Meldung vom letzten Freitag könnte man z.B. auf Basis der DHCP-Server-Logs auch nachträglich gegenprüfen. Findet man die genannte MAC-Adresse nicht im Log, müsste man mir nur noch glauben, dass die DHCP-Requests bei mir rausgegangen sind. Findet man sie nicht im Log, ist es ein Netzproblem, sonst müsste im Log vom DHCP-Server stehen, warum er nicht geantwortet hat.
Ich verdächtige hier den DHCP-Server, weil das nicht auf DHCP angewiesene IPv6 die ganze Zeit tadellos funktioniert hat.
Wir loggen nur so viel, wie wir für eine laufende Verbindung brauchen. Heißt diese Infos haben wir nicht.
Und außerdem bitte ich ja darum, nach den gestern und heute durchgeführten Updates, erneut zu prüfen ob es sich jetzt gebessert hat.
Zur gleichen Zeit könnte dann auch einer der Admins in den laufenden Logs nachvollziehen wenn es Probleme gibt.
Ich werde am Freitag 2. Februar (“Murmeltiertag”) abends ab ca 19:30 Uhr im Dezernat 16 sein. Ist es möglich, dass zu diesem Zeitpunkt jemand vom Freifunk auf die Infrastruktur gucken kann und z.B. bis ca 21.30 Uhr reagieren kann, während ich noch am Ort bin? Wie kann ich Kontakt aufnehmen?
Ich hoffe ja, dass sich das Problem bis dahin erledigt hat, aber man weiß ja nie… Es wäre echt schade, wenn die UUGRN wieder mal ein FIXME mit “halbem” Netz veranstalten müsste.
Also ich habe mir gerade mal selbst ein Bild gemacht und im Dezernat16 versucht das Problem nachzustellen.
Bei mir hat DHCP in jedem Versuch nach 40-60s eine IPv4 zugewiesen. Das bewegt sich im Bereich dessen wie ich es bei jedem Knoten mit mehr als 5 Clients sehe.
IPv6 war allerdings sofort verfügbar und ich konnte nach etwa 3s via IPv6 pingen und surfen.
Ich kann nicht versprechen dass am Freitag um 19:30 jemand verfügbar sein wird um das auf Infrastrukturseite zu überprüfen.
Ideal wäre es wenn während dieses Zeitraums jemand im FFRN Chat ist und und informieren kann.
Das Problem im Dezernat 16 besteht nach wie vor; wir hatten gestern drei Teilnehmer die nicht arbeiten konnten. Dabei ist uns aufgefallen, dass zwar eine IPv6-Adresse gelernt wird, diese aber auch nicht funktionsfähig ist, da schon das Defaultgateway nicht anpingbar ist.
Bei einem Teilnehmer ist sogar das Netz, nachdem es eine halbe Stunde funktioniert hat, spontan verschwunden.
In Verwendung war jeweils der Accesspoint mit den MAC-Endziffern E3:14.
Im Chat war leider niemand :-(
Ich mache dann heute abend beim nächsten UUGRN FIXME einen nächsten (und letzten) Versuch, das Problem zu reproduzieren und hoffentlich zu einer Lösung zu bringen. Bin dann ab ca. 19:30 Uhr im Chat.
Vielleicht noch ein kleiner Hinweis, bei meinen Tests mit dem Offloader bei mir daheim, bin ich ein paarmal auf gw02.ffrn.de rausgekommen und hatte dann das Problem “keine IPv4-Adresse” bei mir daheim. gw05.ffrn.de ist ähnlich problematisch, rückt dann aber wenn man ganz hartnäckig fragt mit einer IPv4-Adresse raus; mit den anderen Gateways funktioniert es normal.
Meinen eigenen Offloader kann ich so lange durchtreten bis es funktioniert, auf dem Offloader im D16 hab ich allerdings keine Kekse. Wenn das Problem das nächste Mal besteht, schaue ich einfach mal nach (wenn das aus dem WLAN geht), mit welchem Gateway der Offloader verbunden ist.
Ich war gerade kurz im Dezernat 16 und hatte im Café Leitstelle, das Problem, dass ich manche Seiten nicht aufrufen konnte. Sie liefen auf einen Timeout. Z.b. www.foodsharing.de