[CUWiN] N00b Question

[Jef Green]

Thanks for the reply, David.

The other question I had was whether or not it is feasible to change the 
private address subnets the radios will be using for user space/dhcp.  We 
have a rather large set of private NAT'd subnets internally already, and I'd 
like to have the CuWin radios conform if possible.  This way if we wanted to 
use a common NAT router, their would be no overlap.  We tried changing 
subnet declarations in the config files and even tried disabling ethip in 
the interface config files, but the radios rebooted with no address instead 
of the addresses we had declared.  Possibly their is an easier solution for 
this as well.  It seems the software is designed to automatically choose 
IPs/subnetting based on MACs of the radios, but I'd like to know if I can 
control or disable this function (within reason).

----- Original Message ----- 
From: "David Young" <dyoung at pobox.com>
To: <cu-wireless at lists.cuwireless.net>
Sent: Thursday, August 02, 2007 3:11 PM
Subject: Re: [CUWiN] N00b Question


> On Thu, Aug 02, 2007 at 01:19:57PM -0500, Jef Green wrote:
>> Hello,
>>
>> My name if Jef, and I am working with onShore Networks and the local
>> West Town Chamber of Commerce to provide a free community wireless
>> internet service to Chicago Avenue in Chicago, Illinois.  I have two
>> Soekris kits here with CuWin/NetBSD installed.  Everything is running
>> fine, but I have a few technical questions.  If this is the wrong list
>> to post such questions, please cut me off short here.
>>
>> The main thing I want to get sorted out is how to manually manage mesh
>> connections from node to node.  Mainly I've had problems with other
>> (brand name) nodes in the past allowing too many hops in a situation
>> where a hop could be avoided - i.e. a node could have associated
>> with a node closer to the root (core) node, but chose not to do so.
>> I'd like to know the best way of handling this manually when need be.
>> Blocking the node's MAC from associating through an ACL would be my
>> first guess, but not quite sure how to implement this.  I'm a bit more
>> familiar with Debian and the like-Linux variety, and not-so familiar
>> with wireless mesh networking within Linux.  So between that, NetBSD
>> and hsls/zebra/CuWin, etc. - I'm a little lost.  Perhaps there is an
>> easy method that I'm missing, or whatnot.  The CuWin release we're
>> using here has a broken web management interface - FYI.
>>
>> I have a few other technical things I need to get worked out, but
>> I'll wait for the response to this question.  Any help is greatly
>> appreciated.
>
> Jef,
>
> This is the right list to ask questions.
>
> You can use the PF packet filter to block routing packets from a
> particular IP source address.  See NetBSD manual pages pfctl(8), pf(4).
> The routing packets are UDP packets sent to destination port 9191 with
> a source address in the 169.254/16 range.  If you block routing packets
> from host X at host Y, then a link X->Y will not form.
>
> I urge you to rely on HSLS to choose routes for you.  Sometimes HSLS will
> make a choice that looks "wrong" to you and I.  The reason may be that
> our hunch about the best route is wrong.  There may be a bug in HSLS.
> Or our routing metric may be performing badly---we expect this sometimes.
> Papering over problems by using the packet filter may sometimes work as
> a stopgap, however, you will have better luck if CUWiN finds and fixes
> the root problem.
>
> Dave
>
> -- 
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933 ext 24
> _______________________________________________
> CU-Wireless mailing list
> CU-Wireless at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless
> Project Page: http://cuwireless.ucimc.org
>