Mal wieder... WebUI nicht erreichbar

[Thisoft]

HAllo zusammen,

nach einer Neuinstallation wegen Bookworm habe ich das Problem dass die WebUI nicht erreichbar ist. Die piVCCU scheint aber soweit fehlerfrei zu laufen:

Code: Alles auswählen

pi@piPivCCU:~ $ sudo pivccu-info
piVCCU version: 3.71.12-85
OS:             Raspbian GNU/Linux 12 (bookworm)
Kernel:         6.1.0-rpi6-rpi-v7 armv7l
Kernel modules: Available
Raw UART dev:   Available
HMRF Hardware:  HM-MOD-RPI-PCB
 Connected via: GPIO@3f201000.serial (/dev/raw-uart)
 Board serial:  OEQ0611036
 Radio MAC:     0x5C7F92
HMIP Hardware:  HM-MOD-RPI-PCB
 Connected via: GPIO@3f201000.serial (/dev/raw-uart)
 SGTIN:         3014F711A061A7D70992BADC
 Radio MAC:     0xBB6073
State:          RUNNING
PID:            1208
IP:             192.168.137.94
Link:           vethpivccu
 TX bytes:      26.03 KiB
 RX bytes:      3.31 MiB
 Total bytes:   3.34 MiB

Ping aus dem Netzwerk funktioniert:

Code: Alles auswählen

C:\Users\Admin>ping 192.168.137.94

Ping wird ausgeführt für 192.168.137.94 mit 32 Bytes Daten:
Antwort von 192.168.137.94: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.137.94: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.137.94: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.137.94: Bytes=32 Zeit=1ms TTL=64

Ping-Statistik für 192.168.137.94:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

Ping auf Heise.de geht auch:

Code: Alles auswählen

pi@piPivCCU:~ $ sudo pivccu-attach ping www.heise.de
PING www.heise.de (193.99.144.85): 56 data bytes
64 bytes from 193.99.144.85: seq=0 ttl=241 time=69.781 ms
64 bytes from 193.99.144.85: seq=1 ttl=241 time=61.499 ms
64 bytes from 193.99.144.85: seq=2 ttl=241 time=77.353 ms
64 bytes from 193.99.144.85: seq=3 ttl=241 time=61.966 ms
64 bytes from 193.99.144.85: seq=4 ttl=241 time=60.521 ms
^C
--- www.heise.de ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 60.521/66.224/77.353 ms

Fehlermeldung bekomme ich diese - auf 3 verschiedenen Browsern...

Firewall finde ich nicht hat sich da bei Bookworm mal wieder alles geändert???

Weiß gerade nicht wo ich noch ansetzen könnte... Bitte um Hilfe.

[Thisoft]

Da mir bisher noch niemand helfen konnte versuch ich's nochmal... Stand der Dinge ist momentan dass die WebUI manchmal zeitweise erreichbar ist, dabei auch öfters mal abstürzt wobei nach einem Absturz meist sogar relativ schnell wieder erreichbar ist. Manchmal geht aber nach wie vor gar kein Zugriff, irgendwann eine Weile später funktioniert's dann mal wieder.

Sehr schleierhaft das Ganze. Der RasPi an sich läuft aber soweit ich das sehen kann sauber durch. Allerdings ist der SWAP ziemlich ausgelastet, nicht so gut oder?

Screenshot 2024-01-01 181943.jpg (17.61 KiB) 419 mal betrachtet

Könnte das außerdem noch was mit der Netzwerkkonfig zu tun haben?

Code: Alles auswählen

pi@piPivCCU:~ $ ip addr
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 noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether b8:27:eb:7d:64:a4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.137.61/24 brd 192.168.137.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2750:188a:6cf8:9854/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b8:27:eb:7d:64:a4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.137.94/24 brd 192.168.137.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe7d:64a4/64 scope link
       valid_lft forever preferred_lft forever
4: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
       valid_lft forever preferred_lft forever
8: vethpivccu@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether fe:e2:2e:9d:0b:5d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fce2:2eff:fe9d:b5d/64 scope link
       valid_lft forever preferred_lft forever

[chriwi]

HAllo zusammen,
…
Firewall finde ich nicht hat sich da bei Bookworm mal wieder alles geändert???

Weiß gerade nicht wo ich noch ansetzen könnte... Bitte um Hilfe.

Hallo Thisoft,

die offizielle Empfehlung für Bookworm ist wegen diverser Änderungen eine Neuinstallation zu machen.

Ich hatte es mit einem Upgrade probiert, siehe viewtopic.php?f=69&t=80244

Je nach (Re-)konfiguration von Dir kann das eine mögliche Ursache Deines Problems sein

[Thisoft]

Hallo Chriwi,

ich habe eine Neuinstallation gemacht (steht im ersten Satz . Nur die Netzwerkkonfiguration hatte dabei nicht automatisch funktioniert, so dass ich die Netzwerk-Bridge "br0" manuell nach der Anleitung auf der pivCCU-Github-Seite hinzugefügt habe... vielleicht ist es ja doch "nur" ein Netzwerkproblem...?

[deimos]

Hi,

deine Netzwerkconfig ist falsch. Du hast sowohl für eth0, als auch für br0 unterschiedliche IPs. Das kann bei einer korrekt konfigurierten Bridge nicht sein. Zusätzlich hat deine Bridge br0 im Host die gleiche IP wie der Container, dami kann der Container nicht erreichbar sein.

Wie hast du genau das Netzwerk konfiguriert? Wie sieht deine /etc/network/interfaces aus?

Viele Grüße
Alex

[Thisoft]

Hi Alex und Vielen Dank für Deinen Hinweis,

die Netzwerkkonfiguration war's. Ich habe jetzt der Bridge br0 eine andere IP gegeben (.61) . Damit läuft's und die CCU ist erreichbar! Ist ja auch klar, dass 2x die gleiche IP im Netzwerk Trouble gibt, da war ich mit Blindheit geschlagen .

Du schreibst allerdings noch dass eth0 und br0 die gleiche IP haben sollten... ist das wirklich so? Wenn ja, warum?

Gruß
Thilo

[deimos]

Hi,

an sich sollte eth0 gar keine IP haben, sondern nur br0.
Aktuell hast du jetzt zwei logische Interfaces mit der gleichen MAC Adresse (eth0 und br0), dass sollte man vermeiden.
Und vor allem hat man hier wieder mal ein Bespiel für den "Spaß" im Support, bei dem irgendwas total spezielles konfiguriert wurde, es nicht funktioniert und dann nach Hilfe gefragt wird ohne dass man auf die spezielle Konfig erwähnt. Hättest du das ganze genau so gemacht, wie es in der Anleitung steht, hätte es das Problem gar nicht erst gegeben.

Viele Grüße
Alex

[Thisoft]

Hättest du das ganze genau so gemacht, wie es in der Anleitung steht, hätte es das Problem gar nicht erst gegeben.

Hast du mir bitte mal einen Link zu der Anleitung die du dafür empfiehlst? Ich frage gleich mal noch direkt - ist die Anleitung schon für die seit Bookworm "aktuelle" Netzwerkkonfiguration über nmcli?

an sich sollte eth0 gar keine IP haben, sondern nur br0.

eth0 bekommt doch automatisch eine über DHCP wenn das nicht explizit abgeklemmt wird - oder?

[deimos]

Hi,

ich meine die piVCCU Anleitung, wie sie auf Github ist. Ja, die ist ohne nmcli, aber die Konfiguration über /etc/network/interfaces ist nicht deprecated und im Gegensatz zu den regelmäßig neuen Varianten funktioniert sie seit Jahrzehnten zuverlässig.

Viele Grüße
Alex

[Thisoft]

Ist schon OK dass du das noch nicht auf nmcli umgestellt hast. Soll auch kein Vorwurf sein. Ich wunder mich nur immer wieder dass Linux auch ständig Updates mit noch nicht so ganz zuverlässigen, neuen Funktionen rausbringt - genau das ist ja der Vorwurf den Linuxer den Windoofs ständig machen wollen

Ich glaube, ich weiß jetzt auch wieder wie die doppelte IP zustande kam. Ich wollte natürlich meine IP der alten CCU wieder verwenden und habe da in der /etc/network/interfaces für die Bridge gleich die gewünschte fest eingetragen - in der irrigen Annahme dass das die wäre unter der die CCU erreichbar ist...