3Com 3CRWE554G72TU | WDS

My wireless setup, consisting of two 3CRWE554G72TU, routers is as follows:

Router 1...

IP Address: 192.168.1.1 SSID: routerU (U for upstairs) DHCP server: enabled MAC filtering: enabled

64-bit WEP: enabled Firewall: enabled WDS: enabled (with wireless mac address of 2) Router is connected to Cable modem Motorola SB5120 which gets signal from Charter Pipeline.

Router 2...

IP Address: 192.168.1.2 SSID: routerD (D for downstairs) DHCP server: DISABLED MAC filtering: enabled

64-bit WEP: enabled Firewall: enabled WDS: enabled (with wireless mac address of 1) Vonage adapter Linksys PAP2 is connected to this router.

The routers are setup at two corners of my house and this wireless setup is working very nicely.

Questions:

  1. the time shown by Router 2 is "Internet time: Thu Jan 1 00:34:43 1970". Time shown by Router 1 correct. What do I need to change so that router 2 has the correct time?

  1. router 2 shows the following in hardware status: LAN Port #4 10 Half Duplex This is for the Linksys PAP2 vonage adapter. Should it be full duplex? Does it matter? Do I need to make a change?

  2. what tools can I use the monitor the traffic between the two units?

Thanks in advance.

Reply to
John Smith
Loading thread data ...

Jeff, thanks for your response. Please see inline.

formatting link
shows that SNTP is supported, but I can't tell if it's a server or a

The client setup does not have a place where NTP server can be set up. Router 1 is displaying the correct time. I would assume that Router 2 would mirror that somehow. I'll poke around the interface some more.

Agreed. Vonage seems to need 90kbps for best connection (at least that's what the config on their web-site says). I have even used Skype and Gizmo on a laptop "wirelessly" connected to Router 2. They all work PERFECTLY.

My concern was regarding the network working at the "lowest common multiple" of the devices connected, which in this case would be 10Mbps (this is pure speculation...I would be perfectly happy to be wrong on this). I would hate for that to happen. Hence the question.

This question came about after I read through your posts (as well as Steve Berry's) in the thread entitled "Extending a wireless network". I was interested in knowing the throughput, # of collisions, and any other parameters which should be measured on a n/w!! Can you recommend? I'll try the tools you recommend and see what metrics they have to offer.

Thanks again.

Reply to
John Smith

|

formatting link

Nice description. I'm not familiar with this model wireless router. If it has an NTP/SNTP (simple network time protocol) client, then it needs to be set to point to a timer server. The data sheet at: |

formatting link
that SNTP is supported, but I can't tell if it's a server or a client. I couldn't find anything on the 3com web pile which shows the specific pages of the config. Look for NTP or SNTP client setup.

If router #1 is getting its time from an NTP server correctly, it might be possible for router #2 to point the SNTP client to router #1.

Leave it alone. The Linksys PAP2 probably default to 10baseT-HDX (half duplex). It really doesn't matter for VoIP because the data rates for voice are so slow compared to the ethernet speeds.

10baseT-HDX should give about 6Mbits/sec thruput. VoIP using G.729 codec needs about 54Kbits/sec. Unless you have over 1500 simultaneous conversations going, raising the 6Mbits/sec to something faster isn't going to do anything.

Just *BETWEEN* router 1 and router 2? Well, that's a wireless link. You could sniff the wireless traffic with a passive sniffer such as Kismet (under Linux). You could capture the wireless traffic with Ethereal. Unfortunately, both routers do not support SNMP so you can use any of the standard SNMP traffic monitors (MRTG, RRDTool, etc). What are you trying to measure? Number of connections? Traffic? Intrusion detection?

Reply to
Jeff Liebermann

Oops. That's a time server, not a timer server. See:

formatting link
formatting link

Reply to
Jeff Liebermann

In that case, the NTP time server is imbedded in the firmware somewhere. Google is your friend: |

formatting link
page 81 of the manual at: |
formatting link
mumbles somemthing about: The Router reads the correct time from NTP servers on the Internet and sets its system clock accordingly. The Daylight Savings option merely advances the system clock by one hour. It does not cause the system clock to be updated for daylight savings time automatically. I can't read the screen shots in the manual for some odd reason. It's in there somewhere. Perhaps you need to forward port 123 from the router #1 to the IP address of router #2. I'm not sure this will work but it's easy enough to try.

Skype uses the more efficient (and better sounding) iLBC codec. Again, with the huge difference in required versus available bandwidth, just about any voice codec will work. What would be more intersting is watching high bandwidth streaming video with a small read-ahead buffer from a locally attached server. You should see the effects of store and forward plus interference with that. Connect via wireless to each router and compare.

I have no idea what you mean by "lowest common multiple".

Well, access to that level of information requires either SNMP support with a proper MIB file, or command line access to the radio directly, as is available in the various Linux mutations for the WRT54G. For example, the "wl" command is what I use: |

formatting link
of detail and plenty of options to tweak. However, the 3com until may not support such low level tweaking and counters.

Thruput, you can measure with a connecting PC using any of the "bandwidth meter" programs available. I use Netstat Live: |

formatting link
It's possible that 3com has some better wireless diagnostic and optimization tools. Google didn't find any but it might be worth a call to support or a question in the appropriate newsgroups or weblog.

Reply to
Jeff Liebermann

Jeff, thanks again.

  1. forwarding port 123 did not help. I think that this is a bug in their firmware.
  2. using the tool that you recommened (Netstat), 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). 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). The number I am writing below is the modal value.

Setup 1: 25 Mbps (max 26Mbps, low variance) Setup 2: 9 Mbps (max 11Mbps, very high variance) Setup 3: 5 Mbps (max 5.5Mbps, medium variance)

I was surprised to see that Setup 1 was as fast as it was. Expecting setup 2 to be faster.

Your thoughts?

formatting link
See page 81 of the manual at:

Reply to
John Smith

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.

formatting link
formatting link
formatting link
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.

formatting link
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.

formatting link
(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.
formatting link
Nope. NTP only, no SNTP.

That's "Netstat Live" from AnalogX. Just netstat is a program supplied with the operating system that is quite different.

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.

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.

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.

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.

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.

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.

I'm thinking of dinner. I slept all Sunday afternoon. Burnout I guess.

Reply to
Jeff Liebermann

There's another possible reason for the dismal thruput performance. Most wireless clients treat the presence of other clients as interference. I find it difficult to maintain a 54Mbit/sec connection in the same room as other active wireless clients. In this benchmark arrangement, you are guaranteed to have both wireless clients simultaneously active, so the these clients may decide that there's some interference. The usual reaction is to slow down the connection to improve reliability. That may also explain the slowdown and erratic speed variations.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.