Jack:
Hurm. I know that I can't assure you of "a". In
fact, quite the opposite: I have no idea what people will
be bringing into the wireless LAN.
On the other hand, I can safely assure you of "b".
Can see your point: if I alias the internal interface to
some other subnet's gateway or DNS IP address, it'd be
tricky to ever trying to send packets thru the router to
the "real" one.
Regarding DHCP, I agree completely. That'd be best,
and it's certainly going to be the default. But, I'm not
sure I can force a user's laptop (say) to use DHCP if it
started life in my LAN as a statically configured device.
I think I just gotta deal with it, somehow detecting "lost"
packets and adapting the interfaces, on the fly, accordingly.
Or, as you suggest, run an active LAN scanner (perhaps an
ARP watcher?) to see what just joined and make some guesses
as to how to handle it.
Risk wise, 802.11 certainly has that limitation
with the independent-BSS mode. My understanding is in that
"software access point" mode, everything on the LAN is
essentially a peer, and so an illicit user can see and
affect legitimate users directly. In "real" access points,
there's a normal BSS mode, in which the AP mediates all of
the traffic, and so peers are safer from each other. My
understanding, though, is that none of the open-source
projects support this second mode -- not until an Orinoco
access point gets reverse engineered.
-Scott
On Fri, 20 Apr 2001, Jack Coates wrote:
> The only way I can see this working is if you:
>
> a) know and define the subnet the fixed addresses will be in
>
> b) don't ever need to get to that subnet on the Internet (or at least
> not at the same time as you're using a wireless device).
>
> Better ways: DHCP. It's pretty easy to write a .bat or .sh which
> releases and renews -- with a little more work and snort you could
> probably autosense when that sort of activity was required?
>
> I'll assume you know about the big ugly holes recently discovered in WEP
> and have heard the stories about driving around with a laptop and an
> antenna...
>
> The risks aren't new (WEP == wired equivalent protocol and imagine a
> hub with a patch cable reaching out to the street for anyone to use),
> but they are recently publicized which means lots more script kiddies
> know about it.
>
> --
> Jack Coates
> Monkeynoodle: It's what's for dinner!
>
> On Fri, 20 Apr 2001, Scott C. Best wrote:
>
> >
> > Heyaz. Curious for any leads, pointers, suggestions,
> > patient explanations here.
> >
> > Here's the situation: given a Linux based NAT'ing
> > firewall/router in between a modem and a 802.11 access point,
> > I'd like to support an 802.11 network device that arrives on
> > the network which is preconfigured "incorrectly". That is,
> > suppose my LAN is 192.168.x.y, but a new device is configured
> > with a static IP# (and static DNS, and even a static proxy) in
> > some *other* range (say, in 206.184.139.137/24 somewhere).
> >
> > Presuming the firewall ruleset is flexible enough,
> > how much of this would common IP-masquerading be able to
> > handle already? Certainly the DNS and and proxy stuff would
> > require some careful forwarding...but what about the NAT'ing
> > and the routing? I've been noodling on this most of the day,
> > and have fairly well convinced myself that it should be
> > fairly straightforward with the NAT'ing, but a bit trickier
> > with the ad-hoc ip-aliasing of the internal interface (so
> > it would appear as the default gateway, DNS, and proxy for
> > multiple devices differently).
> > Anyhow...thanks in advance for any thoughts on this.
> >
> > cheers,
> > Scott
> >
> >
> >
> >
> >
> > _______________________________________________
> > Leaf-devel mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/leaf-devel
> >
>
>
> _______________________________________________
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/leaf-devel
>
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
