Bitte testen: FreeMiNT 1-17-0 und NetUSBee auf Falcon/CT6*

[Latz]

Hi,
erstmal vielen Dank an mOnO für die tatkräftige Unterstützung!
Aber es kann doch nicht sein daß ich der Einzige mit dieser Systemkonfiguration bin!
Vielleicht habe ich Euch auch mit der Menge der gewünschten Angaben abgeschreckt
Also nochmal gaaanz einfach:
Wenn jemand Falcon/CT6* + MiNT + ROMport-Netzwerkarte/Adapter benutzt,
bitte kurz schreiben
- was für'n MiNT
- welche Netzwerkkarte/ROMport-Adapter
- wie's läuft (DL-Geschwindigkeit mit Highwire oder wget).
Dank+Gruß,
Latz

[m0n0]

Hallo,

bevor Du den Debug kernel installierst, könntest Du bitte nochmal versuchen die Trace datei nicht auf eine Festplatte, sondern in auf die FreeMiNT Ramdisk  zu schreiben? Das sollte 1. weniger Geschwindigkeitseinbußen, 2. keine oder andere Interrupts / DMA Transfers auslösen.  
(also /ram bzw. U:\ram )

...Ist immer Gut zu schauen unter welchen Bedingungen etwas (nicht) passiert....

Grüße...

[Latz]

Sackl Zement, der Mann hat gute Ideen, wieso komme ich da nicht selbst
drauf?
Aber es bleibt dasselbe Verhalten. Mit

Code: [Auswählen]

curl http://www.fairlite.demon.co.uk/FreeMiNT/builds/freemint /trunk-05082011.tar.bz2 -o /tmp/testtrunk.tar.bz2 --trace /ram/error_ram.logläuft der Download durch (average speed 21500). Ich denke, das "posten" der 20MB error.log kann
ich mir daher sparen.
Ohne "--trace" ist die Geschwindigkeit (bis zum Abbruch) deutlich höher (~55000)...
und dann hört's einfach auf.
Also dann doch mit dem debug-kernel.
Gruß,
Latz

[m0n0]

Also dann doch mit dem debug-kernel.

"dann doch" ist falsch - das war ja eh nicht gecancelt

Ich würde an deiner Stelle aber auch meine Idee mit dem sniffen in angriff nehmen. Ich werde Dir demnächst ein paar shell kommandos posten mit denen Du deinen Linux Rechner als Router konfigurierst... dann musst Du unter Freemint noch das gateway einstellen.... und dann sollte jeglicher traffic über deine Linux Box gehen. Dann werden 2 Logs gesnifft - einmal mit Fehler, einmal ohne.... Ich tippe zu 70% das Mint irgenwas unternehmen will um den Netzwerk-traffic zu bremsen ( auf tcp ebene ) und das irgendwie in die hose geht ( ebenfalls auf tcp ebene...) .

[m0n0]

Hier sind die Kommandos mit denen Ich meinen Rechner als NAT Router konfigurieren kann:

Code: [Auswählen]

modprobe iptable_nat
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Bitte beachten das evt. das Netzwerkinterface (hier eth0) an Deine Gegebenheiten angepasst werden muss, die Namen deiner Netzwerkkarte kannst Du mit dem Kommando "sudo ifconfig" erfahren - das 127.0.0.1 interface bitte einfach ignorieren!

Dann muss man unter freemint noch mittels des route kommandos die Default route umschreiben.... so das nicht mehr der von DHCP zugewiesene Router verwendet wird, sondern halt die Linux box... da muss ich aber erst nochmal schauen, oder Du machst Dich anderweitig schon mal schlau....

Edit:

Ich denke ich kann jetzt sagen wie Du unter MiNT das gateway einstellst... ( ist aber nur teilweise getestet, weil ich im Moment kein Hardware-Setup habe mit dem ich das so wie bei Dir nachstellen kann - sollte aber gehen )

Code: [Auswählen]

route del default
route add default ne0 gw die_ip_deines_linux_rechners

beim zweiten kommando muss darauf geachtet werden das ne0 evt. durch den namen Deines interfaces ersetzt werden muss - falls abweichend. Die Namen der Netzwerkschnittstellen kannst Du Dir mit dem Kommando "ifconfig" ausgeben lassen.

nun probierst du unter Mint - ob Du wie bisher google.de pingen kannst - falls ja, dann scheint alles geklappt zu haben.

Danach installiert du das tool wireshark auf Deiner Linux box.
...und startest es so:

Code: [Auswählen]

sudo wireshark -k -i eth0
Evt. Netzwerkinterface bei dem Kommando anpassen, s.o....

Sobald Du nun einen ping unter FreeMiNT absetzt sollte das in Wireshark zu sehen sein.... wenn alles geht - gehts los mit sniffen.

Du machst jeweils 2 Testdurchläufe - d.h. Du startest wireshark, machst den Testlauf, speicherst den Log und beendest Wireshark wieder....

1. Durchlauf - Test mit Curl und --trace eine_Datei
2. Durchlauf - Test mit Curl und ohne Trace

Speichern des Paket-Logs:
Klick auf Symbol mit Rot umkreisten Weissem X - auf einer Netzwerkkarte, tooltip: Stop the running live capture.
Danach Im Menü "File" -> "Save As" auswählen. Und dann sinnvoll benennen und Speichern...

Die beiden Logs bitte packen und wieder hochladen. Aus Sicherheitsgründen bitte die URL per PM an mich.

Noch eine Bitte: Dafür sorgen das so wenig Netzwerkprogramme wie möglich nebenher laufen.... dann sind nicht so viele nicht benötigte Pakete in der Datei enthalten.

Grüzi

[Latz]

Uff, danke für die ausführliche Anleitung (solltest Du ins Wiki schreiben,
wenn's bei mir auch funzt)!
Ich mache mich ran und sage dann Bescheid!
Gruß,
Latz

[Latz]

Hi,
ich mach´s kurz (Ubuntu 10.04):

Code: [Auswählen]

modprobe iptable_natgibt die Meldungen:

Code: [Auswählen]

WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release.
Bei

Code: [Auswählen]

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEmusste ich "sudo" davorsetzen damit es geht.

Code: [Auswählen]

sudo echo 1 > /proc/sys/net/ipv4/ip_forwardgibt allerdings immer die Fehlermeldung:

Code: [Auswählen]

bash: /proc/sys/net/ipv4/ip_forward: Keine BerechtigungPing vom PC ins Netz geht.
Mit dem MiNT net-setup kenn´ ich mich aus
Defaultroute ist <PC-IP>, ping zum PC geht, ping zum router oder ins Netz geht nicht.
Wie kriege ich das hin?
Gruß,
Latz

[yalsi]

Hallo Allerseits

Hoffentlich ist's nicht unhöflich, wenn ich mich da einmische- ich liebe nur Linux-Probleme:

Code: [Auswählen]

modprobe iptable_natgibt die Meldungen:

Code: [Auswählen]

WARNING: All config files need .conf: /etc/modprobe.d/ndiswrapper, it will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release.


Das kannst Du ersteinmal ignorieren. Wenn Du ein

Code: [Auswählen]

sudo lsmod | less
machst, sollte iptable_nat in der Liste auftauchen.

Bei

Code: [Auswählen]

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEmusste ich "sudo" davorsetzen damit es geht.

Code: [Auswählen]

sudo echo 1 > /proc/sys/net/ipv4/ip_forwardgibt allerdings immer die Fehlermeldung:

Code: [Auswählen]

bash: /proc/sys/net/ipv4/ip_forward: Keine Berechtigung

Hmm, das ist komisch, das sollte gehen. Was zeigt denn ein

Code: [Auswählen]

ls -l /proc/sys/net/ipv4/ip_forward
Die Zeile sollte anfangen mit -rw-r--r-- 1 root root.

Du kannst übrigens für die Arbeiten auch dauerhaft eine Rootshell nutzen, wenn Du einmal

Code: [Auswählen]

sudo su -
absetzt. Dann bist Du innerhalb dieses Terminalfensters Superuser und kannst Dir die einzelnen sudos sparen. MIt exit wirst Du wieder normaler User.

Vielleicht hilfts weiter.

Gruss- Georg B. aus H.

[Latz]

Hi,

Hoffentlich ist's nicht unhöflich, wenn ich mich da einmische- ich liebe nur Linux-Probleme:

Schön, daß es Leute wie Dich gibt, Probleme mag ich nämlich gar nicht (egal auf
welchem System.
Mit

Code: [Auswählen]

sudo lsmod | lessist iptable_nat in der Liste vorhanden, Size 3543, used by 1.

Hmm, das ist komisch, das sollte gehen. Was zeigt denn ein

Code: [Auswählen]

ls -l /proc/sys/net/ipv4/ip_forward
Die Zeile sollte anfangen mit -rw-r--r-- 1 root root.

Genau so sieht es aus! Dateigröße allerdings 0 Byte.

Gruß,
Latz

[yalsi]

Schön, daß es Leute wie Dich gibt, Probleme mag ich nämlich gar nicht (egal auf
welchem System.

Ooch, komm- dann wär's doch langweilig 

Aber mal ernsthaft: Hätte ich gleich nachgedacht, statt nur blind zu zitieren, wärst Du schon weiter. Ein "sudo echo" kann nämlich niemals funktionieren. "sudo" ruft ein Programm mit Superuser-Rechten auf. "echo" ist aber kein Programm, sondern ein Befehl innerhalb der Shell (meist die bash). Du musst also entweder wie oben gesagt mit sudo su - eine Superuser-Shell aufmachen oder Du verwendest:

Code: [Auswählen]

sudo bash -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
(Anführungszeichen sind wichtig!). Ich bevorzuge persönlich eine Superuser-Shell; meist muss man ja doch mehr als ein Kommando als root absetzen... .

Die Länge von 0 Bytes ist übrigens OK. Dateien in /proc sind ja keine echten Dateien, sondern nur Schnittstellen zu Speicherstellen und Funktionen des Kernels. Da wird selten eine Grösse mit angegeben.

Gruss- Georg B. aus H.

[m0n0]

Hoffentlich ist's nicht unhöflich, wenn ich mich da einmische

Ganz im Gegenteil, besser hätte ich es definitv nicht erklären können =)

[Latz]

Hi,
@ yalsi: Vielen vielen Dank, ich hätte gleich auf Deinen Rat hören und die "superuser-shell" benutzen sollen: Jetzt funzt die Port-Weiterleitung!
Wenn ich´s recht bedenke, haben sich meine Linux-Probleme immer ziemlich leicht lösen lassen...oje, jetzt bekomme ich wohl doch Spaß daran 

@m0n0: Netzwerk-sniffing funktioniert jetzt auch einwandfrei, sauber, Danke auch Dir! Ich schreibe Dir gleich ´ne PM mit den HOCHGEHEIMEN Zugangsdaten zu den NOCH GEHEIMEREN Netzwerk-Protokollen.   
Habe da was von TCP checksum errors gelesen...

Gruß,
Latz

[m0n0]

Hallo,

ich habe mal in den sniffer log geschaut, ist in etwa so wie ich vermutet habe - muss ich aber noch genaur verstehen.

Ich denke es ist nicht falsch wenn ich schon mal sage das Pakete verloren gehen bzw. "auf der Strecke" bleiben. Normalerweise handelt TCP das Problemlos - die fehlenden Pakete werden einfach nochmal übertragen. ( deswegen heisst es ja auch "reliable connection").

Es ist natürlich schon nicht gut das Pakete verloren gehen. Und wenn das zu oft passiert (mehr als 1%) dann müsste man eigentlich schon dagegen was unternehmen - jedenfalls wenn man interesse daran hat das die Verbindung schnell ist. Aber wir nehmen zunächst hin das es passiert. Und dann sieht man das es einen "Fehler" im FreeMiNT gibt, im Umgang mit verlorenen Paketen bzw. mit dem Wiederholen des Transfers dieser Pakete.

Das kann verschiedene Gründe haben. Aber es könnte das in der Zwischenzeit, also zwischen "Paket verloren" und "Protokoll bemerkt das Paket verloren gegangen ist" schon so viele neue Pakete verschickt wurden, das dieses nicht mehr zugeordnet werden kann (nicht mehr in Paketpuffer enthalten...?).

Ich hatte mal ein ganz ähnliches Problem mit StiNG. Ich konnte es beheben in dem Ich die TCP Window Size angepasst (erhöht) habe und die MTU runtergeschraubt habe. Soweit ich weiss, kann man die TCP Window Size mit dem FreeMiNT Protokoll Treiber nicht anpassen. Aber die MTU schon

Das konnte die Probleme mit verlorenen Paketen zwar nicht gänzlich beheben ( die kleinere MTU hat aber dafür gesorgt das die Wahrscheinlichkeit das ein TCP Paket korrekt übertragen wird erhöht, ich habe weniger TCP Retransmissions gesehen), hat aber dafür gesorgt das die Verlorenen Pakete korrekt neu Übertragen werden konnten - die Verbindungsgeschwindigkeit leidet natürlich stark darunter.

Versuche doch erstmal noch folgendes:

lasse cURL mit einem Speed Limit laufen, so :
curl --limit-rate 10K http://die-grosse-datei.de -o datei.endung

und ausserdem, versuche mal mittels ifconfig die MTU runterzuschrauben. Setze doch mal auf 500 oder so... und probiere es dann nochmal.

die sourcen für ifconfig (im Freemint cvs) unterstützem Prinzipiell die MTU zu verändern... Ob das bei allen Hardware Treibern geht, das ist nicht unbedingt gesagt...

Ich werde dann nochmal den Sniff analysieren und bereinigen und dann nochmal eine Zusammenfassung der Problematik auf der MiNT liste posten, oder evt. selber eine Möglichkeit finden wie man es fixt.

Also bis denne.


Vielleicht ist auch einfach der Puffer von der Netzwekrkarte voll, und das wird nicht richtig gehandelt.... könnte auch eine simple erklärung sein, die sowas evt. hervorrufen könnte.

[Latz]

Hi,
das scheint ja so als kämen wir der Sache doch noch auf die Spur...

Mit

Code: [Auswählen]

curl --limit-rate 10K <URL> -o outfilelief der Download fast bis zum Ende durch, dann doch Transferabbruch.
Habe allerdings kein sniffing-log gemacht.
Mit MTU=500 läuft ein curl-DL mit ~37000 bit/s durch, diese
Einstellung ist allerdings für z.B. FalcAmp nicht zu gebrauchen.

Gruß,
Latz

[m0n0]

Und wie schauts aus mit MTU = 1000 =) 

Evt. doch nochmal einen Snig log machen mit einer 500er MTU... es muss immer noch relativ viele fehler geben, sonst kann eine MTU doch nicht für eine so eine gravierende Geschwindigkeitseinbuße sorgen? ... also wenn Du magst,...

[afalc060]

zwecks mtu und so ist hier vielleicht noch ne info dabei..

[Latz]

Hi,
@m0n0: Auch wenn ich nicht mag werde ich es wohl tun (dieses WE).
 
@afalc060: Danke für den Tipp, aber es funzt mit StinG ja einwandfrei
(StinG benutzte ich schon seit Modem-Zeiten mit TOS oder MagiC, da kenn'
ich mich aus). Leider sind nicht alle Einstellungen direkt auf MiNT zu
übertragen.

Gruß,
Latz

[m0n0]

so wie ich jetzt gerade eben erst geoeilt habe, gibt es gar keinen open source treiber in dem man was fixenkoennte,... :-(

geht evt. Noch im tcp stack, aber allgemein waere es sinnvoll die ethernec sourcen ins fremint cvs zu bekommen...

[m0n0]

so wie ich jetzt gerade eben erst geoeilt habe, gibt es gar keinen open source treiber in dem man was fixenkoennte,... :-(

geht evt. Noch im tcp stack, aber allgemein waere es sinnvoll die ethernec sourcen ins fremint cvs zu bekommen...

Ist nicht ganz richtig, unter http://home.arcor.de/thomas.redelberger/prj/atari/etherne/index.htm

sind sourcen zu finden.

[Latz]

Hi,
habe jetzt zwei Durchgänge gemacht, einmal mit MTU=500 und dann mit MTU=1000: Bei beiden kam der Transfer-Abbruch recht früh.
Die sniffer-logs kann ich noch nicht hochladen, irgendwie gibt´s wohl Server-Probleme. Hole das aber sobald wie möglich nach und sage dann Bescheid.

Gruß,
Latz