Is this a wireless problem or a general microsoft workgroup problem? I have an ad-hoc workgroup of 3 computers all talking TCP/IP wirelessly to a Linksys WRT54g (with no WINS server) and a WET54g connected to an IP Cam. The computers IP's are in the range 192.168.2.100 - 192.168.2.102 and run XP Pro and 2000 Pro. Under low network load all the computers can see each other and everything is fine. When the load is high (I have 6 Axis 2100 IP cams talking to the server and using about 10-12M of the 54M bandwidth), the workgroup is pretty much inaccessible. Somtimes the computers can see each other but they cannot connect, sometimes they connect just fine and sometimes the workgroup can only see its own computer. Under very high load the computers cannot even be pinged but under low load they are giving a 1ms ping time. No matter what the load conditions, all computers can see the gateway (192.168.2.254 - WRT54g) and connect to the internet fine. Am I barking up the wrong tree? Should I run the workgroup differently? Should I get rid of Linksys? I am unsure how an ad-hoc workgroup actually works out what computers are connected. I am guessing they are continually sending messages around the network. Are they TCP/UDP or something proprietry? Anyone else solved this problem? Thanks for any help. - David -- davidraw brought to you by http://www.wifi-forum.com/

On Fri, 18 Mar 2005 07:24:03 GMT, davidraw
<davidraw.1m2wbn@WiFi-Forum_dot_com> wrote:

Hard to say.

Are you using Linksys firmware or alternative firmware in the WRT54G?

You don't have 54Mbits/sec bandwidth.  That's the connection speed.
Assuming ideal conditions, you won't get more than about 25Mbits/sec
in thruput.  Typical is about 1/3 to 1/2 of the connection speed.
Dive into the status screen on the routers and radios and check your
connection speed.  My guess is that you're probably saturated at
10-12Mbits/sec.

It's failing the "windows browser election" abomination.

There you have it.  You're saturated.  You're at or above the
available bandwidth limit and are starting to drop packets.  Since the
TTL is artificially short of pings, they'll be the first to disappear.

It's a matter of signal strength and distance.  Some computahs are
closer to each other, or closer to the WRT54G that's next to the
gateway.  Check the connection speed.  It will give a good idea of the
path quality.

Linksys WRT54G are quite good.  Stay with them.  There's nothing much
wrong with the topology.  However, you're making things difficult
using ad-hoc.  There's no central controller, so some things just tend
to get lost.  There's also no bandwidth control or traffic management.

I'm not sure switching to infrastructure is going to help.  It really
depends on your traffic requirements.  If you're cameras are running a
"push server" which send frames as fast as the traffic will bear, you
will be saturated no matter how much bandwidth you give it.  I'm not
familiar with the Axis 2100 but there should be some kind of frame
rate control on the push server.  Slow it down somewhat and you'll
probably be all right with the existing arrangement.  Also, so some
measuring of bandwidth used.  Try it with a wired ethernet connection
instead of wireless and see how much bandwidth it really wants.

I suggest you look into alternative firmware for the WRT54G.  One of
the features is a crude form of bandwidth management.  You can prevent
the cameras from hogging all the bandwidth.  See the various releases
on the Sveasoft site for details.

All these wireless networks are bridges that work on ISO layer 2.
They don't know anything about TCP/UDP/ICMP/whatever that are on ISO
layer 3.

I have a customer with 3ea old Axis 210 cameras.  I can totally fill
up his outgoing DSL bandwidth (384Kbits/sec) with these cameras using
the built in push server.  I forgot exactly what I did to slow them
down, but they're now demand driven and no longer pose a problem.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:
Doesn't ad-hoc limit to 11MbpS?

---
Clarence A Dold - Hidden Valley (Lake County) CA USA  38.8,-122.5

On Fri, 18 Mar 2005 15:35:03 +0000 (UTC),
d***@XReXXuSoft.usenet.us.com wrote:

Yep.  Y'er right.  At least DLink admits it and apparently enforces
it.  However, there's really no technical reason to do so except the
someone forgot to add ad-hoc to the 802.11g specifications.
Considering the gigantic vendor battle that was required to get
802.11g-2003 ratified, it's not suprising that something got left out.
I don't do much ad-hoc networking so I don't know if there are any
client radios that will do 802.11g speeds in ad-hoc mode.  My astute
guess is that most of the "game adapters" will do 54Mbits/sec in
ad-hoc as it seems to be an advertised feature (reading between the
lines).  Dunno for sure.

I'm also suspicious about the original description.  The stock WRT54G
does not have a client mode (the WAP54G does) and therefore cannot
participate in an ad-hoc network.  However, alternative firmware
(Sveasoft) does add a client mode to the WRT54G, thus allowing it's
use in an ad-hoc network.  I've never tried this so I don't know how
it works.  In any case, he would not be getting 10-12Mbits/sec of
thruput in 802.11b mode, which is limited to about 5mbits/sec thruput
under the best of circumstances.

Wireless range help
Access Point/Router IP needed
multiple DSL lines for single infrastructure
Firewall
Airport Extreme signal reception
Netgear DG834G; extending range with ANT2405
802.11g vs. 802.11i
WPA in client-mode on Sveasoft Alchemy
WPA for WET54G
Quirky Wireless Connections in Hotel