We are responsible for fixing a wirless hotel problem. Uses about 15 access points.
Problem is, the network guy here says, that dhcp just stops working. It seems that the wireless access points are hard-wired into a switch into a router serving dhcp. The netowrk guy claims that everytime dhcp stops working, he can walk the hotel with his laprop, and find someone serving a wirless signal. He says he has seen cell phones going into some type of wireless router serving up wireless for the user.
This then knocks off the whole hotel wireless network. If he asks the customer to turn it off, it works. He claims this is the case everytime it goes down...
My theory is that the wireless access points at some point must go into repeater mode. We almost cannot get into these things ( ZYair b-420) , because they are in bridge mode, therefore dont have an ip address.
The only way that someone serving dhcp would screw with the whole hotel network would be if these things are in repeater mode?
We are confused, and are currently trying to access the internal page of these access points....
What you might want to do is either do a ping sweep and try to find out if these Access Points have been assigned a real IP address or use a console cable and reconfigure the devices to use Infrastructure (non-repeater) mode only. This would, of course, mean physical access to the device. It would be a lot easier to assign the APs IP addresses in sequential order and keep track of them for future troubleshooting purposes.
My guess(tm) is that you have more than one DHCP server running on the network. I don't know where it's hiding, or in what box, but it's there. The usual culprit is a Windoze 2003 server which enabled the DHCP server by default. It also has some nifty security features which prevents DHCP from working.
Another typical screwup is to have the DHCP server IP address duplicated by a client computah with a static IP address. This happens often when clueless users discover that DHCP had failed, and decide to assign their own static IP addresses to their own computah. They frequently punch in the IP address of the router/gateway/DCHP server as their own IP address and cause everything to get muddled.
How is this customers client configured? DHCP assigned IP's or are they playing static IP as a backup for the failed DHCP server?
Muddle. *ALL* (and I do mean *ALL*) wireless is bridging. Everything is handled at the MAC address level (layer 2). There are no IP addresses involved in bridging. The only thing the IP address of the router does is allow you access to the access point for configuration. You don't need this IP address for anything else, it will work the same with literally any unused IP address, and will not affect wireless bridging in any way. (It's not the IP address of the wireless access points).
I don't think so. In the repeater mode, the ethernet port goes comatose to the network. It wouldn't work at all in the repeater mode unless configured for a mesh. The B-420 doesn't do mesh, but I thing the B-1000 does. I'm too lazy to look it up as I doubt it's a wireless configuration issue.
What do you mean trying? They should have static IP's assigned that are accessible from your LAN. Hopefully, these IP's are not in the middle of the DHCP assigned address range or you will have yet another mess to deal with.
Sure. Download a DHCP query tool from: |
formatting link
out which server(s) are delivering DHCP IP addresses. You should have only one. I'll guess(tm) that you have more than one including one that's delivering a default route that points to a dead end (not the internet). I doubt it's a cell phone doing it.
In addition, I'll guess(tm) that your IP address plan for these 15 access points and your network is a big mess.
Any chance you're simply running out of available IP addresses for DHCP to assign? What box or server is playing DHCP server and how many IP's do you have available for assignment? If the DHCP lease time is rediculously long, the old leases will not expire in time to deal with new arrivals. This is fatal in a convention environment where literally hundreds of laptops and PDA's compete for perhaps 253 IP addresses.
You should also pay attention to roaming effects. Setup the system so that the ARP table (MAC address to IP mapping in the router) expires quickly. Run this test: 1. Connect to an access point and convince yourself that it works. 2. Now, move the laptop to another access point with the same SSID and channel. Do they track? Do you maintain the connection? Or does it go comatose as in your description? If so, your router is holding onto stale ARP table or router table entries from the initial connection and screwing up roaming.
In bridge mode it will be bridging the hotel guest's wireless network into the hotel network, but this should not stop DHCP from being served up the hotel's server. Could it be possible that the DHCP only stops working in areas where the hotel guest's signal is stronger than the access point's signal, and the guest's computers that lose access are trying to connect to the wrong SSID? With XP, often users have no idea which network their computer is trying to automatically connect to.
In any case, it's probably a bad idea to continue operating in bridge mode.
You need to go to the every access point and reconfigure the network to infrastructure mode, and at the same time assign a unique IP address to each access point so you can do remote management.
Find out which server(s) are delivering DHCP IP addresses. You should
Thanks for the advice, ya, we figured out that whoever installed this network are idiots....So that was the plan, was to install it as infrastructure...We are pretty new to this wireless thing on this level, but from what we understand, we assign each unit an ip (so we can manage it), and we set up each unit to use the same SSID, and alternate the channels that it will use wirelessly. Then instead of seeing maybe 2 or 3 access points, depending on where you are in the hotel, you will just see one...and it should work like that?
Back into it on Thursday...we will probably try a ping sweep and see if we can find the internal pages of the units, or otherwise, were climbing into ceilings with laptops...
Careful. When you declare to the client that your predicessors were idiots, the first mistake that you make, automatically puts you in the same classification in the customers eyes. You end up being required to prove that you are *NOT* also idiots. May I suggest you simply indicate that they did some "strange things" or perhaps "non-standard techniques" so that you're not required to demonstrate that you can walk on water, raise the dead, and otherwise achieve perfection at the first try.
Yep. That's the only way to make such a thing work.
Yes. Use static IP's that are out of the DHCP server IP block. With
15 access points, and an undisclosed number of potential clients, you will probably find that 253 IP's (/24) are not sufficient.
Yep. That's it. May I suggest you read *ALL* of the following "Intel Wireless Hotspot Guide". It covers just about everything you need except authorization, authentication, and payment software:
formatting link
keep a copy with me to throw at my customers. It keeps them busy while I get the work done.
I should, but there are some potential problems you should know about. Few of these hot spots offer much in the way roaming capeabilities. You can start connected to one access point, and the roaming laptop will tenaciously hang onto this access point until the signal is completely lost before switching to a better access point.
If you use all the same SSID (recommended), there is no way for an individual user to select which access point they want to connect. The result is that they usually get the first one heard, which may not necessarily be the best or the nearest access point. This is a limitation of the client softare and cannot be easily solved.
Access points located in high use areas (public areas, conference rooms, lobby) tend to get overloaded. You may want to put two or more radios in these areas.
In view of these RF related issues, I strongly suggest you pay attention to the coverage areas of the various access points.
) at 2005-08-10 08:57 Pacific Daylight Time Host 192.168.1.1 appears to be up. Host 192.168.1.50 appears to be up. Host MICRON (192.168.1.100) appears to be up. Host DELLBERT (192.168.1.101) appears to be up. Host NET44GATE (192.168.1.200) appears to be up. Host GOLEM (192.168.1.201) appears to be up. Host 192.168.1.255 seems to be a subnet broadcast address (returned 1 extra pings). Nmap run completed -- 256 IP addresses (5 hosts up) scanned in 19.71 seconds
Then immediately run: C:\\NMap> arp -a Interface: 192.168.1.11 on Interface 0x1000003 Internet Address Physical Address Type 192.168.1.1 00-0c-41-71-36-30 dynamic 192.168.1.50 00-80-c8-ac-c0-60 dynamic 192.168.1.51 00-c0-a8-7f-fe-92 dynamic 192.168.1.100 00-0f-66-14-e5-4b dynamic 192.168.1.102 00-0f-a3-17-67-01 dynamic (etc)
I got lost in a tangle of frames within frames etc. I figured this was easier.
Yep. No help. You have to read the RFC to understand what the tokens mean. It assumes some knowledge of DHCP. The IP addresses and lease times are obvious, but some of the other tokens are rather obscure. I've been doing some work with RFC-3825 and find the tool rather handy.
I recall that you're on a cable modem. I had problems getting a response from the CMTS because Comcast uses some kind of authentication scheme for DHCP. You'll have to bypass your router to see this. If lucky, you'll get a HUGE list of parameters, which are what the CMTS uses to load settings into your cable modem. If interested, I'll dig out the applicable RFC's.
What's nice is if there are two DHCP servers running, it will deliver a rather longish and messy reply. Other than sniffing, it's the only way I've found that can easily recognize multiple DHCP servers. I haven't found anything better, yet.
I use the first few letters of my ethernet card name "Intel" or "Ethernet".
I thought it was odd that you gave a link directly to the download, especially when the tool didn't work for me initially. But I prowled the web page, and they don't offer support or explanation for this particular tool. The support list has the other products, but not this one. The data sheet for this one is (empty reference).
I had to type in the name of my NIC.
I always download your software suggestions... I even have a separate folder for you ;-)
A little later, I was connected via LAN to somewhere... iConnection. Querytool showed that as expected. Then I noticed that my WiFi had also connected to someone.
QueryTool didn't report the WiFi connection very well. I selected the WiFi, and it still reported my LAN IP address and DHCP servers. It showed nothing about the WiFi, even though ipconfig liked it. I disabled the LAN, and QueryTool still showed my LAN IP, although it then did pick up the other DHCP servers.
virtualearth.msn.com was able to pinpoint my location via the WiFi, whereas the LAN shows up someplace else.
> Find out which server(s) are delivering DHCP IP addresses. You should
Nope. It send out a DHCPDISCOVER broadcast. The DHCP servers reply with a DHCPOFFER packet containing the MAC address of the DHCP server. Negotiations continue using the MAC address until the client has received a proper IP address from the DHCP server. (Note: I'm not
100% sure this is currect and am too lazy to read RFC2131). The problem is that the Weird Solutions DHCP query tool doesn't return the MAC address so one can't identify the DHCP server directly.
Yep.
Nope. Even if your PC gets stuck with the default 169.254.xxx.xxx address, DHCP query tool will still work. I intentionally set my client IP address to garbage, and the query tool produced the anticipated output from the DHCP server.
What kinda network? Wi-Fi or Cellular. I'm lost.
I'll see if I can find a better DHCP query tool. DHCPLOC.EXE from the MS Resource Kit only seems to work with an MS DHCP server. I can also build a filter for Ethereal that will only save DHCP related broadcasts and exchanges.
Find out which server(s) are delivering DHCP IP addresses. You should
I may have expected too much. This appears to return the IP address of the DHCP server that you used. I was hoping for a tool that would return the addresses of various DHCP servers. Do I actually have to install this on a PC that has a bum address?
Maybe I need to release/renew?
I'm on a network today that is seeing sporadic issuance of DHCP addresses at a suspiciously default range like 192.168.0.1, nothing resembling the address in use by most folks on the network.
I don't know that it would be much help anyway. All I will find out, if anything, is that the DHCP server has an address of 192.168.0.xxx.
Sounds like a box perhaps doing ICS. If you do an ipconfig /all and have a look at the issued dns domain name, see if it's MSHOME or something like that, can't remember exactly what it plops there.
Once you've done the ipconfig, why not try a port scanning tool on the ip address. That way if there are any ports open you should be able to fingerprint the device.
For example, if it's a router, expect port 80 to be open for web management, should get some clues there with the http header, same for other ports.
If it happens to be an MS machine doing ICS then do an NBTSTAT -A and you'll get the remote machine name table which will include the computer name and if the device is running the messenger service, the logged on username. The entry with the 16th byte set to . Note that the nbtstat is one of the very few Windows commands that has a case sensitive parameter, -a is the local name table, -A is the remote name table.
I'm not on a box that has one of these bogus addresses. They were mostly visitors with laptops. Regular uses seemed unaffected, with a couple of exceptions.
I'm not sure how many boxes there are responding to 192.168.0.xxx. What my pingsome script was seeing as a live box is unreachable... I think.
Pinging 192.168.0.6 with 50 bytes of data:
Reply from nnn.nnn.237.181: Destination host unreachable.
Ping statistics for 192.168.0.6: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
That looks like a failure, but I was only parsing on the "loss" line.
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.