On Mon, Jun 26, 2006 at 09:22:17PM -0400, wireless wrote: > > This cisco equipment could be filtering based on MAC addresses.
Good idea, but, nope. > You could put one of the dhcp clients on the same LAN as the > server and see if they work together. They do. That was the "testing" to which I had (vaguely) referred. > If they do, then your > problem is your campus network security. I really don't think so. Again, note the two packet dumps I posted earlier. In both cases, we're on the same IP address, same physical network cable; only difference is the switch from old RedHat/Dell to new GNAP/WRAP. In both cases, networking in general works fine, inbound and outbound connections work as expected, and the DHCP request packet gets through. But, a dump of the DHCP packet on the RedHat box shows a lot more data, including an ethernet address for the client, which isn't present in a packet dump on the GNAP box. While I've been in this business too long to say that anything is impossible, it strikes me as highly unlikely that a network switch would make a decision to edit packets like this based on the receiving end's MAC address, unless the switch operater had some very specific measures in place to make that happen. That's unlikely since the networking folks are working with us on this, and saying that everything on their end should be allowing what we want. So, I'm still assuming the following: - Both the RedHat and the GNAP box receive the same data from the wire; - tcpdump functions equivalently on both GNAP and RedHat;[0] - Somewhere between the wire and tcpdump, something in GNAP is truncating the DHCP request packet, such that: a) tcpdump shows different output, and b) dnsmasq never sees the client MAC address, so (correctly) ignores the request. [0] This is the point that I currently see as the weakest in my hypothesis. We had to do some semi-emergency backpedaling in order to restore client services, so at the moment I don't have a GNAP machine that I can use to run comparisons, so I don't know whether tcpdump defaults to a shorter buffer size (or something) on GNAP than it does on our old RedHat machine. I should be able to test again tomorrow. Knowing that DHCP conversations are often confined to a single segment, it wouldn't surprise me to learn that there's some kind of tunneling operation necessary to get the broadcast DHCP request off the local segment to where it needs to go, and it also wouldn't surprise me to learn that the receiving end of that operation would be present in glibc, but left out of uclibc as too rarely used to deserve the code space. All this by way of explaining why I think it's more likely to look at GNAP as the source of the packet differences, rather than some Cisco arcana. Maybe I'll go ask the uclibc folks if this is plausible, or if I'm just confused. -- [email protected] mailing list
