On Fri, 23 Sep 2005 14:41:17 -0400, "John Smith"
<jsmith1970@charter.net> wrote:
>1. forwarding port 123 did not help. I think that this is a bug in their
>firmware.
I agree. It looks like a bug. My guess is port 123 will not go
through the main router. It also appears that the box only support
SNTP and not the real NTP.
If you feel ambitious (or masochistic), you might try installing a hub
(not a switch) between the router #1 and the DSL or cable modem. Then
connect a PC running Ethereal and sniff the traffic. Filter for NTP
or SNTP protocol packets. Unfortunately, it's not so easy to do with
the WDS link as you will need to sniff the wireless traffic. That can
be done with Linux and the Linux version of Ethereal. If you want to
try it, almost any one of the "Live CD" distributions will do the
trick.
SNTP (RFC2030) uses port 123 and should be available at all the NIST
listed time servers.
http://amo.net/AtomicTimeZone/help/ATZ_FAQ.htm http://tf.nist.gov/service/time-servers.html http://www.faqs.org/rfcs/rfc2030.html
It might be interesting to find a Windoze SNTP client and try it at
various locations in the WDS system.
The official NIST Time program supports both NTP on port 13 and SNTP
on port 123.
http://tf.nist.gov/service/its.htm ftp://time.nist.gov/pub/daytime/nistime-32bit.exe
It's a bit tricky and the "help" is a bit misleading. On the "select
server" page, it says to check the boxes after the time server names
to switch to "port 123 (NTP)". It should say "port 123 (SNTP)".
This is always fun but doesn't prove anything:
$ telnet time.nist.gov 13
53639 05-09-26 02:20:28 50 0 0 722.4 UTC(NIST) *
Connection to host lost.
Of course, you could bypass the problem by setting up your own SNTP
time server if you can figure out where 3com buried the time server
selection.
http://amo.net/AtomicTimeZone/ (just an example)
My guess(tm) is that they hard coded server name into the firmware.
If you can find and download a firmware image for the router, try
running "strings" on the image and see if it finds anything with
"time" or "sntp" buried in it. My guess it will be pool.ntp.org.
http://www.pool.ntp.org
Oops. Nope. NTP only, no SNTP.
>2. using the tool that you recommened (Netstat),
That's "Netstat Live" from AnalogX. Just netstat is a program
supplied with the operating system that is quite different.
>I did the following tests.
>
>Machine 1: Dell laptop with Intel PRO/Wireless 2200BG wireless
>Machine 2: Dell desktop with D-Link G520 (used D-Link drivers and windows
>wireless config)
>Router 1: 3COM 3CRWE554G72TU (with DHCP, 64bit WEP, firewall, MAC filtering,
>WDS, WAN)
>Router 2: 3COM 3CRWE554G72TU (no DHCP, 64bit WEP, firewall, MAC filtering,
>WDS)
>
>Activity: copy a 1GB VOB file from Machine 2 to Machine 1
>
>Setup 1:
> Machine 1 ---(wired)--- Router1 ---(wireless)--- Machine 2 (all three
>in same room)
>Setup 2:
> Machine 1 ---(wireless)--- Router1 ---(wireless)--- Machine 2 (all
>three in same room)
>Setup 3:
> Machine 1 ---(wireless)--- Router2 ---(wireless)---
>Router1 ---(wireless)--- Machine 2 (Machine 1 and Router 2 in one room,
>Machine 2 and Router 1 in same room, rooms about 30ft apart)
>
>Monitoring the following - Netstat "Incoming" Current, Average, Max in
>Kbps (bits not bytes).
On the contrary. If you have a perfectly error free connection, with
no interference, collisions, or resends, the current, average, and
maximum speeds will all be identical for large file transfers. (Be
sure to reset the count AFTER starting the file transfer to avoid
starup delays from wrecking the average value). However, if you have
any manner of retries and collisions happening, the counts will start
to diverge.
>I think that average and max are not good metrics in
>this case. What might be more useful may be the mode (most frequently seen
>speed).
That's cheating. If you have interference or collisions, you'll see
burst of impressive speed interspersed with dismal sloth. Any
variations in thruput speed is an indication of a problem.
Unfortunately, the source of the problem is buried in the MAC layer
diagnostics and not accessible in the 3com router.
>The number I am writing below is the modal value.
>
>Setup 1: 25 Mbps (max 26Mbps, low variance).
That's about full speed for 54Mbit/sec connection. There's only one
access point and one wireless client in the room so there's little
possibilities of collisions. The access point handles the flow
control so there's minimal collisions.
>Setup 2: 9 Mbps (max 11Mbps, very high variance)
That's wireless client to client with no WDS. That should be almost
exactly half of of the above 25Mbits/sec thruput. The loss is
probably due to interference between the two wireless clients, which
cannot legally be operated synchronously and only one transmitter may
be on at a time. You might wanna try to enable CTS/RTS flow control
in the 3com router. That will help with some of the collisions. The
thruput will be somewhat reduced but so will the collisions.
>Setup 3: 5 Mbps (max 5.5Mbps, medium variance)
That's a WDS line between two isolated routers with wireless at both
ends for a total of 3 wireless hops. That should be 1/4th of the
maximum thruput of 25Mbits/sec or about 6 mbits/sec. That's close to
what you're getting. Again, only one transmitter in the entire system
can be on at the same time. To send a packet from one end to the
other, you need to belch 3 packets to get there. The first has no
delay, but the 2nd and 3rd need to wait for the previous 1st and 2nd
to be finished xmitting.
Are you getting a good picture of why I think WDS, repeaters, range
extenders, and store and forward are more suitable for desperation
than common deployments?
Incidentally, there are those that proclaim that speed will be reduced
linearly rather than exponentially. This is true if the end points
are isolated from each other and cannot hear each other. However,
30ft through one wall is insufficient isolation and exponential is a
better model.
>I was surprised to see that Setup 1 was as fast as it was. Expecting setup 2
>to be faster.
Nope. Setup 1 was one wireless link. Setup 2 was two wireless links.
In setup 2, only one xmitter can be on at a time, so each client has
to wait for the other client to shut up. Therefore, half the speed
plus some mutual interference.
>Your thoughts?
I'm thinking of dinner. I slept all Sunday afternoon. Burnout I
guess.
--
Jeff Liebermann
jeffl@comix.santa-cruz.ca.us
150 Felker St #D
http://www.LearnByDestroying.com
Santa Cruz CA 95060
http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
3Com 3CRWE554G72TU | WDS 
Linear Mode
