>Number: 32136
>Category: kern
>Synopsis: DHCP VCI not unique for some platforms
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Nov 21 17:35:00 +0000 2005
>Originator: Garrett D'Amore
>Release: 3.99.11
>Organization:
Tadpole Computer, Inc.
>Environment:
evbmips (Au1500 board)
>Description:
This is more fully discussed in http://mail-index.netbsd.org/tech-kern/2005/11/10/0005.html
For reference, here is the original problem description:
I've noticed that the NetBSD in-kernel DHCP client sends a vendor class
identifier which is made up as follows:
snprintf(vci, sizeof(vci), "%s:%s:kernel:%s", ostype, MACHINE,
osrelease);
On my Alchemy based system, this gives "NetBSD:evbmips:kernel:3.99.11"
The problem is that on some systems, this isn't enough information. For
example, on the Alchemy platform, the result given by uname -m is
"evbmips", but the result given by uname -p is either "mipsel" or
"mipseb", depending on whether the kernel is built for big or little endian.
This leads to the problem: I am often switching back and forth on CPU
endianness (to verify changes, for example) on a single unit. This is
set by nothing more than a jumper. However, I need different root
filesystems (the unit is diskless) via NFS, and right now the DHCP
server can't tell the whether I want a big or a little endian userland.
My proposal, therefore, is to add a field, like this:
snprintf(vci, sizeof(vci), "%s:%s:%s:kernel:%s", ostype, machine,
machine_arch, osrelease);
Which would give me a VCI of
NetBSD:evbmips:mipsel:kernel:3.99.11
Or for a big-endian machine
NetBSD:evbmips:mipseb:kernel:3.99.11
I realize this represents change, and there is likely to be some reason
not to change this, but it seems to me the current situation is not
quite adequate and needs fixing. Thoughts?
>How-To-Repeat:
>Fix:
A couple of suggestions were made in the thread:
a) don't change the VCI on platforms where the uname -p and uname -m match.
b) (refinement, if possible) - don't change the VCI on platforms where the uname -m is adequately descriptive (not sure if there is an easy way to tell this, perhaps just a list of platforms where it differs)?
c) change VCI to:
snprintf(vci, sizeof(vci), "%s:%s-%s:kernel:%s", ostype, machine,
machine_arch, osrelease);