Fritz!Box 6490 Cable IP-Telefone Registrierung 408

[verwirrt]

Hallo zusammen,

ich habe ein etwas komplizierteres Problem, bei dem ich Schwierigkeiten habe herauszufinden was jetzt genau die Ursache ist. Genau genommen habe ich gestern eine (eigentlich triviale) Änderung gemacht, woraufhin quasi nichts mehr funktioniert hatte, und es fällt mir schwer herauszufinden was genau.

Zuerst zu meinem Setup (Stand 23.12. Vormittag):
- Router nach draußen Fritz!Box 6490 Cable (Unitymedia), registriert sich da mit ein paar Telefonnummern. Das klappt soweit und klappt auch immer noch.
- Hinter dem Router hängt dann ein weiterer Router, ein Ubiquity EdgeRouter X.
- Von dort an geht es an verschiedene managed Switches (alle L2, alle Cisco), die verschiedene Subnetze in VLANs im Haus verteilen (und auch ein paar APs für WLAN, im folgenden ist aber alle involvierte Hardware verkabelt, das ist also irrelevant)
- In einem VLAN hängt ein Raspberry Pi, der sich als IP Telefon an der Fritz!Box anmeldet (pjsua2 im wesentlichen, via UDP). pjsua2 macht alle 5 Minuten einen keepalive, d.h. re-registriert sich. Kriegt immer 200 (Success), alles gut.
- Ein weiterer Raspberry Pi (im gleichen VLAN) hat einen lokalen Asterisk (ein Raspbx) laufen, der sich auch als IP Telefon bei der FB registiert (outbound trunk). Funktioniert auch.

Dann zum verhängnisvollen Ereignis (23.12. Nachmittag):
- Ich entscheide, dass ich gerne an einem Rechner einen Zoiper Client bei der FB registrieren möchte. Hatte ich schonmal gemacht, weiß also im Grunde wie ich das einstelle (über TCP).
- Ich entscheide außerdem, dass der Asterisk keinen Uplink zur FB braucht.
- Ich ändere folgendes in der FB: 1. Ich lösche das IP-Telefon für den Uplink von dem Asterisk in der FB. 2. Ich lege ein neues an für meinen rechner.
- Ich richte in Zoiper alles ein (bevor jemand fragt: kein STUN, SIP TCP), Ergebnis: 408 (Timeout).
- Ich versuche dabei rauszufinden was schiefgeht und stelle fest: Der pjsua2 Prozess hat auch ständig timeouts. Alle paar Stunden geht mal einer mit 200 durch, dann funktioniert es für 5 Minuten (ist auch beim Zoiper Client so), aber die meiste Zeit kann ich mich nicht registrieren.
- Mir fällt auf, dass der Asterisk immer noch versucht sich bei der FB zu registrieren, jede Minute. Timet auch ständig aus, ist aber doof. Ich lösche den Uplink zur FB aus dem Asterisk, der macht daraufhin gar nix mehr Richtung FB.
- Immer noch ständig 408.
- Ansonsten wurde nix verändert, nicht am Edgerouter, nicht an der FB, insbesondere auch keine Portfreigaben verändert.

Nun zu meinen Versuchen:
- Firewall alles loggen lassen, checken ob der Edgerouter irgendwelche Pakete zwischen Client und FB blockt -> nein (ich komme auch auf das Webinterface der FB...)
- Reboot von Edgerouter oder FB bringen gar nix.
- Ich nehme alle Clients für einige Stunden vom Netz. versuche dann den pjsua2 Prozess wieder zu starten: Immer noch dauer-408.
- Ich klemme den Pi mit dem pjsua2 Prozess direkt an die FB. Effekt: kein 408 mehr, dauer-200, alles super. Hilft mir aber natürlich nicht mit meinem Rechner, weil der kann/soll nicht direkt an die FB. Außerdem sollte der eigentlich in seinem VLAN sein und nicht direkt an der FB.

Irgendjemand eine Idee, was hier schieflaufen könnte und wie ich dahinter kommen könnte.

Hier meine Vermutungen:
- Die FB hat wegen der vielen erfolglosen Verbindungsversuche von dem Asterisk alles was vom EdgeRouter kommt irgendwie geblacklistet, und lässt das nur alle paar Stunden durch einmal und dann nicht mehr.
- Aus irgendeinem Grund hat sich der EdgeRouter plötzlich entschieden irgendwas nicht richtig zu machen und die Antwortpakete nicht zuzustellen (ohne dass ich irgendwas geändert hätte), und der Link mit dem EdgeRouter dazwischen ist plötzlich das Problem... es klappt aber trotzdem manchmal.

Da es ja kaum noch möglich ist auf eine FB draufzukommen auf eine Shell finde ich keine sinnvolle Möglichkeit meine Vermutungen zu bestätigen oder widerlegen. Einen Factory Reset der FB möchte ich gerne vermeiden, das ist nichts was ich eben in ein paar Minuten machen könnte (es sei denn ich reimportiere die alte Config, das läuft aber irgendwie gegen Factory Reset).

So gut wie alle Threads, die ich gefunden habe mit 408 Problemen mit der FB beziehen sich auf Registrieren einer Telefonnummer bei einem Provider. Das klappt bei mir aber problemlos...

 

[hominidae]

...welcher Version des Fritz OS?
Ich habe ein ähnliches Setup und vor 2 Wochen bei meiner 6490 von KD die v7.12 bekommen und nix ging mehr.

Ich habe zwei FB, die als I-Net und Telefonprovider dienen und auch einen Router für diverse VLANs dazwischen...ebenso eine FB in der Mitte, die das ganze Telefongedös zusammenhält (die beiden anderem FB dienen nur als Brückenkopf).
Seit der Umstellung der Firmware der 6490 können Clients aus anderen internen Netzen die 6490 nicht mehr pingen oder ins I-Net.
Mein Fazit:
DIe FB lässt nur noch das eigene Heimnetz zu, andere interne Netze (mit in der FB eingestellten Routen zu einem dahinter als Gateway fungierenden Router) nicht mehr.
Einziger Ausweg, das Interface zur FB des dahinterliegenden Routers auf (src-)NAT stellen.
..und, ja...komischerweise geht es bei manchen IPs aus den Netzen, aber nicht bei allen und nicht konstant vorhersehbar.

 

[stoney]

Da könnte man auf die Idee kommen und den Schalter ala linux_fs_start in der F!B mal umzulegen um zu prüfen, ob es an der FW liegt.

 

[verwirrt]

7.10, und ich glaube nicht dass da am 23.12. ein Upgrade war. Außerdem komme ich aus den anderen VLANs ja noch auf die FB drauf (Webinterface) und ping geht auch.

Mir scheint nur dass der SIP Server der FB plötzlich alles ablehnt was aus Richtung ER kommt. Bei der Flut von unsinnigen (User existiert nicht) Anfragen von dem Asterisk hätte ich ja ein gewisses Verständnis dafür was zu blocken, aber es muss möglich sein das auch wieder zu reparieren oder zumindest rauszufinden, dass es so ist.

So nur: 408, und auf FB Seite sehe ich nicht wirklich was.

Was ich aber machen kann, ist ein bisschen Wireshark auf Seiten der Clients. Das habe ich getan, und dabei folgendes rausgefunden:
- SIP TCP, IPv4, hinter ER: Client stellt erfolgreich eine TCP Verbindung zur FB port tcp 5060 her, schickt REGISTER (das wird auch empfangen, ACK kommt), und dann trennt die FB sofort die Verbindung.
- SIP UDP, IPv4, hinter ER: Client schickt REGISTER via UDP. Es kommt keine Antwort.
- SIP UDP, IPv4, direkt an FB: Client schickt REGISTER via UDP, es kommt eine Antwort, alles funktioniert.
- SIP UDP, IPv6, hinter ER: Client schickt REGISTER via UDP, es kommt eine Antwort, alles funktioniert.

Heißt: Es klappt über ipv6, aber nicht über ipv4. Es ist aber komisch, dass im TCP Fall die Verbindung erfolgreich hergestellt wird und seitens der FB beendet wird.



Warum? Keine Ahnung.
Ich habe auch nochmal die Firewall Logs (im ER, FB ist black box) gecheckt. Es wird nichts gedroppt.

Wäre IPv6 ein Workaround? Für den pjsua2 Client auf jeden Fall. Es ist allerdings etwas nervig dass ich die Host Resolution selbst machen muss, Hostname klappt nicht mit IPv6 in pjsua. Für den anderen Client allerdings nicht so. Ich will bis zu drei Clients haben (einmal macOS, einmal Linux, einmal iOS), und ich finde keine guten die IPv6 unterstützen, schon gar nicht mit Hostname Resolution. Und selbst schreiben klingt etwas übertrieben.

 

[koyaanisqatsi]

Moinsen


Wird in der Konfiguration auf Asteriskseite "qualify=" genutzt?
1. Unnötig*
2. Spamt das die FRITZ!Box zu
...ist sowas wie ein DoS Angriff auf die FRITZ!Box, wenn die OPTIONS Anfragen ständig mit "SIP/2.0 401 Unauthorized" abgeschmettert werden müssen...

[Dec 27 14:22:05] SIP/2.0 401 Unauthorized
[Dec 27 14:22:05] Via: SIP/2.0/UDP 192.168.188.9:5060;branch=<hash>
[Dec 27 14:22:05] From: "asterisk" <sip:[email protected]>;tag=<hash>
[Dec 27 14:22:05] To: <sip:192.168.188.1>;tag=<hash>
[Dec 27 14:22:05] Call-ID: <hash>@192.168.188.9:5060
[Dec 27 14:22:05] CSeq: 102 OPTIONS
[Dec 27 14:22:05] Contact: <sip:<hash>@192.168.188.1>
[Dec 27 14:22:05] WWW-Authenticate: Digest realm="fritz.box", nonce="<hash>"
[Dec 27 14:22:05] User-Agent: FRITZ!OS
[Dec 27 14:22:05] Content-Length: 0

Für Asteriskqualifies ( qualify= ) ist völlig unerheblich wie geantwortet wird, nur das geantwortet wird

PS: Das "SIP Log" der FRITZ!Box kann über die erstellten erweiterten Supportdaten eingesehen werden...
http://fritz.box/support.lua
...erstellen lassen und einfach mal in dieser Textdatei danach** suchen.

Hostname klappt nicht mit IPv6 in pjsua

In Dual Stack Netz ist genau das ein Fehler.
Denn der Hostname oder FQDNS Name soll ja erreichen, dass zuerst eine IPv6 geliefert wird, und wenn nicht, ein Fallback auf IPv4 erfolgen kann.
Deswegen ist auch der Registrar und/oder Proxy dann auch zwingend: fritz.box

# Kommando: Löse fritz.box über den Nameserver fritz.box auf...
nslookup fritz.box fritz.box
Server:        fritz.box
Address:    2001:<IPv6>#53

Name:    fritz.box
Address: 192.168.188.1
Name:    fritz.box
Address: fd00:<IPv6>
Name:    fritz.box
Address: 2001:<IPv6>

* OPTIONS Spam kann vermieden werden durch Heraufsetzung des Intervals
Für alle 2 Minuten wäre das in Millisekunden...
qualify=120000
** SIP Log, OPTIONS, REGISTER, INVITE

 

[verwirrt]

Der Asterisk ist inzwischen offline. Ich hab ehrlich gesagt keine Ahnung was da verkonfiguriert war, hatte das über FreePBX zusammengeklickt.

SIP Log hat leider nix geholfen da die Requests gar nicht erst auftauchen.

Ich habe heute tatsächlich einen Factory Reset der FB gemacht. Und dabei ganz seltsame Dinge beobachtet:
- Eine andere FB, die sich über IP-Telefonie als Client anmeldet, hatte nachdem ich sie an die resettet FB drangehangen habe auch 408 beim Anmelden an der FB. Das hatte vorher funktioniert.
- Spezialfall: Ich habe das Heimnetz auf 192.168.1.1/24 gesetzt mit DHCP von 192.168.1.2 bis .200. Default der FB sind 192.168.178.1/24 und DHCP von .20 bis .200
- Insbesondere: die andere FB hatte nach dem Factory Reset 192.168.1.3, vorher 192.168.1.49.
- Meine Vermutung: AVM wird sich etwas dabei gedacht haben, also DHCP erst ab 20 eingestellt. FB bekommt .20 => geht wieder!

Dann denke ich mir, vielleicht liegt es daran? Der ER hatte die ganze Zeit 192.168.1.2. Also dem auch eine neue IP verschafft (.21), Anmeldung aus dem richtigen Netz => immer noch 408.

Es wird seltsamer und seltsamer.