My goal is a _really slow_ connection
From: Helmut Giese (hgiese_at_ratiosoft.com)
Date: 12/03/04
- Next message: /\\/\\ichau Smoczyk: "libnvidia-tls.so.1 - where?"
- Previous message: Knut Godskalk Sætre: "Re: SuSE 9.2 and ndiswrapper-0.10: Why does it freeze during booting, and how do I get around it?"
- Next in thread: Tim Kynerd: "Re: My goal is a _really slow_ connection"
- Reply: Tim Kynerd: "Re: My goal is a _really slow_ connection"
- Reply: kalev-: "Re: My goal is a _really slow_ connection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 03 Dec 2004 09:51:01 GMT
Hello out there,
I have an extremely slow connection between 2 machines (a research
project involving powerline modems over 10.000 Volt lines). The
connection itself is reliable - data which is sent out eventually
arrives at the other machine. Both boxes are running Suse Linux 9.0.
We try to transfer a small file (187 byte) from server 172.16.3.1 via
tftp 172.16.3.1:minihttp.tcl
This doesn't work, due to timing problems: The server starts to
repeat, and the IP level on the client gives up too early (at least
that's what I suppose).
I have 2 main questions:
1) How do I keep the server (/usr/sbin/in.tftpd) from repeating too
early (or repeating at all)? I tried the -T option with values like
6000000 (6 minutes) - but then it didn't even start. Am I missing
something here?
1a) tftpd has an option -v, saying it will log information. But where?
I didn't see anything in /var/log.
2) Is there an option / a command to make the IP level on the client
wait sufficiently long?
Below is tcpdump's result on the client (172.17.1.2). I numbered the
lines since my news reader will surely break them up. If someone is
familiar with tcpdump's output: Please explain, what's going on.
- Line 1 evidently is the initial request 'send file minihttp.tcl'
- To me it seems, that in steps 2 thru 4 the requested transfer takes
place. (What does 'udp 4 (DF)' mean ?)
- In line 5 the server starts anew (as I would interprete it) - ok,
could be the server hit it's timeout (see above).
- Now what do lines 7 & 8 signify?
- The whole story repeats 5 times and that's it. BTW, this was a
succesful transfer - in the end, the file existed on the client.
1) 21:54:42.061902 172.17.1.2.filenet-tms > 172.16.3.1.tftp: 21 RRQ
"minihttp.tcl" (DF)
2) 21:54:52.882742 172.16.3.1 > 172.17.1.2: udp (frag 105:71@128)
3) 21:55:04.469749 172.16.3.1.filenet-tms > 172.17.1.2.filenet-tms:
udp 191 (frag 105:128@0+)
4) 21:55:04.470402 172.17.1.2.filenet-tms > 172.16.3.1.filenet-tms:
udp 4 (DF)
5) 21:55:16.910742 172.16.3.1 > 172.17.1.2: udp (frag 106:71@128)
6) 21:55:28.014755 172.16.3.1.filenet-tms > 172.17.1.2.filenet-tms:
udp 191 (frag 106:128@0+)
7) 21:55:28.015311 172.17.1.2 > 172.16.3.1: icmp (frag 4167:2@128)
[tos 0xc0]
8) 21:55:28.015319 172.17.1.2 > 172.16.3.1: icmp: 172.17.1.2 udp port
filenet-tms unreachable (frag 4167:128@0+) [tos 0xc0]
[lines 5 - 8 repeated several times]
17) 21:56:34.261744 172.16.3.1 > 172.17.1.2: udp (frag 109:71@128)
18) 21:56:49.339758 172.16.3.1.filenet-tms > 172.17.1.2.filenet-tms:
udp 191 (frag 109:128@0+)
19) 21:56:49.340314 172.17.1.2 > 172.16.3.1: icmp (frag 4170:2@128)
[tos 0xc0]
20) 21:56:49.340322 172.17.1.2 > 172.16.3.1: icmp: 172.17.1.2 udp port
filenet-tms unreachable (frag 4170:128@0+) [tos 0xc0]
Thanks for any help and best regards
Helmut Giese
- Next message: /\\/\\ichau Smoczyk: "libnvidia-tls.so.1 - where?"
- Previous message: Knut Godskalk Sætre: "Re: SuSE 9.2 and ndiswrapper-0.10: Why does it freeze during booting, and how do I get around it?"
- Next in thread: Tim Kynerd: "Re: My goal is a _really slow_ connection"
- Reply: Tim Kynerd: "Re: My goal is a _really slow_ connection"
- Reply: kalev-: "Re: My goal is a _really slow_ connection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
