The interfaces on the NIST NET system are *.17.1 and *.18.1. The interfaces
on the far end systems are *.17.3 and *.18.3. I have 5 boxes:
A - originating client - 192.168.17.3
B - transparent proxy (my software)
C - NIST NET - 192.168.17.1 (eth2) & 192.168.18.1 (eth0)
D - transparent proxy (my software again)
E - server - 192.168.18.3
Each box has an additional ethernet that I use to access the boxes, but that
should be irrelevant for the discussion. Hmmm, maybe I'll just plain
disconnect all those wires to make sure...
In either of two configurations - one with NIST NET running a transparent
bridge or with specific defined routes (I tested this last night with
ip_forwarding => 1), the situation is the same. Packets flow all the way
across A -> B -> C -> D -> E and back without any interference. There are
no default routes on any of the boxes...
----- Original Message -----
From: "David Morris" <[EMAIL PROTECTED]>
To: "Karl A. Nyberg" <[EMAIL PROTECTED]>
Cc: <nistnet@antd.nist.gov>
Sent: Friday, March 07, 2008 11:36 PM
Subject: Re: [nistnet] Multiple Ethernet / Bridge Issues
From your text, it sounds like *.17.3 and *.18.3 are the interfaces on
your nistnet system. If so, that is a problem. Nistnet wants the IPs of
the remote hosts whose data flow is to be tampered with.
But the 0*0 0*0 case should have caught everything. SO I suspect you need
to replace the bridge with a route like I suspect you have for eth3 which
sounds like it with tampered with delay wise. You may want your eth3 to be
the default route with explict routes between eth0&2.
Also, there is a config option for nistnet which changes how nistnet
handles first packet delay with bandwidth limitation. The default is
to delay the 2nd packet for first packet time. I have found that to
not be effective in my testing ... I changed my setting to impose
the packet A delay before sending packet A, etc. That make timing
as tested with various ping packet sizes rock solid. The second thing
I did was add drops (DRD?). Unfortunately, the drops are specified as
queue size in packets, not logical, I want the drops to relate to
queue size based on time to transmit at the specified bandwidth. I
did some fudging based on average packet size and now find my
simulated link matches a physical SDSL line pretty closely when
tested using www.numion.com/maxspeed or speedtest.net.
On Fri, 7 Mar 2008, Karl A. Nyberg wrote:
Thanks to David Morris who cleared up some issues for me in my crazy
configuration description earlier. I've got my network working
WITHOUT NIST NET running. But, for some reason, I'm not getting NIST
NET to touch ANY packets on my test network when I turn it on.
I have three working ethernets on the machine running NIST NET. Two
of them (eth0 & eth2) are bridged and passing traffic I'm trying to
test. The third (eth3) is how I get in and out of the box remotely.
When I run NIST NET as:
cnistnet -a 0.0.0.0 0.0.0.0 --bandwidth 2300
I see traffic on (I believe) eth3 getting delayed, via entries in
kern.log. tcpdump shows packets with the same sizes on eth3 that are
reported in kern.log, like:
date host kernel: [timestamp] nistnet: packet size 132 packettime
xxxx usec delay xxxxx sec.
And there's only a few of them while I'm running my test between my other
ethernets.
When I use the following (hopefully symmetrical, but I could care
less) on the routes that I'm trying to test (192.168.17.3 from one
side, 192.168.18.3 on the other), I see NOTHING in kern.log (despite
transferring a 13MB file). But tcpdump clearly shows the data being
passed back and forth and yet there's no delay in the FTP transfer
from when NIST NET is not running.
cnistnet -a 192.168.17.3 192.168.18.3 --bandwidth 2300
cnistnet -a 192.168.18.3 192.168.17.3 --bandwidth 2300
20:58:56.800900 IP (tos 0x0, ttl 64, id 36255, offset 0, flags [DF],
proto: TCP (6), length: 72) seventeendotthree.59118 >
eighteendotthree.ftp: SWE, cksum 0xb8b4 (correct),
1372459339:1372459339(0) win 65535 <mss
1460,opt-20:4000,opt-20:1070ff112d9e47118656000000000280,wscale 8,eol>
20:58:56.801608 IP (tos 0x0, ttl 64, id 36256, offset 0, flags [DF],
proto: TCP (6), length: 72) eighteendotthree.ftp >
seventeendotthree.59118: SE, cksum 0xa56c (correct),
1179584509:1179584509(0) ack 1372459340 win 65535 <mss
1460,opt-20:4000,opt-20:1070ff41632b4830477d471186560280,wscale 8,eol>
20:58:56.801680 IP (tos 0x0, ttl 64, id 36257, offset 0, flags [DF],
proto: TCP (6), length: 52) eighteendotthree.ftp >
seventeendotthree.59118: ., cksum 0xf350 (correct), ack 1 win 54931
<opt-20:,timestamp 1211123581 1192330838>
20:58:56.801995 IP (tos 0x0, ttl 64, id 36256, offset 0, flags [DF],
proto: TCP (6), length: 52) seventeendotthree.59118 >
eighteendotthree.ftp: ., cksum 0xf350 (correct), ack 1 win 54931
<opt-20:,timestamp 1192330838 1211123581>
20:58:56.805769 IP (tos 0x2,ECT(0), ttl 64, id 36258, offset 0, flags
[DF], proto: TCP (6), length: 72) eighteendotthree.ftp >
seventeendotthree.59118: P, cksum 0x7aa0 (correct), 1:21(20) ack 1 win
54931 <opt-20:,timestamp 1211131394 1192330838>
Is my use of a bridge causing difficulties for NIST NET? I believe I
have been able to configure things with 192.168.17 on one ethernet,
192.168.18 on the other ethernet, set ip_forwarding and create a
default route using one of the interfaces as well, but I didn't get
any delay there either.
_______________________________________________
nistnet mailing list
nistnet@antd.nist.gov
http://www-x.antd.nist.gov/mailman/listinfo/nistnet
