| 1 |
On Mon, Jun 26, 2006 at 09:22:17PM -0400, wireless wrote: |
| 2 |
> |
| 3 |
> This cisco equipment could be filtering based on MAC addresses. |
| 4 |
|
| 5 |
Good idea, but, nope. |
| 6 |
|
| 7 |
> You could put one of the dhcp clients on the same LAN as the |
| 8 |
> server and see if they work together. |
| 9 |
|
| 10 |
They do. That was the "testing" to which I had (vaguely) referred. |
| 11 |
|
| 12 |
> If they do, then your |
| 13 |
> problem is your campus network security. |
| 14 |
|
| 15 |
I really don't think so. Again, note the two packet dumps I posted |
| 16 |
earlier. In both cases, we're on the same IP address, same physical |
| 17 |
network cable; only difference is the switch from old RedHat/Dell to new |
| 18 |
GNAP/WRAP. In both cases, networking in general works fine, inbound and |
| 19 |
outbound connections work as expected, and the DHCP request packet gets |
| 20 |
through. But, a dump of the DHCP packet on the RedHat box shows a lot |
| 21 |
more data, including an ethernet address for the client, which isn't |
| 22 |
present in a packet dump on the GNAP box. |
| 23 |
|
| 24 |
While I've been in this business too long to say that anything is |
| 25 |
impossible, it strikes me as highly unlikely that a network switch would |
| 26 |
make a decision to edit packets like this based on the receiving end's |
| 27 |
MAC address, unless the switch operater had some very specific measures |
| 28 |
in place to make that happen. That's unlikely since the networking |
| 29 |
folks are working with us on this, and saying that everything on their |
| 30 |
end should be allowing what we want. |
| 31 |
|
| 32 |
So, I'm still assuming the following: |
| 33 |
|
| 34 |
- Both the RedHat and the GNAP box receive the same data from the wire; |
| 35 |
|
| 36 |
- tcpdump functions equivalently on both GNAP and RedHat;[0] |
| 37 |
|
| 38 |
- Somewhere between the wire and tcpdump, something in GNAP is |
| 39 |
truncating the DHCP request packet, such that: |
| 40 |
|
| 41 |
a) tcpdump shows different output, and |
| 42 |
b) dnsmasq never sees the client MAC address, so (correctly) ignores |
| 43 |
the request. |
| 44 |
|
| 45 |
|
| 46 |
[0] This is the point that I currently see as the weakest in my |
| 47 |
hypothesis. We had to do some semi-emergency backpedaling in order to |
| 48 |
restore client services, so at the moment I don't have a GNAP machine |
| 49 |
that I can use to run comparisons, so I don't know whether tcpdump |
| 50 |
defaults to a shorter buffer size (or something) on GNAP than it does on |
| 51 |
our old RedHat machine. I should be able to test again tomorrow. |
| 52 |
|
| 53 |
|
| 54 |
Knowing that DHCP conversations are often confined to a single segment, |
| 55 |
it wouldn't surprise me to learn that there's some kind of tunneling |
| 56 |
operation necessary to get the broadcast DHCP request off the local |
| 57 |
segment to where it needs to go, and it also wouldn't surprise me to |
| 58 |
learn that the receiving end of that operation would be present in |
| 59 |
glibc, but left out of uclibc as too rarely used to deserve the code |
| 60 |
space. All this by way of explaining why I think it's more likely to |
| 61 |
look at GNAP as the source of the packet differences, rather than some |
| 62 |
Cisco arcana. |
| 63 |
|
| 64 |
Maybe I'll go ask the uclibc folks if this is plausible, or if I'm just |
| 65 |
confused. |
| 66 |
-- |
| 67 |
gentoo-embedded@g.o mailing list |
Archives