staging.inyokaproject.org

Ich kann mich mit dem WLAN im ICE nicht richtig verbinden. Die Login-Seite für das WLAN wird nicht angezeigt, obwohl (glaube ich) eine grundsätzliche Verbindung besteht. In verschiedenen Foren wird docker als Problem identifiziert, aber das habe ich nicht installiert. (Mit dem Handy war gleichzeitig eine Verbindung möglich.)

L460:~$ iwconfig
lo        no wireless extensions.

enp0s31f6  no wireless extensions.

wlp3s0    IEEE 802.11  ESSID:"WIFIonICE"  
          Mode:Managed  Frequency:5.18 GHz  Access Point: A8:B4:56:3D:0C:80   
          Bit Rate=130 Mb/s   Tx-Power=22 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=45/70  Signal level=-65 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

L460:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 50:7b:9d:b7:08:6e brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default qlen 1000
    link/ether a4:34:d9:b0:58:83 brd ff:ff:ff:ff:ff:ff
    inet 172.18.163.210/16 brd 172.18.255.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 543sec preferred_lft 543sec
    inet6 fe80::55b4:5051:335a:6bbe/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

hdis1969 schrieb:

Ich kann mich mit dem WLAN im ICE nicht richtig verbinden.

Die Nutzung eines WLANs mit Portalseite ist generell problematisch. Es gibt zu viele Varianten.

Die Login-Seite für das WLAN wird nicht angezeigt

Du musst jedenfalls einen Internet-Browser starten, sofern das nicht automatisch erfolgt, und eine beliebige Seite aufrufen. Statt dieser sollte die Portalseite erscheinen; diese wie von ihr angefordert bedienen. Falls die von Dir angeforderte Seite erscheint, bist Du bereits angemeldet.

Danke! Der Aufruf der Portalseite (login.wifionice.de, vgl. https://www.bahn.de/service/zug/wlan-im-zug) im Browser hat allerdings nicht funktioniert.

Vielleicht kannst du das Smartphone mit dem WLAN verbinden und dann das Smartphone als Hotspot nutzen, ich bin unsicher, ob das funzt. Aber versuchen könntest du es. Kommt natürlich erstmal darauf an, ob dein Smartphone diese Funktion unterstützt.

LG

Imho cookies aktivieren, Adblock aus und zuerst Firmenproxy ausmachen.

Habe es nochmal mit verschiedenen Browsern (Firefox, Chrome, Chromium und Edge) versucht. Leider erfolglos. Firmenproxy o.ä. ist nicht vorhanden.

Funktioniert mit Firefox reproduzierbar problemlos.

Mit allem Chromium-basierenden dagegen hier gar nicht

Ich habe nochmal zwei Screenshots hochgeladen, die zeigen, dass in den WLAN-Einstellungen der Verbindungsstatus als "verbunden" angezeigt wird (während die Verbindung aber nicht funktionsfähig ist) und wie das Fenster "Hotspot-Anmeldung" ausschaut, das ab und an erscheint (meistens, wenn ich die WLAN-Verbindung vorher gelöscht habe und den Rechner komplett neu starte) und eine Verbindung zu http://connectivity-check.ubuntu.com herstellen will.

hdis1969 schrieb:

[…] in den WLAN-Einstellungen der Verbindungsstatus als "verbunden" angezeigt wird (während die Verbindung aber nicht funktionsfähig ist)

Angezeigt wird, dass Du mit dem WLAN verbunden bist. Damit ist nicht notwendigerweise die Zuweisung einer IP-Adresse verbunden und falls Du doch bereits eine solche bekommen hast, bedeutet „verbunden“ keine Zusicherung zur Weiterleitung ins Internet.

Zugewiesene IP-Adressen kann man sich so anzeigen lassen:

ip addr 

und wie das Fenster "Hotspot-Anmeldung" ausschaut, das ab und an erscheint (meistens, wenn ich die WLAN-Verbindung vorher gelöscht habe und den Rechner komplett neu starte) und eine Verbindung zu http://connectivity-check.ubuntu.com herstellen will.

Warum willst Du so etwas sinnloses tun? Der Server http://connectivity-check.ubuntu.com erzeugt niemals eine lesbare HMTL-Ausgabe, sondern liefert als Antwort nur HTTP-Header:

$ wget -S  http://connectivity-check.ubuntu.com/
--2023-06-22 14:01:58--  http://connectivity-check.ubuntu.com/
Auflösen des Hostnamens connectivity-check.ubuntu.com (connectivity-check.ubuntu.com) … 2001:67c:1562::23, 2001:67c:1562::24, 2620:2d:4000:1::2a, ...
Verbindungsaufbau zu connectivity-check.ubuntu.com (connectivity-check.ubuntu.com)|2001:67c:1562::23|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 204 No Content
  server: nginx/1.14.0 (Ubuntu)
  date: Thu, 22 Jun 2023 12:01:58 GMT
  x-cache-status: from content-cache-1ss/0
  x-networkmanager-status: online
2023-06-22 14:01:58 (0,00 B/s) - »index.html« gespeichert [0]

NetworkManager benutzt die markierte Header-Zeile zur Überprüfung der Konnektivität, das hat aber gar nichts mit dem Aufbau einer IP-Verbindung ins Internet zu tun.

Ich würde ja voll gern was sinnvolles tun, allein mir fehlen dafür die Fachkenntnisse. Lustigerweise habe ich während eines Aufenthalts am Bahnhof zu WIFI@DB (vgl. https://www.bahn.de/service/zug/wlan-bahnhof) problemlos eine Verbindung aufbauen können.

Ich hatte heute auch das Problem. Ursprünglich lag's bei mir mal an Docker, aber das kann ich jetzt ausschließen.

Ich hab' definitiv eine IP-Adresse erhalten (100.72.78.198), konnte aber keine Portal-Seite öffnen (nur mit Chromium ausprobiert).

Kann das leider jetzt erstmal nicht testen, aber hier gibt's paar mögliche Lösungen:

• https://jogruber.de/blog/linux-fix-broken-dns-when-using-wi-fi-in-german-ice-trains

• https://gist.github.com/TimKraemer/512e8a73dcbf34d57ba19824ef199d57

• https://blog.medienman.de/blog/2023/10/04/wlan-im-ice-loginseite-oeffnet-sich-nicht/

Hallo hdis1969,

Dies muss auf off stehen ....

Power Management:on

Gruss Lidux

Ich hatte das gleiche Problem wie @Wurzel. Bei mir hatte das Docker Interface die gleiche default IP-Address Range wie ich vom DHCP Server der Bahn zugeteilt bekommen habe.

Noch ein Link um das Problem mit dem Docker Daemon dauerhaft zu beheben: https://slurpit.io/knowledge-base/change-docker-default-interface-ip-and-subnet/