VOIP: protocol not supported

superflip · 27. September 2024 um 09:39

Hallo,

ich stehe hier vor einem etwas seltsamen Problem. Irgendetwas ist bei meiner Installation vor 2 Tage passiert und ich habe einige Probleme. u.a. musste ich meinen Raspi seit dem schon 3x neu starten, damit (fast alle) funktionen wieder funktionieren. Ich tippte zuerst auf die Fehlermeldung, dass zu viele Skripte gleichzeitig laufen würden - das hab ich mal gefixt mit 2 Skripte umbauen/deaktivieren und dem setzen der max. Threads auf 50 - die Fehlermeldung bleibt fürs erste Mal weg.

Was ich aber noch nicht fixen konnte ist mein VoIP Problem - eben auch vor 2 Tagen ist zum ersten Mal die Fehlermeldung „Protocol not supported [93]“ gekommen. Wenn ich den VoIP Client in Symcon neu aktiviere, geht dieser aktiv ohne Fehlermeldung. Ich Logfile sehe ich aber:

logfile.log:27/09/24 11:28:48 | 32082 | MESSAGE | VoIP | Registering failed! Reason: Protocol not supported [93]

Ich habe heute Vormittag von 7.1 auf 7.2 upgedated in der Hoffnung, dass das vielleicht das Problem fixt, leider ohne Erfolg.

Nachdem meine Türklingel via VoIP geht, ist das grad ein bisschen unangenehm ohne Glocke.
Woran könnte das noch liegen bzw. wie könnte ich weiter troubleshooten.

Ich verwende übrigens einen asterisk SIP Server, der am selben Raspi läuft, dort taucht der Symcon-VoIP-Client trotz Fehler auf. der Client kann aber nicht angerufen werden (timeout)

Danke,
Philipp

paresy · 27. September 2024 um 18:28

Kannst du mal schauen, ob es hilft, wenn du beim Spezialschalter „ProxyInterface“ deine IP-Adresse vom Raspberry Pi eingibst?

paresy

superflip · 30. September 2024 um 07:02

die steht eh drinnen.
zur Info hierzu: Der Raspi hängt in 2 Netzen, einerseits das Netz, wo die Clients drauf zugreifen - andererseits das Netz mit allen Komponenten. Das Proxy-Interface habe ich auf das Komponenten-Netz konfiguriert. (in diesem Netz ist auch der asterisk Server und die VoIP Türglocke aktiv)

Danke,
Philipp

paresy · 30. September 2024 um 07:34

Kannst du Test-Weise mal IPv6 auf dem Pi deaktivieren? Vielleicht ist dies ein gangbarer Workaround.

paresy

superflip · 3. Oktober 2024 um 06:53

das hat das Problem gefixt!

Was hab ich gemacht:
Ich hab ipv6 via sysctl.conf deaktiviert:

net.ipv6.conf.all.disable_ipv6 = 1

danach mit „sysctl -p“ die Werte neu geladen.

WICHTIG! Symcon muss danach auch nochmals neu gestartet werden, sonst kommt die gleiche Fehlermeldung.

Danke für den Support!
Philipp

superflip · 3. November 2024 um 20:07

Hallo,

leider tritt das Problem seit einiger Zeit wieder auf (natürlich ab dem Zeitpunkt, wie ich für einige Tage nicht da war ;-( ).
Booten hilft auch nichts - ich habe dann gestern auf die letzte Release upgedated, auch das war leider nicht erfolgreich. (IPv6 ist nach wie vor ausgeschaltet)

logfile1730575373.log:02/11/24 20:22:56 | 00000 | MESSAGE | ModuleLoader logfile1730575373.log:02/11/24 20:23:53 | 32082 | MESSAGE | VoIP logfile1730575373.log:02/11/24 20:23:53 | 32082 | MESSAGE | VoIP logfile1730575373.log:02/11/24 20:23:53 | 32082 | MESSAGE | VoIP logfile1730575373.log:02/11/24 20:23:53 | 39393 | MESSAGE | VoIP logfile1730575373.log:02/11/24 20:23:53 | 39393 | MESSAGE | VoIP logfile1730575373.log:02/11/24 20:23:53 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:12 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:12 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:12 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile1730588409.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:12 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:12 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:12 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP logfile.log:03/11/24 20:57:14 | 39393 | MESSAGE | VoIP | Loaded# VoIP
| Creating…
| Registering…
| Registering failed! Reason: Protocol not supported [93]
| Creating…
| Registering…
| Registering failed! Reason: Protocol not supported [93]
| Applied settings
| Unregistering…
| Unregistered!
| Applied settings
| Unregistering…
| Unregistered!
| Registering…
| Registering failed! Reason: Protocol not supported [93]
| Applied settings
| Unregistering…
| Unregistered!
| Applied settings
| Unregistering…
| Unregistered!
| Registering…
| Registering failed! Reason: Protocol not supported [93]

oheidinger · 29. Dezember 2024 um 17:21

Hallo zusammen,

ich habe seit kurzen auch das Problem.

25.12.2024, 20:29:41 | VoIP | Registrierung fehlgeschlagen! Grund: Das Protokoll wird nicht unterstützt [93]

Folgendes hat das Problem nicht gefixt.

net.ipv6.conf.all.disable_ipv6 = 1

Ich verwende eine FRITZ!Box 7590.

Jemand einen Tip?

Grüße

Oli

paresy · 29. Dezember 2024 um 17:23

Siehst du denn an deinem Interface, dass IPv6 inaktiv ist?

paresy

oheidinger · 29. Dezember 2024 um 18:01

Danke war nicht vollständig deaktiviert.

Dies war meine Lösung:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Danke und Grüße

Oli

mark-e-polo · 6. Februar 2025 um 13:51

Hi zusammen,

das eintragen der Raspi-IPv4 Adresse in das ProxyInterface hat kurze Zeit funktioniert, dann wieder keine Verbindung.

Mit der Deaktivierung der IPv6 hab ich es auch gefixed bekommen.
Jedoch ist die Einstellung bei jedem Neustart des Raspis wieder weg und die IPv6 ist wieder aktiv.

Die Einträge in der sysctl.conf sind dauerhaft enthalten aber ich muss wieder sudo sysctl -p ausführen, damit IPv6 deaktiviert wird und Symcon neustarten.

Gibt es einen Befehl/Lösung wie ich die IPv6 dauerhaft, auch nach einen Raspi-Neustart ausgeschalten bekomme?

EDIT: @paresy, was mir auch aufgefallen ist, wenn die IPv6 nicht deaktivert wird, sondern nach dem Neustart des Raspis, nur Symcon (sudo /etc/init.d/symcon restart) neugestartet wird, funktioniert auch alles. Hab ihr da evtl. eine Lösung?

Danke und Grüße
mark-e-polo

bereziak · 10. Februar 2025 um 13:29

Ja:
Hierzu musst Du die Datei cmdline.txt in /boot/firmware/ editieren.
An’s Ende der Zeile musst Du folgendes anfügen: ipv6.disable=1.

Meine /boot/firmware/cmdline.txt sieht z.B. so aus:

console=serial0,115200 console=tty1 root=PARTUUID=5b55eecc-02 rootfstype=ext4 fsck.repair=yes rootwait plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=DE ipv6.disable=1

Ich würde dich noch bitten uns die Ausgabe von ip a zu posten, wenn’s O.K. für dich ist (also mit aktiviertem IPv6); vielleicht können wir dann besser ein Muster erkennen, etc.

McFly · 10. Februar 2025 um 17:35

Das hat bei mir leider auch nicht geholfen. IP6 wird zwar nicht gestartet aber Symcon benötigt trotzdem ein restart um das voip Modul zum Laufen zu bringen.
Gibt es einen Trick einen verzögerten restart befehl zum Linuxanlauf zu machen?
Vielleicht ein „at“ Kommando in der init.d?

paresy · 10. Februar 2025 um 17:45

@McFly Da wir den Auslöser oder Fehler sehr suchen - könntest du irgendwie schauen wie dein Netzwerk mit ,ip a‘ aussieht? Evtl. auch zum Start Zeitpunkt von Symcon. Wir würden gerne es nachstellen können und dann das Problem nachhaltig lösen.

paresy

McFly · 10. Februar 2025 um 18:07

Das war ne super idee.
Man sieht was passiert.
Ich habe das init.d script angepasst:

case "$1" in
    start)
        if [ "$(pidof symcon)" ]; then
                echo "IP-Symcon is already running"
        else
                ip a > /home/user/ip.txt
                /usr/bin/symcon service > /dev/null &
                        sleep 1
                        echo "IP-Symcon started with PID $(pidof symcon)"
        fi
        ;;

Und dann einmal „reboot“ (voip rot) und dann nochmal symcon stop->start (voip grün).
Man sieht schön, dass das ipv4 Interface zum Startzeitpunkt noch nicht initialisiert ist.

Systemstart:

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
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d8:3a:dd:b1:30:77 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d8:3a:dd:b1:30:79 brd ff:ff:ff:ff:ff:ff

Restart:

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
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d8:3a:dd:b1:30:77 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.170/24 brd 192.168.10.255 scope global dynamic noprefixroute eth0
       valid_lft 863885sec preferred_lft 863885sec
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d8:3a:dd:b1:30:79 brd ff:ff:ff:ff:ff:ff

Vielleicht würde eine Wartezeit helfen oder der Dienst könnte auf die Schnittstelle warten.

Aus Neugier habe ich mal ipv6 wieder aktiviert. Die Interfaces beim reboot sehen genauso aus.
Das ipv6 Interface kommt auch erst nach dem symcon start.

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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d8:3a:dd:b1:30:77 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.170/24 brd 192.168.10.255 scope global dynamic noprefixroute eth0
       valid_lft 863925sec preferred_lft 863925sec
    inet6 2a00:6020:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128 scope global dynamic noprefixroute
       valid_lft 7127sec preferred_lft 3527sec
    inet6 2a00:6020:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic noprefixroute
       valid_lft 2210sec preferred_lft 2210sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d8:3a:dd:b1:30:79 brd ff:ff:ff:ff:ff:ff

Ich hoffe das hilft.

paresy · 10. Februar 2025 um 18:19

Ja, sehr! Magst du noch kurz schauen wie im init.d Ordner die Reihenfolge ist? Also ist theoretisch das Netzwerk vor dem Symcon da?

paresy

McFly · 10. Februar 2025 um 18:30

Hehe. Die idee hatte ich auch.
Es stand im rc3.d, rc4.d und rc5.d alles auf @S01…
Hab symcon mal auf @S09symcon genommen. Aber mit gleichem Ergebnis.
Mit systemd gibt es wohl eine Möglichkeit auf einen Netzwerkstart zu warten. Aber für init.d finde ich gerade nix.
Wie macht ihr das eigentlich beim reconnect der sockets? Könntet ihr da nicht auch neu auf die interfaces verbinden?

McFly · 10. Februar 2025 um 18:36

hm, sehe gerade das das network gar nicht im init.d sondern im systemd gestartet wird.
Die sind wahrscheinlich nicht synchronisiert.

paresy · 10. Februar 2025 um 18:54

Wir schieben die Migration auf systemd schon etwas vor uns her. Vielleicht wird das die sauberste Lösung.

paresy