Wireless Network in Public Places Options

[Jeff Liebermann]

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

Nope. 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.

 

[Smowk]

Nope. 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.

this is good if i'm building my own access point...but...

lol

 

[Floyd L. Davidson]

Again, this cannot be done at the IP level by tweaking the routing
table even if every client were trustworthy. There would be nothing

A WRT54G router with the correct route table does it quite well.

Also, without any control, everyone would also get everyone else's
broadcasts.

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

Therefore, it has to be one at with a bridge/switch at
the MAC level.

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

 

[Jeff Liebermann]

A WRT54G router with the correct route table does it quite well.

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.

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

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.

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

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]

this is good if i'm building my own access point...but...
lol

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.

 

[Floyd L. Davidson]

Using routeing to keep wireless clients seperated will only work if
the clients can be trusted.

Not necessarily true.

For example, I can easily setup a phony
DHCP server on a wireless laptop that will deliver a creative IP
address and gateway.

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.

I think route that IP address to the real
wireless access point and router going to the internet. Instant "man

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...

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.

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!)

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.

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.

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.

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

(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.

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.

In a common shared network, broadcasts go to every machine on the
network.

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

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.

Well, 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.

 

[Jeff Liebermann]

Not necessarily true.

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.

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.

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.

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.

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.

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.

Nope. 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.

So is passive sniffing.

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.

I agree that can be done.

If it can be done, it will 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;

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

and 2) advise customers that they are responsible for encrypting
their data sufficiently if industrial spying is a significant
concern to them.

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".

(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!)

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

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.

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.

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

It'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.

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

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.

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

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.

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

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.

Well, 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.

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).

 

[Floyd L. Davidson]

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

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.

There is no wireless to wireless "route" but there is a wireless to
wireless "bridge".

If you install the *wrong* equipment.

I'm not sure how the WRT54G works.

So I noticed.

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

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.

Actually, you'll find passive sniffing to be somewhat of a challenge.

It isn't.

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

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.

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.

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.

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

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

and 2) advise customers that they are responsible for encrypting
their data sufficiently if industrial spying is a significant
concern to them.

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".

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

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

Well, a simple traceroute will usually detect the extra hop.

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

Sigh. AP's don't route...they bridge. AP's don't have routers. AP's

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

Think bridging, not routing.

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

It's possible that your customized firmware WRT54G firmware does it
correctly. However, I'm suspicious. It's easy enough to test.

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...

I just
tried it with my BEFW11S4 and my laptop can easily see the other
wireless clients on the LAN.

Wrong equipment, wrong results.

Nope.

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.

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.

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.

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.

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

Please pardon my suspicious nature.

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.

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

See above.

 

[Jeff Liebermann]

If you *can't* get the AP to bridge, then all this esoteric
techie "commentary" of yours means nothing.

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.

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.

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.

So I noticed.

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.

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.

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.

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

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.

I'm sure the hotel's General Counsel would approve, once another
line is added:
"The customer is responsible for their own data encryption."

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

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

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.

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

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.

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

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.

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...

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.

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.

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.

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

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 Psuedo VLAN.pdf

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.

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.

See above.

I was hoping a for a bit more detail. In:
(e-mail address removed)
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.

 

[Floyd L. Davidson]

We may be arguing semantics here.

You are. Please stop.

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

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

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.

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

Had I known it this discussion would grow to acrimonious levels

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

However, I'm weird and prefer technical debates to product searches.

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

Well, I have a WRT54G v1.1 sitting in the office that I could test.

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.)

I'm not thrilled with the time it takes to replace the firmware, but

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.)

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.

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...)

Oops, you're half right.

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??)

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.

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

I don't suppose it would help if I repeat myself once more.

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

My contention is that

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

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.

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.

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.

Imagination is always going to be a point of contention.

I agree that it's a
good idea to test before one posts, but that's also impractical and
time consuming.

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.

However, I wanna do my own testing first.

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.

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 Psuedo VLAN.pdf

You 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!)

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.

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.

I was hoping a for a bit more detail. In:
(e-mail address removed)
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.

That is not required to separate wireless clients.

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.

"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'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.

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.

 

[Floyd L. Davidson]

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

We may be arguing semantics here.

You are. Please stop.

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

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

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.

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

Had I known it this discussion would grow to acrimonious levels

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

However, I'm weird and prefer technical debates to product searches.

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

Well, I have a WRT54G v1.1 sitting in the office that I could test.

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.)

I'm not thrilled with the time it takes to replace the firmware, but

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.)

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.

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...)

Oops, you're half right.

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??)

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.

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

I don't suppose it would help if I repeat myself once more.

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

My contention is that

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

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.

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.

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.

Imagination is always going to be a point of contention.

I agree that it's a
good idea to test before one posts, but that's also impractical and
time consuming.

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.

However, I wanna do my own testing first.

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.

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 Psuedo VLAN.pdf

You 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!)

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.

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.

I was hoping a for a bit more detail. In:
(e-mail address removed)
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.

That is not required to separate wireless clients.

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.

"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'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.

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.

 

[Floyd L. Davidson]

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

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...

 

[Smowk]

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

No problems here...sorry for trolling, but it's my purpose in life i think

 

[Jeff Liebermann]

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

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.

You are. Please stop.

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 various types of
bridges.

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

Take any government printed map and lay it on a flat table. The map
lies flat, not round. If the earth were round, then maps would also
be round. What more proof do you need when various agencies of the US
government all produce flat maps?
http://www.flat-earth.org
http://www.alaska.net/~clund/e_djublonskopf/Flatearthsociety.htm
http://www.lhup.edu/~dsimanek/febible.htm

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

I'm listening. I may be a bit slow and stubborn as I really do prefer
to understand how things work and why things happen. I'll readily
admit that I only have a superficial knowledge of the WRT54G and
almost no knowledge of the various firmware mutations. However, none
of my assertions are specific to the WRT54G. A wireless router is
nothing more than an access point with a router glued onto a switch
where one of the switch ports goes to the router section. I've used
all three blocks both separately and together in various combinations.
If together, it's called a wireless router. If separated, they're an
access point, ethernet switch, and ethernet router. Such combinations
are found in other products other than the WRT54G.

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

I prefer testing to prove (or disprove) my "facts". Would it help if
I write it up as an FAQ thereby gaining some form of authoritative
image?

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.)

Yes, sir. I'll have some time on Tuesday evening. If it's as easy as
you claim, I should know who's correct in short order.

To what purpose?

I don't claim a monopoly on wireless knowledge and often find it
helpful to ask those that know more than I about things I know little.
The exercise is called "learning" and the process is called "asking
for help". There are several people on the thirdbreak.org mailing
list with considerably more experience in setting up and operating
wireless hot spots than me. Also, if the merits of my argument are
insufficient to convince you, perhaps others can do better. You
should be able to read the responses from the archive:

http://www.thirdbreak.org/pipermail/wireless/2005-February/thread.html
One reply already.

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.

Patience. Got any favorite firmware for the version 1.1 router? I
was thinking Sveasoft Satori 4.0.

(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...)

Well, I tested two today. Both are local coffee shops.

Hot spot #1 was populated with 4 laptops (plus mine). Two XP machines
and two Mac IBooks. I could see both XP laptops with Network
Neighborhood. I could ping all 4 machines from my laptop. All 4
laptops showed up in my arp table (arp -a). The router was a WRT54G
but I couldn't easily determine the version.

Hot spot #2 was about the same. Only one XP laptop present. I could
ping it, but could not see it with Network Neighborhood. File sharing
is apparently disabled or the firewall does not have file and print
sharing exception checked. I couldn't tell what access point or
router was being used. The sticker on the door was "AMD Hotspot".

So, we have two hotspots that can move traffic between clients without
going through the router. I'll see if I can find some more. I
suspect that Starbucks and T-Mobile use better access points.

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.

Who said anything about the WRT54G in the traceroute? I was talking
about a man in the middle attack using a laptop with a spoofed access
point, spoofed DHCP server, and software router (with capture or
redirection software) running on the laptop.

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

Traceroute requires that ICMP Time Exceeded response is functional.
Traceroute packets have very small TTL values. Each router decrements
the TTL value until it hits zero. A TTL of 1 will get the first
router to respond. TTL=2 for the 2nd router. TTL=3 for the third,
etc. More details:
http://www.freesoft.org/CIE/Topics/54.htm
Bottom line... ICMP has to be working in order to get a response.

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

It says router on the front panel.

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.

Try this little test. Go to whatever page in the WRT54G web
configuration that reports traffic statistics in the router section.
Now, generate some traffic between two wireless computers through the
WRT54G. Netstat -r should also show per-interface statistics. Do the
router statistics increment? Nope. That's because none of the
packets are going through the router section. Therefore, there's
nothing you can do in the router section that will affect traffic in
the access point section between wireless clients. Same with wired
PC's plugged into the LAN ports. The packets don't hit the router
section.

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.

I did? Kindly re-read the beginning of my:
(e-mail address removed)
where I clearly proclaim:
"Nope. 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."
That's called a disclaimer. I make it habit of posting such
disclaimers when I'm not really 100.0% sure of what I'm posting. I
did the same in several other places where I wasn't 100.0% sure. If
I'm wrong, I expect a correction, not abuse.

You missed the point: It affects a lot more than Layer 2 when it
hits a router. Does it get routed, or not?

I say that traffic between wireless clients does NOT get routed. You
say otherwise. I can prove my contention by simply monitoring the
traffic that goes through the router. If wireless to wireless traffic
does not increment the router section traffic counters, then it's
doesn't go through the router.

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!)

A switch maps destination MAC addresses to ethernet ports. A VLAN
segments the ports into separate switch domains by tagging the packets
with the VLAN number. Everything is done on Layer 2 with no IP
addresses involved.

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.

Ok. I'll accept that as valid criticism. I do tend to have a short
temper when irritated and do tend to say dumb things. I'm not sure
what I'm going to do about it, but I'll at least try to be more
diplomatic in the future.

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

I eat, drink, breath, and work with equipment. It's a constant
learning exercise. I'm one of those that takes things apart BEFORE I
plug them in. If you dive into my web pile photo collections:
http://members.cruzio.com/~jeffl/pics/
http://jeffl.ihwy.com
you'll see a few photos of equipment I've torn apart, dissected, and
sometimes repaired successfully. I'm not sure what gave you that
erroneous impression.

That is not required to separate wireless clients.

OK, so you're not using a VLAN to separate wireless clients. It's odd
that a company would produce a wireless virtual VLAN product line when
such things are allegedly easily done without a VLAN.
http://www.cpx.com/whitepapers/Compex Psuedo VLAN.pdf
Let's say I'm suspicious.

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.

Well, yes. ICMP and UDP ping do work at the IP level and honor
routing. The conventional access points DCHP server delivers
255.255.255.0 as the netmask making all the machines on the wireless
LAN visible to each other. However, I can see everyone at the MAC
level. If the requirement is to only be invisible at the IP level,
then you're absolutely correct. The routing table you posted in:
(e-mail address removed)
will work as you described. However, if the requirement is to remain
invisible at the MAC level, then I can still see other wireless
devices at the MAC level. I'm not sure how much damage I can do with
this, but I'm sure something can be done.

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?

Thanks. So you tried to ping between wireless clients and it didn't
work. Now, it's my turn to try the same thing. If you have a Linux
box or Live CD handy, you might try using arping to ping by MAC
address.

 

[Jeff Liebermann]

No problems here...sorry for trolling, but it's my purpose in life i think

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

 

[Floyd L. Davidson]

Take any government printed map and lay it on a flat table. The map
lies flat, not round. If the earth were round, then maps would also
be round. What more proof do you need when various agencies of the US
government all produce flat maps?

Excellent example of the logic you've been using. Now go buy a
globe, but don't get if from a US government agency.

 

[Jeff Liebermann]

Excellent example of the logic you've been using. Now go buy a
globe, but don't get if from a US government agency.

I already have a globe. Actually, I have two. An inflatable world
globe and an inflatable one of the night sky (that glows in the dark).
When all the hot air is removed from the globe, it lies quite flat as
one would logically expect from a flat earth.

Anyway, I get the point. You don't like my humor. I'll try to cease
and desist, but it's gonna be difficult. I never could resist such
temptation.

Anyway, let's give this a rest before we both begin to get angry. PBS
is doing The Verbier Festival concert with up to 16 (piano) hands and
I wanna watch.

 

[dold]

I think (not sure) that some of the higher end switch/routers made for
wireless hot spots do this by default.

A Google search of
wireless bridge "client to client"
turns up a bunch of hits with obvious phrases like "which prevents
client-to-client traffic", and "Intra-cell blocking to prevent
client-to-client snooping" .

Orinoco AP-600, AP4000, Vivato VA2200, Cisco, 3com, Minitar
I didn't see any Linksys in the first few pages that I looked at, but the
concept certainly is there for some of these APs.

The 3com A+G is $500.