Testing A Mesh Network

Hi,

We have a mesh network consisting of Linksys WRT54GL routers that we
want to test/play around with. A big problem that we forsee is
controlling the radio signals. Ideally, we'd like to be able to
determine which router communicates with which other router even if all
the routers were in the same room.

Does anyone have any ideas on how we might accomplish this?

charlie

On 26 Jan 2007 09:13:19 -0800, "Charlie" <(E-Mail Removed)> wrote in
<(E-Mail Removed). com>:

>We have a mesh network consisting of Linksys WRT54GL routers that we
>want to test/play around with. A big problem that we forsee is
>controlling the radio signals. Ideally, we'd like to be able to
>determine which router communicates with which other router even if all
>the routers were in the same room.
>
>Does anyone have any ideas on how we might accomplish this?

What firmware in the routers?
Real mesh or WDS pseudo-mesh?
If using DD-WRT and WDS, connections can be controlled by MAC address.
See <http://www.dd-wrt.com/wiki/index.php/WDS_Linked_router_network>.
See also <http://www.linksysinfo.org/forums/showthread.php?t=47118>.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>

"Charlie" <(E-Mail Removed)> hath wroth:

>We have a mesh network consisting of Linksys WRT54GL routers that we
>want to test/play around with. A big problem that we forsee is
>controlling the radio signals. Ideally, we'd like to be able to
>determine which router communicates with which other router even if all
>the routers were in the same room.
>
>Does anyone have any ideas on how we might accomplish this?

Sure. If your WRT54GL routers have alternative firmware (i.e. DD-WRT
or OpenWRT) which support SNMP, you can dump the connecting MAC
addresses and lots of other goodies using a MIB browser or any other
SNMP tool. SNMP details and examples on request (time permitting).
<http://www.dd-wrt.com/wiki/index.php/SNMP>

For Windoze, find a copy of SNMPUTIL.EXE and run:
snmputil walk 192.168.1.1 public .1.3.
which dumps the entire MIB table. You should see (I haven't checked)
the connecting MAC addresses listed by physical port number/name.
Duh... you'll have to first enable SNMP in the router configuration.

If you want connecting IP's instead of MAC's (becuase I'm too lazy to
figure out who belongs to which MAC address), try:
snmputil walk 192.168.1.1 public .1.3.6.1.2.1.3.1.1.3.1.1

Variable = at.atTable.atEntry.atNetAddress.1.1.63.249.85.1
Value = IpAddress 63.249.85.1 <---- my router WAN IP

Variable = at.atTable.atEntry.atNetAddress.1.1.192.168.1.11
Value = IpAddress 192.168.1.11 <---- my desktop IP via CAT5

Variable = at.atTable.atEntry.atNetAddress.1.1.192.168.1.105
Value = IpAddress 192.168.1.105 <---- the neighbors laptop

Variable = at.atTable.atEntry.atNetAddress.1.1.192.168.1.111
Value = IpAddress 192.168.1.111 <---- My xv6700 PDA phone

(etc...)

End of MIB subtree.



There's also quite a bit on monitoring mesh networks on the MIT
Roofnet Mesh Network web site.
<http://pdos.csail.mit.edu/roofnet/doku.php>
<http://pdos.csail.mit.edu/roofnet/doku.php?id=publications>

This article is particularly interesting:
<http://pdos.csail.mit.edu/roofnet/doku.php?id=interesting>
Especially the parts on measuring packet delivery probability.

Incidentally, you'll find that all the routers in the same room
constitutes a worst case test as each router is guaranteed to
interfere with at least one other router. Only one packet at a time
can be successfully transmitted in a given air space.

I guess I should mention that I consider single channel mesh networks
to be an abomination. Light reading (somewhat old but still
interesting):
<http://black.csl.uiuc.edu/~prkumar/ps_files/exp.pdf>
<http://www.smallworks.com/archives/00000072.htm>
<http://www.moskaluk.com/papers.htm>
<http://wifinetnews.com/archives/003972.html>
<http://dailywireless.org/modules.php?name=News&file=comments&sid=2750&tid=1 12&mode=&order=0&thold=0>

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <(E-Mail Removed)> hath wroth:
>For Windoze, find a copy of SNMPUTIL.EXE and run:

SNMPUTIL
<http://www.wtcs.org/snmp4tpc/testing.htm>

Also grab GetIF 2.3.1 from:
<http://www.wtcs.org/snmp4tpc/getif.htm>
along with a collection of MIB's.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

John Navas <(E-Mail Removed)> hath wroth:

>Real mesh or WDS pseudo-mesh?

MESH = Make Engineers Suffer Horribly

When it gets deployed, it turns to:

MUSH = Make Users Suffer Horribly

and/or:

MASH = Make Admins Suffer Horribly


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Fri, 26 Jan 2007 10:01:59 -0800, Jeff Liebermann
<(E-Mail Removed)> wrote in
<(E-Mail Removed)>:

>John Navas <(E-Mail Removed)> hath wroth:
>
>>Real mesh or WDS pseudo-mesh?
>
>MESH = Make Engineers Suffer Horribly
>
>When it gets deployed, it turns to:
>
>MUSH = Make Users Suffer Horribly
>
>and/or:
>
>MASH = Make Admins Suffer Horribly

And here I thought it was "MEga Sustained Hell".

--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>

On Jan 26, 10:51 am, Jeff Liebermann <j...@comix.santa-cruz.ca.us>
wrote:
> "Charlie" <ctuc...@gmail.com> hath wroth:
>
> >Does anyone have any ideas on how we might accomplish this?Sure. If your WRT54GL routers have alternative firmware (i.e. DD-WRT
> or OpenWRT) which support SNMP, you can dump the connecting MAC
> addresses and lots of other goodies using a MIB browser or any other
> SNMP tool. SNMP details and examples on request (time permitting).
> <http://www.dd-wrt.com/wiki/index.php/SNMP>
>
> For Windoze, find a copy of SNMPUTIL.EXE and run:
> snmputil walk 192.168.1.1 public .1.3.
> which dumps the entire MIB table. You should see (I haven't checked)
> the connecting MAC addresses listed by physical port number/name.
> Duh... you'll have to first enable SNMP in the router configuration.
>
> If you want connecting IP's instead of MAC's (becuase I'm too lazy to
> figure out who belongs to which MAC address), try:
> snmputil walk 192.168.1.1 public .1.3.6.1.2.1.3.1.1.3.1.1
>
> Variable = at.atTable.atEntry.atNetAddress.1.1.63.249.85.1
> Value = IpAddress 63.249.85.1 <---- my router WAN IP
>
> Variable = at.atTable.atEntry.atNetAddress.1.1.192.168.1.11
> Value = IpAddress 192.168.1.11 <---- my desktop IP via CAT5
>
> Variable = at.atTable.atEntry.atNetAddress.1.1.192.168.1.105
> Value = IpAddress 192.168.1.105 <---- the neighbors laptop
>
> Variable = at.atTable.atEntry.atNetAddress.1.1.192.168.1.111
> Value = IpAddress 192.168.1.111 <---- My xv6700 PDA phone
>
> (etc...)
>
> End of MIB subtree.
>
> There's also quite a bit on monitoring mesh networks on the MIT
> Roofnet Mesh Network web site.
> <http://pdos.csail.mit.edu/roofnet/doku.php>
> <http://pdos.csail.mit.edu/roofnet/doku.php?id=publications>
>
> This article is particularly interesting:
> <http://pdos.csail.mit.edu/roofnet/doku.php?id=interesting>
> Especially the parts on measuring packet delivery probability.
>
> Incidentally, you'll find that all the routers in the same room
> constitutes a worst case test as each router is guaranteed to
> interfere with at least one other router. Only one packet at a time
> can be successfully transmitted in a given air space.
>
> I guess I should mention that I consider single channel mesh networks
> to be an abomination. Light reading (somewhat old but still
> interesting):
> <http://black.csl.uiuc.edu/~prkumar/ps_files/exp.pdf>
> <http://www.smallworks.com/archives/00000072.htm>
> <http://www.moskaluk.com/papers.htm>
> <http://wifinetnews.com/archives/003972.html>
> <http://dailywireless.org/modules.php?name=News&file=comments&sid=2750...>

Jeff, thanks a lot for the information, opinions and joke. This is
really good stuff & it's going to take me a while to digest it. Using
the MAC addresses to control the routing will be helpful.

I understand when you say putting all the routers in the same room is a
worst case scenario. I hope this doesn't sound too silly but I don't
have much experience in this area so I can't judge for myself. Would it
be possible to 'pipe' the radio signals from one router to another
using some sort of physical device so that the radio signal doesn't
escape into the ether? I am thinking something along the lines of some
sort of metal tubing that wraps around the antenna stubs. This would
keep the routers from interfering with each other when they're trying
to set up the network.

charlie

"Charlie" <(E-Mail Removed)> hath wroth:

>Jeff, thanks a lot for the information, opinions and joke.

Joke? I'm serious.... Well, mostly serious.

>This is
>really good stuff & it's going to take me a while to digest it. Using
>the MAC addresses to control the routing will be helpful.

The basics. *ALL* and I do mean *ALL* 802.11 wireless is bridging.
There's no routing involved until it this a router. Therefore, all
transmission control, encryption, authentication, and connections are
made at the Layer 2 (MAC) layer.

>Would it
>be possible to 'pipe' the radio signals from one router to another
>using some sort of physical device so that the radio signal doesn't
>escape into the ether?

Yes. There are RF proof test chambers. Most 802.11 test bench setups
use these because the measurements would be ruined from all the 2.4GHz
crud floating around in the air. You can build your own, or simply
embalm the routers in aluminum foil. Leave some aluminum mesh (window
screening) around the vent holes to prevent meltdown. This is what I
used to do in order to get sane and repeatable measurements.

>I am thinking something along the lines of some
>sort of metal tubing that wraps around the antenna stubs. This would
>keep the routers from interfering with each other when they're trying
>to set up the network.

That won't work. Pretend it's all setup and configured. You have an
unspecified number of mesh access points (or wireless routers) in the
same room. All are on the same RF channel. Only one can transmit at
a time or you have a collision. For fun, try to send some packets
through as many mesh routers as you can. You'll find that things slow
down to 1/2 through one (store and forward) hop, by 1/4 through two,
by 1/8th through three hops, and so on. However, this is under ideal
conditions, which means the end points and intermediate routers can
only hear the adjacent radios. That's not going to happen in a
closed environment. You'll get considerable interference from your
own radios, and I predict your thruput will suffer accordingly.

Grab IPerf and setup two computers for benchmarking TCP thruput. Get
some real numbers. As you add WDS or mesh repeaters in the path,
watch the thruput go down, down, down, etc.
<http://dast.nlanr.net/Projects/Iperf/>
I would be interested in seeing your results (because I'm too lazy to
do the same test myself).

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558