Has anyone ever encountered a problem where after change made to the Canopy network (Frequency or color code) that results in customer routers (mainly certain brands of Linksys) will lockup or stop accepting DHCP. We made just a few changes to our network recently and now customers with Linksys WRT54G’s and associated models cannot accept DHCP resulting in mass phone calls and unhappy customers.
Any suggestions would be helpful as we have pulled our hair out on this one.
Everything we do is static so that has not come up for us.
What are you using for a DHCP server?
It’s just dhcp server (version 3) on linux.
“dhcp3-server: This is the DHCP server from version 3 of the Internet Software Consortium DHCP package”
Hey!
I’m reasonably sure that the Linksys uses a proprietary method of negotiating the ‘link speed’ which is unique to Cisco. Not radically, different than the norm, obviously, but I have seen many instances where I have had to hard-code the link speed on the Canopy device to keep the client connection stable with a Linksys router.
Just wondering, in context, if your client SM are set to auto-negotiate the link speed: I would try hard-coding to 10FDX or 10HDX and see what happens. Perhaps that would allow DHCP to pass?
I am suspecting buggered bridge tables. This happens once in a while.
We reboot anything with a bridge table. AP’s, tower switches, root switch, and router. You might have to reboot the DHCP server as well or flush all the leases.
DHCP is a PITA on a bridged network. You’d be better off going with PPPoE as it will force the connection to reconnect if it drops.
this happened to us a few years ago when we first started VLaning sites. the only solution was to replace the router. happened for about a month then stopped. hasnt happened since.
We’ve had a few problems here and there with that happening and upgrading the firmware and powercycling the router usually fixed the problem.
Hello, I work with James, who originally started this thread, and have a bit more information on this particular problem.
As I haven’t examined a router as it was having a problem, I can’t offer anything more than circumstantial information that seem to point towards the problem. First, I wrote some Linux scripts that tallied up DHCP requests by device, looked up the device manufacturer from the MAC address, and located the particular device in the bridge tables of the SMs. From this it was clear that there is a bunch of Linksys routers, and only Linksys, that is requesting an address anywhere from 1-3 thousand times a day. We have seen something similar with a certain version of Belkin routers, but that seemed to be a problem with the router itself, where this seems to have appeared all of the sudden.
Tcpdump showed that most of these requests are “discover” and “offer” packets, with very little “request” or “ack”. I went back in the logs and verified that before the obvious problems started, there was much more reasonable DHCP conversations going on. I’ve uploaded a couple graphs (PDFs) I made representing the various aspects of the DHCP traffic over the past two and half months.
Graph - stacked (pdf)
Graph - not stacked (pdf)
It is clear something is going on, I’m just not sure if the routers aren’t sending “request” packets, or if they simply aren’t making it back to the DHCP server. This could be verified with a packet sniffer in between a known problematic router and the SM, but that may be a bit difficult to arrange.
We greatly appreciate any insights into this.
Thanks,
Adam
have you turned on any protocol filtering in the sm’s?
i 2nd the notion that pppoe would be a much better method then dhcp over a bridged network. multiple benefits to using this type of authentication vs a wide open scheme. are you just letting anyone on your network with a canopy radio pull a dynamic address from your dhcp server? no mac authentication? seems this is a discussion for another thread ;D
i guess it’d be nice to know what “small changes” were made to the network which resulted in this issue you are having.
its been a while since you posted, is this resolved i assume? would be good of you to post your fix for this if it is resolved.
newcastle wrote:
Just wondering, in context, if your client SM are set to auto-negotiate the link speed: I would try hard-coding to 10FDX or 10HDX and see what happens. Perhaps that would allow DHCP to pass?
If you force full-duplex and the other side is auto-negotiating, you will CREATE problems. When you force speeds, you disable auto-negotiation. Thus, the side that is set to auto-negotiate will default to half-duplex. Your resulting configuration now has one side set to full-duplex with the other side set to half-duplex. This is a recipe for dropped packets and collisions!!! (because you are in effect disabling CSMA/CD on the full duplex side while the other is still in half duplex mode.)
There's no such thing as Linksys having a 'proprietary' auto-negotiate technique. The best recommended practice with modern equipment is to auto-negotiate all the time, period.
Cisco made some older 100Mbps ports, back in the mid 90s, that did not auto-negotiate, they only worked at 100/full if you forced it on both sides of the link. This may be where the rumor comes from. So if you plug a cisco 7206 with PA-FE-TX or 3600 with NM FE port, then you have to either run both sides as half duplex by leaving all settings to default, or force both sides to full duplex.
Hey!
Yeah, you would have to hard-code both ends of the link. I get that.
Cisco weirdness aside, Linksys don’t play well with Canopy from an auto-negotiate standpoint. The vast majority of routers requiring restarts on our network are Linksys. When you look at the SM, what you find is that the Canopy is set to auto-negotiate, yet the link speed to the Linksys is 10HDX. Far, far too often for it to be coincidental. Only with Linksys. Hard-coding the SM side to 10HDX dramatically reduces the tendency for the router to need a reboot.
Whether that’s due to sunspots or tide cycles or what, it is what it is. Thus my thought for hard-coding the link, which was admittedly a shot in the dark. :roll:
newcastle wrote: Hey!
Yeah, you would have to hard-code both ends of the link. I get that.
Cisco weirdness aside, Linksys don't play well with Canopy from an auto-negotiate standpoint. The vast majority of routers requiring restarts on our network are Linksys. When you look at the SM, what you find is that the Canopy is set to auto-negotiate, yet the link speed to the Linksys is 10HDX. Far, far too often for it to be coincidental. Only with Linksys. Hard-coding the SM side to 10HDX dramatically reduces the tendency for the router to need a reboot.
Whether that's due to sunspots or tide cycles or what, it is what it is. Thus my thought for hard-coding the link, which was admittedly a shot in the dark. :roll:
How does one go about setting the WAN link speed on the factory linksys firmware? I don't recall seeing that option anywhere. I have all my units set to autonegotiate 10HD/FD and that seems to work alright. The links always come up in 10FD.