[ gelöst ] 6490 per ftp/bootloader flashen

[PeterPawn]

Noch mal: Ich würde in die aktiven MTDs versuchen zu schreiben (also 0+1 und 6+7).

Was noch auffällt ... ich kenne zwar den exakten Aufruf für die Paketmitschnitte jetzt nicht und die sind so als "CODE"-Block auch schwer zu entziffern (ich weiß also nicht, ob da irgendetwas aggregiert wurde) - aber wenn ich das richtig lese, sendet der PC sogenannte "Jumbo-Frames" auf L2 (4374 Byte, bevor die Box die Verbindung mit "426" schließt - normalerweise ist die Länge des Payloads bei Ethernet auf 1500 Byte begrenzt), was die FRITZ!Box vermutlich nicht versteht (ohne kompletten Mitschnitt schwer definitiv zu sagen) und wo ggf. intern irgendwelche Puffer überschrieben werden oder die Pakete vielleicht nicht komplett ausgewertet werden (wenn sie denn tatsächlich komplett empfangen wurden).

 

[stoney]

Ablauf

quote SETENV linux_fs_start 0

RESTART

mtd0

sudo tcpdump -s0 -i enp0s10 -w ./mtd0.pcap
tcpdump: listening on enp0s10, link-type EN10MB (Ethernet), capture size 262144 bytes
^C80 packets captured
81 packets received by filter
0 packets dropped by kernel

./eva_store_tffs mtd0 /home/stoney/Schreibtisch/6490-6.63/remote/var/tmp/filesystem.image
Found AVM bootloader: AVM EVA Version 1.2567 0x0 0x36409

eva_store_tffs.log
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd0
501 store failed
 data connection
426 Data connection closed

RESTART

mtd1

sudo tcpdump -s0 -i enp0s10 -w ./mtd1.pcap
tcpdump: listening on enp0s10, link-type EN10MB (Ethernet), capture size 262144 bytes
^C180 packets captured
181 packets received by filter
0 packets dropped by kernel

./eva_store_tffs mtd1 /home/stoney/Schreibtisch/6490-6.63/remote/var/tmp/kernel.image
Found AVM bootloader: AVM EVA Version 1.2567 0x0 0x36409

eva_store_tffs.log
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd1
150 Opening BINARY data connection
426 Data connection closed

RESTART

mtd6

sudo tcpdump -s0 -i enp0s10 -w ./mtd6.pcap
tcpdump: listening on enp0s10, link-type EN10MB (Ethernet), capture size 262144 bytes
^C190 packets captured
190 packets received by filter
0 packets dropped by kernel

./eva_store_tffs mtd6 /home/stoney/Schreibtisch/6490-6.63/remote/var/tmp/x86/filesystem.image 
Found AVM bootloader: AVM EVA Version 1.2567 0x0 0x36409

eva_store_tffs.log
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd6
150 Opening BINARY data connection
426 Data connection closed

RESTART

mtd7

sudo tcpdump -s0 -i enp0s10 -w ./mtd7.pcap
tcpdump: listening on enp0s10, link-type EN10MB (Ethernet), capture size 262144 bytes
^C182 packets captured
185 packets received by filter
0 packets dropped by kernel

./eva_store_tffs mtd7 /home/stoney/Schreibtisch/6490-6.63/remote/var/tmp/x86/kernel.image 
Found AVM bootloader: AVM EVA Version 1.2567 0x0 0x36409

eva_store_tffs.log
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd7
150 Opening BINARY data connection
426 Data connection closed

(OT: Problem mit Dateianhängen mit ändern der Einstellung "Dateimanager nicht aktivieren")

 

[PeterPawn]

Da werden offenbar immer noch übergroße Pakete gesendet (ich habe nur die "mtd6.pcap" geöffnet) - ich würde das mal auf "normalen" Modus zurückstellen, zumal für die FTP-Datenverbindung eigentlich eine MSS von 1460 vorgegeben wird (Pakete 56 + 57).

Anschließend sendet der PC aber in folgenden Größen (der Nutzlast):

2048
2880
4320
4320
1440
4320
1440
[...]

Dabei knallt der Sender dann ständig an die Begrenzung des TCP-Windows (mal 8032, mal 8640 Byte - geht bei Paket 71 los und zieht sich eine Weile) und irgendwann hat dann wohl der FTP-Server die Schn***e voll (Paket 130) und versucht den Sender mit einem FIN-Paket zum Abbruch der Datenverbindung zu bewegen - der hat aber noch jede Menge Daten zu senden, wie man an den nachfolgenden Paketen mit "FTP-DATA" sehen kann.

Mit diesem Schließen seitens des FTP-Servers (nach dem Motto: "Was sendest Du da für einen Quatsch?") geht dann auch die "426"-Nachricht einher und dann killt der Client im Anschluß die FTP-Control-Verbindung (in Paket 141) mit einem FIN-Paket - was ihn aber nicht davon abhalten kann, bis Paket 182 noch fleißig Daten in die FTP-Datenverbindung (zum Port 13893) zu stopfen.

Da kann man ja leicht ausrechnen, daß die Daten gar nicht komplett übertragen werden können ... selbst wenn jedes zwischen 71 und 130 aufgezeichnete Datenpaket eines wäre, das 4320 Byte zum FTP-Server transportiert, dann wären das gerade mal (130 - 71) * 4320 => ca. 60 * 4320 => rund 256 KByte, die da in Richtung der Box gesendet wurden, bevor diese ihrerseits die Verbindung abbricht; das ist weit unterhalb jeder Dateigröße, die da gesendet werden sollte.

Was soll ich also schreiben? Ich würde mich gerade an so einer kritischen Stelle (der Bootloader ist ja nun kein "ausgewachsenes System") nicht auf irgendwelche "Nicht-Standard"-Features verlassen und daß heißt nun einmal, daß es für Ethernet-Pakete eine max. Größe gibt, die deutlich unter der hier gesendeten liegt - und die auch eigentlich per MSS-Wert in den SYN-Paketen für eine über Ethernet transportierte TCP-Verbindung vereinbart wurde.

Ich habe keine Ahnung, wo man das beim verwendeten System nun umstellen kann oder soll oder muß ... aber der Hinweis, es doch einmal mit einem "standardgerechten" System zu probieren, sollte eigentlich auch reichen - und den gab es in einem früheren Beitrag bereits. Die Umsetzung liegt nun deutlich bei Dir ...

 

[stoney]

Also liegt es am MTU Wert des PC's ?

Was ist ein "standartgerechtes" System ? (ich werde dies mal installieren)

 

[Shirocco88]

gib mal "ifconfig; ifconfig enp0s10 mtu 1500; ifconfig" ein; das sollte die MTU auf Normal-Size setzen.

 

[PeterPawn]

Also liegt es am MTU Wert des PC's ?

Mal ehrlich ... woher soll ich das jetzt wissen? Es ist nur ein ungewöhnlicher Umstand, der mir anhand des Mitschnitts aufgefallen ist. Ob der schon das gesamte Problem darstellt, kann ich nicht wissen. Im schlechtesten Falle ändert sich gar nichts am Problem - da kann ich dann aber auch nichts dafür.

Was ist ein "standartgerechtes" System ?

Das kommt ganz darauf an, wo man da in Gedanken den Bindestrich einfügt ... aber das ist wieder ein anderes Thema.

Ich wäre ja jetzt hingegangen und hätte mit der Information "jumbo packets" (EDIT: bzw. "jumbo frames", wobei "packets" auch direkt zu den Treffern bei "jumbo frames" führt) mal eine Suchmaschine befragt, was das eigentlich ist, wo die Vorteile, aber auch die Nachteile und Gefahren liegen und wo man das beim von mir verwendeten Betriebssystem eigentlich einstellen kann. Ich halte es für ein Gerücht, daß irgendein System von sich aus die Verwendung solcher "jumbo frames" aktiviert (eben weil das heftige Nebenwirkungen haben kann) und daraus folgt fast zwangsläufig die Vermutung, daß wohl irgendjemand diese Einstellung geändert haben wird. Wenn derjenige jetzt auch noch weiß, was er da warum gemacht hat, ist die Frage nach einem "standardgerechten" Verhalten und wie man wieder dahin kommt, ja praktisch schon beantwortet.

 

[PeterPawn]

@stoney0815:
Der Thread hier steht zwar bereits auf "gelöst" (von @noob_noob), aber irgendwie hatte ich den Eindruck, daß Du den weiterhin "betreiben" wolltest. Hast Du denn nun mal mit "normalgroßen" Ethernet-Paketen probiert oder nicht? Hast Du von einem solchen Versuch dann einen neuen Mitschnitt? Ich hätte nach 48 Stunden jetzt irgendwie neue Versuche und neue Ergebnisse erwartet.

Oder ist das Thema generell gestorben? Dann drücke ich auf "mental purge" und hake den Thread auch für mich ab - das ist einer der wenigen, die ich noch aktiv verfolge.

 

[stoney]

guten Abend

Sorry das ich hier bislang noch nicht geantwortet habe (kann auch bis zur nächsten Antwort, zumindest mit "Fakten" wieder ein paar Tage dauern, leider --_--)

Habe die MTU bei der Installieren Ubuntu Version auf Fix 1500 gestellt - keine Änderung (eth auf 10 / 100 / half / full)

Ich habe es mit der Ubuntu Live CD mit der selben Hardware versucht - keine Änderung

Ich habe es mit anderer Hardware auf W7 sowie Ubuntu Live versucht - keine Änderung

Paketmitschnitte habe ich erst mal keine gemacht, da alles im selben 426 endete, diese werde ich aber sobald ich dazu komme, nachholen und Preis geben.
(Hattest Du jetzt mal in die mtd.img reingeschaut welche ich gepostet habe ? ist diese korrekt?)

 

[PeterPawn]

Nein, in das TFFS-Image (ich nehme mal an, das soll sich in dieser "mtd.img" befinden) habe ich noch nicht hineingesehen.

Nach der Feststellung, daß die Box bereits nach ~ 256KB gesendeter Daten dann ihrerseits das "426" in der Control-Verbindung sendet und die Datenverbindung schließt, ist ja die Theorie mit "gesendete Daten = richtiges Image" wieder vom Tisch (zu der mich das mit den 14 MB gesendeter Daten im FTP-Client verleitet hatte) ... soweit kommt es erst gar nicht.

Also geht es wieder um das Timing der verschiedenen Pakete ... jedenfalls solange das Schreiben von TFFS-Images nach "mtd3" und "mtd4" nicht ebenfalls mit einem entsprechenden Fehler "426" quittiert wird. Das würde dann den Schluß zulassen, daß es nur beim Schreiben von eMMC-Partitionen dieses Problem gibt und nicht beim Schreiben von MTD-Partitionen, die im SPI-Flash liegen. Wenn sich das bewahrheiten sollte, wäre ggf. noch denkbar, daß die GPT im eMMC-Device nicht mehr stimmt - wobei m.W. die Firmware dann auf das Backup der GPT in einer der SPI-Partitionen zurückgreifen müßte.

Bei dieser Box könnte es sich vielleicht sogar lohnen, die serielle Schnittstelle zu bestücken ... soweit ich weiß, ist die im Bootloader noch aktiv (habe ich aber nie selbst getestet) und wird erst im gestarteten Linux-Kernel dann stillgelegt.

Das mit dem "noch nicht geantwortet" ist auch nicht weiter wild ... ich war nur etwas verunsichert, ob Du das nun aufgegeben hast oder nicht. So langsam beginnt mich diese Box halt zu interessieren ... ein solches Fehlerbild hatte ich tatsächlich noch bei keiner 6490, die ich in die Hände bekommen habe.

Ich würde glatt noch einmal mit "üblichen" Paketgrößen versuchen, die beiden TFFS-Partitionen neu zu beschreiben ... einfach nur aus reiner Vorsicht, falls es schon da ein Problem gab. Es ist auch nicht klar vorherzusagen, wie sich ein System verhält, wenn es solche "jumbo frames" empfängt und darauf gar nicht wirklich vorbereitet ist ... und ob das beim AVM-Bootloader der Fall wäre oder nicht, weiß ich auch nicht. Wenn das Ergebnis aber am Ende ist, daß da nur die Daten in der "normalen Länge" eines Ethernet-Pakets verarbeitet werden, dann kann das schon merkwürdige Auswirkungen haben.

Ob das TFFS-Image paßt (vom Format her), kannst Du auch selbst prüfen, indem Du es einfach noch einmal von "dissect_tffs" in seine Bestandteile zerlegen läßt und dann diese einzelnen Dateien/Daten mit den ursprünglichen Eingabedaten vergleichst.

Also noch einmal das TFFS-Image (mit normalen Paketgrößen) nach "mtd3" und "mtd4" schreiben (dabei merkt man auch gleich, ob sich SPI-Partitionen beschreiben lassen, trotzdem gleich beim ersten Versuch dann auch mitschneiden und den Mitschnitt aufheben, falls man später noch einmal nachsehen will, ob das reibungslos lief und was da geschrieben wurde) und dann die Box neu starten und mit "eva_get_environment env" noch einmal das Environment auslesen lassen. Wenn das ohne Probleme funktioniert und mit den erwarteten Daten endet, sollte das TFFS in Ordnung sein - irgendwelche Einstellungsdateien sind ja bei leerem TFFS-Image (also einem, wo nur die Name-Table und die Environment-Variablen, ggf. noch die Counter, enthalten sind) nicht vorhanden.

 

[robert_s]

Da werden offenbar immer noch übergroße Pakete gesendet (ich habe nur die "mtd6.pcap" geöffnet) - ich würde das mal auf "normalen" Modus zurückstellen, zumal für die FTP-Datenverbindung eigentlich eine MSS von 1460 vorgegeben wird (Pakete 56 + 57).

Anschließend sendet der PC aber in folgenden Größen (der Nutzlast):

An die Netzwerkkarte, nicht zwingend über die Leitung! Ich würde gerade wegen der schwankenden Größe nicht auf Jumbo-Frames, sondern auf TCP Segmentation Offload tippen.

Um das zu prüfen und ggf. abzuschalten, gibt es das "ethtool":

ethtool -k <netzwerkadaptername ohne /dev>

finden sich im Ergebnis die Zeilen:

tcp-segmentation-offload: on
    tx-tcp-segmentation: on

ist TCP Segmentation Offload in Senderichtung aktiv und dürfte zu obigen Beobachtungen führen. Dann mit:

sudo ethtool -K <netzwerkadaptername ohne /dev> tx off tso off

den Zauber ausschalten, und mit dem ersten Befehl oben noch mal prüfen, dass er wirklich aus ist.

 

[PeterPawn]

Wenn da tatsächlich GSO/TSO zum Einsatz kommen sollte, dann würden im Ergebnis bei der FRITZ!Box tatsächlich "normale" Pakete ankommen ... das klärt dann auch ein Mitschnitt auf einem Transit-Knoten, notfalls über einen Switch mit Mirror-Port zwischen PC und FRITZ!Box.

GSO/TSO (oder auch als LSO bekannt, ggf. i.V.m. LRO) braucht m.W. auch noch entsprechende Unterstützung im NIC-Treiber und muß (hoffentlich) ebenfalls explizit eingeschaltet werden, weil auch das oft genug I14Y-Probleme nach sich ziehen kann - daher für mich zunächst einmal die unwahrscheinlichere Erklärung, wobei eben auch das ein neuer Mitschnitt bei einer eingestellten MTU von 1500 ja sofort klären würde, ob da immer noch Pakete > 1518 Byte aus Sicht des Systems an den NIC-Treiber übergeben werden bzw. auch schon das direkte Auslesen mit "ifconfig" ja vor jeder Änderung gezeigt hätte, ob da tatsächlich eine MTU > 1500 verwendet wurde (#28 klingt für mich nach einer Änderung) ... und entsprechende Tipps findet man m.W. wesentlich häufiger im Internet als Hinweise zu den Offload-Möglichkeiten, weil letztere eben passende Hardware (und meist unter Linux dann noch proprietären Treiber-Code für die Unterstützung einer TOE auf einer NIC) voraussetzen.

Bei der Verwendung von virtuellen Maschinen kann das noch etwas anders aussehen, denn da übernimmt dann der Netzwerk-Stack des Hypervisors unter Umständen diese Segmentierungen bzw. Aggregationen im Rahmen der Emulation eines Netzwerk-Interfaces.

"jumbo frames" brauchen allerdings auch "passendes Blech", denn wenn man Switches verwendet in seinem Netzwerk, dann müssen auch diese natürlich in der Lage sein, die Pakete (Frames) in entsprechender Größe zwischenzuspeichern, gerade dann, wenn die auf Interfaces mit unterschiedlichen Modi behandelt werden müssen - das ist dann wieder bei "jumbo frames" einer der typischen Gründe für I14Y-Probleme.

 

[robert_s]

GSO/TSO (oder auch als LSO bekannt, ggf. i.V.m. LRO) braucht m.W. auch noch entsprechende Unterstützung im NIC-Treiber und muß (hoffentlich) ebenfalls explizit eingeschaltet werden,

Gibt es schon seit Jahren selbst in SoCs (z.B. Marvell Kirkwood), wird von Linux auch schon seit Jahren unterstützt und ist sowohl in Debian als auch in Ubuntu auch schon seit Jahren standardmäßig eingeschaltet. Das verwenden vermutlich schon seeehr viele Leute, ohne es zu ahnen.

Negativ bemerkt habe ich davon nur mal einen Fehler im Marvell-Treiber, der dazu führte, dass beim Offload mal ein paar Daten mit der MAC-Adresse überschrieben wurden - übel.

Positiv macht sich das bemerkbar, weil durch das Offloading in Empfangsrichtung auch erheblich weniger TCP-ACK Pakete versendet werden. So werden bei mir bei einem Download mit 200Mbps statt 4Mbps nur noch 0,8Mbps im Upstream für die TCP-ACKs benötigt - weil das Offloading bis zu 20 empfangene TCP/IP-Pakete als 1 an die CPU übergibt.

 

[PeterPawn]

Ah ja, hatte ich halt noch nicht auf einem "normalen PC". Vielleicht mangels geeigneter Hardware oder weil ich Debian und Ubuntu nicht ernsthaft verwende, sondern nur dann, wenn es wg. Freetz bei anderen eingesetzt wird und ich es somit tatsächlich in Form einiger VM auch ab und an mal starte.

Da ich dann WireShark-Mitschnitte auch immer auf dem VM-Host mache (wenn die Daten dort die physikalische Netzwerk-Karte verlassen), habe ich das auch noch nicht in einem FRITZ!Box-Mitschnitt gesehen.

Für ein Offloading-Szenario empfinde ich persönlich (anhand dessen, was ich z.B. von Windows kenne, wo dann die (effektive) TCP-Window-Size auch schon mal > 11.500 geht, wobei sogar Werte von 64K gesetzt sind als "Wunsch" seitens des PCs) die Werte für das TCP-Window dann wieder recht konservativ, weil natürlich der TCP-Stack des Betriebssystems nur so lange Daten hinterherschickt, bis das (kleinere) Window ausgereizt ist.

Im LAN sollten da jetzt auch nicht großartig irgendwelche Pakete oder die passenden ACKs verloren gehen, die ein Verkleinern des Windows "rechtfertigen" würden und der Offload-Code sollte ja auch das Window in Richtung System entsprechend an das anpassen, was er selbst puffern kann - mir fehlt da gerade die Phantasie (und das Wissen, was da im TCP-Stack alles hineinspielen könnte an zusätzlichen Variablen), warum das Fenster dann überhaupt verkleinert (bzw. immer wieder verändert) wird, wenn die Buffer im Offload-Prozessor doch immer dieselbe Größe haben müßten/sollten. Da sollte das doch aus meiner Sicht eine Einbahnstraße sein ... es wird mit jeder erfolgreichen Übertragung die Paketgröße so lange verdoppelt (die Segmentierung erfolgt später), bis die Window-Size erreicht ist. Was führt jetzt dazu, daß diese Window-Size wieder reduziert wird ... immer unter der Annahme, daß tatsächlich keine Pakete verloren gehen, also die Übertragung im LAN zu 100% "reliable" ist.

Bisher sind mir solche Offloading-Szenarien eigentlich nur dadurch aufgefallen, daß es häufig doppelte ACKs gibt und daß bei den empfangenen Paketen, die über die pcap-Schnittstelle abgefangen werden, in der Regel die "Frame check sequence" nicht mehr stimmt, wenn da auch noch LRO oder GRO eingeschaltet ist. Zumindest bei einigen NICs offensichtlich (konkret hier ein Marvell Yukon 88E8056) ... da wird wohl auf die Berechnung einer korrekten Prüfsumme für die Frames, die an das System weitergereicht werden, verzichtet (auch das Bilden der Prüfsummen kann/muß ja dann ausgelagert werden aus dem TCP-Stack des Systems).

Mehr oder weniger gestartet als "Beschleuniger" für 10G-Karten, mag es sein, daß TSO oder GSO inzwischen auch auf Embedded-Systems als Funktion im Netzwerk-Prozessor angekommen ist, weil es dort die eher schwachen Prozessoren bei der Verarbeitung von Netzwerk-Paketen entlasten kann.

Vielleicht gibt es inzwischen auch nur noch "normale" GbE-NICs, die bereits GSO/TSO unterstützen ... auf einem normalen (Linux-)PC ist es mir persönlich (aber das muß man auch nicht überbewerten, meine "Bastlerzeiten" sind seit 4-5 Jahren auch endgültig gestorben, seitdem man auch passende Systeme "von der Stange" kriegt) noch nicht untergekommen; das liegt also vermutlich wirklich an der falschen Hardware oder am falschen System (unter Windows kenne ich die Einstellungen bei den entsprechenden Treibern allerdings, würde die jedoch als "aus" im Standardfall annehmen, ohne das jetzt zu überprüfen).

(M)Ein Realtek-NIC (unter openSuSE) unterstützt dann offenbar auch kein Offloading oder das System fordert es nur in sehr begrenztem Umfang an:

[COLOR="#0000FF"]# lspci -k -s 01:00.0[/COLOR]
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
        Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
        Kernel driver in use: r8169
        Kernel modules: r8169
[COLOR="#0000FF"]# ethtool --show-offload eth0 | grep "[^i]on"[/COLOR]
rx-checksumming: on
generic-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
[COLOR="#0000FF"]# ethtool --show-offload eth0[/COLOR]
Features for eth0:
rx-checksumming: on
tx-checksumming: off
        tx-checksum-ipv4: off
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: off
        tx-scatter-gather: off
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off 
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]

GRO ist ja wesentlich restriktiver als LRO (und damit "neutraler" ggü. dem System-Stack), wenn es um das Zusammenfassen von mehreren Segmenten zu einem neuen, größeren Paket geht ... mit der Folge, daß durch GRO zusammengefaßte Pakete auch wieder neu segmentiert werden können, während bei LRO dann wichtige Informationen auf der Strecke bleiben (weil unterschiedliche Zustände in den ursprünglichen TCP-Headern "vermischt" werden können beim LRO).

@stoney0815:
Wenn das tatsächlich Offloading ist, dann sollten ja bei der FRITZ!Box wieder korrekte Pakete ankommen (bliebe der Switch mit Mirror-Port und ein dort aufgezeichneter Mitschnitt als "Beweismittel") und dann fällt das (sofern dann nicht die TOE (TCPIP Offload Engine) selbst das Problem ist, weil sich der FTP-Server im Bootloader vielleicht atypisch verhält) als denkbare Ursache wieder aus.

 

[stoney]

mtd3 und mtd4 werden problemlos übertragen

... und dann die Box neu starten und mit "eva_get_environment env" noch einmal das Environment auslesen lassen. Wenn das ohne Probleme funktioniert und mit den erwarteten Daten endet, sollte das TFFS in Ordnung sein ....

Das Auslesen von "env" ergibt den selben Inhalt wie vor dem "packen" -


Anbei die Terminal logs sowie wie Paketmitschnitte vom mtd0+3+4

ifconfig 
enp0s10   Link encap:Ethernet  Hardware Adresse 6c:f0:49:01:4f:90  
          inet Adresse:192.168.178.2  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::10d4:b2f2:f1c4:a5c3/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1460  Metrik:1
          RX-Pakete:14 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:274 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:956 (956.0 B)  TX-Bytes:35811 (35.8 KB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX-Pakete:43348 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:43348 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1 
          RX-Bytes:3216821 (3.2 MB)  TX-Bytes:3216821 (3.2 MB)

220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd3
150 Opening BINARY data connection
226 Transfer complete
sed

sudo tcpdump -s0 -i enp0s10 -w ./mtd3.pcap
tcpdump: listening on enp0s10, link-type EN10MB (Ethernet), capture size 262144 bytes
^C92 packets captured
92 packets received by filter
0 packets dropped by kernel

220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd4
150 Opening BINARY data connection
226 Transfer complete
sed

sudo tcpdump -s0 -i enp0s10 -w ./mtd4.pcap
tcpdump: listening on enp0s10, link-type EN10MB (Ethernet), capture size 262144 bytes
^C59 packets captured
59 packets received by filter
0 packets dropped by kernel

220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd0
150 Opening BINARY data connection
426 Data connection closed

ob

tcp-segmentation-offload: on
	tx-tcp-segmentation: on
	tx-tcp-ecn-segmentation: off [fixed]
	tx-tcp6-segmentation: off [fixed]

oder

tcp-segmentation-offload: off
	tx-tcp-segmentation: off
	tx-tcp-ecn-segmentation: off [fixed]
	tx-tcp6-segmentation: off [fixed]

ändert nichts

220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR mtd0
150 Opening BINARY data connection
426 Data connection closed

@stoney0815:
....... (bliebe der Switch mit Mirror-Port und ein dort aufgezeichneter Mitschnitt als "Beweismittel") ....

Lässt sich das mit einer F!B machen ?


Ich denke nicht das es an den Netzwerksettings liegt, daran wurde außer was hier angegeben ist nichts geändert - andere Distri sowie LiveSystem (Linux) sowie W7 VM - mit anderer Hardware wurden ja abenfalls schon getestet um das auschließen zu können.

 

[PeterPawn]

Entweder es findet sich jemand mit einer 6490 mit exakt derselben Loader-Version, der zuvor mal die prinzipielle Funktionsfähigkeit des Schreibens von eMMC-Partitionen bei dieser Version testet oder Du müßtest ggf. doch noch einmal versuchen, die GPT (bzw. zumindest das Backup in der entsprechenden SPI-Partition) neu zu schreiben. Mir fehlt etwas die Phantasie, warum nun bei Dir das Schreiben in die SPI-Partitionen funktioniert und bei wirklich jedem Versuch des Schreibens in eine der eMMC-Partitionen das Ganze umgehend seitens der Box abgebrochen wird.

Wobei ich auch nicht so ganz verstehe, was das mit dem TFFS-Image soll ... wenn es - wie hier - um generelle Probleme geht, würde ich erst einmal nach dem "KISS"-Prinzip die Basics wieder reparieren (dazu gehört ziemlich sicher keine "provideradditive.tar" im TFFS-Image) und da auch tatsächlich nur die Werte setzen, die relevant sind. Ein Eintrag "firstfreeaddress 0x00B20000" gehört da ziemlich sicher auch nicht dazu ... ich weiß zwar mangels Quellen auch nicht, wo das gesetzt wird und wer das dann verwendet (es taucht in den AVM-OSS-Paketen nur einmal in der "tffs.h" bei der Definition der TFFS-Minor-ID auf), aber dieser Wert ist abseits von allem, was ich bei der 6490 je in meinem Archiv gefunden habe. Das kann eigentlich schon wegen des Memory-Layouts der 6490 nicht stimmen ... höchstens dann, wenn es der Wert vom ATOM-Core ist, der da gespeichert wurde.

Den Wert von "firmware_info" würde ich komplett auslassen (im Moment wird da "141.06.24" gesetzt) oder auf "recovered=2" setzen. Damit gehen dann zwar (bei alter Firmware - ich habe immer noch keine richtige Ahnung, was da nun in welcher Partition installiert ist und nicht starten will) u.U. neue Zertifikate verloren, wenn das System "/nvram" neu initialisiert ... aber bei einer Box, die gar nicht erst starten will, wäre das erst meine zweite Sorge.

Weiterhin verstehe ich nicht, warum Du über das TFFS-Image ein Branding (firmware_version) von "lgi" setzen läßt und im Anschluß versuchst Du (auch wenn das nicht klappt, gibt es spätestens beim Starten Probleme, wobei Du die vermutlich auch nicht mehr haben wirst, denn inzwischen ist wohl keine Partition mehr startfähig), ein Image mit ausschließlich "avm" installieren zu lassen.

Woher kommt denn bei diesem TFFS-Image der Wert "other" für "provider"? Der spielt zwar hier auch noch keine wirkliche Rolle, aber irgendwie macht das Environment den Eindruck, daß es "zusammengebaut" wurde (eine konfigurierte Box hätte dann auch Einträge bei "country" und "language") und daß dabei Werte aus verschiedenen Quellen herangezogen wurden.

Zusammenfassung:

- "firstfreeaddress" raus
- "modulemem" raus
- "firmware_info" auf leer
- "firmware_version" auf "avm"
- "provider" auf leer oder ganz raus
- "linux_fs_start" auf "0" (steht im Moment auf "1" im Image)
- "provideradditive.tar" (ID 29 - 0x1D) weglassen

Dann noch einmal das TFFS-Image in beide Partitionen schreiben und die Box neu starten.

Irgendwie blicke ich bei den Mitschnitten aber auch nicht mehr durch ... hier wird (bei Schreiben für MTD3) jetzt vom PC eine TCP-MSS von 1420 gefordert. Was ist denn da nun wieder eingestellt ... die "normale" MSS bei einem per Ethernet (1500 Byte Payload) transportierten TCP-Paket wäre m.W. 1460 Byte (20 Byte IP-Header + 20 Byte TCP-Header). Warum will denn der PC hier nun 40 Byte "verschenken" bzw. was will der darin noch transportieren? Die Begrenzung der MSS seitens der Box auf 1440 Byte ist offenbar wirklich so irgendwo im Bootloader hinterlegt, das macht meine Box mit Version 4125 jedenfalls auch, wenn man den FTP-Server im Bootloader anSYNct - im "normalen Betrieb" sind das dann allerdings auch wieder 1460 Byte, wie man es bei Ethernet im LAN erwarten kann, wenn man nicht an der MTU "gedreht" hat. Die zusätzlich "unterschlagenen" 20 Byte (1440 vs. 1460) wären spätestens dann bei IPv6 wieder erklärt, wobei ich nicht glaube, daß der Bootloader auch IPv6 "spricht" - alllerdings habe ich es auch noch nie wirklich getestet, weil an dieser Stelle bei mir (im "Labor"-VLAN für den Bootloader) kein IPv6 unterstützt wird.

Komischerweise sendet dann der FTP-Client (keine Ahnung, ob das nun eines meiner EVA-Skripte ist (und damit "nc") oder irgendein anderer Client) immer noch als erstes Paket beim Schreiben von "mtd3" eines mit einer Länge von 2102 Byte (insgesamt) - das sollte (aus meiner Sicht) nach dem Abschalten aller "Beschleunigungen" nun gar nicht mehr passieren.

Die danach folgenden zwei Pakete haben spaßigerweise auch wieder nur 1474 Byte - das sind die vom PC "geforderten" 1420 Byte MSS + 20 Byte TCP-Header + 20 Byte IP-Header + 14 Byte Ethernet-Header; obwohl bis zum RWin-Size noch genug Luft wäre, um da weiter in 2 KB-Blöcken oder gar den kompletten Inhalt auf einen Schlag zu senden. Das letzte Paket hat dann noch "den Rest" von 138 Byte (84 Byte Payload + 54 Byte Header).

Nun funktioniert zwar das Speichern für "mtd3" wohl noch einwandfrei ... dabei darf man aber auch nicht übersehen, daß es sich hier beim Schreiben des TFFS nur um sehr kleine Datenmengen handelt und die ganzen Methoden des "traffic managements" beim TCP/IP hier noch gar nicht so richtig greifen (als "TCP window size" sind 8640 Byte seitens der Box und 28400 seitens des PCs aufgerufen, das ist bei beiden mehr als das TFFS-Image überhaupt hat).

Selbst wenn es also nicht ausschließlich an irgendwelchem Offloading oder "jumbo frames" gelegen haben sollte (was Du mit Deinen Kreuztests ja auszuschließen versucht hast), dann ist es trotzdem in meinen Augen nicht wirklich zielführend, das im Anschluß wieder auf irgendetwas "Beschleunigtes" umzustellen. Wenn Du das nicht getan hast (und jedes Offloading genauso ausgeschaltet ist wie event. verwendete größere MTU-Werte), verstehe ich den Mechanismus nicht, der bei einer MSS von 1420 seitens des PC dazu führt, daß der erst einmal mit 2048 Byte TCP-Payload (in Paket 35 in der mtd3.pcap) beginnt. Vielleicht findet ja jemand anderes die Ursache oder eine Erklärung dafür.

Auf alle Fälle sieht man auch beim Schreiben von "mtd0" wieder, daß die Box ihrerseits die Verbindung beendet, wenn noch lange nicht alle Daten übertragen sind. Wenn Du keine andere Möglichkeit des Mitschnitts hast (es interessiert ja weniger, was der verwendete PC nun an seinen Netzwerk-Adapter schickt als das, was am Ende auf dem Kabel bei der FRITZ!Box ankommt), dann mußt Du Dir eben eine besorgen. Ich bleibe bis zum Beweis des Gegenteils bei meiner Vermutung, daß der Bootloader (zumindest in der bei Dir vorhandenen Version) etwas fragil ist, wenn es um die korrekte Funktion des Netzwerks geht. Als Beweis sei die "MAC-Adresse" "0x00, " angeführt, die offenbar bei fehlender/falscher Adresse im Environment verwendet wird. Das ist (zumindest mit hoher Wahrscheinlichkeit) auch kein "geplantes Verhalten" und was da bei Deiner Box ansonsten noch im Argen liegen mag, kann man nur raten.

Da würde ich jetzt also eher versuchen, soviele Bedingungen wie möglich an die "gute alte Zeit" anzupassen und auf die rudimentären Funktionen zurückzuführen, wie ich es nur kann. Der TCP-Stack im Bootloader kann durchaus auch schon etwas älter sein bzw. mit irgendwelchen späteren RFC-Erweiterungen eben nicht problemlos klarkommen (z.B. mit Window-Scaling).

Ob das Schreibproblem nun am Unterschied SPI vs. eMMC liegt oder eben doch an der reinen Datenmenge, kannst Du ja auch leicht ausprobieren, indem Du eben bloß 4 KB in eine der eMMC-Partitionen versuchst zu schreiben. Solange da im Moment ohnehin nichts Sinnvolles enthalten ist, wird der Schaden auch nicht größer. Wenn sich dann herausstellen sollte, daß es tatsächlich die Flußsteuerung des TCP/IP ist, die den Bootloader nervt, muß man eben schön Paket für Paket (mit einem RWin, das gleich der MSS ist) eines nach dem anderen übertragen und quittieren lassen.

Aber auch dazu gehört eben ein Mitschnitt, der das protokolliert, was da tatsächlich über das Kabel geht und das sollten (hoffentlich) eben keine Pakete mit einer TCP-Segment-Sizevon 4260 sein, wie es der Mitschnitt für "mtd0" erneut (oder immer noch) behauptet. Dann mußt Du eben anders mitschneiden ... hier sieht man eben nicht mehr genau, welches Paket die Box nun zum FIN-Paket (No. 104 im Mitschnitt) veranlaßt hat und damit sind auch alle Versuche des "Auszählens", ob es an der (in der Box ggf. gepufferten) Datenmenge liegt und das irgendetwas mit Blockgrößen des eMMC-Speichers zu tun haben könnte (denn als NAND-Flash schreibt der auch blockorientiert und puffert erst einmal, bis genug Daten vorliegen), bereits am Beginn zum Scheitern verurteilt.

 

[stoney]

kurzer Zwischenstand

das mtd.img (ohne provideradditive.tar sowie ohne die aufgezählten Envs) lässt sich in mtd0 mtd1 mtd3 mtd4 mtd6 mtd7 mtd11 mtd12 mtd13 und mtd14 schreiben

Zu Paketmitschnitten (diese würde ich nachliefern) bin ich heute leider nicht mehr gekommen

Es muss mit der Größe der einzelnen Files also filesystem.image und kernel.image liegen, welche die Box ablehnt wie schon o.g. - allerdings komme ich heute nicht weiter zur "Analyse"

 

[stoney]

Wieder mal ein Zwischenstand

Ich habe die von die @PeterPawn vorgeschlagegen Änderungen in Bezug auf die provider und die envs umgesetzt und ein neues mtd.img erstellt.

Allerdings wird wieder die

firstfreeaddress 0x00b20000
gesetzt, wo du ja schon meintest du wüsstest nicht woher diese kommt. (Die envs kommen vom rukernel, welches ich nachdem ich die Box zur damaligen Zeit ja mit dem PushMailBug "gekillt" hatte - es ist da nichts "zusammengesammelt" - aber klar in Betracht ziehen muss man es natürlich erst mal)
(EDIT: habe eine weitere 6490 mit bootloader 12279 ausgelesen, welche ebenso diese "firstfreeaddress" hat ?!)

Habe im Anhang die env*.txt zum erstellen des images, die ausgelesenen envs nach dem flashen sowie das image selbst.

Desweiteren habe ich gestern Abend / heute Nacht mal versucht in 512KB files einzeln in die Speicher zu schreiben, was auch mit einem "226" quittiert wurde, allerdings änderte sich nichts am Verhalten der Box (ich weiß auch nicht ob ich das alles richtig umgerechnet habe - kann jmd ein Programm oder eine Website empfehlen mit welcher man schneller und einfacher von HEX auf Byte umrechnen kann)

mtd0 
 1. 0x0 - 0x80000 (0 - 512)
 2. 0x80000 - 0x100000 (512 - 1024)
 3. 0x100000 - 0x180000 (1024 - 1536)
 4. 0x180000 - 0x200000 (1536 - 2048)
 5. 0x200000 - 0x280000 (2048 - 2560)
 6. 0x280000 - 0x300000 (2560 - 3072)
 7. 0x300000 - 0x380000 (3072 - 3584)
 8. 0x380000 - 0x400000 (3584 - 4096)
 9. 0x400000 - 0x480000 (4096 - 4608)
10. 0x480000 - 0x500000 (4608 - 5120)
11. 0x500000 - 0x580000 (5120 - 5632)
12. 0x580000 - 0x600000 (5632 - 6144)
13. 0x600000 - 0x680000 (6144 - 6646)
14. 0x680000 - 0x700000 (6646 - 7168)
15. 0x700000 - 0x780000 (7164 - 7680)
16. 0x780000 - 0x800000 (7680 - 8192)
17. 0x800000 - 0x880000 (8192 - 8704)
18. 0x880000 - 0x900000 (8709 - 9216)
19. 0x900000 - 0x980000 (9216 - 9728)
20. 0x980000 - 0xA00000 (9728 - 10240)
21. 0xA00000 - 0xA80000 (10240 - 10752)
22. 0xA80000 - 0xB00000 (10752 - 11264)
23. 0xB00000 - 0xB80000 (11264 - 11776)
24. 0xB80000 - 0xC00000 (11776 - 12288)
25. 0xC00000 - 0xC80000 (12288 - 12800)
26. 0xC80000 - 0xD00000 (12800 - 13312)
27. 0xD00000 - 0xD80000 (13312 - 13824)
28. 0xD80000 - 0xE00000 (13824 - 14336)
29. 0xE00000 - 0xE80000 (14336 - 14848)


mtd1
 1. 0x4000000 - 0x4080000 (65536 - 66048) [64MB]
 2. 0x4080000 - 0x4100000 (66048 - 66560)
 3. 0x4100000 - 0x4180000 (66560 - 67072)
 4. 0x4180000 - 0x4200000 (67072 - 67584)

mtd6
 1. 0x4800000 - 0x4880000 (73728 - 74240)[72MB]
 2. 0x4880000 - 0x4900000 (74240 - 74752)
 3. 0x4900000 - 0x4980000 (74752 - 75264)
 4. 0x4980000 - 0x4A00000 (75264 - 75776)
 5. 0x4A00000 - 0x4A80000 (75776 - 76288)
 6. 0x4A80000 - 0x4B00000 (76288 - 76800)
 7. 0x4B00000 - 0x4B80000 (76800 - 77312)
 8. 0x4B80000 - 0x5000000 (77312 - 81920)
 9. 0x5000000 - 0x5080000 (81920 - 82432)
10. 0x5080000 - 0x5100000 (82432 - 82944)
11. 0x5100000 - 0x5180000 (82944 - 83456)
12. 0x5180000 - 0x5200000 (83456 - 83968)
13. 0x5200000 - 0x5280000 (83968 - 84480)
14. 0x5280000 - 0x5300000 (84480 - 84992)
15. 0x5300000 - 0x5380000 (84992 - 85504)
16. 0x5380000 - 0x5400000 (85504 - 86014)
17. 0x5400000 - 0x5480000 (86014 - 86528)
18. 0x5480000 - 0x5500000 (86528 - 87040)
19. 0x5500000 - 0x5580000 (87040 - 87552)
20. 0x5580000 - 0x5600000 (87552 - 88064)
21. 0x5600000 - 0x5680000 (88064 - 88576)
22. 0x5680000 - 0x5700000 (88576 - 89088)
23. 0x5700000 - 0x5780000 (89088 - 89600)
24. 0x5780000 - 0x5800000 (89600 - 90112)
25. 0x5800000 - 0x5880000 (90112 - 90624)
26. 0x5880000 - 0x5900000 (90624 - 91136)


mtd7
 1. 0x8800000 - 0x8880000 (139264 - 139776)
 2. 0x8880000 - 0x8900000 (139776 - 140288)
 3. 0x8900000 - 0x8980000 (140288 - 140800)
 4. 0x8980000 - 0x8A00000 (140800 - 141312)
 5. 0x8A00000 - 0x8A80000 (141312 - 141824)
 6. 0x8A80000 - 0x8B00000 (141824 - 142336)
 7. 0x8B00000 - 0x8B80000 (142336 - 142848)
 8. 0xB800000 - 0x8C00000 (142848 - 143360)

Dabei bin ich wie folgt vorgegangen (mit der FreetzVM - habe jetzt so einiges an Distris in Bezug auf die das Problem ja durchprobiert und gehe davon aus das es an der Box liegt

deb
bin
pas
quote UNSETENV mtd0
quote SETENV mtd0 0x0,0x80000
quote MEDIA FLSH
put filesystem.image.001 mtd0

Somit habe ich alle files (29 vom ARM filesystem, 4 vom ARM kernel, 26 vom ATOM filesystem und 8 vom ATO kernel) einzeln per Hand übertragen.

Ich habe ja noch die ein oder andere F!B hier liegen - werde mich, wenn es klappt da heute Abend dran setzten und mal über den MirrorPort (das erste mal) die Mitschnitte erstellen.

Danke für die Hilfe

(ein Mod/Admin könnte aber wirklich das ganze vll in ein neues Thema (6490 - Fehler beim Schreiben der FW per FTP/ADAM) verlagert werden ?)

- - - Aktualisiert - - -

So Mirror Daten liegen nun vor (von einer 3370)

Verkabelung:

linux PC (192.168.178.3) -> LAN1 3370 (192.168.178.2)
3370 LAN2 -> 6490 LAN1 (192.168.178.1 - default - was aber ja keine Rolle spielt im FTP / Bootloader)

Habe erst ein ./eva_store_tffs mtd3+4 (mit mtd.img) und dann filesystem nach mtd0 welches fehl schlug (aktive partiton lässt nicht schreiben) dann folgt filesystem mtd11 und kernel nach mtd12

Ich hoffe ich habe es wie erwartet gemacht und die Mitschnitte helfen weiter

 

[stoney]

In Bezug auf http://www.ip-phone-forum.de/showthread.php?t=293142&p=2216884&viewfull=1#post2216884


Die Mitschnitte habe ich mit einer 3370 über die AVM Boardmittel erstellt (ich fragte mal an einer anderen Stelle nach, wie ich das mit dem MirrorPortMitschnitt am besten lösen könnte / sollte, allerdings erhielt ich darauf keine Antwort, dann stieß ich auf die AVM Mittel)

Gerne würde ich gezielt alle relevanten Daten nach wie vor liefern, allerdings gelingt das nur in diesem Maße, wie mir auch Hinweise/Tipps/Arschtritte eröffnen.

Trotzdem kann ich immer noch nicht nachvollziehen, wieso (und wie) Du auf die Idee kommst, da eine Partition "in kleinen Happen" beschreiben zu wollen - wenn ich etwas davon geschrieben habe, daß Du das so konservativ wie möglich "einstellen" sollst, dann ging es immer darum, die echten - bei der FRITZ!Box ankommenden(!) - Daten irgendwie zu sehen (und das finde ich in keiner der beiden eth-Dateien aus Deinem ZIP-File).

Das mit den kleinen Happen, versuchte ich eben daraufhin das die Box zu große Daten ja "blockte", das mtd.img lies sich ja auch in die ARM und ATOM Bereiche schreiben

Ich habe zwei verschiedene Rechner mit unterschiedlicher HW für den ganzen Spaß hergenommen

Windows: 7 64bit (VM Ubutu / freetz)
Linux: Ubuntu

Die MTU Werte wurden nicht geändert bzw wieder zurück auf 1500 gesetzt

Also wie setzte ich bitte genau den Paketmitschnitt um (ggf. kaufe ich mir passende HW - wobei ein linux PC mit 2 Netzwerkkarten ja auch als Router "fungieren"?)

 

[PeterPawn]

Ja, Du kannst auch auf einem Linux-Rechner mit zwei Netzwerk-Interfaces (sogar mit nur einem, wenn die Technik komplett VLAN-fähig ist) einen solchen Mitschnitt anfertigen lassen.

Das geht notfalls sogar mit einer vom Stick gestarteten Version - man muß halt nur das Routing passend aktivieren, was bei solchen "Live-Systemen" häufig nicht der Fall ist. Wie man das genau macht, steht i.d.R. für die jeweilige Distribution irgendwo im Internet.

Ein solches System sollte dann - wenn es als Router verwendet wird (allerdings ohne NAT und CT) - auch nichts am Inhalt der "vorbeiziehenden" Pakete ändern ... also seinerseits keine weitere Verarbeitung der Daten ausführen, abseits des Transports von einem Interface zum nächsten und damit sollte so ein "eingeschliffener" (oder doch "eingeschleifter" ;-)) Monitor-Rechner auch tatsächlich die Daten so aufzeichnen, wie sie auf dem Kabel zur FRITZ!Box am Ende vorliegen.

 

[stoney]

Also ist der Paketmitschnitt, in diesem Fall mit einer F!B nicht zu realisieren, und ich müsste andere HW einsetzten (welche wäre das zB.?) oder einen "Router" über Linux mit ggf. 2 Netzwerkkarten mitschneiden (ohne NAT und CT) ?

Ich will das Gerät nicht aufgeben - da ich es, wie du ja scheinbar auch (auch wenn du viel mehr Plan davon hast als ich) nicht nachvollziehen kann, warum das so passierte - ich habe zwar noch eine andere ehemalige UM Box da, auf welcher schon die 6.63 ist - allerdings mit old/old (woher auch der Vergleichs Env mit der fristfreeaddress kommt) - ich würde es gerne mit gleicher HW und Settings dieser (unter den verschiedenen Systemen) testen, ansich kann ja nicht viel passieren, die 6.63 und 6.62 sind ja schon drauf, wenn ich jetzt in die 6.62er mtd's nochmals "inaktiv gesetzt" die 6.63 "per Hand / eva_tools" schreibe, oder ?