Homer, There are two further tests you could try to confirm/deny a prob with your dhcp server, without fiddling with the dhcp server itself
1. Temporarily replace the ABO with a AP in client bridge mode (indoor/outdoor/total, dhcp/static - all should give the same result). The AP handles this differently and I think you will have no prob getting a (or many) dhcp leases to client pc(s) behind the AP and browsing. The clients on the ethernet side of an AP(x) require the real "offer" header, not the BootP message. 2. Temporarily regress the troublesome ABO to v1.43 available on line at sB. I believe this behaves differently too. In effect the ABO "sub-leases" its own ip information to the client pc - as long as the ABO gets a lease so does the client. All normal traffic (incl offer) is passed straight through to the pc mac address, and you will be able to obtain a dhcp lease at the pc and browse etc. A by-product of this is that the AP does not have a unique ip so its impossible to manage it thro SNMP (ie no SimpleNMS) - this is unlikely to be a tenable long term solution. Nobody said it would be easy :( If either / both these work correctly you are on the way to confirming a prob with the dhcp server. I suppose its worth mentioning that if you have other ABs with v1.43 or less, it might be best not to upgrade before solving this issue. Happy hunting bw ----- Original Message ----- From: "Brian Winter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 22, 2003 7:34 AM Subject: Re: [smartBridges] Clients can't DHCP > Hi Homer, > > I think everything you've observed fits the same prob I described / fixed in > my setup. > > > > Not my experience when changing IPs on a desktop.. Laptop I just eject > > and put the card back in.. Well, till Windows has a brainfart, and then it > > needs a restart.. My testing is behind my firewall... I've assigned > > 10.x.x.x to the SB units, and the DHCP server is handing out 192.x.x.x.. > > Your saying I can skip the reboot after changing from static to DHCP > > assigned? > > No, you're right there. The change between static and dynamic needs at > least disable/enable (a few secs via "Network and Dial-Up Connections") but > occasionally even that gets confused and requires a Windoze restart. I'm > using Win2KPro to manage sBs, XPPro (desktop with ethernet/AB or > ethernet/AP) and Win2KPro (laptop with either ethernet/AB or Orinoco gold > (waste of money)) clients, and Linux for clever stuff. I've no experience > of ME. > > > > Let me describe my layuot again: > > dhcp server - switch - appo (backhaul) appo - switch - appo - abo > > > > At the second switch I can see the DHCP server response coming back to > > the client.. I can at the first as well, but I did check it on the second > > to make sure it's getting through.. > > Yes, that fits nicely. The thing to check is that the response you see at > the final appo is a "broadcast" (addressed to ff-ff-ff-ff-ff-ff-ff-ff) and > not a "unicast" directed at the client pc (mac#) on the other side of the > abo. The abo will not let it thro. The client pc mac# is further down the > message, not in the header where you might expect it. > > My work was with AB indoor but I guess the same latest software. > > As a sideshow, I think you'll find that if you set your abo to dynamic even > that would correctly get a dhcp lease (check that you can see it from > SimpleNMS) as that only needs to see a unicast reply (dhcp offer message > addressed to it directly). The prob lies in the way the AB hands on the > clients lease. > > > > > > 3) I stuck an Orinoco silver in my laptop, and got the DHCP response. > > > > Went > > > surfing just fine. > > > .... and not passing through an AB to get a dhcp lease ?? > > > > Correct.. It attached to the last APPO in the above diagram directly.. > > Worked fine.. > > The Orinoco wants to see its mac address in the header of the reply (as > would the abo in dynamic) - and thats where it is. This is not a "BootP" > transaction like the one your client pc on the other side of the abo is > trying to make. > > > > You said something in another post that I might be not understanding > > correctly, but after reading the FAQ you pointed to I understand it to be > > saying that I set the ABO to DHCP and it hands the IP of to the PC.. I'm > > waiting on everything to boot back up now and will try that.. > > Well not quite - the faq is a little confusing, and I only really understood > it after I had finished. In the end it doesn't matter whether you have your > abo working dhcp or static. Its a seperate ip address negotiate in its own > right (or fixed). The bit I struggled to get my head around was that, > whatever the ab was doing to get itself on the network, the client pc mac# > should never appear in the header of the reply message - the AB will block > it. The reply is a brodcast which the ab is transparent to. If you find > its not a broadcast message, then you might try changing your dhcp server > (or reconfig your existing one for BootP if you have that level of control > over it - I didn't). > > Good luck > Brian > > > ----------ANNOUNCEMENT---------- > Don't forget to register for WISPCON IV > http://www.wispcon.info/us/wispcon-iv/wispcon-iv.htm > > The PART-15.ORG smartBridges Discussion List > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) > Archives: http://archives.part-15.org > ----------ANNOUNCEMENT---------- Don't forget to register for WISPCON IV http://www.wispcon.info/us/wispcon-iv/wispcon-iv.htm The PART-15.ORG smartBridges Discussion List To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) Archives: http://archives.part-15.org
