Nach oben

Diese Frage wartet auf Beantwortung

Warum klappt Login im neuen WifionICE mit Ubuntu nicht mehr?

Hallo,

ich fahre sehr häufig Bahn (BC 100), auch mit verschiedenen ICEs und hatte mit dem Telekom Hotspot fast nie Probleme. Seit es dieses WifiOnICE gibt, kann ich mich zwar mit dem Hotspot verbinden, bekomme auch eine IP zugewiesen, aber kann keine Webseiten aufrufen, weder die wifionice.de noch sonstige.
Handy und Tablet funktioniert. Das System ist eine Ubuntu 14.04.

Es ist im Wesentlichen das selbe Symptom wie https://community.bahn.de/questions/1211627-1-klasse-wifi..., nur hat es sich nach der offiziellen Einführung des sozialistischen WLAN-Zugangs nicht gelöst.

Nochmal zur Verdeutlichung: Es liegt an keiner Uhrzeit, keinem Bestimmten ICE, Wetterlage oder Mondphasen. Es tritt IMMER auf.

Ich bitte Sie, sich diesem Problem zügig zu widmen, da ich sehr viel Geld für Bahnreisen investiere und im Jahr 2017 erwarte, einen - wenn auch nicht kostenlosen - funktionierenden Internetzugang zu erhalten.

Anonym
Anonym

Anonym

Ebene
0
33 / 100
Punkte

Antworten

Anonym
Anonym

Anonym

Ebene
0
33 / 100
Punkte

Weder Chrome noch Firefox klappt.
Meine Verbindungsdaten:

wlan0 Link encap:Ethernet Hardware Adresse **:**:**:**:**:**
inet Adresse:172.16.64.35 Bcast:172.16.255.255 Maske:255.255.0.0
inet6-Adresse: fe80::6267:20ff:feec:f0a0/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1350 Metrik:1
RX-Pakete:5524795 Fehler:0 Verloren:1 Überläufe:0 Fenster:0
TX-Pakete:3011936 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:5279669237 (5.2 GB) TX-Bytes:642797355 (642.7 MB)

$ ping wifionice.de
PING wifionice.de (172.18.10.10) 56(84) bytes of data.
From nbanfe.local (172.18.0.1) icmp_seq=1 Destination Host Unreachable
From nbanfe.local (172.18.0.1) icmp_seq=2 Destination Host Unreachable
From nbanfe.local (172.18.0.1) icmp_seq=3 Destination Host Unreachable
^C
--- wifionice.de ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3146ms
pipe 3

Anonym
Anonym

Anonym

Ebene
0
11 / 100
Punkte

Ein Workaround der bei mir funktioniert hat:

http://172.18.10.10/ zum Einloggend verwenden, das ist die IP von wifionice.de

Anonym
Anonym

Anonym

Ebene
0
33 / 100
Punkte

Ich hatte eben dasselbe Problem. Bei mir war die Ursache, dass auf meinem Laptop Docker bzw LXC installiert ist und diese Dienste ein Bridge-Interface br-xxxxx auf der IP Adresse 172.18.0.1 konfigurieren:

$ ifconfig
br-034d1e2af367 Link encap:Ethernet Hardware Adresse 02:42:0a:4e:70:01
inet Adresse:172.18.0.1 Bcast:0.0.0.0 Maske:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metrik:1
RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:0 (0.0 B) TX-Bytes:0 (0.0 B)

Da die Seite zum Einloggen ins Wifi just in diesem Subnetz liegt wird es logischerweise auf das brige-interface geroutet.
Ich habe mit `ipconfig br-034d1e2af367 down` das Ding abgeschaltet und klappt's auch mit dem Wifi. Ist zwar erst mal ein Workaround, aber besser als nix.
Nun muss ich noch verstehen wofür genau das Bridge-Interface gebraucht wird und wie man dessen IP selbst festlegen kann.

Gruss,
darthvader

Anonym
Anonym

Anonym

Ebene
0
33 / 100
Punkte

Vielen Dank darthvader, genau das war es. Docker samt Bridge interface aus, neu verbinden, geht.

@Bahn: Den IP Adressraum auf eine der am meisten verwendeten zu legen (172.x.x.x) ist vielleicht keine gute Idee und führt sicher bei einer ganzen Menge an Benutzern zu Problemen Könnte auch oftmals ein Problem mit Firmen-VPNs auslösen. Einfacher wäre es, einen eher ungewöhnlichen Adressbereich zu nehmen.

Anonym
Anonym

Anonym

Ebene
0
33 / 100
Punkte

Schön, dass ich helfen konnte.

@bahn: Anfe hat recht, diese sehr weit verbreitet genutzte IP für's Login zu nutzen ist denkbar ungünstig. Am unproblematischsten ist es, wenn die IP für die wifionice.de Login-Seite aus demselben Netz ist, wie die über den DHCP zugewiesenene Adresse. Dann sollte es keine Konflikte geben.

Hallo zusammen,

wie hier auch schon vermutet, liegt das Problem nicht am Betriebssystem, sondern an der Nutzung/Konfiguration privater IP-Adressen beim Nutzer, die wir auch für WIFIonICE, ICE-Portal und Maxdome nutzen.

Das wird wohl immer mal passieren können. Aktuell geht man aber nicht von einer spürbaren Verringerung des Problems aus, wenn man andere IP-Adressbereiche verwendet. Alleine der DHCP-Adressbereich (Sitzplätze*x) ist schon groß und macht eine zufällige Überlappung nicht unwahrscheinlich.

Wenn Anwendungen nun einen privaten Adressbereich auf dem Endgerät nutzen, führt es dann dazu, dass diese Adressbereiche außerhalb des Rechners nicht mehr genutzt werden können. Zu diesen Anwendungen zählen auch viele VPN-Clients. Hier hatten die bisherigen (detaillierteren) Nutzermeldungen zur VPN-Nutzung aber eher in die Richtung MTU/Paketgrößen gedeutet als auf eine Überlappung von Adressbereichen.

Die im WIFIonICE genutzten Adressbereiche sind 172.16.x.x und 172.18.x.x. Nutzen Anwendungen auf dem Endgerät diese Adressbereiche, muss man entweder die Anwendung abschalten oder auf eine andere Adresse umkonfigurieren. /ti

Anonym
Anonym

Anonym

Ebene
0
33 / 100
Punkte

Hallo,

Ihre Antwort greift für mich zu kurz.

Die Lösung ist eigentlich ganz einfach: man muss nur über den DHCP Server in den Zügen eine explizite Route zur IP (oder dem Netz) der Login-Seite anbieten.

Hallo darthvader,

wir haben schon eine Rückmeldung aus dem Fachbereich.

Derzeit ist das System bewusst so gestaltet, dass über DHCP nur das (von wirklich allen Endgeräten unterstützte) Default-Gateway gesetzt wird. Dies gibt den (technischen) Nutzern auch die Flexibilität mit beliebigen eigenen lokalen Routingeinstellungen auf den Datenfluss einzuwirken.

Genau das passiert auch in Ihrem Fall, bei dem (entsprechend Ihres vorangehenden Posts) durch die direkt lokal auf Ihrem Laptop installierte Docker/LXC Software ein lokales Interface mit dem gesamten im 172.18.x.x Adressbereich definiert wird, das mit den unter anderen für die WIFIonICE-Anmeldeseite und weiteren Diensten genutzten IP Adressbereichen überlappt. Vielleicht würde man Ihre lokale IP-Konfiguration sogar von außen mit z.B. DHCP single routes (DHCP Option 33) überschreiben können (fraglich was hier, je nach Betriebssystem Vorrang erhält und erhalten sollte) – selbst wenn dem so wäre, würde man aber umgekehrt Adressen in Ihrem lokalen Docker/LXC Adreßbreich nicht mehr erreichen können. Daher schlägt unser Fachbereich vor, dass Sie Ihren Ansatz zur lokalen Umgehung auch weiterhin nutzen.

Viele Grüße /mi