FRITZ!Box 6591 07.19 Labor Serie

[James_VF]

auch bei deiner 7490 ?
[Edit Novize: Beitrag wieder hergestellt]

 

[Chatty]

Meines Wissens ist die 75516 "die aktuelle Laborversion". Keine Ahnung, wo du eine aktuellere her hast.

 

[jha4711]

Neue Infos und eine Frage zu meinem DHCP Problem (zur Wiederholung: ich habe eine 6591 Cable Vodafone Edition entbrandet, auf reinen IP-Client via LAN umkonfiguriert und die Laborversion 07.19-75516 aufgespielt. DVB-C läuft wunderbar ABER ich kann die 6591 nicht als WLAN-AP einsetzen, weil die WLAN-Clients über diese Box keine IP-Adresse via DHCP von einem im LAN laufenden DHCP-Server zugewiesen bekommen).

Die neue Erkenntnis ist jetzt, dass das mit dem DHCP ein sch..... "geht nicht"/"geht nach einer Weile"/"geht dann wieder nicht" - Fehler zu sein scheint.
Also wenn ich einige Minuten warte und Glück habe, bekommt der WLAN-Client tatsächlich irgendwann einmal eine IP-Adresse zugewiesen. Am Log sieht man, dass die DHCP Anfrage tatsächlich beim DHCP-Server ankommt, aber die Antwort Ihren Weg nicht zurück bis zum Client zu finden scheint! Mit der ebenfalls modifizierten 07.12/13 Firmware gab es diese Probleme nicht.

Log vom DHCP-Server:

2020:03:09-12:20:02 kbw dhcpd: DHCPDISCOVER from 88:19:08:12:f7:3b via eth0
2020:03:09-12:20:02 kbw dhcpd: DHCPOFFER on 192.168.1.230 to 88:19:08:12:f7:3b via eth0
2020:03:09-12:20:04 kbw dhcpd: DHCPDISCOVER from 88:19:08:12:f7:3b via eth0
2020:03:09-12:20:04 kbw dhcpd: DHCPOFFER on 192.168.1.230 to 88:19:08:12:f7:3b via eth0
2020:03:09-12:20:06 kbw dhcpd: DHCPDISCOVER from 88:19:08:12:f7:3b via eth0
2020:03:09-12:20:06 kbw dhcpd: DHCPOFFER on 192.168.1.230 to 88:19:08:12:f7:3b via eth0

... so geht das im 2-4 Sekunden Rhythmus ...

2020:03:09-12:24:47 kbw dhcpd: DHCPDISCOVER from 88:19:08:12:f7:3b via eth0
2020:03:09-12:24:47 kbw dhcpd: DHCPOFFER on 192.168.1.230 to 88:19:08:12:f7:3b via eth0
2020:03:09-12:24:55 kbw dhcpd: DHCPDISCOVER from 88:19:08:12:f7:3b via eth0
2020:03:09-12:24:55 kbw dhcpd: DHCPOFFER on 192.168.1.230 to 88:19:08:12:f7:3b via eth0
2020:03:09-12:24:56 kbw dhcpd: DHCPREQUEST for 192.168.1.230 (192.168.1.1) from 88:19:08:12:f7:3b via eth0

... bis schließlich ein DHCPACK erfolgt und der WLAN-Client TATSÄCHLICH seine IP-Adresse (hier 192.168.1.230) vom DHCP-Server bezieht (DHCP-Server --> LAN --> FRITZ!Box 6591 Cable --> WLAN --> WLAN-Client)

2020:03:09-12:24:56 kbw dhcpd: DHCPACK on 192.168.1.230 to 88:19:08:12:f7:3b via eth0

Zeitgleich im "dmesg -T" der FRITZ!Box 6591 Cable ...

[Mon Mar  9 12:24:13 2020] _ieee80211_node_leave, macaddr 88:19:08:12:f7:3b left,  decremented iv_sta_assoc(0)
[Mon Mar  9 12:24:13 2020] ol_ath_node_cleanup: Cleanup for peer:88:19:08:12:f7:3b, decremeting sta, tx_nss:0, rx_nss:2
[Mon Mar  9 12:24:13 2020] ath_green_ap_state_mc: Decrementing nodes, node_count :0
[Mon Mar  9 12:24:13 2020] ol_ath_node_cleanup: Cleanup for peer:88:19:08:12:f7:3b, decremeting multi-sta, tx_nss:0, rx_nss:2
[Mon Mar  9 12:24:13 2020] ath_green_ap_state_mc: Decrementing multi-stream nodes, node_count :0
[Mon Mar  9 12:24:13 2020] [ol_ath_node_cleanup]: Num of associated stas: 0
[Mon Mar  9 12:24:13 2020] [ol_ath_node_cleanup]: Sending peer delete for ni: 88:19:08:12:f7:3b, nss of peer:2
[Mon Mar  9 12:24:13 2020] [DEBUG] vap-0(ath0):ieee80211_recv_asreq Disabling LDPC for better performance
[Mon Mar  9 12:24:13 2020] ieee80211_node_join: macaddr 88:19:08:12:f7:3b joined, incremented iv_sta_assoc(1)
[Mon Mar  9 12:24:13 2020] [avm_event_node]send_msg: failed 0
[Mon Mar  9 12:24:13 2020] [avm_event_main][avm_event_source_trigger] propagating event to remote nodes failed! (id=0)
[Mon Mar  9 12:24:13 2020] [ol_ath_send_peer_assoc]: Sending peer assoc cmd to FW for peer:88:19:08:12:f7:3b, assoc_id: 1,nss:2
[Mon Mar  9 12:24:13 2020] ieee80211_assoc_resp_complete_handler: Tx status flags 0x0
[Mon Mar  9 12:24:13 2020] ieee80211_assoc_resp_complete_handler: Assoc complete for peer:88:19:08:12:f7:3b, incrementing sta, tx_nss:0, rx_nss:2
[Mon Mar  9 12:24:13 2020] ath_green_ap_state_mc: Incrementing nodes, node_count :1
[Mon Mar  9 12:24:13 2020] ath_green_ap_state_mc: Incrementing multi-stream nodes, node_count :1
[Mon Mar  9 12:24:13 2020] ieee80211_assoc_resp_complete_handler: Assoc complete for peer:88:19:08:12:f7:3b, incrementing multi-steam sta, tx_nss:0, rx_nss:2
[Mon Mar  9 12:24:13 2020] [RRM] vap-0(ath0):    44 4e 6d e3 35 df     5      184
[Mon Mar  9 12:24:13 2020] [wifi1] FWLOG: [1048922] WAL_DBGID_SECURITY_UCAST_KEY_SET ( 0xf73b, 0x0 )
[Mon Mar  9 12:24:13 2020] [wifi1] FWLOG: [1048922] WAL_DBGID_SECURITY_ENCR_EN (  )
[Mon Mar  9 12:24:13 2020] [wifi1] FWLOG: [1048922] WAL_DBGID_SECURITY_ALLOW_DATA ( 0x458124 )
[Mon Mar  9 12:24:13 2020] [wifi1] FWLOG: [1049246] RATE: ChainMask 3, peer_mac f7:3b, phymode 5, ni_flags 0x00201006, vht_mcs_set 0x0000, ht_mcs_set 0xffff, legacy_rate_set 0x0fff
[Mon Mar  9 12:24:13 2020] [wifi1] FWLOG: [1049290] WAL_DBGID_SECURITY_UCAST_KEY_SET ( 0xf73b, 0x0 )
[Mon Mar  9 12:24:13 2020] [wifi1] FWLOG: [1049290] WAL_DBGID_SECURITY_ENCR_EN (  )
[Mon Mar  9 12:24:13 2020] [wifi1] FWLOG: [1049290] WAL_DBGID_SECURITY_ALLOW_DATA ( 0x458124 )
[Mon Mar  9 12:24:25 2020] [RRM] vap-0(ath0):     44 4e 6d e3 35 df     5      187
[Mon Mar  9 12:24:25 2020] [RRM] vap-0(ath0):    44 4e 6d e3 35 df     5      187
[Mon Mar  9 12:24:25 2020] [RRM] vap-0(ath0):     44 4e 6d e3 35 de     60      174
[Mon Mar  9 12:24:31 2020] [RRM] vap-0(ath0):    44 4e 6d e3 35 de     60      174
[Mon Mar  9 12:24:31 2020] [RRM] vap-0(ath0):     44 4e 6d e3 35 df     5      188
[Mon Mar  9 12:24:53 2020] [wifi1] FWLOG: [1090449] RATE: ChainMask 3, peer_mac f7:3b, phymode 5, ni_flags 0x00201006, vht_mcs_set 0x0000, ht_mcs_set 0xffff, legacy_rate_set 0x0fff
[Mon Mar  9 12:24:55 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:56 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:58 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0
[Mon Mar  9 12:24:59 2020] ppa_lpal_cppi_rx:855: got wrong vpid 0

Meine Frage in die Runde:
Hat jemand Lust sich die Logs anzuschauen und mir ggf. einen Tipp zu geben, was ich an der FRITZ!Box noch versuchen könnte um dieses Problem ggf. zu beheben. Hat es ggf. was mit der ar7.cfg und dem Bridgen zu tun? Vielleicht gibt's für so ein DHCP Problem ja auch längst schon Lösungen die ich aber nicht gefunden habe?
ODER
lautet die einfache, ehrliche Antwort eher: keine Chance bei dieser Konstellation (Provider Box entbrandet und für IP-Client-Mode modifiziert und dann noch eine Laborversion) --> VERGISS ES und hoffe auf die nächste Laborversion von avm ;-) ;-) ;-) ?

Danke im Voraus!

 

[AndiBerl]

Heute morgen spontaner Neustart der 6591 mit der aktuellen Beta. Hat das Problem sonst noch wer bemerkt?

Hast du ein USB-gerät an der Fritte dran? Das Problem mit der 7.19 hatte ich auch. Hab wieder 7.13

 

[KunterBunter]

... bis schließlich ein DHCPACK erfolgt und der WLAN-Client TATSÄCHLICH seine IP-Adresse (hier 192.168.1.230) vom DHCP-Server bezieht

Wie ist denn da der DHCP-Bereich eingestellt, wenn eine Adresse .230 vergeben wird?

 

[Chatty]

Bei mir fällt der DNS-Server der 6591 vermehrt aus. Ich habe eine 7490 mit der aktuellen Inhaus (76608) im Mesh. Und selbst lokal auf der 6591 funktioniert die Namensauflösung nicht. Erst ein Neustart von multid hilft.

 

[syberstef]

Wenn ich viel Traffic über meine 6591 per VPN generiere, startet sie sofort neu! Habe eben eine 1 GB Datei per VPN aus der Ferne von meinem NAS geladen und plötzlich war die Fritzbox nicht mehr erreichbar. Sie startete dann neu und lief wieder. Selber Versuch endete dann wieder im Reboot. Lässt sich stets zuverlässig reproduzieren. Hoffe, dass das schnell gefixt wird.

 

[jha4711]

Wie ist denn da der DHCP-Bereich eingestellt, wenn eine Adresse .230 vergeben wird?

Der DHCP-Bereich geht von 192.168.1.100 bis 192.168.1.199
Zusätzlich gibt es Reservierungen von festen IP Adressen (wie die 1.230) für gewisse MAC Adressen (bewusst außerhalb des o.g. Bereichs)

 

[eisbaerin]

Es gibt was neues:

FRITZ.Box_6591_Cable-labor-07.19-77042.image

 

[syberstef]

ENDLICH!!! Bisher TOP! Meine Fritzbox startet auch bei hoher VPN-Last nicht mehr neu. Die letzte Labor war der blanke Horror. Davor die Final war im VPN-Bereich so langsam wie eine Schnecke. Mit der aktuellen Version läuft das VPN super schnell und ich laste meinen Upload vollständig aus.

 

[feelfree]

Die mit der letzten Beta zwischenzeitlich verschwundenen DVB-C-Senderlogos sind nun alle wieder da.

 

[repete1]

Bei mir ist die VPN Verbindung weiterhin sehr lahm. Muss ich die Verbindung neu einrichten um den Verbesserungseffekt zu sehen?

 

[syberstef]

Seltsam. Ich habe hier eine 7590 mit 10 Mbit/s Upload und wenn ich über die Leitung eine Datei auf ein per VPN verbundenes NAS hochlade, bekomme ich einen Speed von 1,3 MB / Sekunde. Auf der anderen Seite wo das NAD steht, läuft die 6591 mit der aktuellen Beta! Mehr geht bei den Upload ja auch nicht!
Lade ich die selbe Datei vom NAS runter, komme ich auf einen Speed von 2,1 MB und auf der NAS-Seite habe ich 20 Mbit/ Upload.

 

[PeterPawn]

Bei mir ist die VPN Verbindung weiterhin sehr lahm.

Die Gegenstelle spielt natürlich hier auch eine Rolle. Da VPN-Übertragungen halbwegs synchron erfolgen müssen, spielt es keine Rolle, wenn eine Seite die Daten schneller verarbeitet (also ver- oder entschlüsselt), als die andere. Der schnellere Part MUSS irgendwann auf den langsameren warten.

Zwar enthält der ESP-Payload tatsächlich in jedem Datagramm erneut den für dieses Datagramm verwendeten IV, aber die im VPN-Tunnel übertragenen Datenverbindungen haben ja auch noch ihre eigenen Sicherungsverfahren, zumindest dann, wenn es sich dabei um TCP-Verbindungen handelt.

Dieser IV ergibt sich aus dem Status des Verschlüsselungssystems nach dem vorhergehenden Paket und ist dann in jedem ESP-Datagramm gleich an dessen Beginn enthalten, damit nach Paketverlusten - immerhin ist das Transportprotokoll da nur UDP, was nicht ausgeliefert werden MUSS von Transit-Routern,. sondern ohne Benachrichtigung von Absender oder Empfänger verworfen werden darf, wenn der Router das für erforderlich hält - keine ESP-Datagramme wiederholt werden müssen, solange darüberliegende Protokolle für eine Wiederholung der Übertragung ihrer eigenen Datagramme sorgen.

Selbst wenn hier die eine Seite sehr schnell ist beim Verschlüsseln einer TCP-Verbindung und das verwendete TCP-Window (das ist die Anzahl von gesendeten Paketen, die noch keine Empfangsbestätigung haben) schnell bis zum Anschlag füllen kann, muß die andere Seite bei verschlüsselten Daten diese erst einmal entschlüsseln, bevor dort dann festgestellt werden kann, daß sie erfolgreich übertragen wurden und die Bestätigung für diese Pakete dann an den Absender geht - natürlich auch wieder verschlüsselt, aber weder die Anzahl der Bestätigungen, noch deren Länge ist hier der Knackpunkt, sondern der Flaschenhals beim Dekodieren auf der langsameren Seite.

 

[repete1]

Ok, Du meinst also, die 7490 (auf der anderen Seite) ist der Flaschenhals und schaft nicht mehr als 800-900 kbit/s über die VPN Verbindung?

 

[syberstef]

Ja! Das kann ich bestätigen. Habe meine 7490 gehen eine 7590 mit aktueller Beta getauscht und schon waren die 300 kbit/s Geschichte und ich hatte bei selber Leitung 1,3 MB/s

 

[KunterBunter]

Wow. Das ist ja eine Steigerung um fast das 35-fache!

 

[syberstef]

Sorry KB/s statt kbit/s!
Trotzdem deutlich mehr als vorher.

 

[schweisssfusss]

ENDLICH!!! Bisher TOP! Meine Fritzbox startet auch bei hoher VPN-Last nicht mehr neu. Die letzte Labor war der blanke Horror. Davor die Final war im VPN-Bereich so langsam wie eine Schnecke. Mit der aktuellen Version läuft das VPN super schnell und ich laste meinen Upload vollständig aus.

Hi.

Darf ich fragen was heißt voll ausreizen?

Wie viel erreicht du mit welcher Leitung?

Habe leider Mietbox . Also alte fw.
Bei meinem theoretisch 50mbit Upload gehen aber da nur 10 durch ( Gegenstelle kann das locker)

Denke Mal die bekommen die CPU langsam in den Griff und ich hoffe es gibt dann maximalen Speed.

Danke für ein Feedback.

 

[syberstef]

Steht alles in meinen darauf folgenden Posts beschrieben!