Firmware-Problem: Webserver antwortet nicht

Hilfe / Support Gerätebau & Reparatur
#1

Ich versuche meinen OBS mit dem Access-Point-Modus zu konfigurieren, aber es klappt leider nicht.

Ich kann mich erfolgreich zum WLAN verbinden und den Microcontroller pingen:

$ ping 172.20.0.1            
PING 172.20.0.1 (172.20.0.1) 56(84) bytes of data.
64 bytes from 172.20.0.1: icmp_seq=1 ttl=64 time=0.066 m

Aber der Webserver antwortet auf http und https nicht:

$ wget http://172.20.0.1 -O - 
--2022-01-11 18:47:45--  http://172.20.0.1/
Connecting to 172.20.0.1:80... failed: Connection refused.
$ wget https://172.20.0.1 -O -
--2022-01-11 18:47:44--  https://172.20.0.1/
Connecting to 172.20.0.1:443... failed: Connection refused.
$ nmap 172.20.0.1 -PN
Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-11 18:53 CET
Nmap scan report for theos (172.20.0.1)
Host is up (0.00020s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
1717/tcp open  fj-hdnet

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Es hat schon einmal geklappt und wir haben ein WLAN konfiguriert gehabt, aber das gibt es leider nicht mehr in der Nähe. Also habe ich mir gedacht, vielleicht hängt es damit zusammen und habe zuerst die Firmware neu geflasht per Kabel und dann den ganzen Flash gecleared bevor ich die Firmware neu drauf gespielt habe:

python3 -m esptool \       
    --chip esp32 \
    --port /dev/ttyUSB0 \
    erase_flash

(Achtung! Dazu braucht man das epstool >= 3.0, weil v2.8 einen Bug hat und erase_flash ist da kaputt.)

Danach ist beim Booten der SSL-Key neu erstellt worden, aber weiterhin gleiche Symptome.

Mir gehen langsam die Ideen aus woran das liegen könnte. Hat wer einen Tipp?

Firmware-Version: v0.11.706

#2

Oh! Vom Handy aus geht es. Ich habe mehrere Browser auch im Private-Mode funktioniert und wie oben ersichtlich ist ja auch der Port nicht offen. Ich kann mir das nicht erklären.

#3

Hallo @lumbric, Willkommen im Forum!

Deine Bitte um Hilfe ist klasse, mit konkreten Symptomen und den Schritten die du schon versucht hast. Super, weiter so!

Ich kann dir hier leider kaum helfen, außer „die üblichen Verdächtigen“ ins Spiel zu bringen:

  • Firewall auf dem PC an, die das blockiert?
  • Hat der PC im Access Point eine IP im Subnetz 172.20.0.0/24 bekommen? (ip addr oder ipconfig oder ifconfig je nach Betriebssystem)

Ob du vorher ein anderes WLAN konfiguriert hattest sollte egal sein. Der OBS macht dann wie beim ersten Mal seinen eigenen AP auf, der genau so funktioniert wie sonst – eigentlich :wink:

Bist du außerdem sicher, dass die IP stimmt, und dass nicht noch ein anderes Netzwerk bei dir dieses Subnetz verwendet? Ein Port 22 sollte auf dem ESP32 nicht offen sein, das ist merkwürdig, was nmap dort berichtet. Könnte einfach ein anderer host sein, als der, den du vermutest. ip route könnte helfen das zu analysieren.

Edit: Bei mir weist Docker einem bridge interface standardmäßig scheinbar 172.20.0.0/16 zu, dem nächsten dann 172.21.0.0/16 und so weiter. Das könnte kollidieren, falls du beim ersten Mal (als es noch ging) gerade kein docker network erstellt hattest, und nun eins hast:

--» ip route
default via 10.13.37.1 dev wlp61s0 proto dhcp metric 600 
10.13.37.0/24 dev wlp61s0 proto kernel scope link src 10.13.37.101 metric 600 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.20.0.0/16 dev br-f2a037496554 proto kernel scope link src 172.20.0.1 
172.21.0.0/16 dev br-5543867d96a5 proto kernel scope link src 172.21.0.1 linkdown
1 „Gefällt mir“
#4

Oh danke für die schnelle Antwort, das war’s in der Tat! Ich hab’s dann schon mit dem Handy geschafft mein WLAN zu konfigurieren, aber ja - du hast vollkommen recht. Ich habe hier einfach nicht den microcontroller gepingt, sondern ein Netzwerkinterface von docker. Dass der host, der falsche host sein könnte, auf die Idee bin ich nicht gekommen, dabei hab ich sogar noch die IP kontrolliert gehabt mit ip a, aber wohl nicht weit genug runter gescrollt. Das letzte Mal wie es funtioniert hat, war es ein anderer Computer, wohl ohne Docker.

$ ip a
[...]
7: br-868f14b54a30: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:4a:52:17:ec brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-868f14b54a30
       valid_lft forever preferred_lft forever
8: br-e23b614f9cbc: <NO-CARRIER,BROADCAST,MULTICAST,UP>
[...]

Danke!

2 „Gefällt mir“
#5