Description of problem: NetworkManager sends the full kernel version as part of the DHCP packets (the second set of dhcp packets sent, anyway; the first set seem to come from dhclient but then get ignored by NetworkManager). Version-Release number of selected component (if applicable): NetworkManager-0.3.3-1.cvs20050119.2.fc3 How reproducible: Always, I think. Steps to Reproduce: 1. stop NetworkManager 2. bring all network interfaces down 3. start capturing packets using ethereal 4. restart NetworkManager 5. examine the last DHCP Discover and last DHCP request packets logged Actual results: These contain the full kernel version (as part of what is essentially the output of uname -srm) Expected results: The kernel version shouldn't be sent. Additional info: For reasons for concern about sending the kernel version, see https://bugzilla.mozilla.org/show_bug.cgi?id=57555 for the reasons that Mozilla no longer sends the kernel version in the User-Agent header. Essentially, it's an advertisement of potential security vulnerabilities.
The uname call in question is in class_id_setup in dhcpd/client.c
True, we probably shouldn't be doing this. It's kind of left over from dhcpcd.
Would just using the sysname field of the uname() call be OK in your opinion?
It seems reasonable to me, although I'm not really sure what the field is for. (dhclient doesn't seem to send it at all.)
I assume that administrators can set clients up to use a particular value in this field, say fill it with "Engineering" or "Engineering Linux" or something liek that to direct certain DHCP options at certain classes of hosts. Anyway, fixed in CVS.