Nach Migration Knoten nicht im Config-Modus erreichbar

Hallo,

viele Knoten sind einwandfrei automatisch migriert worden. Allerdings machen die TP-Link 1043 Vx.x Probleme. Diese meshen zwar per WLAN und die Statusseite ist per IPv6 erreichbar, aber sie bekommen am WAN-Port kein Internet.

Bei zwei Knoten ist es mir gelungen diese per 203.0.113.1 anzusprechen und die Bielefelder Firmware ohne Konfigübernahme neu zu flashen. Danach händisch konfigurieren und alles ist fein wie es sein sollte. Zwei 1043 (einer V3, einer V2.1) habe ich hier aber, an denen ich mir die Zähne ausbeiße. Ich kann sie in den Config-Mode versetzen, aber dann holen sie sich keine IPv4. Ein Zugriff über die 203.0.113.1 scheitert. Zwar kommt dort eine Seite …

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
		<meta http-equiv="Pragma" content="no-cache" />
		<meta http-equiv="Expires" content="0" />
		<meta http-equiv="refresh" content="0; URL=/cgi-bin/config" />
	</head>
	<body>
	</body>
</html>

… aber die Weiterleitung zu /cgi-bin/config landet in einem Timeout. Grundsätzlich scheint also die 203.0.113.1 dann erreichbar, aber mit der Firmware passt was nicht.

Ich habe auch versucht per TFTP die Firmware zu flashen (was in der Vergangenheit durchaus auch schon mal funktioniert hat), aber auch das gelingt bei diesen 1043 nicht. Es kommt schlicht keine Meldung, die ich interpretieren könnte.

Viele Grüße

Andreas

Moin,

wie gesagt, ich hab’ nur 'nen 1043Nv5 hier. Reset gedrückt bis Reboot => Config-Mode.

root@cohen:~# ip addr show enxa0cec85b4714
14: enxa0cec85b4714: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether a0:ce:c8:5b:47:14 brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.11/24 brd 203.0.113.255 scope global enxa0cec85b4714
       valid_lft forever preferred_lft forever
wusel@cohen:~$ ping 203.0.113.1
PING 203.0.113.1 (203.0.113.1) 56(84) bytes of data.
From 203.0.113.11 icmp_seq=1 Destination Host Unreachable
[…]
From 203.0.113.11 icmp_seq=47 Destination Host Unreachable
64 bytes from 203.0.113.1: icmp_seq=48 ttl=64 time=1015 ms
64 bytes from 203.0.113.1: icmp_seq=49 ttl=64 time=0.484 ms
[…]

Also:

wusel@cohen:~$ ssh -A root@203.0.113.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
[…]
Host key verification failed.
wusel@cohen:~$   ssh-keygen -f "/home/wusel/.ssh/known_hosts" -R "203.0.113.1"
# Host 203.0.113.1 found: line 1528
/home/wusel/.ssh/known_hosts updated.
Original contents retained as /home/wusel/.ssh/known_hosts.old
wusel@cohen:~$ ssh -A root@203.0.113.1
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
RSA key fingerprint […]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.1' (RSA) to the list of known hosts.


BusyBox v1.30.1 () built-in shell (ash)

      _/_/_/_/                      _/      _/_/                      _/
     _/        _/  _/_/    _/_/          _/      _/    _/  _/_/_/    _/  _/
    _/_/_/    _/_/      _/_/_/_/  _/  _/_/_/_/  _/    _/  _/    _/  _/_/
   _/        _/        _/        _/    _/      _/    _/  _/    _/  _/  _/
  _/        _/          _/_/_/  _/    _/        _/_/_/  _/    _/  _/    _/

  Freifunk-Firmware für den Kreis Gütersloh, für Bielefeld, Bad Oeynhausen,
  Minden, Lüneburg sowie die Müritz-Region und die Feldberger Seenlandschaft

  Info/Kontakt: https://freifunk-bielefeld.de | https://mueritz.freifunk.net
                  https://freifunk-kreisgt.de | https://freifunk-feldberg.de
            https://freifunk-badoeynhausen.de | https://freifunk-lueneburg.de

  Tools:
  - autoupdater -f    (Firmware-Update erzwingen)
  - batctl gwl        (Informationen zu batman-adv-Gateways anzeigen)
  - batctl o | wc -l  (Anzahl 'orginators' (Knoten) im Netz anzeigen)
  - batctl tg | wc -l (Anzahl aller Geräte im Netz anzeigen)


  OS: 19.07-SNAPSHOT, r11430+26-ecbbb3    FW: 1.4.0~75                        
  HW: TP-LINK TL-WR1043N v5                                               
root@32549-Liegnitzer-Str-ab8a:~# ip addr show | grep " eth"
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
6: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-setup state UP group default qlen 1000
7: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 203.0.113.1/24 brd 203.0.113.255 scope global eth0.1
root@32549-Liegnitzer-Str-ab8a:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-setup		7fff.b04e26b0ab8a	no		eth0.2
root@32549-Liegnitzer-Str-ab8a:~#

Webseite, wget:

wusel@cohen:~$ wget -O - --save-headers http://203.0.113.1
--2023-03-06 17:31:40--  http://203.0.113.1/
Verbindungsaufbau zu 203.0.113.1:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 345 [text/html]
Wird in »STDOUT« gespeichert.
HTTP/1.1 200 OK
Connection: Keep-Alive
Keep-Alive: timeout=20
ETag: "173-159-63d9e04d"
Last-Modified: Wed, 01 Feb 2023 03:45:17 GMT
Date: Wed, 01 Mar 2023 18:27:52 GMT
Content-Type: text/html
Content-Length: 345


-                     0%[                    ]       0  --.-KB/s               <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
		<meta http-equiv="Pragma" content="no-cache" />
		<meta http-equiv="Expires" content="0" />
		<meta http-equiv="refresh" content="0; URL=/cgi-bin/config" />
	</head>
	<body>
	</body>
</html>
-                   100%[===================>]     345  --.-KB/s    in 0s      

2023-03-06 17:31:40 (54,9 MB/s) - auf die Standardausgabe geschrieben [345/345]
wusel@cohen:~$ wget -O - --save-headers http://203.0.113.1/cgi-bin/config
--2023-03-06 17:36:28--  http://203.0.113.1/cgi-bin/config
Verbindungsaufbau zu 203.0.113.1:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 302 Found
Platz: /cgi-bin/config/wizard [folgend]
--2023-03-06 17:36:28--  http://203.0.113.1/cgi-bin/config/wizard
Wiederverwendung der bestehenden Verbindung zu 203.0.113.1:80.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »STDOUT« gespeichert.
HTTP/1.1 200 OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Keep-Alive: timeout=20
Expires: 0
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache
Vary: Accept


-                       [<=>                 ]       0  --.-KB/s               <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
	<head>
		<meta charset="UTF-8" />
		<link rel="stylesheet" type="text/css" media="screen" href="/static/gluon.css" />
		<title>32549-Liegnitzer-Str-ab8a - Wizard</title>
	</head>
	<body>

	<div id="menubar">
[…]
2023-03-06 17:36:29 (83,4 KB/s) - auf die Standardausgabe geschrieben [/6625]

Webseite, Browser:

Kurzum: Ich kann das leider nicht nachvollziehen.

Bitte schick’ mal ein ip addr show | grep " eth" ; brctl show von diesen 1043 ohne WAN — einmal aus’m Config-Mode und einmal aus dem Normalbetrieb.

Ist denn das WAN wieder da, wenn Du FFBI 0.6.5 wieder installierst (sysupgrade -n)?

Abhilfe: Einloggen, per „firstboot“ das Overlay-FS entsporgen und from Scratch installieren, mehr fällt mir dazu auch nicht ein. Du kannst sonst auch noch über fw.4830.org das Image aus dem aktuellen tng (≥ 1.5.0~71) ziehen, ab Build 71 basiert das auf Gluon v2022.1.3, wo Probleme mit insbesondere 1043er (im aktuellen OpenWrt und damit Gluon) behoben wurden — allerdings Probleme mit der Initialisierung des WIFis, nicht des Ethernets …

Kollegen in Löhne hatten auch Probleme, die teilweise aber auf grundsätzlichem Mißverständnis beruhten (»kein Webinterface auf der WAN-IP«), was zu weiteren Hinweisen führte. Dort konnten aber AFAIK alle 1043 mindestens durch Neuaufsetzen im Config-Mode aktiviert werden.