MADWIFI

Have you tried turning on 4 address mode (i.e. wds)?
Try: 
iwpriv wlan0 wds 1
You will also need to do the same at the AP end.

Brett

> -----Original Message-----
> From: Dmitry Katsubo [mailto:dma_k@...]
> Sent: Thursday, 27 November 2008 6:31 PM
> To: madwifi-users@...
> Subject: [Madwifi-users] Setting up a bridge for wifi interface
> 
> Dear MadWifi users!
> 
> I try to setup a bridged interface between eth1 and wlan0. I know,
that
> maybe it's general setup problem, but I was not able to solve it
myself.
> 
> The problem is that after joining two interface into a bridge, DHCP
> packets do not go from wlan0 to eth1 interface, so the WiFi client
> cannot join the network. My general configuration is:
> 
> <WLAN ADSL router, DHCP server>
>      |
>      v
>   (eth1)
> <Linux box, Debian>
>   (wlan0)
>      |
>      v
> <Windows box>
> 
> I have setup the bridge as usual:
> 
> === cat /etc/network/interfaces: ===
> auto wlan0
> iface wlan0 inet manual
> 	pre-up iwpriv wlan0 authmode 2
> 	wireless-essid myserver
> 	wireless-key s:somepassword
> 
> auto br0
> iface br0 inet dhcp
> 	bridge_ports eth1 wlan0
> === end ===
> 
> The Access Point interface is autocreated:
> 
> === cat /etc/modprobe.d/madwifi: ===
> options ath_pci autocreate=ap
> blacklist ath5k
> === end ===
> 
> I have enabled ip forwarding in /etc/sysctl.conf:
> 
> === start ===
> /proc/sys/net# cat ./ipv4/ip_forward ./ipv4/conf/default/forwarding
> ./ipv4/conf/br0/forwarding ./ipv4/conf/eth1/forwarding
> ./ipv4/conf/wlan0/forwarding
> 1
> 1
> 1
> 1
> 1
> === end ===
> 
> The bridge br0 gets the IP address automatically during the startup
with
> no problems. I can also get the IP address for interface eth1:
> 
> === start ===
> # dhclient eth1
> wifi0: unknown hardware address type 801
> wifi0: unknown hardware address type 801
> Listening on LPF/eth1/00:01:80:66:5c:68
> Sending on   LPF/eth1/00:01:80:66:5c:68
> Sending on   Socket/fallback
> DHCPREQUEST on eth1 to 255.255.255.255 port 67
> DHCPACK from 192.168.1.1
> bound to 192.168.1.11 -- renewal in 272309 seconds.
> 
> # tcpdump -i eth1 -n | egrep 'BOOTP/DHCP|ICMP'
> 12:23:04.003282 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request
> from 00:01:80:66:5c:68, length 300
> 12:23:04.008202 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP,
Reply,
> length 300
> === end ===
> 
> Now I want to get the IP address for wlan0:
> 
> === start ===
> # dhclient wlan0
> wifi0: unknown hardware address type 801
> wifi0: unknown hardware address type 801
> Listening on LPF/wlan0/06:c0:a8:d2:8b:ed
> Sending on   LPF/wlan0/06:c0:a8:d2:8b:ed
> Sending on   Socket/fallback
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
> === end ===
> 
> and it fails. ping also does not work:
> 
> === start ===
> centurion:/proc/sys/net# ping -I wlan0 mail.ru
> PING mail.ru (194.67.57.126) from 192.168.1.10 wlan0: 56(84) bytes of
> data.
> >From centurion.local (192.168.1.10) icmp_seq=1 Destination Host
> Unreachable
> >From centurion.local (192.168.1.10) icmp_seq=2 Destination Host
> Unreachable
> >From centurion.local (192.168.1.10) icmp_seq=3 Destination Host
> Unreachable
> === end ===
> 
> I have run the same steps with setting both interfaces into
promiscuous
> mode:
> 
> === start ===
> # ifconfig eth1 up promisc
> # ifconfig wlan0 up promisc
> # dhclient wlan0
> === end ===
> 
> no positive result. I also tried to load the module with
> "autocreate=none" and then perform all steps to create the bridge and
> tune the wlan0 interface from the command line -- no success.
> 
> I someone can help me, that will be very appreciated!
> 
> Thank you a lot in advance!
> 
> === additional information ===
> # iwconfig wlan0
> wlan0     IEEE 802.11g  ESSID:"centurion"  Nickname:""
>           Mode:Master  Frequency:2.437 GHz  Access Point:
> 00:C0:A8:D2:8B:ED
>           Bit Rate:0 kb/s   Tx-Power:17 dBm   Sensitivity=1/1
>           Retry:off   RTS thr:off   Fragment thr:off
>           Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XX   Security
> mode:restricted
>           Power Management:off
>           Link Quality=0/70  Signal level=-96 dBm  Noise level=-96 dBm
>           Rx invalid nwid:4336  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> # ifconfig -a
> br0       Link encap:Ethernet  HWaddr 00:01:80:66:5c:68
>           inet addr:192.168.1.10  Bcast:192.168.1.255
Mask:255.255.255.0
>           inet6 addr: fe80::201:80ff:fe66:5c68/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:1763604 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:2207324 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:129239429 (123.2 MiB)  TX bytes:2147801672 (2.0
GiB)
> 
> wlan0     Link encap:Ethernet  HWaddr 06:c0:a8:d2:8b:ed
>           inet6 addr: fe80::4c0:a8ff:fed2:8bed/64 Scope:Link
>           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:2101 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 B)  TX bytes:260772 (254.6 KiB)
> 
> eth1      Link encap:Ethernet  HWaddr 00:01:80:66:5c:68
>           inet6 addr: fe80::201:80ff:fe66:5c68/64 Scope:Link
>           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>           RX packets:1763621 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:2235459 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           RX bytes:156157312 (148.9 MiB)  TX bytes:2149673495 (2.0
GiB)
>           Memory:fdde0000-fde00000
> 
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:275409 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:275409 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:17237491 (16.4 MiB)  TX bytes:17237491 (16.4 MiB)
> 
> wifi0     Link encap:UNSPEC  HWaddr
00-C0-A8-D2-8B-ED-65-74-00-00-00-00-
> 00-00-00-00
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:298 errors:0 dropped:0 overruns:0 frame:64
>           TX packets:2280 errors:24 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:280
>           RX bytes:19519 (19.0 KiB)  TX bytes:344458 (336.3 KiB)
>           Interrupt:16
> 
> # ip route ls
> 192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.10
> default via 192.168.1.1 dev br0
> 
> # brctl show
> bridge name	bridge id		STP enabled	interfaces
> br0		8000.000180665c68	no		eth1
> 							wlan0
> === end ===
> 
> 
> 
> 
> 
>
------------------------------------------------------------------------
-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Madwifi-users mailing list
> Madwifi-users@...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users
> 
> 
>

I had a similar problem although not completely identical.

I tried the madwifi driver with some of those 600mW Engenius Atheros chip
based cards. When I had more than one AP setup on a single card, once I
associated a client for the first time to an AP, the client would not
associate to any of the other VAP's. At first I thought it was only the base
AP I created that it worked with. However I found as soon as I destroyed and
set everything back up and associated to the second AP it worked, but no
longer would associate with the first one I tried previously.

I thought it must have been some sort of caching of MAC addresses or
something on the client side that was causing it to not associate with a
different VAP. I'm still not sure if this was the case, I ended up just
setting up a standalone AP and putting the suse router away for a rainy day.

Gavin.


----- Original Message -----
From: "Derek C" <derekmadwifi@...>
To: "madwifi-users" <madwifi-users@...>
Sent: Thursday, November 27, 2008 10:22 PM
Subject: [Madwifi-users] Two APs [VAPs] and can't associate


> Hi all,
>
> I'm using madwifi (stable) thats bundled with openwrt kamikaze 8.09 RC1
> (iwconfig --version says "version 29").
>
> If I create one AP everything works fine.
>
> If I create one STA and one AP (both on the single wifi0 card) everything
> works fine.
>
> If I create two APs (again both on the single wifi0 card) I might be able
> to associate to either AP once but after this I can never associate to
> either AP again - the client computer just tries and tries to associate
> and then gives up.
>
> Strangely I can't find anyone else discussing this type of issue.
>
> Has anyone else come across this?
>
> thanks,
>
> Derek
>
>
> --
> Derek C
> In Ireland
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Madwifi-users mailing list
> Madwifi-users@...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users

Derek C wrote:
> -----Original Message-----
> From: Derek C [mailto:derekmadwifi@...]
> Sent: Thursday, 27 November 2008 7:23 PM
> To: madwifi-users
> Subject: [Madwifi-users] Two APs [VAPs] and can't associate
> 
> Hi all,
> 
> I'm using madwifi (stable) thats bundled with openwrt kamikaze 8.09
RC1
> (iwconfig --version says "version 29").
> 
> If I create one AP everything works fine.
> 
> If I create one STA and one AP (both on the single wifi0 card)
everything
> works fine.
> 
> If I create two APs (again both on the single wifi0 card) I might be
able
> to associate to either AP once but after this I can never associate to
> either AP again - the client computer just tries and tries to
associate
> and then gives up.
> 
> Strangely I can't find anyone else discussing this type of issue.
> 
> Has anyone else come across this?
> 
> thanks,
> 
> Derek

I had this problem too.
I discovered that you need to make sure that the AP VAP's each have
unique MAC addresses (i.e. do not specify the "-bssid" option when
creating the VAP).
When the VAPs do share the same MAC address, when a STA authenticates,
madwifi looks at the destination MAC address and assumes that the frame
is destined for that last VAP in the list. So making sure that VAP's
have unique MAC addresses ensures that doesn't happen.

Brett

Hi Brett,

I'll try this out today and see if it fixes it

thanks very much

Derek


On Thu, November 27, 2008 11:56 pm, Brett Wright wrote:
> Derek C wrote:
>
>> -----Original Message-----
>> From: Derek C [mailto:derekmadwifi@...]
>> Sent: Thursday, 27 November 2008 7:23 PM
>> To: madwifi-users
>> Subject: [Madwifi-users] Two APs [VAPs] and can't associate
>>
>>
>> Hi all,
>>
>>
>> I'm using madwifi (stable) thats bundled with openwrt kamikaze 8.09
>>
> RC1
>
>> (iwconfig --version says "version 29").
>>
>>
>> If I create one AP everything works fine.
>>
>>
>> If I create one STA and one AP (both on the single wifi0 card)
>>
> everything
>> works fine.
>>
>> If I create two APs (again both on the single wifi0 card) I might be
>>
> able
>> to associate to either AP once but after this I can never associate to
>> either AP again - the client computer just tries and tries to
> associate
>> and then gives up.
>>
>> Strangely I can't find anyone else discussing this type of issue.
>>
>>
>> Has anyone else come across this?
>>
>>
>> thanks,
>>
>> Derek
>>
>
> I had this problem too.
> I discovered that you need to make sure that the AP VAP's each have
> unique MAC addresses (i.e. do not specify the "-bssid" option when creating
> the VAP). When the VAPs do share the same MAC address, when a STA
> authenticates, madwifi looks at the destination MAC address and assumes
> that the frame is destined for that last VAP in the list. So making sure
> that VAP's have unique MAC addresses ensures that doesn't happen.
>
> Brett
>
>
>


-- 
Derek C
In Ireland

Hi Brett,

Right you are it seems!

I've made the VAPs have different BSSIDs via the madwifi
/etc/config/wireless "uniquebssid     1" directive.

thanks very much - this was bugging me for ages


Derek



On Thu, November 27, 2008 11:56 pm, Brett Wright wrote:
> Derek C wrote:
>
>> -----Original Message-----
>> From: Derek C [mailto:derekmadwifi@...]
>> Sent: Thursday, 27 November 2008 7:23 PM
>> To: madwifi-users
>> Subject: [Madwifi-users] Two APs [VAPs] and can't associate
>>
>>
>> Hi all,
>>
>>
>> I'm using madwifi (stable) thats bundled with openwrt kamikaze 8.09
>>
> RC1
>
>> (iwconfig --version says "version 29").
>>
>>
>> If I create one AP everything works fine.
>>
>>
>> If I create one STA and one AP (both on the single wifi0 card)
>>
> everything
>> works fine.
>>
>> If I create two APs (again both on the single wifi0 card) I might be
>>
> able
>> to associate to either AP once but after this I can never associate to
>> either AP again - the client computer just tries and tries to
> associate
>> and then gives up.
>>
>> Strangely I can't find anyone else discussing this type of issue.
>>
>>
>> Has anyone else come across this?
>>
>>
>> thanks,
>>
>> Derek
>>
>
> I had this problem too.
> I discovered that you need to make sure that the AP VAP's each have
> unique MAC addresses (i.e. do not specify the "-bssid" option when creating
> the VAP). When the VAPs do share the same MAC address, when a STA
> authenticates, madwifi looks at the destination MAC address and assumes
> that the frame is destined for that last VAP in the list. So making sure
> that VAP's have unique MAC addresses ensures that doesn't happen.
>
> Brett
>
>
>


-- 
Derek C
In Ireland

Likewise will try it later today/tomorrow. Sounds like the solution.

Cheers.

----- Original Message -----
From: "Derek C" <derekmadwifi@...>
To: "Brett Wright" <Brett.Wright@...>
Cc: "madwifi-users" <madwifi-users@...>
Sent: Saturday, November 29, 2008 12:02 PM
Subject: Re: [Madwifi-users] Two APs [VAPs] and can't associate


> Hi Brett,
>
> Right you are it seems!
>
> I've made the VAPs have different BSSIDs via the madwifi
> /etc/config/wireless "uniquebssid     1" directive.
>
> thanks very much - this was bugging me for ages
>
>
> Derek
>
>
>
> On Thu, November 27, 2008 11:56 pm, Brett Wright wrote:
> > Derek C wrote:
> >
> >> -----Original Message-----
> >> From: Derek C [mailto:derekmadwifi@...]
> >> Sent: Thursday, 27 November 2008 7:23 PM
> >> To: madwifi-users
> >> Subject: [Madwifi-users] Two APs [VAPs] and can't associate
> >>
> >>
> >> Hi all,
> >>
> >>
> >> I'm using madwifi (stable) thats bundled with openwrt kamikaze 8.09
> >>
> > RC1
> >
> >> (iwconfig --version says "version 29").
> >>
> >>
> >> If I create one AP everything works fine.
> >>
> >>
> >> If I create one STA and one AP (both on the single wifi0 card)
> >>
> > everything
> >> works fine.
> >>
> >> If I create two APs (again both on the single wifi0 card) I might be
> >>
> > able
> >> to associate to either AP once but after this I can never associate to
> >> either AP again - the client computer just tries and tries to
> > associate
> >> and then gives up.
> >>
> >> Strangely I can't find anyone else discussing this type of issue.
> >>
> >>
> >> Has anyone else come across this?
> >>
> >>
> >> thanks,
> >>
> >> Derek
> >>
> >
> > I had this problem too.
> > I discovered that you need to make sure that the AP VAP's each have
> > unique MAC addresses (i.e. do not specify the "-bssid" option when
creating
> > the VAP). When the VAPs do share the same MAC address, when a STA
> > authenticates, madwifi looks at the destination MAC address and assumes
> > that the frame is destined for that last VAP in the list. So making sure
> > that VAP's have unique MAC addresses ensures that doesn't happen.
> >
> > Brett
> >
> >
> >
>
>
> --
> Derek C
> In Ireland
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Madwifi-users mailing list
> Madwifi-users@...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users

On Wed, 2008-11-26 at 21:56 +0100, ConiKost@... wrote:
> Hello 
> Maybe here is somebody who can help me?
> I bought a miniPCI b/g atheros card and build it in. Compils 0.9.4 drivers.
> After setting this card into master mode, the whole system hard crashes after 5-15 minutes. 
> There is no error reported to dmesg oder messages. is there possible to get more debug infos why the card freezes my whole system? Is there anything i could do?

I'm almost sure it's related to ticket 1903:
https://madwifi-project.org/ticket/1903

The workaround is to use a uniprocessor kernel.  There is no known fix
for version 0.9.4.  The issue is fixed in the trunk, but there is no
single fix, and the changes are too extensive to be backported.

-- 
Regards,
Pavel Roskin

> I'm almost sure it's related to ticket 1903:
> https://madwifi-project.org/ticket/1903
> 
> The workaround is to use a uniprocessor kernel.  There is no known fix
> for version 0.9.4.  The issue is fixed in the trunk, but there is no
> single fix, and the changes are too extensive to be backported.
> 
> -- 
> Regards,
> Pavel Roskin

Hi!
What do you mean by uniprocess kernel? A kernel without smp support? My
kernel is without smp support build. I also tried lastest svn now, but it
didn't help. Same freeze and hard reboot needed.
Still nothing via dmesg or /var/log/messages.
I am also not sure how ticket 1903 could help me, as i don't see a real solution for me?

On Wed, 2008-11-26 at 23:21 +0100, ConiKost@... wrote:

> What do you mean by uniprocess kernel? A kernel without smp support?

Yes.

>  My
> kernel is without smp support build. I also tried lastest svn now, but it
> didn't help.

Then it's something else.

>  Same freeze and hard reboot needed.
> Still nothing via dmesg or /var/log/messages.

/var/log/messages and dmesg rely on userspace working.  I suggest that
you check other ways for diagnosing kernel problems described in
Documentation/oops-tracing.txt in Linux sources.  You may also want to
enable some debugging options in the kernel.

-- 
Regards,
Pavel Roskin

> /var/log/messages and dmesg rely on userspace working.  I suggest that
> you check other ways for diagnosing kernel problems described in
> Documentation/oops-tracing.txt in Linux sources.  You may also want to
> enable some debugging options in the kernel.
> 
> -- 
> Regards,
> Pavel Roskin

Hi!
I catched finally something in the logs. Do you know what happend here?
http://pastebin.com/m48518477

Conrad

On Wed, 2008-11-26 at 20:25 +0000, Derek C wrote:
> Hi,
> 
> Does anyone know if there are downloads, or SVN, for the madwifi-ng VAP
> branch?

There is no such branch.

-- 
Regards,
Pavel Roskin

Hi Pavel,

I read this at the top of a madwifi README: -

================================================================
MADWIFI: Multimode Atheros Driver for WiFi on Linux (VAP branch)
================================================================

This was part of the openwrt distribution used by Meraki
(http://meraki.com/linux)

Derek


On Wed, November 26, 2008 9:25 pm, Pavel Roskin wrote:
> On Wed, 2008-11-26 at 20:25 +0000, Derek C wrote:
>
>> Hi,
>>
>>
>> Does anyone know if there are downloads, or SVN, for the madwifi-ng VAP
>>  branch?
>
> There is no such branch.
>
>
> --
> Regards,
> Pavel Roskin
>
>


-- 
Derek C
In Ireland

Quoting Derek C <derekmadwifi@...>:

> Hi Pavel,
>
> I read this at the top of a madwifi README: -
>
> ================================================================
> MADWIFI: Multimode Atheros Driver for WiFi on Linux (VAP branch)
> ================================================================

It's likely a historical notice from the days when VAPs were not  
supported in the trunk.  At some point the changes were merged,  
including the documentation changes.  As it stands now, "VAP branch"  
is mentioned in the trunk, and the VAP branch doesn't exist.

It's also possible that "VAP branch" refers to HAL or to some branch  
in FreeBSD.

-- 
Regards,
Pavel Roskin

Hi Pavel,

Thanks very much - I'm having a problem with VAPs so I was having a look
at other people's choice in madwifi source.  I'll email in to the list
again with my problem now

Derek


On Thu, November 27, 2008 5:22 am, Pavel Roskin wrote:
> Quoting Derek C <derekmadwifi@...>:
>
>
>> Hi Pavel,
>>
>>
>> I read this at the top of a madwifi README: -
>>
>>
>> ================================================================
>> MADWIFI: Multimode Atheros Driver for WiFi on Linux (VAP branch)
>> ================================================================
>>
>
> It's likely a historical notice from the days when VAPs were not
> supported in the trunk.  At some point the changes were merged, including
> the documentation changes.  As it stands now, "VAP branch" is mentioned in
> the trunk, and the VAP branch doesn't exist.
>
> It's also possible that "VAP branch" refers to HAL or to some branch
> in FreeBSD.
>
> --
> Regards,
> Pavel Roskin
>
>


-- 
Derek C
In Ireland

On Tue, 2008-11-25 at 17:16 +0100, saravanan chanemouganandam wrote:

> root@...# ./ath_info 48000000
> mmap of device at 0x48000000 for 0x10000 bytes failed - Invalid
> argument

It must be something specific to your system.  ath_info is working for
others.  Check that /dev/mem is a correct character device and not some
dummy:

$ ls -al /dev/mem
crw-r----- 1 root kmem 1, 1 Nov 25 12:21 /dev/mem

If it's not a dummy, check what's happening in the kernel.  There are 4
occurrences of EINVAL in drivers/char/mem.c in the kernel sources.  Try
replacing them with other codes to find out which function code is
returning -EINVAL.  Then try to figure out why it's happening.

-- 
Regards,
Pavel Roskin

Queenie de Melo schrieb:
> Thanks Mike for your response.
>  
> Can you let me know if we can have a mesh network using madwifi .0.9.4 
> using ad-hoc mode ?
> or does it mean.... when we say mesh network using adhoc mode, that it 
> should be following 802.11s standards?
>  

Depending on how you define a 'mesh' network, ad-hoc, the demo ad-hoc, 
will provide the underlying
connectivity for a mesh, based on say the routing software like olsrd, 
or (I have not used this) Batman.

If your goal is 100's of nodes... that may be difficult, but if it is 
under 15 or so, a 'simple' approach can
work for you.

John Clark.