crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
25.08.2016 11:30 Zuletzt bearbeitet: 26.08.2016 14:15 durch den Autor
Hallo liebe Hybrid-Community,
ihr habt lange darauf gewartet - jetzt ist es soweit: die neue Firmware 050124.03.00.012 für den Speedport Hybrid steht - voraussichtlich ab morgen - zum Download bereit.
Diese Änderungen gibt es in der neuen Firmware:
Die Firmware wurde in den letzten zwei Wochen im Telekom hilft Labor von vielen sehr engagierten Hybrid-Usern getestet. Für die wertvollen Feedbacks möchte ich mich an dieser Stelle sehr herzlich bei allen Testern bedanken.
Grüße von
Schmidti
-------------------
26.08.2016 Nachtrag:
Hinweis: Da das Design der Konfigurationsoberfläche geändert wurde, kann es beim ersten Aufruf zu einer verschobenen Ansicht kommen. Sollte also das Konfigurationsmenü nach Login nicht richtig angezeigt werden, leert bitte den Cache eures Browsers.
14.10.2016 09:39
Johann.Nissl schrieb: Einen Magenta M Zuhause Hybrid ohen eine 2 . Mein Vdsl kommt ja auf 47,14 Kbits.
Johann.Nissl schrieb: DSl alleine 13,48 kbit Download 1,45 Kbits
14.10.2016 10:31 Zuletzt bearbeitet: 14.10.2016 10:32 durch den Autor
@danXde schrieb:@Gelöschter Nutzer ...da mach doch mal ein Capture mit Wireshark. Denke das geht am schnellsten.
Grüße
danXde
Guten Morgen danXde,
werde ich, habe es gerade auf dem Raspi installiert, muss mich damit aber erst vertraut machen, im Augenblick ist Ruhe im Netz, bin mal auf die Rückmeldung der T gespannt, (8h Support).
Da LTE aber nicht garantiert ist, - Support oder nicht Support, das ist hier die Frage, orakelt Manukura
14.10.2016 13:05
geegee schrieb: Busybox ist eine Softwarekomponente für einen Shell Login etwa per Telnet oder SSH.
14.10.2016 13:22 Zuletzt bearbeitet: 14.10.2016 13:30 durch den Autor
@Marita S. schrieb:
@geegee
geegee schrieb: Busybox ist eine Softwarekomponente für einen Shell Login etwa per Telnet oder SSH.
Danke für die Erläuterung.
Welche relevants (ob entfernt oder nicht) das jetzt für @ThomasR._1 hat, erschließt sich mir trotzdem noch nicht. Fehlt mir da vielleicht einfach die Erfahrung im Umgang mit Linux?
Viele Grüße
Marita S.
hier gibt es weitere Erklärungen:
https://de.wikipedia.org/wiki/BusyBox
Ich möchte jedoch auch an meine Störungsmeldung von heute erinnern. Das Problem ist nicht nur die Geschwindigkeit. Eine weitere Anwendung, welche bisher mit DSL, ab Juli mit SPH mit FW .02 ohne Probleme lief, funktioniert nicht mehr zuverlässig. Damit ist das jetzt für mich eine Störung, welche unabhängig vom der LTE-Verfügbarkeit ist, jedoch in Verbindung mit dem gestern autom. durchgeführten Update auf die FW .03 steht.
Meine Daten stehen im Profil.
Ich bitte um Weiterleitung und Bearbeitung, innerhalb der gebuchten 8h
Manukura wartet auf eine Rückmeldung......
14.10.2016 13:36
Hallo @d-stadler,
@Schmidti schrieb:
Hallo @d-stadler,
danke für diesen Hinweis:
d-stadler schrieb:Ich kann aber noch etwas zur Clientverwaltung beitragen. Es schein so, dass der Speedport Hybrid ab dem 19ten angemeldeten Gerät nach Abschalten des Geräts die IPv4 Adresse vergißt bzw. auf 0.0.0.0 zurücksetzt. Zumindest ist das bei mir in der V2 reproduzierbar so, wird aber in der V3 das gleiche sein. Und das hat nichts mit den Lease-Zeiten zu tun. DHCPv4 läuft bei mir auf meinen TP-Link Access Point unter Openwrt. Evtl. könnte dieses Verhalten auch mit den DHCP Fehlern zu tun haben.
Ich habe ihn an unsere Endgeräteabteilung weitergeleitet.
Die Kollegen haben den Fehler nicht nachstellen können. Das Ergebnis nach einem Neustart des Speedport Hybrid mit der Firmware 050124.03.00.012 war identisch wenn 14 bzw. 19 Clients angemeldet waren. Getestet wurde mit 13 WLAN und 6 LAN-Clients, wobei 4 über einen
Switch verbunden waren. Nach Neustart hatten alle eine Verbindung.
Aufgefallen war an der Stelle nur, dass einige Clients nach dem Neustart eine andere IP-Adresse bekommen haben, obwohl die betreffende IP-Adresse vor dem Neustart einem anderen Client zugeordnet war. Dieses Fehlerbild ist ja schon bekannt und auch "eingetütet".
Da du geschrieben hattest, dass du es reproduzieren kannst, hatte ich gedacht, dass wir das hier auch recht einfach hinbekommen - hätte die Ursachenforschung vereinfacht Jetzt stellt sich natürlich die Frage, was ist in deinem Netzwerk anders als in unserem Testaufbau? Hast du die IP-Adresse des Routers geändert?
Viele Grüße
Schmidti
14.10.2016 14:08
14.10.2016 14:29
14.10.2016 14:47
@Marita S. schrieb:
Hallo @Gelöschter Nutzer,
wie telefonisch besprochen, benötige ich folgende Angaben an unser Kontaktformular http://bit.ly/Teamkontakt:
SIM-Kartennummer
IMEI des Routers (zu finden im Konfigurationsmenü unter Konfigurationsmenü / Systeminformationen)
Verbindung schon mal zufriedenstellend funktioniert?: Ja
Seit wann funktioniert die Verbindung nicht mehr zufriedenstellend?: seit FW .03
Messwerte Speedtest:
1. DSL & LTE: DL: MBit's / UL: MBit's -
2. nur DSL: DL: MBit's / UL: MBit's -
3. nur LTE: DL: MBit's /UL: MBit's -
Funkzellen Info:
Signalbalken:
IP-Adressen (zu finden im Konfigurationsmenü unter "Internet / Internetverbindung / IP-Adressinformationen"): IPv6-Adresse (GUA) und öffentliche WAN-IP
Viele Grüße
Marita S.
Hallo Marita,
nach dem Senden des Formulares kam die Meldung:
"gesicherte Verbindung fehlgeschlagen"
Ich versuche es nochmal
14.10.2016 14:56
14.10.2016 15:38 Zuletzt bearbeitet: 14.10.2016 15:40 durch den Autor
@Schmidti kannst Du mal hier vorbeischauen?
und
@Marita S. Du vielleicht hier?
Vielen Dank, schönes Wochenende!
danXde
14.10.2016 15:41
Router hat die IP 192.168.178.1
DHCP ist deaktiviert und wird extern bereitgestellt.
Ich poste mal die ARP Tabelle, wenn ich am Sonntag wieder daheim bin.
14.10.2016 16:19
14.10.2016 16:23
Ich habe gerade mal die Messungen durchgeführt die Marita benötigt,
der letzte Abschnitt ist interessant, vielleicht hat ja jemand eine Idee dazu?
----------
Messwerte Speedtest:
6. Messung
1. DSL & LTE: DL: MBit's / UL: MBit's -
15:48:08,14.Oktober 2016: Ihre Pingzeit wird ermittelt...
15:48:19,14.Oktober 2016: Durchschnittliche Pingzeit: 241,40 ms
15:48:19,14.Oktober 2016: Jitter: 429,12 ms
15:48:49,14.Oktober 2016: Download ca.188571 kBits gemessen in 30 s --> Downloadrate: 6298 kBit/s
15:49:20,14.Oktober 2016: Upload ca.38085 kBits gemessen in 30 s --> Uploadrate: 524808 kBit/s
7. Messung
2. nur DSL: DL: MBit's / UL: MBit's -
15:53:00,14.Oktober 2016: Durchschnittliche Pingzeit: -
15:53:00,14.Oktober 2016: Jitter: -
15:53:30,14.Oktober 2016: Download ca.16935 kBits gemessen in 30 s --> Downloadrate: 582 kBit/s
15:54:02,14.Oktober 2016: Upload ca.224005 kBits gemessen in 30 s --> Uploadrate: 794195 kBit/s
8. Messung
3. nur LTE: DL: MBit's /UL: MBit's -
15:58:28,14.Oktober 2016: Ihre Pingzeit wird ermittelt...
15:58:34,14.Oktober 2016: Durchschnittliche Pingzeit: -
15:58:34,14.Oktober 2016: Jitter: -
15:59:04,14.Oktober 2016: Download ca.670422 kBits gemessen in 30 s --> Downloadrate: 22377 kBit/s
15:59:35,14.Oktober 2016: Upload ca.224005 kBits gemessen in 30 s --> Uploadrate: 704717 kBit/s
* Was mir jetzt gerade aufgefallen ist:
Nachdem DSL getrennt wurde, letzte Messung, und wieder hergestellt ist,
kann auf die Menüs des SPH ohne Wartezeiten von ca. 20. sec.
zugegriffen werden.
9. Messung DSL+LTE nachdem DSL getrennt und wiederhergestellt wurde:
16:13:58,14.Oktober 2016: Ihre Pingzeit wird ermittelt...
16:14:04,14.Oktober 2016: Durchschnittliche Pingzeit: 12,30 ms
16:14:04,14.Oktober 2016: Jitter: 19,54 ms
16:14:34,14.Oktober 2016: Download ca.493335 kBits gemessen in 30 s --> Downloadrate: 16480 kBit/s
16:15:05,14.Oktober 2016: Upload ca.224004 kBits gemessen in 30 s --> Uploadrate: 872609 kBit/s
15.10.2016 19:19
@danXde schrieb:@Gelöschter Nutzer ...da mach doch mal ein Capture mit Wireshark. Denke das geht am schnellsten.
Grüße
danXde
Das ging doch nicht so einfach wie ich dachte, auf dem Raspi unter Wheezy
Fehlermeldung:
$ gksu /usr/bin/wireshark
(gksu:5823): GLib-CRITICAL **: g_str_has_prefix: assertion 'str != NULL' failed
15.10.2016 21:16
Schmeiß mich jetzt auch gerade mal dazwischen. Hatte gestern Abend auf einmal das Phänomen das mein iPhone zum verrecken keine IP mehr vom SPH bekommen hat. Alles versucht bis hin zum Hardreset vom iphone da ich dachte es liegt am Handy. Letzten Endes ging es dann nur über einen Neustart des Hybriden. Also hatte ich damit jetzt auch mein erstes DHCP Problem mit dem Router. Schade.
16.10.2016 09:40
Moin moin,
nach der Aktion:
Zugriff auf SPH nicht mehr möglich, Fenster wechseln ging gerade noch zu:
Der letzte Neustart erfolgte am 15.10.2016 um 09:05 Uhr.
IPv4-Adressinformationen
Öffentliche WAN-IP:
217.241.135.xxx <<<< neuer IP-Bereich, vorher 87.xxx.xxx.xxx
läuft der SPH jetzt ohne Probleme.
Der SPH mit FW .02 hatte immer den Adressbereich 87.xxx.xxx.xxx
keine Probleme,
dann FW .03, damit das bekannte Geschwindigkeitsproblem,
nach reboot und danach Adressbereich 217.xxx.xxx.xxx seit 24 Stunden kein Problem mehr.
Frage: hat hier jemand auch diese Beobachtung gemacht, oder eine Erklärung, fragt, Manukura
16.10.2016 10:17
@Manukura_1 schrieb:Moin moin,
nach der Aktion:
Zugriff auf SPH nicht mehr möglich, Fenster wechseln ging gerade noch zu:
Der letzte Neustart erfolgte am 15.10.2016 um 09:05 Uhr.IPv4-Adressinformationen
Öffentliche WAN-IP:
217.241.135.xxx <<<< neuer IP-Bereich, vorher 87.xxx.xxx.xxxläuft der SPH jetzt ohne Probleme.
Der SPH mit FW .02 hatte immer den Adressbereich 87.xxx.xxx.xxx
keine Probleme,
dann FW .03, damit das bekannte Geschwindigkeitsproblem,
nach reboot und danach Adressbereich 217.xxx.xxx.xxx seit 24 Stunden kein Problem mehr.
Frage: hat hier jemand auch diese Beobachtung gemacht, oder eine Erklärung, fragt, Manukura
Hallo @Gelöschter Nutzer
Bei mir habe ich auch einen adressbereich 217.xxx.xxx.xxx und keine Geschwindigkeitsprobleme.
Ich bin mir fast sicher das ich früher auch einen anderen adressbereich hatte. Nach dem update hatte ich Probleme mit der Geschwindigkeit aber die haben sich ja dann von alleine gelöst. Ob das am Adressbereich 217... liegt kann ich nicht sagen.
Grüße
16.10.2016 13:25
Anbei die Tabellen mit den Clienteinträgen. Meine Konfiguration:
- IP Speedport: 192.168.178.1, keine zweiter Router hinter dem Speedport
- Telefonie über FB 7490 im Clientmodus und Speedport ISDN Adapter
- Firmware: letzte V2
- DHCPv6 und DNS über den Speedport
- DHCPv4 deaktiviert
- DHCPv4 wird über einen Access Point unter Openwrt mit dnsmasq zur Verfügung gestellt. D.h. jedes Gerät im Netzwerk ist als Static Lease definiert und bekommt vom DHCP anhand der MAC Adresse immer die gleiche IP Adresse.
In der folgenden Tabelle sind die Geräte teilweise eingeschaltet, teilweise nicht. Gerät 23 ist ein PC unter Windows 10 und läuft:
DHCP Server
IPv4 Active Lease
index | IP address | Hardware address | Client ID | Expire time | Lease state |
1 | 192.168.178.243 |
| 0 | 1 | |
2 | 192.168.178.101 |
| 0 | 1 | |
3 | 192.168.178.204 |
| 0 | 1 | |
4 | 192.168.178.200 |
| 0 | 1 | |
5 | 192.168.178.240 |
| 0 | 1 | |
6 | 192.168.178.201 |
| 0 | 0 | |
7 | 192.168.178.241 |
| 0 | 1 | |
8 | 192.168.178.233 |
| 0 | 1 | |
9 | 192.168.178.230 |
| 0 | 1 | |
10 | 192.168.178.202 |
| 0 | 1 | |
11 | 192.168.178.210 |
| 0 | 1 | |
12 | 192.168.178.232 |
| 0 | 1 | |
13 | 192.168.178.234 |
| 0 | 1 | |
14 | 192.168.178.242 |
| 0 | 1 | |
15 | 192.168.178.231 |
| 0 | 0 | |
16 | 192.168.178.222 |
| 0 | 1 | |
17 | 192.168.178.250 |
| 0 | 1 | |
18 | 192.168.178.122 |
| 0 | 0 | |
19 | 192.168.178.220 |
| 0 | 0 | |
20 | 192.168.178.206 |
| 0 | 0 | |
21 |
| 0 | 0 | ||
22 | 192.168.178.212 |
| 0 | 1 | |
23 | 192.168.178.211 |
| 0 | 1 |
Gerät 23 ausgeschaltet und ein paar Minuten gewartet, dann wird die Adresse im Cache auf von diesem Gerät 0.0.0.0 gesetzt.
DHCP Server
IPv4 Active Lease
index | IP address | Hardware address | Client ID | Expire time | Lease state |
1 | 192.168.178.243 | 0 | 1 | ||
2 | 192.168.178.101 |
|
| 0 | 1 |
3 | 192.168.178.204 |
|
| 0 | 1 |
4 | 192.168.178.200 |
|
| 0 | 1 |
5 | 192.168.178.240 |
|
| 0 | 1 |
6 | 192.168.178.201 |
|
| 0 | 0 |
7 | 192.168.178.241 |
|
| 0 | 1 |
8 | 192.168.178.233 |
|
| 0 | 1 |
9 | 192.168.178.230 |
|
| 0 | 1 |
10 | 192.168.178.202 |
|
| 0 | 1 |
11 | 192.168.178.210 |
|
| 0 | 1 |
12 | 192.168.178.232 |
|
| 0 | 1 |
13 | 192.168.178.234 |
|
| 0 | 1 |
14 | 192.168.178.242 |
|
| 0 | 1 |
15 | 192.168.178.231 |
|
| 0 | 0 |
16 | 192.168.178.222 |
|
| 0 | 1 |
17 | 192.168.178.250 |
|
| 0 | 1 |
18 | 192.168.178.122 |
|
| 0 | 0 |
19 | 192.168.178.220 |
|
| 0 | 0 |
20 | 192.168.178.206 |
|
| 0 | 0 |
21 |
|
| 0 | 0 | |
22 | 192.168.178.212 |
|
| 0 | 0 |
23 | 0.0.0.0 |
|
| 0 | 0 |
Die Geräte haben natürlich alle eine MAC Adresse und eine ID, die ich unter "Heimnetzwerk" im Webif des Speedport vergeben habe. Diese Einträge habe ich aber in beiden Tabellen entfernt.
Der Eintrag von Gerät 11 würde nach dem Ausschalten auch nach ein paar Minuten auch auf 0.0.0.0 zurückgesetzt. Auf dieem PC (Windows 10) schreibe ich gerade aber diesen Beitrag, deshalb konnte ich ihn nicht deaktivieren.
Es ist also im Moment so, dass bei dieser Konstellation die beiden zuletzt eingeschalteten Geräte nach dem Ausschalten die Adresse im Cache verlieren.
17.10.2016 08:57 Zuletzt bearbeitet: 17.10.2016 11:35 durch den Autor
guten Morgen
nach dem Neustart des SPH am 15.10.2016 wechselte die IP vom Segment 87.135.xxx.xxx nach 217.241.xxx.xxx
Seit dem ist keine Fehlfunktion mehr aufgetreten!
aktuelle Datenrate:
Ihre IP-Adresse 217.241.xxx.xxx
Gegenstelle 212.42.224.72 (AVM Speedtest)
08:39:12,17.Oktober 2016: Durchschnittliche Pingzeit: 14,80 ms
08:39:42,17.Oktober 2016: Download ca.1028407 kBits gemessen in 30 s --> Downloadrate: 34355 kBit/s
Frage: Was ist in dem Segment 217.xxx.xxx.xxx anders als im 87.xxx.xxx.xxx Segment?
Nachtrag: Gerade habe ich auf beide Bereiche mal TraceRoute laufen lassen. Das Ergebnis erklärt einiges wenn ich den Graph und die RTT Werte sehe.
eine gute Woche, wünscht, Manukura
17.10.2016 08:58 Zuletzt bearbeitet: 17.10.2016 09:01 durch den Autor
Anbei der Status von heute morgen, nachdem ich das Haus verlassen habe:
DHCP Server
IPv4 Active Lease
index | IP address | Hardware address | Client ID | Expire time | Lease state |
1 | 192.168.178.243 | 0 | 1 | ||
2 | 192.168.178.101 | 0 | 1 | ||
3 | 192.168.178.204 | 0 | 1 | ||
4 | 0.0.0.0 | 0 | 0 | ||
5 | 192.168.178.240 | 0 | 1 | ||
6 | 192.168.178.201 | 0 | 1 | ||
7 | 192.168.178.241 | 0 | 1 | ||
8 | 192.168.178.233 | 0 | 1 | ||
9 | 192.168.178.230 | 0 | 1 | ||
10 | 192.168.178.202 | 0 | 0 | ||
11 | 0.0.0.0 | 0 | 0 | ||
12 | 192.168.178.232 | 0 | 1 | ||
13 | 192.168.178.234 | 0 | 1 | ||
14 | 192.168.178.242 | 0 | 1 | ||
15 | 192.168.178.231 | 0 | 0 | ||
16 | 192.168.178.222 | 0 | 0 | ||
17 | 192.168.178.250 | 0 | 1 | ||
18 | 192.168.178.122 | 0 | 0 | ||
19 | 192.168.178.220 | 0 | 0 | ||
20 | 192.168.178.206 | 0 | 0 | ||
21 | 0 | 0 | |||
22 | 192.168.178.212 | 0 | 0 | ||
23 | 0.0.0.0 | 0 | 0 |
Gerät 4 ist mein Nexus 5x Handy, dass sich abgemeldet, als ich das Haus verlassen habe. Gerät 11 und 23 sind PCs, die ausgeschaltet wurden. D.h. der Cache kann von maximal 19 Geräten die IPs behalten, bei jedem weiteren Gerät wird ein paar Minuten nach der Abmeldung die IP auf 0.0.0.0 gesetzt.
17.10.2016 09:47
17.10.2016 15:04
Hallo @d-stadler,
kannst du mir bitte nochmal kurz einen Satz schreiben zu den funktionalen Einschränkungen, die zu bemerken sind, wenn ein Client die 0.0.0.0 erhalten hat? Danke
Viele Grüße
Schmidti
17.10.2016 16:00
Funktionale Einschränkungen gibt es nicht, außer ich versuche den Client zu pingen.
Ich dachte nur, das Verhalten könnte evtl. mit dem DHCP Problem zusammenhängen.
Aber wenn nicht, dann ist dieses Verhalten ein eher zweitrangiger Bug.
17.10.2016 16:22
17.10.2016 17:27
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.