On 06/03/2015 20:45, Marc Joliet wrote: > First of all, thanks to everybody who responded so far. > > I wanted preface my reply to Alan by mentioning that the local sysadmin made > changes to the DHCP server that appear to have worked around whatever the > issue > is. > > I don't fully understand the error analysis (something to do with the DHCP > client reaching a particular state and sending DHCP packets that something > in-between it and the DHCP server doesn't like and that might result in vendor > dependent behaviour), but what the DHCP server now does is tell the client to > use the broadcast address as the DHCP server address (which is weird, because > the DHCP clients always switch to the broadcast address after a timeout, but > of > course I'm no DHCP expert). The affected PCs have been working normally all > day today.
In light of what you say below: I'd be interested to hear what your sysadmin has to say; dhcp is one of those things that JustWork(tm) - it uses regular tcp and nothing funny about it at all. The only thing normally between your NIC and the dhcp server is a switch, so that's what I'd be looking at. > > So the current resolution is "it works", but we still don't understand (or at > least me and my boss don't) what the underlying issue is. Hence I'm still > curious what people who know these technologies better than me think. > > Also, I suppose it was confusing to say that the switch never saw the packets. > The way this was determined was by post-mortem log inspection; AFAIK we didn't > do any live inspection on the switch. Based on the workaround, the conclusion > we came to is that the switch must have dropped the packets (for whatever > reason) without logging that it did. > > Am Fri, 6 Mar 2015 08:01:44 +0200 > schrieb Alan McKinnon <alan.mckin...@gmail.com>: > > [...] >> I've seen similar things many times myself (but nevr on Intel network >> kit so far) >> >> A lot of reading and Googling usually leads to the solution: >> >> - firmware upgrade for the hardware > > OK, I can look into that. > >> - use the correct driver (this is often non-obvious) >> - try the in-kernel driver vs any out-of-tree vendor driver > > All PCs run with the e1000e in-kernel module. I think the Fedora systems run > 3.18.7, so it's about as current as it can be, too. Could it really be that > the > kernel selects the wrong driver? > >> - apply driver parameters designed to work around buggy hardware (this >> often involves (much reading) > > I will also consider that. I see that the kernel sources contains > documentation for the e1000e driver that I can look at. I wasn't aware you had e1000e hardware - those are about as reliable as they come. I've used many of them and never had the slightest trouble at all. By all means study up on firmware and driver options - if you don;t know much about that area it's very illuminating to find out more. But based on experience I'd say the chances of finding an oddity with e1000e are slim, and I'd be looking at a misconfigured switch. There are some strange switches out there that let you make crazy configuration, like eg blanket drop all broadcast traffic on one or more ports. That's where I'd be looking first. -- Alan McKinnon alan.mckin...@gmail.com
