Wireless Network in Public Places Options

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.

Reply to
Jeff Liebermann
Loading thread data ...

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

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

lol

Reply to
Smowk

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.

Reply to
Floyd L. Davidson

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.

Reply to
Jeff Liebermann

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.

Reply to
Jeff Liebermann

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

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.

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

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.

formatting link
'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:

formatting link

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.

formatting link
formatting link

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.

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.

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

Reply to
Jeff Liebermann

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.

Reply to
Floyd L. Davidson

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:

formatting link
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:

formatting link

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.

formatting link

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: snipped-for-privacy@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.

Reply to
Jeff Liebermann

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.

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

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.

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

Reply to
Floyd L. Davidson

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.

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

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.

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

Reply to
Floyd L. Davidson

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

Reply to
Floyd L. Davidson

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

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?

formatting link
formatting link
formatting link

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

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.

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:

formatting link
reply already.

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

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.

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.

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:

formatting link
line... ICMP has to be working in order to get a response.

It says router on the front panel.

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.

I did? Kindly re-read the beginning of my: snipped-for-privacy@4ax.com 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.

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.

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.

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.

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:

formatting link
formatting link
'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.

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.

formatting link
's say I'm suspicious.

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: snipped-for-privacy@barrow.com 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.

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.

Reply to
Jeff Liebermann

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

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

Reply to
Floyd L. Davidson

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

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

Reply to
Smowk

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.

Reply to
Jeff Liebermann

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.

Reply to
dold

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.