[Info] FRITZ!Box 7490 Labor-Firmware Version 113.06.36-31540 vom 09.10.2015

gomes · 15 Okt 2015

Hallo,

zwei Fehler sind mir aufgefallen:
1. Onlinespeicher von 1&1 verbindet sich nicht mehr siehe auch http://www.ip-phone-forum.de/showthread.php?t=281785&p=2122151&viewfull=1#post2122151

2. (...und da bin ich mir nicht sicher, ob es ein Laborproblem ist) wenn ich einen Benutzer einrichte, der lediglich auf Smarthome zugreifen darf und dies auch noch aus dem Internet, dann funktioniert das nicht Benutzer und Passwort wird als ungültig dargestellt. Setze ich aber den Haken bei "FRITZ!Box Einstellungen Benutzer mit dieser Berechtigung können alle Einstellungen der FRITZ!Box sehen und bearbeiten. " dann kommt der Nutzer auch auf die Oberfläche der Fritzbox und kann alles einsehen. Das möchte ich aber so nicht. War das vorher auch schon so oder habe ich da einen Denkfehler bei der Einrichtung.

Entschuldigt bitte, wenn es doch nicht hierhergehört.

zu 1. habe ich ein Ticket an AVM gesendet und bei dem Anderen bin ich mir halt nicht sicher.

Gruß gomes

Micha0815 · 15 Okt 2015

Beim Online-Speicher, auch wenn ich das nicht 24h/7d über die GUI kontrolliere, sind keine Auffälligkeiten erkennbar. Ich musste den nur mal Löschen/Deaktivieren/Neu-Einrichten und das wars. (Master-7490 am VDSL).

gomes · 15 Okt 2015

@Micha0815

das hatte ich auch schon probiert und leider ohne Erfolg.

Trotzdem Danke für die Antwort.

tacitus-nrw · 15 Okt 2015

Micha0815 schrieb:
Beim Online-Speicher, auch wenn ich das nicht 24h/7d über die GUI kontrolliere, sind keine Auffälligkeiten erkennbar. Ich musste den nur mal Löschen/Deaktivieren/Neu-Einrichten und das wars. (Master-7490 am VDSL).

Bis zur nächsten Änderung der IP oder einem Resync.:-(

alarbiere · 15 Okt 2015

PeterPawn schrieb:
@H'Sishi:
...
Wenn ich raten sollte, wo diese "apps_list.lua" in der Menüstruktur der FRITZ!Box auftauchen müßte, würde ich irgendwo auf die Benutzerverwaltung unterhalb von "System" tippen ... aber die "menu_data.lua" ist ein kleines bisschen unübersichtlich und so richtig will ich mich noch nicht in den Mechanismus der Menü-Klassen der neuen Lua-Implementierung vertiefen (s.o.).

Super geraten

Die Liste befindet sich unter System/FRITZ!Box-Benutzer.

Scheint so als ob AVM da plant eine Liste von autorisierten Apps zu verwalten. Mal schauen was da noch kommt...

Pauli315 · 15 Okt 2015

Bei mir das gleiche Problem mit dem Online-Speicher.
Mal verbindet er ihn nach Resync mal nicht.

fritzdean · 15 Okt 2015

Im AVM DECT-Repeater Thread gehts um die neue "Auto-Update" Funktion (System > Update > Auto-Update), siehe hier.

Anscheinend taucht dieser Punkt nicht bei allen Geräten auf. Bei meiner 1&1 Box (7490 UI mit 6.36-31540) ist der Punkt nicht im Menü. Erweiterte Ansicht ist aktiviert und Cache wurde geleert. Wie siehts hier bei weiteren Mitforisten aus?

cbeckstein · 15 Okt 2015

Pauli315 schrieb:
Bei mir das gleiche Problem mit dem Online-Speicher.
Mal verbindet er ihn nach Resync mal nicht.

Yepp, auch hier mit T-Online-Speicher...

und da hilft bei mir leider nur, solange die Box neu zu starten, bis er irgendwann verbunden ist
(mehr als 2 Reboots in Folge habe ich dafür glücklicherweise noch nicht gebraucht)...

DickS · 15 Okt 2015

fritzdean schrieb:
Im AVM DECT-Repeater Thread gehts um die neue "Auto-Update" Funktion (System > Update > Auto-Update), siehe hier.

Anscheinend taucht dieser Punkt nicht bei allen Geräten auf. Bei meiner 1&1 Box (7490 UI mit 6.36-31540) ist der Punkt nicht im Menü. Erweiterte Ansicht ist aktiviert und Cache wurde geleert. Wie siehts hier bei weiteren Mitforisten aus?

Der Reiter Auto-Update wird nur gezeigt wenn man unten auf "Inhalt" klickt und dann bei AVM-Dienste die erste Option aktiv hat. Dann erscheint der Reiter unter "Update".

Bei meine DECT-Geräte dauert es eine Weile, aber dann steht dabei "Software aktuell". Das ist schon mal ein cooles Feature, dann muss man nicht jedes Telefon über das Menü updaten

Benares · 15 Okt 2015

Micha0815 schrieb:
Ich musste den nur mal Löschen/Deaktivieren/Neu-Einrichten und das wars.

Ich hatte auch Probleme mit dem Online-Speicher auf der Router-7490 nach der Zwangstrennung. Deaktivierung/Aktivierung hat bei mir nichts gebracht, erst eine (Pseudo-)Änderung am Passwort. In den Logs taucht im Gegensatz zu früher auch nichts mehr zur Wiederverbindung des Online-Speicher nach der Zwangstrennung auf, so dass ich vermute, dass es die FB nach der Zwangstrennung erst gar nicht probiert. Evtl. ist auch die Trennung so kurz, dass es der Online-Speicher gar nicht merkt.

Ich bin mir relativ sicher, dass es mit der letzten Final nach jeder Zwangstrennung auch einen Log-Eintrag zur Wiederherstellung des Online-Speichers gab. Das ist nun nicht mehr so.

PeterPawn · 15 Okt 2015

gmeyer schrieb:
Evtl. ist auch die Trennung so kurz, dass es der Online-Speicher gar nicht merkt.

Das sollte nicht auf ein "merken" des davfs-Clients hinauslaufen ... eigentlich sollte der multid (der erhält die Info vom dsld) nach dem neuen Verbinden /bin/onlinechanged aufrufen, was dann in der Folge /etc/onlinechanged abgrast und das dort hinterlegte webdav_net abarbeitet. Damit wird dann der davfs-Client beendet und neu gestartet.

Wenn das also nicht erfolgt, könnte es gut sein, daß AVM auch am weiteren "Ausbau" (und das meint die Abschaffung und keine Erweiterung) von "onlinechanged" arbeitet (im Moment ist da ohnehin nur noch "send_crashreport" als zweiter "Kunde" involviert neben WebDAV) und an die Stelle der Abarbeitung der Shell-Skripte irgendeine interne Routine setzen will, die im Moment noch nicht zuverlässig arbeitet. Ist zwar reine Spekulation ... aber ansonsten sind die beschriebenen Phänomene schon sehr komisch.

Die frühere Berücksichtigung des Verzeichnisses /var/tmp/onlinechanged zusätzlich zum Verzeichnis /etc/onlinechanged ist ohnehin schon mit der 06.30 "verschwunden", wie ein schneller Blick in das Shell-Skript /bin/onlinechanged offenbart.

Wenn es jemand mit einem Telnet-Zugang mal probieren will ... nach der Eingabe von

Code:

/bin/onlinechanged online status_onlinev4

sollten die "alten" Skripte (aber eben nur /etc/onlinechanged) erneut abgearbeitet werden und wenn dabei der DAV-Speicher wieder verbunden wird (/var/tmp/webdav.log ist auch interessant, da wird das alles protokolliert), dann spart das zumindest die berichteten "Kopfstände" zur Wiederbelebung, bis AVM das in den Griff bekommt. Normalerweise wird auch der ctlmgr beim Start des davfs-Clients getriggert, dieser fragt dann nach 60 Sekunden den Status des WebDAV-Clients noch einmal ab und protokolliert das in der erwähnten Datei, das kann ein weiterer Anhaltspunkt sein, ob das "onlinechanged" überhaupt aufgerufen wurde.

Wenn also mal jemand mit dem Onlinespeicher-Problem nach der Ursache sehen will, wäre die erste Anlaufstelle die Datei /var/tmp/webdav.log. Notfalls findet man die auch in den Support-Daten ... damit braucht es nicht einmal unbedingt einen Telnet-Zugang.

fritzdean · 15 Okt 2015

DickS schrieb:
Der Reiter Auto-Update wird nur gezeigt wenn man unten auf "Inhalt" klickt und dann bei AVM-Dienste die erste Option aktiv hat. Dann erscheint der Reiter unter "Update".

Bei meine DECT-Geräte dauert es eine Weile, aber dann steht dabei "Software aktuell". Das ist schon mal ein cooles Feature, dann muss man nicht jedes Telefon über das Menü updaten

Das war es. Wäre ich nie drauf gekommen. Danke!

Benares · 15 Okt 2015

Danke PeterPawn für die wie immer umfangreichen Ausführungen. Bei den nächsten Problemen mit dem Online-Speicher (damit rechne ich), werde ich mal in die /var/tmp/webdav.log reinschauen.

splenditnet · 15 Okt 2015

USB-Tethering und Problem No-Inbound-RTP-Streams

Mopedmeister schrieb:
ja, ich habe hier einen E3372 mit Highlink-Firmware an meiner FB7490 mit der aktuellen LabFW am laufen.
Der Stick ging bei mir online, nachdem ich USB-Tethering einmal komplett de- und dann wieder neu aktiviert habe.
Surfen klappt dann auch problemlos, nur irgendwie will die IP-Telefonie bei mir nicht so richtig, sodass ich meinen zweiten E3372 (mit einer Non-Highlink-FW) wieder angeschlossen habe.

hallo Mopedmeister,
habe weiteren Test durchgeführt:
Samsung Galaxy S4 Smartphone mit FB 06.36-31540 im USB-Tethering Mode konfiguriert und Internet-Telefonie mit verschiedenen VOIP-Providern (Easybell, ...) eingerichtet und Dialout sowie Dialin mit C4 durchgeführt.

Ergebnis:
bei allen Smartphone Internet-Access-Arten (Mobilfunk getestet via O2-/Telekom-Netz sowie WLAN via UM-Netz) konnte kein Inbound-RTP-Stream aufgebaut werden; dadurch blieb der C4 Lautsprecher stumm und in GUI >> Telefonie >> Eigene Rufnummern >> Sprachübertragung wurde in Empfangsrichtung kein Codec angezeigt.

Test mit Stock-FW 06.24 und 06.30 mit Faktory-Reset unter gleichen Testbedingungen (USB-Tethering, VOIP-Provider) hat problemlos funktioniert.

Fazit:
Problem hat nichts mit Huawei Mobilfunk-Sticks im HiLink-Modus zu tun sondern tritt generell bei USB-Tethering und VOIP auf.

next Steps: sofern ich Zeit finde, werde ich abklären, ob das Problem im Zusammenhang mit voipd- oder kdsld/dsld-Implementierung steht.

Gruß
Splenditnet

Micha0815 · 15 Okt 2015

Nurmal so

tacitus-nrw schrieb:
Bis zur nächsten Änderung der IP oder einem Resync.:-(

Resync bisher nicht notwendig

am VDLS 50k 1&1=Telekom. Via Zwangstrennung gibt es eigentlich jede Nacht eine neue IP?
Da es die Produktiv-Box ist, habe ich die auch seit Aufspielen/Upgraden der Labor kommend von der vorherigen Labor seither -11.10.2015 nach GUI-Update- nicht rebootet?

Ein PPPoE-Prob (ob dies ein Snyc-Problem vorsichherzieht ... K.A.) sehe ich gerade erst für "vorletzte" Nacht für ~1h ... " Glatt Verschlafen!

"

Code:

15.10.15
	03:02:42	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 79.XX, DNS-Server: 217.237.151.142 und 217.237.150.188, Gateway: 87.186.224.48, Breitband-PoP: STGR72-se800-B2244460703500
15.10.15
	03:02:41	Internetverbindung wurde getrennt.
15.10.15
	03:02:39	Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
14.10.15
	04:56:11	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 79.241.107.19, DNS-Server: 217.237.151.142 und 217.237.150.188, Gateway: 87.186.224.48, Breitband-PoP: STGR72-se800-B2244460703500
14.10.15
	04:44:46	Anmeldung beim Internetanbieter ist fehlgeschlagen.
14.10.15
	04:44:34	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:43:42]
14.10.15
	04:42:50	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:41:58]
14.10.15
	04:41:06	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:39:22]
14.10.15
	04:38:30	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:36:46]
14.10.15
	04:35:54	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:35:02]
14.10.15
	04:34:10	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:32:26]
14.10.15
	04:31:34	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:29:50]
14.10.15
	04:28:58	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:28:06]
14.10.15
	04:27:14	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:25:30]
14.10.15
	04:24:38	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:22:54]
14.10.15
	04:22:02	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:21:10]
14.10.15
	04:20:18	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:18:34]
14.10.15
	04:17:43	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:15:59]
14.10.15
	04:15:07	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:14:15]
14.10.15
	04:13:23	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:11:39]
14.10.15
	04:10:47	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:09:03]
14.10.15
	04:08:10	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:07:18]
14.10.15
	04:06:26	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:04:42]
14.10.15
	04:03:50	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 04:02:06]
14.10.15
	04:01:14	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 04:00:22]
14.10.15
	03:59:30	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 03:57:46]
14.10.15
	03:56:54	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 03:56:02]
14.10.15
	03:55:10	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 03:53:26]
14.10.15
	03:52:34	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 03:50:50]
14.10.15
	03:49:58	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 03:49:06]
14.10.15
	03:48:14	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 03:46:30]
14.10.15
	03:45:38	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 03:43:54]
14.10.15
	03:43:02	PPPoE-Fehler: Zeitüberschreitung. [2 Meldungen seit 14.10.15 03:42:10]
14.10.15
	03:41:18	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 03:39:34]
14.10.15
	03:38:42	PPPoE-Fehler: Zeitüberschreitung. [3 Meldungen seit 14.10.15 03:36:58]
14.10.15
	03:36:06	PPPoE-Fehler: Zeitüberschreitung. [10 Meldungen seit 14.10.15 03:28:18]
14.10.15
	03:27:36	Internetverbindung wurde getrennt.
13.10.15
	03:43:33	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 79.241.121.2, DNS-Server: 217.237.151.142 und 217.237.150.188, Gateway: 87.186.224.48, Breitband-PoP: STGR72-se800-B2244460703500
13.10.15
	03:43:29	Internetverbindung wurde getrennt.
13.10.15
	03:43:27	Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
12.10.15
	03:44:30	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 79.241.126.76, DNS-Server: 217.237.151.142 und 217.237.150.188, Gateway: 87.186.224.48, Breitband-PoP: STGR72-se800-B2244460703500
12.10.15
	03:44:29	Internetverbindung wurde getrennt.
12.10.15
	03:44:27	Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
11.10.15
	19:37:59	Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 84.186.121.30, DNS-Server: 217.237.151.142 und 217.237.150.188, Gateway: 87.186.224.48, Breitband-PoP: STGR72-se800-B2244460703500
11.10.15
	19:37:55	DSL ist verfügbar (DSL-Synchronisierung besteht mit 51392/10048 kbit/s).

Das würde ich eher Providerseite zuschreiben als hiesiger FB+Labor-FW.

DickS · 15 Okt 2015

Kann mir jemand diesen Text oberhalb im Zusammenhang mit dem gewählten "Autokanal" erklären? Wenig genutzten Kanälen = bessere Bandbreite. Warum wählt die Box dann Kanal 1? Einstellung ist alles auf Automatik.

HabNeFritzbox · 16 Okt 2015

Dann verwende Kanal 11 und Koexistenz deaktivieren und nur g+n ohne b.

Stellt man halt selbst ein. Ist aber nicht Thema der Labor.

tacitus-nrw · 16 Okt 2015

DSL Statistiken immer noch Blödsinn. Erst einen negativen Wert in "CRC Errors letzte 15 min" und nun mit einem Schlag 7532 Fehler / min ;-). (Vorher 3 Sek mit Fehlern (ES), 0.0 / min, VDSL-Sync seit einer Woche, VDSL 100)

	Sekunden mit	Nicht behebbare Fehler (CRC)
	Fehlern (ES)	vielen Fehlern (SES)	pro Minute	letzte 15 Minuten
FRITZ!Box	4	0	7532	0
Vermittlungsstelle	64	0	0.02	0

splenditnet · 17 Okt 2015

Problem "bei USB-Tethering funktioniert VOIP nicht richtig (kein RTP-Inbound-Stream)"

Mopedmeister schrieb:
ja, ich habe hier einen E3372 mit Highlink-Firmware an meiner FB7490 mit der aktuellen LabFW am laufen.
Der Stick ging bei mir online, nachdem ich USB-Tethering einmal komplett de- und dann wieder neu aktiviert habe.
Surfen klappt dann auch problemlos, nur irgendwie will die IP-Telefonie bei mir nicht so richtig, sodass ich meinen zweiten E3372 (mit einer Non-Highlink-FW) wieder angeschlossen habe.

hallo Mopedmeister und andere Interessierte,

anbei Update zu #22, #116:
verschiedene Tests durchgeführt und dabei "interessantes Ergebnis" erhalten.

Testumgebebung:

Netzkonfig USB-Tethering (Router-Mode mit NAT)

Internet-Telefonie mit Sipgate eingerichtet

Telefonat zu Test-Echoserver von SIP-Gate sip:[email protected], sowie Sipgate-to-Easybell und Easybell-To-Sipgate

Code:

17.10.15    06:50:00    Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 192.168.42.240, DNS-Server: 192.168.42.129 und 192.168.42.129, Gateway: 192.168.42.129
17.10.15    06:49:44    USB-Gerät 1016, Klasse 'USB 2.0 (hi-speed) usbnet', angesteckt

# ifconfig dsl
dsl       Link encap:Point-to-Point Protocol
          inet addr:192.168.178.1  P-t-P:192.168.178.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1020 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1101 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:195468 (190.8 KiB)  TX bytes:126902 (123.9 KiB)
#

# ifconfig usb0
usb0      Link encap:Ethernet  HWaddr 02:54:01:xx:xx:xx  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:4966 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5961 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:698860 (682.4 KiB)  TX bytes:865039 (844.7 KiB)
#

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 dsl
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 lan
192.168.42.0    0.0.0.0         255.255.255.0   U         0 0          0 dsl
192.168.42.129  0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.178.0   0.0.0.0         255.255.255.0   U         0 0          0 lan
192.168.179.0   0.0.0.0         255.255.255.0   U         0 0          0 guest
192.168.180.1   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
#

# brctl show
bridge name     bridge id               STP enabled     interfaces
guest           8000.c80e14xxyyzz       no
lan             8000.c80e14aabbcc       no              eth0
                                                        eth1
                                                        eth2
                                                        eth3


0: name internet
0: sync_group: sync_usb
0: iface usb0 RBE/14/dsl c8:0e:14:xx:xx:xx stay online 1 (voip) (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2015-10-17 06:50:02 (setup time 3 secs) (connect cnt 6)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 192.168.42.240 mask 255.255.255.0 gw 192.168.42.129 dhcp mtu 1500
0: IPv4: masqaddr 192.168.42.240
0: IPv4: dns 192.168.42.129
0: route 192.168.42.0/24 protocol iface
0: route 192.168.42.129/32 protocol dns


Diagnose >> Sicherheit >> Verbindung, Internet
Internetzugang über 'Anderer Internetanbieter'
Internet    
verbunden über SAMSUNG SAMSUNG_Android (USB-Tethering)
FRITZ!Box-Dienste
Übersicht der geöffneten Ports für den Zugriff aus dem Internet:
Geöffnete Ports    Verwendete Protokolle    FRITZ!Box-Dienst     
5060        UDP, TCP, IPv4    Telefonie (SIP)       Bearbeiten
7078-7109    UDP, IPv4    Telefonie (RTP)       Bearbeiten


supportdata:
usb0 ethervcc_fastrcv [kdsldmod](8167c654)

##### BEGIN SECTION nqos nqos
appls:
  0: sip (1) => 1
early_recvhook:
   enabled
usb0 ethervcc_fastrcv [kdsldmod](8167c654)
lan:
  0: ip.proto 17 udp.dport 43962,47806 => 2
  0: ip.proto 58 => 2
  0: ip.proto 1 => 2
  0: ip.proto 17 => 2
  1:    udp.dport 53 => 2
  1:    udp.dport 5060 (sip) => 5
  0: ip.proto 6 tcp.dport 5060 (sip) => 5
local:
  0: localmark sip => 1
  0: localmark rtp => 1
  0: localmark sip_internet => 1
  0: localmark rtp_internet => 1
  0: localmark sipdns,ntpdns,tr069dns,tr069 => 2
  0: localmark igmp => 3
  0: localmark webdav => 4
  0: localmark dns => 2
results:
  0: queue 5
  1: queue 2
  2: queue 1
  3: queue 0
  4: queue 6
  5: queue 2 appl sip
##### END SECTION nqos nqos


##### BEGIN SECTION PCP
MAP  UDP [192.168.178.1]:5060 [192.168.42.240]:5060, lifetime 120 secs, renew in 19 secs
    nonce SNIP active
    group "0/voip"
    "VOIP"
    wanted_lifetime 184549375 lifetime 120
    age 2989 lasttime 43 endtime 19 nsent 0

MAP  TCP [192.168.178.1]:5060 [192.168.42.240]:5060, lifetime 120 secs, renew in 31 secs
    nonce SNIP active
    group "0/voip"
    "VOIP"
    wanted_lifetime 184549375 lifetime 120
    age 2989 lasttime 34 endtime 31 nsent 0

MAP  UDP [192.168.178.1]:7078 [192.168.42.240]:7078, lifetime 120 secs, renew in 14 secs
    nonce SNIP active
    group "0/voip"
    "VOIP"
    port set: wanted 32p got 32p (7078)
    wanted_lifetime 184549375 lifetime 120
    age 2989 lasttime 46 endtime 14 nsent 0


pcpd[2721] dump (Sat Oct 17 2015)
------------------------------------------
CTX AF_INET max_lifetime 600 [192.168.178.1] :0 proxy



internet v4
--------------

-------- pcp44 ----------------------------------------
MAP  TCP [192.168.178.1]:5060 [192.168.42.240]:5060, lifetime 120 secs, expire in 86 secs
     nonce SNIP
     "VOIP"
     wanted_lifetime 120 lifetime 120
     pid 10818 caddr [192.168.178.1] inuse 0

MAP  TCP [192.168.178.1]:9 [192.168.42.240]:9, lifetime 120 secs, expire in 66 secs
     nonce SNIP
     "IGDPROBE4"
     filter version 1
     <= [255.255.255.255]/128 port 9
     wanted_lifetime 120 lifetime 120
     pid 10818 caddr [192.168.178.1] inuse 0

MAP  UDP [192.168.178.1]:5060 [192.168.42.240]:5060, lifetime 120 secs, expire in 77 secs
     nonce SNIP
     "VOIP"
     wanted_lifetime 120 lifetime 120
     pid 10818 caddr [192.168.178.1] inuse 0

MAP  UDP [192.168.178.1]:7078 [192.168.42.240]:7078, lifetime 120 secs, expire in 74 secs
     nonce SNIP
     "VOIP"
     port set: 32p
     wanted_lifetime 120 lifetime 120
     pid 10818 caddr [192.168.178.1] inuse 0

-------- pcpitems -------------------------------------
##### END SECTION PCP

Messung:
1.) SIP-Sessionlog: "/bin/showshringbuf sip"
keine Auffälligkeiten erkennbar:
Auf ein "INVITE" (Anruf von A zu B) folgt in dem Fall ein "TRYING", dann ein "PROGRESS" u.s.w. bis "BYE"
inkl. der Records "via", "Route", "rtpmap"

2.) Pakettracing http://fritz.box/?lp=cap

wenn Pakettracing auf Netzwerkschnittstelle usb0 aktiv ist, dann funktioniert VOIP ohne Probleme

wenn Pakettracing auf Netzwerkschnittstelle usb0 nicht aktiv ist, dann ist VOIP gestört (Inbound-RTP-Stream fehlt)

voip_sipgate_echotest_mit_capture_usb0:

Code:

08:21:59.317935 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 4
08:22:12.832313 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 1177
08:22:12.865986 IP sipgate.de.5060 > 192.168.178.1.5060: SIP, length: 422
08:22:12.867876 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 399
08:22:12.876847 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 1362
08:22:12.905894 IP sipgate.de.5060 > 192.168.178.1.5060: SIP, length: 300
08:22:12.936139 IP sipgate.de.5060 > 192.168.178.1.5060: SIP, length: 901
08:22:12.952712 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 526
08:22:12.989494 IP 192.168.178.1.7078 > rtp01.service.sipgate.net.20342: UDP, length 252
08:22:13.017471 IP 192.168.178.1.7078 > rtp01.service.sipgate.net.20342: UDP, length 252
08:22:13.043229 IP rtp01.service.sipgate.net.20342 > 192.168.178.1.7078: UDP, length 172
08:22:13.049491 IP 192.168.178.1.7078 > rtp01.service.sipgate.net.20342: UDP, length 252
08:22:13.067105 IP rtp01.service.sipgate.net.20342 > 192.168.178.1.7078: UDP, length 172
08:22:13.077437 IP 192.168.178.1.7078 > rtp01.service.sipgate.net.20342: UDP, length 252
08:22:13.085873 IP rtp01.service.sipgate.net.20342 > 192.168.178.1.7078: UDP, length 172
08:22:13.100852 IP rtp01.service.sipgate.net.20342 > 192.168.178.1.7078: UDP, length 172
08:22:13.109492 IP 192.168.178.1.7078 > rtp01.service.sipgate.net.20342: UDP, length 252
08:22:13.120930 IP rtp01.service.sipgate.net.20342 > 192.168.178.1.7078: UDP, length 172
08:22:13.137437 IP 192.168.178.1.7078 > rtp01.service.sipgate.net.20342: UDP, length 252
08:22:13.140887 IP rtp01.service.sipgate.net.20342 > 192.168.178.1.7078: UDP, length 172
08:22:13.160977 IP rtp01.service.sipgate.net.20342 > 192.168.178.1.7078: UDP, length 172
08:22:13.169492 IP 192.168.178.1.7078 > rtp01.service.sipgate.net.20342: UDP, length 252
...
Messung per tcpdump@FB durchgeführt

voip_sipgate_echotest_ohne_capture:

Code:

08:25:47.407248 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 1177
08:25:47.555422 IP sipgate.de.5060 > 192.168.178.1.5060: SIP, length: 422
08:25:47.557317 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 399
08:25:47.565927 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 1362
08:25:47.596650 IP sipgate.de.5060 > 192.168.178.1.5060: SIP, length: 300
08:25:47.737155 IP sipgate.de.5060 > 192.168.178.1.5060: SIP, length: 901
08:25:47.753972 IP 192.168.178.1.5060 > sipgate.de.5060: SIP, length: 526
08:25:47.790283 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:47.818218 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:47.850277 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:47.878221 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:47.910276 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:47.938218 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:47.970276 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:47.998317 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.030277 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.058221 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.090278 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.097964 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.100208 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.100213 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.100216 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.100218 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.100220 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.100222 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.105027 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.118320 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.124978 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.150296 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.178220 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.210275 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.238382 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.270302 IP 192.168.178.1.7078 > rtp03.service.sipgate.net.17396: UDP, length 252
08:25:48.280434 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.281712 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.282335 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.282761 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.282766 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.282768 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.282770 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
08:25:48.285469 IP rtp03.service.sipgate.net.17396 > 192.168.178.1.7078: UDP, length 172
...
Messung per tcpdump@FB durchgeführt

Test wurde 2 x durchgeführt, jeweils gleiches Testergebnis;
nach Telefonat von Easybell nach Sipgate ohne Pkg-Tracing ist im SIP-Sessionlog die Meldung "SIP Error 403 Maximum parallel calls exceeded" bei Easybell-Registrar erschienen; Email von Easybell Support "Privatkundentarif erlaubt die Nutzung von maximal zwei Leitungen, daher SIP-Fehlermeldung"

Fazit, TL;DR:
wenn Pakettracing http://fritz.box/?lp=cap auf Netzwerkschnittstelle usb0 aktiv ist, dann funktioniert VOIP via USB-Tethering ohne Probleme;
es sieht nach Firewall-Problem "dev dsl" @Fritzbox aus;
aufgrund von Closed-Source ist AVM für Problemlösung erforderlich; Bugreport an AVM folgt.

Gruß
Splenditnet

page · 17 Okt 2015

Was ich noch zu dieser und auch die letzten 3 Betas anmerken muss ist.
Die Probleme sind nicht im Log zu sehen und auch die Umstellung auf manuell Kanal
oder Autokanal bringt nichts. Die Wlanprobleme Internet steht aber der Laptop meldet
keine Verbindung oder die Äpfel die auch sich über keine Internet beschweren ist einfach
nicht näher einzugrenzen. Auch wird die Internetverbindung im laufe des Tages immer langsamer
und langsamer. Obwohl die Verbindung ja 1A zur Box steht und ein Geschwindigkeitstest auch nichts
auffälliges zeigt. Sicher kann man nun sagen es liegt am Win10 Rechner (Treiber) oder am Apfel (OS)
nur zeitgleich? Ich kann mich noch an einer Zeit letztes Jahr erinnern wo ich dieses Problem (Verhalten)
auch über mehrere Betas hatte bis sie auf einmal weg waren. Gemeldet habe ich es an AVM, schauen wir mal.

[Info] FRITZ!Box 7490 Labor-Firmware Version 113.06.36-31540 vom 09.10.2015

Neuer User

IPPF-Promi

Anhänge

Neuer User

Neuer User

Neuer User

Neuer User

Mitglied

Mitglied

Aktives Mitglied

IPPF-Promi

IPPF-Urgestein

Mitglied

IPPF-Promi

Neuer User

IPPF-Promi

Aktives Mitglied

HabNeFritzbox

Guest

Neuer User

Neuer User

Mitglied

Statistik des Forums