FRITZ!Box 7390 Labor-Firmware Version 06.10-28618 LabBETA vom 27.08.2014

[Joesixatpack]

Siemens Gigaset AS28H

Die zwei haben bisher eigentlich immer problemlos funktioniert.

 

[eisbaerin]

Showstopper...

Der ist soooo gut :lach:

 

[Outlaw]

ich habe jetzt erst mitbekommen, dass es für die 7390 eine neue Labor gibt. Erst mal installieren und dann testen

Gut, dass Du uns darüber informiert hast, denn es wäre nicht auszudenken, was wohl passiert wäre, wenn nicht ....

 

[chuckie]

Haste die Box nach dem Update mal ein paar Minuten stromlos gemacht? Wirkt manchmal Wunder ;-)

Jo, Danke für den Tipp. Gestern POR gemacht, aber vermutlich nicht lang genug. Hab heute die FW nochmal drübergebügelt, jetzt scheint alles anstandslos zu laufen...
Die Fritte kann schon mal ganz schön zickig sein

 

[make]

Ich beobachte bei meiner FritzBox mit der besagten Labor-Firmware ein Verhalten, dass meiner Meinung nach falsch ist. So wird IPv4-Traffic zu nicht-erreichbaren Hosts mit Adressen aus dem Bereich privater Netze an den Provider weitergereicht, statt von der Box blockiert bzw. zurück gewiesen zu werden (Network unreachable, no Route to host etc.).

Beispiel (mit MacOS):

$>ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
60 bytes from dslb-088-074-032-001.088.074.pools.vodafone-ip.de (88.74.32.1): Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 2f07   0 0000  3e  01 77d9 192.168.11.32  10.0.0.1

Request timeout for icmp_seq 0
60 bytes from dslb-088-074-032-001.088.074.pools.vodafone-ip.de (88.74.32.1): Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 0368   0 0000  3e  01 a378 192.168.11.32  10.0.0.1

Request timeout for icmp_seq 1
60 bytes from dslb-088-074-032-001.088.074.pools.vodafone-ip.de (88.74.32.1): Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 e815   0 0000  3e  01 beca 192.168.11.32  10.0.0.1

Request timeout for icmp_seq 2
60 bytes from dslb-088-074-032-001.088.074.pools.vodafone-ip.de (88.74.32.1): Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 667e   0 0000  3e  01 4062 192.168.11.32  10.0.0.1

^C
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
[xxx] ~ $>traceroute 88.74.32.1
traceroute to 88.74.32.1 (88.74.32.1), 64 hops max, 52 byte packets
 1  fritz.box (192.168.11.254)  19.256 ms  1.858 ms  1.559 ms
 2  dslb-088-074-032-001.088.074.pools.vodafone-ip.de (88.74.32.1)  10.160 ms  9.719 ms  9.004 ms
[xxx] ~ $>

Wie man dabei sehen kann, kommt vom Provider die Antwort, dass der ICMP-Request gefiltert wurde. Der sollte den Traffic aber gar nicht sehen. Richtig wäre statt dessen, dass die Box selber mir eine entsprechende ICMP-Antwort zurückschickt, da sie _weiss_ dass 10.0.0.1 nicht erreichbar ist.
Probeweise ist es auch möglich, die Box dazu zu bringen, Traffic für 0.0.0.0/8-Adressen an den DSL-Provider weiter zu leiten (zB. IOS-Geräten). Auch diese Adressen sind als Destination-Adressen eigentlich unzulässig.

Oder hab ich da jetzt irgendwas Grundlegendes übersehen?

 

[JL3]

@RudatNet: Bei mir ist es eine 546E, die als WLAN-Repeater fungiert, und das Verhalten mit den ersten 5 "abgewiesenen" Minuten ist bei jedem Box-Reboot wiederholbar. Richtig ist das wohl irgendwie auch nicht, aber zumindest klappt nach der Wartezeit die automatische Anmeldung dann doch.

Was mir noch auffällt ist, dass das WLAN (bei mir 2,4GHz/40) immer wieder Aussetzer aufweist. Beim Aufnehmen mit der Dreambox über WLAN-Bridge wird das deutlich. Hatte ich mit der letzten Final noch nicht gehabt, betrifft aber alle Labors.

 

[padowa76]

@make: also hier kann ich das Verhalten nicht nachvollziehen, hier fängt die Box direkt die Anfragen ab ...

Gruß Patrick

 

[H´Sishi]

@make: Ist der entsprechende PC / Client in der Fritz!Box-Firewall als DMZ eingerichtet?

 

[Outlaw]

Hat außer mir niemand sporadische Hänger im Sekundenbereich mit dieser Version bei DSL 16.000 ??

 

[Fritzbox_7390]

Sieht bis her ganz anständig aus, Festplatte geht schlafen und der HTML
Player etc... und in Verbindung mit dem neuen Fritzmedia ... da kann man schon mal was mit anfangen
VDSL Fehler sind fast bei 0 also 0,01 Pro Minute.

 

[tester25]

Von AVM habe ich vor wenigen Tagen endlich eine Rückmeldung zum Feedback der 5GHz-WLAN-Problematik bekommen. Unter anderem mit den Fragen

X Tritt das Problem ebenfalls mit der heute erscheinenden Laborversion 28618 auf?

X Tritt es auf wenn Sie manuell einen anderen als den derzeit gesetzten Kanal wählen? Welche haben Sie probiert?

Es scheint also Veränderungen in dieser Version zu geben, was das WLAN betrifft. Leider habe ich immer noch Abbrüche im 5GHz-Netz, die sich teilweise auch im Log bemerkbar machen:

30.08.14 10:21:11 WLAN-Gerät wird abgemeldet (5 GHz): WLAN-Gerät antwortet nicht. MAC-Adresse: A0:.........55. (#0302).

Viele Grüße
tester25

 

[M.Hennicke]

Ich beobachte bei meiner FritzBox mit der besagten Labor-Firmware ein Verhalten, dass meiner Meinung nach falsch ist. So wird IPv4-Traffic zu nicht-erreichbaren Hosts mit Adressen aus dem Bereich privater Netze an den Provider weitergereicht, statt von der Box blockiert bzw. zurück gewiesen zu werden (Network unreachable, no Route to host etc.).
...
Oder hab ich da jetzt irgendwas Grundlegendes übersehen?

Also bei mir werden auch IPs aus privaten Class A-/B- und C-Netze an meinen Provider geroutet, obwohl dies laut RFC1918 nicht im Internet routbar sind!
(siehe http://de.wikipedia.org/wiki/Private_IP-Adresse und http://tools.ietf.org/html/rfc1918)

tracert 10.0.0.1
Routenverfolgung zu PC1.local [10.0.0.1] über maximal 30 Abschnitte:

  1    <1 ms    <1 ms    <1 ms  dsl [192.168.23.1]
  2  dslb-188-106-224-001.188.106.pools.vodafone-ip.de [188.106.224.1]  meldet: Zielnetz nicht erreichbar.
Ablaufverfolgung beendet.

tracert 172.16.20.20
Routenverfolgung zu PC1.local [172.16.20.20] über maximal 30 Abschnitte:
  1    <1 ms    <1 ms    <1 ms  dsl [192.168.23.1]
  2     *     dslb-188-106-224-001.188.106.pools.vodafone-ip.de [188.106.224.1]  meldet: Zielnetz nicht erreichbar.
Ablaufverfolgung beendet.

tracert 192.168.77.77
Routenverfolgung zu PC1.local [192.168.77.77] über maximal 30 Abschnitte:
  1    <1 ms    <1 ms    <1 ms  dsl [192.168.23.1]
  2  dslb-188-106-224-001.188.106.pools.vodafone-ip.de [188.106.224.1]  meldet: Zielnetz nicht erreichbar.
Ablaufverfolgung beendet.

Wer hat eine Erklärung, was das soll??? (Muss man wo eigentlich AVM fragen!)
Kann jemand mit der aktuellen Stable diesen Test wiederholen, um zu sehen ob es dort noch korrekt funktioniert.

 

[PeterPawn]

Also bei mir werden auch IPs aus privaten Class A-/B- und C-Netze an meinen Provider geroutet, obwohl dies laut RFC1918 nicht im Internet routbar sind!

Ich spekuliere jetzt mal, daß bei einigen Providern mit isolierten Netzen (bei KDG weiß ich es) die VoIP-Telefonie teilweise auf diesen reservierten Adressen läuft und dann muß natürlich der Traffic auch zum Provider gelangen.

In diesem Fall gilt eben: Providernetz ist noch nicht Internet.

Es ist auch nicht auf die 7390-Labor beschränkt, bei einer 7490 mit 06.20 am T-DSL-Business:

root@FB7490:~ $ traceroute 10.1.1.1
traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 38 byte packets
 1  217.5.98.14 (217.5.98.14)  30.870 ms  30.672 ms  31.405 ms
 2  *  *  *
 3  *  *  *
 4  *^C
root@FB7490:~ $

Hop 1 ist der erste auf dem Weg ins Internet über den Telekom-Anschluß ... erst dann wird offenbar gefiltert (ohne passende ICMP-Message bei der Telekom).

Wenn der Traffic also an der FB vorbeikommt und es keine passende Route gibt, geht er eben über "default". Läßt sich aber mit eigener Route für 10/8, 172.16/12 und 192.168/16 "overrulen".

 

[kimchi]

Habe es auch mit dieser Labor nicht geschafft, DSL eines externen Modems an die 7390 weiterzuleiten.

http://www.ip-phone-forum.de/showthread.php?t=272446&p=2030383&viewfull=1#post2030383

Hierbei habe ich die Vorschläge von PeterPawn (Danke) ebenso berücksichtigt.

http://www.ip-phone-forum.de/showthread.php?t=272446&p=2030412&viewfull=1#post2030412

Nun habe ich das externe Modem probeweise abgehangen und musste (nach langer Leidenszeit) erfreut feststellen, dass ich wieder vollen
Speed mit dem internen Modem habe. Soweit so gut. :--)

Leider reagiert die Beta FW (bei mir) extrem instabil :

In den ersten Minuten habe ich vollen Speed an meinen Rechnern, dann plötzlich ist die 7390 nicht mehr erreichbar (?) und die DSL Verbindung weg.
Nach einem "steckerziehen" = reboot, ist die Box wieder erreichbar und DSL wieder normal da.

Ich habe bereits mehrfach die Box komplett stromlos gemacht (c.20 Minuten), sowie händisch alles komplett neu eingerichtet & und die Beta auch neu geflasht.

Leider ohne Erfolg .

Die letze stabile FW läuft ohne Schwankungen und mit erfreulichem vollen ADSL Speed.

 

[make]

Ich spekuliere jetzt mal, daß bei einigen Providern mit isolierten Netzen (bei KDG weiß ich es) die VoIP-Telefonie teilweise auf diesen reservierten Adressen läuft und dann muß natürlich der Traffic auch zum Provider gelangen.

In diesem Fall gilt eben: Providernetz ist noch nicht Internet.

Ja, aber dann hat die Fritzbox auch keine öffentliche IP-Adresse (wie bei mir). In dem von dir beschriebenen Fall wäre das Verhalten richtig, da der Traffic von der FritzBox dann ja nicht ins "öffentliche" Internet geleitet wird.

Es ist auch nicht auf die 7390-Labor beschränkt, bei einer 7490 mit 06.20 am T-DSL-Business:

Interessant. Bleibt die Frage, ob das Phänomen auch mit deutlich älteren Firmware-Version zu beobachten ist. Ich hab die Vermutung, dass der Effekt neu mit der 06er Linie ist.

Wenn der Traffic also an der FB vorbeikommt und es keine passende Route gibt, geht er eben über "default". Läßt sich aber mit eigener Route für 10/8, 172.16/12 und 192.168/16 "overrulen".

Verstehe ich jetzt nicht. Wenn die Fritzbox Traffic für nicht erreichbare private Adressen, (auch für die) die NICHT im Adressbereich des Fritzbox-"Heimnetzes" liegen, auf den Default-GW routet, auf welche Adressen sollen denn dann deine Routen zeigen?
Genau darin liegt doch genau das Problem, dass dieser Traffic über den default-gw an den Provider geleitet wird?! Ich probier gerne was aus, wenn du einen konkreten Vorschlag hast.

Zu den anderen Anmerkungen:
- Firewall auf dem Client an oder aus ist egal, da das Problem hier in der Fritzbox bzw. zwischen FritzBox und Provider auftritt und zwar nachdem der Traffic den Client verlassen hat.
- Für diejenigen, die das Problem nicht nachvollziehen können - ja, meistens ist der Client schon schlau genug und unterbindet offensichtlich unsinnigen Traffic, zB. fangen Windows und MacOS Sachen wie "ping 0.0.0.8" o.ä ab, ohne das irgendwelche Pakete den lokalen Rechner verlassen. IOS-Geräte, zumindestens mit IOS 5 tun das aber nicht.
Wie dem auch sei, mein Problem ist, was die FritzBox mit derartigem Traffic macht. Das Problem beschränkt sich im übrigen nicht auf ICMP, sondern lässt sich unter bestimmten Umständen auch mit TCP-Traffic beobachten.

 

[PeterPawn]

Ja, aber dann hat die Fritzbox auch keine öffentliche IP-Adresse (wie bei mir).

Jein, nicht zwingend. Wenn der Provider nicht zwei verschiedene Interfaces (internet+voip) konfiguriert (da hätte dann das voip-Interface die private Adresse), steht es ihm ja auch frei, irgendwo in seinem Netz die Ausleitung des Verkehrs an seine SIP-Server (sagen wir mal als Beispiel mit 10.4/12) zu machen.

Verstehe ich jetzt nicht. Wenn die Fritzbox Traffic für nicht erreichbare private Adressen, (auch für die) die NICHT im Adressbereich des Fritzbox-"Heimnetzes" liegen, auf den Default-GW routet, auf welche Adressen sollen denn dann deine Routen zeigen?

Ich habe bei mir einen zentralen Server, die Route dorthin wird für die FRITZ!Box mit 192.168/16 gesetzt. Damit wird erst einmal aller Traffic zu diesen Adressen (leider auch beim VPN, das ist eine andere Geschichte, die man dann gesondert regeln muß) von der FB nicht auf "dev dsl", sondern auf "dev lan" an diese Adresse geroutet. Der hängt per LAN an der Box und auch die WLAN-Clients, die sich an der FB anmelden, werden erst einmal über diesen Server "gejagt".

Ich probier gerne was aus, wenn du einen konkreten Vorschlag hast.

Das kommt auf Dein Ziel an ... wenn Du lediglich verhindern willst, daß Traffic mit unbekannten privaten Adresse (den ja sonst niemand im LAN haben will, sonst wäre die Adresse ja nicht unbekannt und z.B. per ARP auflösbar) in Richtung Provider Dein Netz verläßt, ist es Dir doch unbenommen, den an einen fiktiven "Blackhole"-Router im LAN weiterzureichen. Bei den meisten Netzmasken/-Adressen sollte das sogar über das GUI klappen, die o.a. 192.168/16 läßt sich (bei 192.168.xxx.1/28-Adresse der FB) so jedenfalls problemlos einrichten.

Wenn für den Traffic ein legitimes Ziel existiert in Deinem Netz, dürfte er ja entweder gar nicht bei der FB als Default-GW ankommen oder diese müßte die korrekte Route (dann natürlich zu einem funktionierenden Router und nicht zu einem Blackhole) ihrerseits kennen.

 

[Smithy]

Mit dieser Firmware funktioniert nun die SD-Karte im UMTS Stick (E176 bzw. Web'n'Walk IV) an der 7390. (16GB)
Schade, dass es nicht in der Release der 7490 funktioniert.

 

[oldmen]

ot
Und ganz besonders schade, dass es nicht an der 7270 funktioniert. Weil die hat ja nur 1x USB.
Aber zumindest für die 7490 wird ja in Zukunft noch was kommen...
/ot

 

[trendchiller]

Das WLAN läuft scheinbar stabiler (zumindest sind bis jetzt keine Fehler aufgetreten). Warten wir mal ab.

 

[SF1975]

Hallo,
Ich wurde heute Vormittag von Annex B auf Annex J umgestellt. Soweit nicht tragisch .
Der Upload wird in meiner Box nun mit ca. 2,4-2,5 Mbit/s angezeigt. So steht es in allen DSL-Reitern.

Nur diese Anzeige "spinnt ein wenig. Den Neustart habe ich gerade gemacht.

Mal schauen, wie es heute Abend nach einem POR ist. Meldung geht dann raus.

Hallo,
Ich sehe gerade: Die "reale Bandbreite" lt. Telekom ist nur 1Mbit/s im Upload (lt. Log.)
Mal schauen, ob sich das noch ändert. Umstellung ist erst 2 Stunden her...