What is a list of options for setting up a public wifi network where each
person that connects couldn't see the other person in network neighborhood,
or even ping them, using 1 wireless router?

any suggestions?

I would just disable File and Printer sharing....

Show quoteHide quote

$uc.9265@trnddc02:

this is for security in a hotel, with users not knowing how to do that kind
of stuff, and the hotel staff doesn't want to interfere with any sharing,
etc..of their work files.  so that when they go home, all their mapped
drives, etc...are still there.

Smowk <Smowk***@Yahoo.com> wrote in
Just ensure that the Access Point you purchase has a protocol filter.
Filter the Windows File Sharing Ports (Netbios).

Lucas Tam wrote:

Show quoteHide quoteAS Lucas said, block the Netbios file sharing ports (135, 137,138,139
and 445).
This will not block a ping. Ping is a different protocol. Blocking every
port won't block a ping.

Lucas Tam <REMOVEn***@rogers.com> wrote in news:Xns95F99FF5D78Bnntprogerscom@
140.99.99.130:

a smart person would still be able to scan ip's and connect that way

Smowk wrote:

How are you going to connect if the port you need to connect with is closed?

Smowk <Smowk***@Yahoo.com> wrote in
Well, if you've blocked the File Sharing Points on the AP... the person
can't connect!

The user would need to take it upon himself to have a firewall installed on
his computer to protect him from other wireless network users. Windows XP
has a built in firewall and there are many free for personal use ones
available such as Zone Alarm. --- Steve

http://www.dslreports.com/faq/8696

Show quoteHide quote

Show quote Hide quote well, it's a hotel, hospitality is our #1 priority.  we want to provide the
security for them, and not have to have them do anything...

I would contact the various manufactures to see if they have a device that
can isolate wireless users. The WAPs that I know of will not do such. D-link
has some Hot Spot products but they did not have any manuals to download.
Cisco would be someone to look at. Maybe someone at CDW would know if they a
product that would do what you need. Make sure you are very specific about
your needs, take names who you talked to/ordered from, etc..  --- Steve

http://www.cdw.com/shop/search/results.aspx?grp=WAP

Show quoteHide quote

@TK2MSFTNGP10.phx.gbl:

we have an acct with cdw...ill look into it

Smowk <Smowk***@Yahoo.com> wrote:
Relatively easy to do with LinkSys equipment.

Smowk <Smowk***@Yahoo.com> wrote:
Use DHCP to provide IP addresses, and simply do *not* route
to those addresses, but *only* to an Internet gateway.

what type of router would support this specifically

On Wed, 09 Feb 2005 21:56:22 -0600, Smowk <Smowk***@Yahoo.com> wrote:

This is messy but doable.  However, I don't think it can be done by
any of the cheapo wireless routers.  The reason is that wireless is
really bridging, not routing.  As has been suggested, you could do the
trick by tweaking the routers routing table to send literally
everything from the various clients to the default gateway, with
nothing going to anything on the LAN IP block.  However, a few minor
routing commands on the client machine and they instantly can "see"
the other wireless users.  That's because the router is NOT located
between users, just between the users and the internet.  Between the
users is a simple ethernet bridge (actually a switch or multi-port
bridge).

Perhaps an easier way to visualize the problem is to just remove
802.11 wireless from the puzzle temporarily, and just deal with the
wired equivalent components.  After all, 802.11 is nothing move than
encapsulation of 802.3 ethernet packets.  What goes in and out of
wireless is just ethernet.  So, you have a common 4 port ethernet
unintelligent switch and a router to the internet.  Effectively,
you've asked how does one prevent PC's, plugged into the ethernet
switch, from seeing each other.  That's not possible without some
intelligence at the bridging level (Layer 2) in the switch.  The
router is out of the circuit between PC's and has no effect on traffic
between PC's.  It's just plugged into yet another port on the
unintelligent ethernet switch.

Well, the way this is done is to disable the dynamic bridging table
feature of the switch, and implement a static bridging table.  Each
wireless MAC address goes to a specific ethernet port, which only
allows traffic to one other ethernet port, which conveniently happens
to be that of the router.  Without the ability to add additional MAC
address to ethernet port mapping, everything from a wireless client
goes to one place.  Again, note that this must happen at the bridge
level (Layer 2), and not via IP routing (Layer 3).

Intelligent (or at least configurable bridging) is a common feature in
radios used by WISP's (wireless ISP's).  WISP's do not want their
wireless customers to "see" each other.  They also don't want users to
turn their wireless networking into their private game network, where
none of the packets ever go to the internet, and where the router has
no control over traffic.  Same with trojan infected machines that scan
the wireless LAN for exploitable PC's and open shares, which also
never hit the internet.

I think (not sure) that some of the higher end switch/routers made for
wireless hot spots do this by default.
  http://www.dlink.com/products/?sec=0&pid=349
  http://www.dlink.com/products/?sec=0&pid=402
I haven't played with these.

Very good explaination Jeff!

I was under the impression that some of the wireless protocols themselves
had some kind of "privacy features" built into them that did just what the
guy is asking about.  This is why some home users add a wireless element to
the already "wired" home LAN and then complain that their laptop on the
wirless can see all the wired machines on their LAN just fine but nothing on
the wired can see the laptop on the wireless. I wasn't sure enough to say
anything earlier but doesn't a lot of wireless equipment ahve some sort of
privacy features built into them?


Show quoteHide quote

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:
Fairly easily with LinkSys WRT54G(S) routers.

I'm not sure if it is possible to get the right route table
configuration using the LinkSys firmware, but certainly with
Sveasoft or HyperWRT firmware it is not difficult to do.

Welllll...  the WRT54G is actually routing, and has three network
interfaces, one each for wireless, the LAN switch (with 4 ports),
and another for the single WAN/Internet port.  That last one is
what makes it possible.

Won't work with this example though.

Except that isn't true on the WRT54G!

Here's a route table copied from a WRT54G which will not allow
packets to be routed between anything on the 192.168.1.0 subnet,
but will send everything to a firewall on the 192.168.0.0 subnet
if it is connected via wired ethernet on one of the LAN ports of
the WRT54G,

Kernel IP routing table
Destination  Gateway      Genmask         Flags ...  Iface
192.168.0.2  *            255.255.255.255 UH    ...  br0
192.168.1.0  *            255.255.255.0   U     ...  vlan1
192.168.0.0  *            255.255.255.0   U     ...  br0
127.0.0.0    *            255.0.0.0       U     ...  lo
default      192.168.0.2  0.0.0.0         UG    ...  br0

Without the route to the vlan1 (the WAN port) interface, all of
the 192.168.1.0 traffic was going to br0 (the bridge to the LAN
switch, which also connects to the wireless port, vlan0).  By
routing that subnet to vlan1, and assigning an IP address on
that subnet to the bridge (192.168.1.2 in this particular case),
it prevents any traffic on that subnet from going to the bridge.
It does allow traffic from wireless to the wired LAN though, for
the subnet 192.168.0.0, so anything in that address range has to
be hardened.

I would also expect that the default route could also be to vlan1,
but haven't actually tried that.  The results should be the same.

Here's the output of ifconfig on the router, just for information,
edited to remove at least some of the useless parts.  Note there
are three unique MAC address, and (the lo device excluded) there
are two of them with assigned IP addresses (br0 and vlan1, the
LAN and WAN ports respectively):

br0    Link encap:Ethernet  HWaddr 00:12:17:27:FE:B8
        inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0

eth0   Link encap:Ethernet  HWaddr 00:12:17:27:FE:B8

eth1   Link encap:Ethernet  HWaddr 00:12:17:27:FE:BA

lo     Link encap:Local Loopback
        inet addr:127.0.0.1  Mask:255.0.0.0

vlan0  Link encap:Ethernet  HWaddr 00:12:17:27:FE:B8

vlan1  Link encap:Ethernet  HWaddr 00:12:17:27:FE:B9
        inet addr:192.168.0.3  Bcast:192.168.255.255  Mask:255.255.0.0

wds0.2 Link encap:Ethernet  HWaddr 00:12:17:27:FE:BA

wds0.3 Link encap:Ethernet  HWaddr 00:12:17:27:FE:BA


Whether this can be done on any other wireless router I don't know.
It requires a router that will route 192.168.0.0 addresses, and
with separately routed ports for the wireless and wired network.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:

Show quoteHide quoteBuffalo's products also have a "privacy separator" option that
supposedly bars communication between wireless clients.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote in
yea, but we would have to register all of the mac addresses of the guests who
use the hotels wifi and set it up manually for each new user (around 20 or so
per day peak season). 

right?

other than that, i agree with phil...VERY GOOD EXPLANATION

smowk

On Thu, 10 Feb 2005 17:49:22 -0600, Smowk <Smowk***@Yahoo.com> wrote:

Show quoteHide quoteNope.  Here's where I get on thin ice as I'm not sure how existing
implementations do such things.  I'm also not too good on the protocol
thing.  Therefore, I'll guess(tm) how I would implement such a scheme.

The bridging algorithm needs a bit of tweaking.  For example, the
bridge would still automatically sniff for 802.3 ethernet packets
source MAC addresses.  However, instead of allowing multiple MAC
addresses per port and multiple MAC addresses per destination, it
would have a fixed destination MAC address pointing at the router
port.  Any other MAC destination addresses or other source addresses
would simply be ignored.  The switch (multi-port bridge) would still
be able to connect new wireless MAC addresses to the router port after
a disconnect, but destination MAC addresses other than the router
would be ignored.

Packets with no destination addresses such as broadcasts and DHCP
requests would also need to be handled.  Broadcasts have a source, but
no destination MAC address.  So, the switch sends them to every port.
Not good.  So, the broadcast mechanism has to restricted to pass
broadcasts only to the port in the bridging table.  Broadcasts from
the router port go to every port and wireless connection.

As I vaguely recall, that's the way some ancient access point firmware
worked.  I do recall the constant complaints in the mailing lists that
some access points would not allow communications between wireless
clients, or between wireless clients and wired LAN ports.  For WISP
(wireless ISP), hot spot, and neighborhood LAN service, it's the
desired mode of operation.

Again, this cannot be done at the IP level by tweaking the routing
table even if every client were trustworthy.  There would be nothing
to prevent a client from turning your access point into their private
game network, which never sees the router or goes to the internet.
Also, without any control, everyone would also get everyone else's
broadcasts.  Therefore, it has to be one at with a bridge/switch at
the MAC level.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote in
Show quoteHide quotethis is good if i'm building my own access point...but...

lol

On Fri, 11 Feb 2005 12:31:23 -0600, Smowk <Smowk***@Yahoo.com> wrote:

Mind if I unload my frustrations on you?  I have a personal contempt
for one line comments and unsubstantiated judgements to long postings
with no editing and find it occasionally necessary to unload my wrath
upon the unsuspecting.  It's quite painless and will only sting for a
moment.

What I scribbled is my guess as to how things should work.  Methinks
it's a good guess.  It's considered a good thing to know how things
work so you can make intelligent decisions as to which contraption is
suitable for the intended purpose.  If you don't know how things work,
you will soon end up with a large collection of useless "boxes" that
cannot be bludgeoned into functionality.  Hopefully, you're not
suggesting that such information is worthless, unless one is designing
an access point.  In this case, the question and problem are quite
real and useful.  I don't have a "just buy this product and all your
problems will be solved" type of answer for the original question.
However, I've supplied enough clues as to what to look for and
evaluate such a device.  If you don't mind, I'll continue to answer
questions with an explanation of how they function and operate, and
avoid packaged answers the vaguely resemble product promotion.

Thank you for playing target.  Now, I feel so much better.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote in
No problems here...sorry for trolling, but it's my purpose in life i think

On Sun, 13 Feb 2005 18:50:36 -0600, Smowk <Smowk***@Yahoo.com> wrote:

Likewise.  Sorry for being rather nasty and bad tempered.  I'll try to
be more diplomatic in the future.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:
A WRT54G router with the correct route table does it quite well.

If they are indeed on the same network, that is exactly what is
supposed to happen.

Typically, yes.  Where the hardware is as you've described.
Obviously there is more to it than that.

On Fri, 11 Feb 2005 13:55:37 -0900, fl***@barrow.com (Floyd L.
Davidson) wrote:

Using routeing to keep wireless clients seperated will only work if
the clients can be trusted.  For example, I can easily setup a phony
DHCP server on a wireless laptop that will deliver a creative IP
address and gateway.  I think route that IP address to the real
wireless access point and router going to the internet.  Instant "man
in the middle" exploit.  I can capture traffic going in both
directions and not even bother with removing the 802.11 encapsulation
required by wireless sniffing.

Methinks you're missing my point.  If the packets do not go to the
internet, as in a wireless to wireless attack, then there is NOTHING
that a router can do to stop such an attack as it's not even in the
data path.

Last year, I got a call to see if I could do something about lousy
thruput at a WISP.  They thought they had an RF interference problem.
After a day of useless RF sniffing, I started looking at the router
traffic.  Nothing unusual or excessive.  Eventually, I connected a hub
at where the access points came together and found LOTS of traffic
between access points or being repeated out of a single access point.
(The reason this wasn't done before is the access points were located
at 40ft on a tower).  The system was being used as a repeater between
a bunch of gamers.  All their traffic was wireless to wireless with
nothing going via the router to the internet.  The problem was that
the access points on the tower had no provision for preventing their
use in this manner.  They would merrily bridge between connected
clients.  (The system WEP keys were cracked long ago).  So, I just
blocked the MAC addresses involved, which slowed them down long enough
to fix the configuration.  I dunno what was done to fix it as I only
did the RF part.  They had a qualified and clueful service company
that only required that I explain 4 times why tweaking the router
isn't going to fix traffic problems that don't go through the router.

In a common shared network, broadcasts go to every machine on the
network.  They even go through some routers.  However, on a VLAN, they
stay within the confines of the VLAN.  You could make each client a
seperate VLAN.  I vaguely recall that this was done by some WISP's
with problems.  Not every cheapo home router can handle the oversized
802.1q tagged packets.

In my hypothetical implimentation of a broadcast domain, the broadcast
packets would NOT propogate to every machine on the network, but only
go to/from the connected router.  That will prevent spoofing DHCP
servers, Windoze browsing, and fake ARP replies.

Methinks is "less" to it than that.  It's not like one needs to add
features to the MAC layer of an access point.  One needs to remove
features.  A wireless bridge that only sends packets to one port (i.e.
the router to the internet port), is a very simple device.  Nothing
fancy or complex required that isn't already in the firmware.  One
only needs to disable a few functions to get this.  I suspect it's
already been done in some products, but I don't have any info on which
ones.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:
Not necessarily true.

The server on your wireless laptop can't provide an IP or a
gateway route through the router.  Hence, regardless of what it
served up, the results would still be exactly the same...  no
route to another wireless client through the AP.  Routing on the
client makes no difference at all, nor does the IP address used.
There simply is no wireless-to-wireless route.

And of course that *does* presume an AP/router which in fact
routes wireless packets.  As pointed out, that is the way it
works with the WRT54G, which does not blindly send wireless
packets to the ethernet switch.

So just how do you route "to the real wireless access point and
router"???  There is exactly one AP/router.  It routes everything
to the Internet...

Your description is not clear (it looks like a bit of editing
went astray, so I'm guessing about what you meant, and may well
be wrong).  It sounds as if you mean you can set up another AP
(not a wireless laptop), and operate it as a repeater to the
real AP.  That is a threat to a wireless network no matter what
hardware is used.

So is passive sniffing.

I agree that can be done.  That is one reason the OP should 1)
be considering physical security as well, and making efforts at
limiting the signal coverage of his AP to the conference room;
and 2) advise customers that they are responsible for encrypting
their data sufficiently if industrial spying is a significant
concern to them.

(I would also point out that detection of the Man-in-the-Middle
exploit would be only slightly above trivial...  the provider
can do sniffing too!)

That is true, but hardly an insurmountable problem.  If the
attacker can sniff... so can the provider!

However, I'm unclear about exactly what you are referring to,
given the above description fits one scenario and the below
description is not at all the same.  The one above, if I
understood you correctly, requires adding hardware between the
desired AP and the desired Client, while below you describe an
example of poor administration.

If by "wireless to wireless" above you also meant the same
thing, it ain't gonna happen!  The AP *won't* route from one
wireless client to another in the example that I gave, and the
route *is* in the data path.

Which is to say, that is unrelated to the method that I
described, which *does* have a provision to prevent use in that
manner.

Fine, but what I described is hardware that *does* run the
wireless to wireless traffic through the router.

What I said there is in error.  That won't happen if there is no
route to the client.

They go to every machine on the subnet, if there is a route.
(In the example I gave, there is no route.)

Show quoteHide quoteWell, I'm not guessing about the functionality that I described.
I did guess that it had that capability, but before I spoke up I
reconfigured a WRT54G as described and tried it.

On Sat, 12 Feb 2005 11:01:53 -0900, fl***@barrow.com (Floyd L.
Davidson) wrote:

Yeah, sorta maybe.  If I can get the access point to bridge between
two client radios, none of the packets will go through the router.
Therefore tweaking the routing will do nothing to prevent this.  I can
build a MAC layer that sends blindly sends everything to the router
port, and not repeat broadcasts or pass packets between wireless
devices, but that's not the way commodity wireless access points work.
If you just place an access point on the table, not connect the
ethernet port to anything, and setup two wireless laptops, it will
happily allow communications between the laptops.  That's what the OP
was trying to avoid.  Note that such laptop to laptop communication
could not be blocked by routing because (insert drum roll), there is
no router.

There is no wireless to wireless "route" but there is a wireless to
wireless "bridge".  Again, you're trying to solve a bridging problem
with route ting.  You can do that, and it will work, if the client
computers are non-hostile.  The nice thing about access points is that
they are Layer 3 independent.  I have a wireless Novell IPX/SPX (plus
tcp/ip) bridge running between two medical offices.  If I can get the
computers to talk on layer 2 (bridging), then there's nothing you can
do on Layer 3 to prevent that.

I'm not sure how the WRT54G works.  I can break out the 5th ethernet
port that goes to the wireless section and sniff the traffic.
However, it's much easier to just use a separate access point (WAP54G
or WAP11) and an ethernet router.  I can sniff the traffic on the
cable in between, and see what it's getting.  To the best of my
limited knowledge, the stock WRT54G *DOES* blindly send 802.3 ethernet
packets from the wireless port to the ethernet switch.  If it didn't,
then broadcasts and arp request (no destination MAC address) would not
propagate from wireless to ethernet or ethernet to wireless.  Since I
know they do or DHCP, ARP, SAP, ICMP, etc would not work.

However, if I assume that you're correct and the WRT54G does NOT
blindly dump packets into the ethernet switch, then what criteria does
it use?  At this point, they are just 802.3 ethernet packets.  No IP
layer involved or desired.  What mechanism makes the decision as to
what to pass or block between wireless and ethernet?  There's a MAC
address filter on the wireless side, but I've found that the filter
only applies to the wireless port.

Show quoteHide quoteNope.  It can be done with a single laptop and single radio.  I really
didn't want to get into implementation.  However, if you insist.

First, an ethernet *OR* wireless port can be made to act as a router.
It's easier to see using an ethernet port than with wireless.  Also,
I've done this with a Freesco.org router and a Windoze 2000 based
router.  The ethernet port can have two IP addresses.  Linux (or
Windoze) will do IP Forwarding between the two addresses, on a single
port.
  http://www.wown.com/j_helmig/w2kprout.htm
It's a rather gross and inefficient router as every packet appears on
the network twice (once for each IP address).  However, it does work.

It's a bit more difficult building a one port router with a wireless
card.  Some cards will allow two IP's on a single card, others will
not.  Two radios in the laptop will certainly work.

So, one laptop radio connects normally to the hot spot wireless
router.  The other radio is running an access point simulator, with
DHCP server, using the same SSID but on a different radio channel.
The unsuspecting client connects to the laptop instead of the hot
spot.  The router software in the laptop forwards the packets to the
other radio, which forwards them to the hot spot wireless router.
Replace the router software on the laptop with a logger and sniffer
and you have a man in the middle exploit.  Wanna throw some
advertising at the customers?  No problem.  Just sniff for URL's and
replace them with your advertising web pile.  That should make the
customers thoroughly confused as they would first suspect spyware
instead of a man in the middle substitution exploit.

Actually, you'll find passive sniffing to be somewhat of a challenge.
The problem is finding a location that can hear both the access point
and the client at the same time in order to capture both sides of the
traffic.  That's fairly easy in a small cafe, but there are plenty of
other locations where it would be difficult to find a suitable
location.

If it can be done, it will be done.

Got it.  Wifi absorbant wallpaper:
  http://www.newscientist.com/article.ns?id=dn6240

Groan...another warning label.  Click here [ ] to approve the terms of
service, acceptable use policy, and general repudiation of
responsibility.
  "Warning.  Unencrypted WiFi may be dangerous to your security".

Well, a simple traceroute will usually detect the extra hop.  I once
hacked my Unix box to report a fake IP address in response to ICMP
ping and traceroute requests using hping and dnsspoof.
  http://www.hping.org/manpage.html
  http://olympus.het.brown.edu/cgi-bin/man2html?dnsspoof+8

Sigh.  AP's don't route...they bridge.  AP's don't have routers.  AP's
can pass packets between wireless clients by bridging.  No router or
routing required.  AP's do not require a router to function.  Think
bridging, not routing.

I think I clarified some of my points with examples.  The man in the
middle attack can be done with a laptop and either one or two wireless
cards.

Show quoteHide quoteIt's possible that your customized firmware WRT54G firmware does it
correctly.  However, I'm suspicious. It's easy enough to test.  All
you need are two wireless clients (or one wireless client and a LAN
wired client).  Both should have IP addresses and no personal
firewalls running.  Can you ping each other?  If so, then you can see
each other, which means it's not working as you described.  I just
tried it with my BEFW11S4 and my laptop can easily see the other
wireless clients on the LAN.

Nope.  I can do the same thing with just an access point, which
doesn't even have a router attached.  Again, think bridging (as in
layer 2) and forget about routing.

Incidentally, one of the really dumb ways to implement invisibility is
to deliver a netmask of 255.255.255.252 via DHCP.  This doesn't always
work as some clients don't allow for the default route to be outside
the netmask.  All current Windoze and Mac clients do, so it's not a
big problem.  However, any clueful user can manually assign themselves
a larger netmask, making the other clients visible.  Clever, but not
very secure.

Ummmm... Not so.  Broadcasts have no destination address.  They go
almost everywhere.  You can build a rule set or ACL that will block
broadcasts by type, but such fine control is not common on cheapo
routers.  Since there is no destination address to route, there is no
way to use a layer 3 router to direct broadcasts as routing requires a
destination.  All you can do is block them by type. 

Sorry.  I missed the example.  How do you control broadcasts by
routing?  Without a destination address, there's no way to direct
broadcasts anywhere.  That's why it had to be done on Layer 2 with
VLAN 802.1q.

Please pardon my suspicious nature.
How did you test?
Could the clients "see" each other?
Could you ping other clients?  (No fair using personal firewalls).

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:
If you *can't* get the AP to bridge, then all this esoteric
techie "commentary" of yours means nothing.  The appropriate
hardware *is* available, your point is has no merit, and all you
are saying is that installing the wrong equipment will provide
the wrong results.  That's not news, and not interesting to me
or probably to the OP either.

If you install the *wrong* equipment.

So I noticed.

Yep.  You merely use different terminology.  It makes no difference,
the point is the same, and un-interesting.  You've got "another
AP (not a wireless laptop), and operate it as a repeater", no
matter what you want to call it.

It isn't.

Which is even less critical than locating the above "access
point simulator".  You can't argue one is easy and the other is
not easier.

No provider will go to the expense required to counter that
possibility, nor should they.  There are better ways to deal
with it, and those are at the customer's discretion.

Now we are down to where every hotel conference room needs to be
Tempest proof... ;-)

I'm sure the hotel's General Counsel would approve, once another
line is added:

  "The customer is responsible for their own data encryption."

Traceroute won't even show that the WRT54G is there, never mind
an intruder.

Sigh.  The WRT54G is an AP that routes.  Probably others do to.

Think wrong equipment, get wrong results.  Don't install a
bridge, install a router.  (Get one with an AP built in... :-)

I'm suspicious myself.  That's why I checked to see if your
analysis was correct, by testing it for myself.  The difference
is that I did the testing *before* I started writing...

Wrong equipment, wrong results.

What do you mean "Nope."???  I described hardware that *does* do
exactly that.  The number of _other_ equipments that you've
looked at which do not, has no significance.

Wrong equipment, wrong results.  And as long as you want to use
a bridge rather than a router, you still won't get the right
results.

So tell us what happens when the broadcast packet hits a router?
Is that done in Layer 2, according to VLAN 802.1q???

Read the previously provided description.

You responded to the OP's summary dismissal of your technically
_useless_ detail with a rebuke, which you claimed would "sting".
Yet you don't seem willing to read the *pertinent* technical
details provided to demonstrate where your analysis was
incomplete.

See above.

On Sun, 13 Feb 2005 01:58:05 -0900, fl***@barrow.com (Floyd L.
Davidson) wrote:

We may be arguing semantics here.  To the best of my knowledge, a
wireless router (such as the WRT54G) is a wireless bridge (also known
as an access point) with an ethernet router hung on one of the
switched ports.  (A switch is a multi-port bridge).  Therefore, if I
ignore the router section of the wireless router, the WRT54G is
nothing more than an access point, which does bridging.  However, I
will concede that the manner in which it bridges can be affected by
replacement firmware.  I will NOT concede that tweaking the router,
that's not even in the data path, will do anything useful to affect
the bridging between wireless clients.

Well, I admitted that I didn't have a specific recommendation for
specific hardware.  I also indicated that I was posting how I though
it should work.  If this is deemed useless drivel, then I'll stop and
blunder onward to something else.  Had I known it this discussion
would grow to acrimonious levels, I probably would have simply found a
commerical product with Google, and offered a ready to run solution.
However, I'm weird and prefer technical debates to product searches.

Well, I have a WRT54G v1.1 sitting in the office that I could test.
I'm not thrilled with the time it takes to replace the firmware, but
I'm willing if I can find the time.  There are also a few hot spots
running in the area:
  http://www.thirdbreak.org/hotspots.html
which are running mostly WRT54G hardware with alternative firmware.  I
guess this would be easier than modifying my own.  I'll let you know
what I find.  It's gonna be weird walking in with two laptops, but
I've done stranger things in the past.  I'll also ask on their mailing
list.

Ok, you're correct.  I've done some sniffing and found it to be rather
difficult.  However, that was sniffing point to point links and not in
a cafe hot spot.   Sniffing inside a hot spot is easy.  From outside,
it's tricky, again depending upon location.

Well, I just thought it might be an "interesting" solution.  I showed
it to a few of my customers and was asked to get details and quotes.
However, they wanted it for the cafeteria in the hope that the
microwave oven leakage could be reduced.  I told them cleaning the
door seals would be cheaper and more useful.

Most sane hotspot operators have already done that.  For example:
  http://selfcare.hotspot.t-mobile.com/security.htm

Oops, you're half right.  With a man in the middle attack, the extra
(laptop) router in the path will show up only if set to respond to
ICMP or UDP pings.  I guess that can be disabled.  However, it would
still show up as a "hop" in traceroute, although no info would be
returned.

I don't suppose it would help if I repeat myself once more.  An access
point is a wireless bridge, not a wireless router.  Can we agree on
the terminology?  Your "...AP that routes" is a wireless router or an
box with an access point and a router.

My contention is that by installing a wireless router, you end up with
the equivalent of a wireless access point, and a router, in one
package.  The bridge part still functions as a bridge or access point,
when the router is not being used.  I think what we're arguing about
is what is how the access point part of the puzzle works.

If I'm wrong, I'll gladly admit it.  I trip to the local hot spot
should be sufficient.  I'll do it today and see.  I wasn't aware that
there was a point of contention when I first replied and therefore
didn't verify my statements with prior testing.  I agree that it's a
good idea to test before one posts, but that's also impractical and
time consuming.

If you're right, I'll admit I'm wrong, apologize, and go away and
sulk.  (I hate being wrong).  We can then live happily ever after.
However, I wanna do my own testing first.

With a VLAN, there's a few extra bytes tacked onto each packet that
labels the virtual LAN in which the packet belongs.  It's all layer 2.
The tags are also attached to broadcasts, so that the switch knows
which VLAN the packets need to stay inside.  It's really kinda cool
with wireless as it cuts down on excessive broadcast traffic.  Here's
a wireless VLAN implementation.
  http://www.cpx.com/whitepapers/Compex%20Psuedo%20VLAN.pdf

Guilty as charged.  How would you feel if I had replied to your long
posting detailing your offered WRT54G solution to the hotel hot spot
problem with a one line summary judgment?  That, combined with some
current personal problems tend to ruin what little diplomacy I have
left.

I was hoping a for a bit more detail.  In:
  87u0okjj7z.***@barrow.com
you describe the use of two VLAN's, one for the ethernet, and one for
the wireless as in the edited ifconfig output below (lo and WDS
deleted):

br0    Link encap:Ethernet  HWaddr 00:12:17:27:FE:B8
        inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0

eth0   Link encap:Ethernet  HWaddr 00:12:17:27:FE:B8

eth1   Link encap:Ethernet  HWaddr 00:12:17:27:FE:BA

vlan0  Link encap:Ethernet  HWaddr 00:12:17:27:FE:B8

vlan1  Link encap:Ethernet  HWaddr 00:12:17:27:FE:B9
        inet addr:192.168.0.3  Bcast:192.168.255.255  Mask:255.255.0.0

I agree that you can use the VLAN feature to isolate the two ethernet
VLAN's from each other and possibly from the br0 (wireless) port.
What I'm asking is if the same mechanism can be used to isolate
individual users on br0 from each other.  Methinks not or there would
be multiple VLAN's showing on the wireless side.

With all due respect, I just re-read *ALL* your previous postings in
this thread and cannot find any comments where you've stated that two
wireless clients cannot ping (or "see") each other.  I may have missed
something.  You've stated that you've tested your WRT54G, but I can't
find how or what application was used for testing.  I'm not looking
for a detailed procedure.  Just a simple question:  Can two wireless
clients ping each other?  Extra credit for using arping to ping by MAC
address.  If so, I'm correct.  If not, I'm wrong.

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:
You are.  Please stop.

The earth is flat?   ... despite all evidence to the contrary!

I'll concede you were correct when you said you didn't know what
you were talking about (a WRT54G).

I'm trying to get you to actually listen instead of just talk
about the things you imagine to be true.

I prefer facts to your imagination, which is no different than
marketing hype.

Then test it and stop imagining what the test would show if it
was built differently than it is.  (I tested a version 2.0 unit.)

A really severe constraint...  all 53 seconds of wasted time.
(Well, okay... you need to add 30 seconds for a reset before and
after.  Call it 90 seconds.)

To what purpose?  You might as well test more bridges to see if
they route!  It makes no difference how many hot spots are *not*
configured to do that.  The only reasonable test is to configure
your own WRT54G and test it.

(Of course, it you luck onto even so much as one hot spot that
does have it configured that way, that is a definitive test.
But who knows how many you'll need to test...)

Actually, you are simply wrong again.  Let me repeat that for you:
The WRT54G _won't_ _even_ _show_ _up_ _with_ _traceroute_, and there is no
expectation that an intruder would be stupid enough to configure
a node that would.

Again, you imagine what it might do, if it works as you assume.
But alas, I just described *precisely* what happens.  No
guessing involved.  (Do you need the version number of my
traceroute program?  The serial number of my WRT54G??)

What traceroute returns depends on how the TTL field is handled.
It has nothing to do with either ICMP or UDP pings.

Don't be a boor, stop arguing silly semantics.  It's an AP.

Your contention is that semantics is more interesting than
equipment.  I deleted it because I don't care...

You are in fact wrong, and that has been demonstrated already.

The logic of going to a local hot spot is the same as testing
bridges to see if they will route.  It make no difference how
many you find that do what you say, it only matters that the
WRT54G *does* route, regardless of what you say.

Imagination is always going to be a point of contention.

That is true if we are discussing proving the Theory Of
Relativity.  But it took only minutes to test a WRT54G to see
that it does not work the way you describe.

Then test before you make claims based on imaginary equipment.

Not that speculation is bad!  But you've posted it as *fact*,
and when someone points to real examples that contradict your
speculation you obfuscate with illogical arguments, semantic
games, and irrelevant examples... and say it isn't true.

Show quoteHide quoteYou missed the point: It affects a lot more than Layer 2 when it
hits a router.  Does it get routed, or not?  If it does, it
certainly is not happening at Layer 2!  (And of course if it
doesn't, none of the above is relevant then either!)

The non-techie OP can logically respond with a one line summary
judgment to what you posted.  Your response to my detail was
illogical, and far less appropriate than what the OP had to say.

You don't seem interested in learning about the equipment and
how to use it.

Show quoteHide quoteThat is not required to separate wireless clients.

     "Here's a route table copied from a WRT54G which
     will not allow packets to be routed between
     anything on the 192.168.1.0 subnet,  ..."

Perhaps terse, and I realize that you have to apply some simple
logic to that statement to realize that it answers your
question.  But I was assuming that you understood that ping uses
routed packets, and if there is no route...  then two wireless
clients cannot ping each other.

You might even have drawn the conclusion (giant leap of faith
that it is) that the only reasonable way I would know it does
not route packets between wireless clients would be because I
tried to ping one wireless client from another (or in this case,
a couple of them) and found that it failed, while at the same
time it was possible to ping hosts on the Internet via the
gateway.  Why else would I say that it works the way I
described?

Do you need to know the version of ping?

  @(#) Copyright (c) 1989 The Regents of the University of California.
  All rights reserved.
  $Id: ping.c,v 1.39 2000/07/23 04:16:21 dholland Exp $
  $NetKit: netkit-base-0.17 $

The OS, the specifications on the ethernet cables, or any other
of insignificant or obvious details?

You aren't right about this either.

Whatever, if you aren't looking for a detailed procedure don't
claim it can't be correct short of having a detailed procedure
listed.  The procedures and tests are trivial and obvious.



I see that this response does not contain an ounce of useful
technical information.  For me, that pretty much signifies there
is no point in continuing the discussion.  I'll certainly read
whatever you have to say in a followup; but unless this gets
back onto a technical track, absent the imagination and the
semantic debates, I'm not likely to discuss it further.

(This is a repost, because the original hasn't shown up in
over an hour...)

Jeff Liebermann <je***@comix.santa-cruz.ca.us> wrote:
You are.  Please stop.

The earth is flat?   ... despite all evidence to the contrary!

I'll concede you were correct when you said you didn't know what
you were talking about (a WRT54G).

I'm trying to get you to actually listen instead of just talk
about the things you imagine to be true.

I prefer facts to your imagination, which is no different than
marketing hype.

Then test it and stop imagining what the test would show if it
was built differently than it is.  (I tested a version 2.0 unit.)

A really severe constraint...  all 53 seconds of wasted time.
(Well, okay... you need to add 30 seconds for a reset before and
after.  Call it 90 seconds.)

To what purpose?  You might as well test more bridges to see if
they route!  It makes no difference how many hot spots are *not*
configured to do that.  The only reasonable test is to configure
your own WRT54G and test it.

(Of course, it you luck onto even so much as one hot spot that
does have it configured that way, that is a definitive test.
But who knows how many you'll need to test...)

Actually, you are simply wrong again.  Let me repeat that for you:
The WRT54G _won't_ _even_ _show_ _up_ _with_ _traceroute_, and there is no
expectation that an intruder would be stupid enough to configure
a node that would.

Again, you imagine what it might do, if it works as you assume.
But alas, I just described *precisely* what happens.  No
guessing involved.  (Do you need the version number of my
traceroute program?  The serial number of my WRT54G??)

What traceroute returns depends on how the TTL field is handled.
It has nothing to do with either ICMP or UDP pings.

Don't be a boor, stop arguing silly semantics.  It's an AP.

Your contention is that semantics is more interesting than
equipment.  I deleted it because I don't care...

You are in fact wrong, and that has been demonstrated already.

The logic of going to a local hot spot is the same as testing
bridges to see if they will route.  It makes no difference how
many you find that do what you say, it only matters that the
WRT54G *does* route, regardless of what you say.

Imagination is always going to be a point of contention.

That is true if we are discussing proving the Theory Of
Relativity.  But it took only minutes to test a WRT54G to see
that it does not work the way you describe.

Then test before you make claims based on imaginary equipment.

Not that speculation is bad!  But you've posted it as *fact*,
and when someone points to real examples that contradict your
speculation you obfuscate with illogical arguments, semantic
games, and irrelevant examples... and say it isn't true.

Show quoteHide quoteYou missed the point: It affects a lot more than Layer 2 when it
hits a router.  Does it get routed, or not?  If it does, it
certainly is not happening at Layer 2!  (And of course if it
doesn't, none of the above is relevant then either!)

The non-techie OP can logically respond with a one line summary
judgment to what you posted.  Your response to my detail was
illogical, and far less appropriate than what the OP had to say.

You don't seem interested in learning about the equipment and
how to use it.

Show quoteHide quoteThat is not required to separate wireless clients.

     "Here's a route table copied from a WRT54G which
     will not allow packets to be routed between
     anything on the 192.168.1.0 subnet,  ..."

Perhaps terse, and I realize that you have to apply some simple
logic to that statement to realize that it answers your
question.  But I was assuming that you understood that ping uses
routed packets, and if there is no route...  then two wireless
clients cannot ping each other.

You might even have drawn the conclusion (giant leap of faith
that it is) that the only reasonable way I would know it does
not route packets between wireless clients would be because I
tried to ping one wireless client from another (or in this case,
a couple of them) and found that it failed, while at the same
time it was possible to ping hosts on the Internet via the
gateway.  Why else would I say that it works the way I
described?

Do you need to know the version of ping?

  @(#) Copyright (c) 1989 The Regents of the University of California.
  All rights reserved.
  $Id: ping.c,v 1.39 2000/07/23 04:16:21 dholland Exp $
  $NetKit: netkit-base-0.17 $

The OS, the specifications on the ethernet cables, or any other
of insignificant or obvious details?

You aren't right about this either.

Whatever, if you aren't looking for a detailed procedure don't
claim it can't be correct short of having a detailed procedure
listed.  The procedures and tests are trivial and obvious.



I see that this response does not contain an ounce of useful
technical information.  For me, that pretty much signifies there
is no point in continuing the discussion.  I'll certainly read
whatever you have to say in a followup; but unless this gets
back onto a technical track, absent the imagination and the
semantic debates, I'm not likely to discuss it further.

fl***@barrow.com (Floyd L. Davidson) wrote:
It was an hour and 19 minutes...  so I reposted.  And then
the original showed up 6 minutes later, 1:25 after it was posted.

Supernews is clogged... :-)

On Sun, 13 Feb 2005 13:29:01 -0900, fl***@barrow.com (Floyd L.
Davidson) wrote:

Both postings made it to Newsguy.  Consider yourself fortunate as
Supernews is methinks the best of the usenet news providers.  I use
news.something.sbcglobal.net in the office.  At least once per month,
ALL my postings are delayed anywhere between several hours and several
days.  At least nothing I posted has been missing in the last few
months.

I'm partial to exact definitions.  It's a bad habit of mine as I often
find it useful to know what the terms, acronyms, buzzwords, and
marketing terminology really means.  Wireless seems to be the worst as
buzzwords seem to be generated daily and some techy terms seem to
overlap.  The worst is the definitions of the var