passing multiple params to modules via dhcpd.conf

Hi,

I posted this question to the LTSP mailing list but there wasn't a clear
solution. I built a small thin client network using the LTSP 4.1 package.
Most of the machines work fine with the exception of some old Compaq
Deskro 4000s that use the TI ThunderLan network adapter (tlan.o).

The tlan NICs tend to autoneg into half-duplex mode. The terminal server
and all of the other machines attached to the net switch are full-duplex.
A thin client that comes up in half-duplex is unusable because the
interface is too slow.

I know that by running 'modprobe tlan duplex=2 speed=10' I can force
full-duplex. The LTSP ML people told me to put in the dhcpd.conf file as
an option for each work station like this:

option option-128 code 128 = string;
option option-129 code 129 = text;

....

option option-128 e4:45:74:68:00:00;
option option-129 "NICOPT=duplex=2 speed=10";

The only part that gets passed is the "duplex=2". The rest seems to get
chopped off because of the space. Since the tlan module requires both
parameters, it won't load. I'm pretty sure the linuxrc script processes
the string it gets from the dhcpd.conf (somehow).

Is there a special way to format this in the dhcpd.conf so that multiple
parameters can be passed to the kernel module via linuxrc?

I looked through the "Defining New Options" of the dhcp-options man page.
I may be able to define a Record to pass multiple strings or text. I'm
new to all of this, any suggestions?

-kevin

Kevin Valentine <(E-Mail Removed)> wrote:
> Hi,
>
> I posted this question to the LTSP mailing list but there wasn't a clear
> solution. I built a small thin client network using the LTSP 4.1 package.
> Most of the machines work fine with the exception of some old Compaq
> Deskro 4000s that use the TI ThunderLan network adapter (tlan.o).
>
> The tlan NICs tend to autoneg into half-duplex mode. The terminal server
> and all of the other machines attached to the net switch are full-duplex.
> A thin client that comes up in half-duplex is unusable because the
> interface is too slow.
>
> I know that by running 'modprobe tlan duplex=2 speed=10' I can force
> full-duplex. The LTSP ML people told me to put in the dhcpd.conf file as

Stop *right* *there*. If you're forcing ethernet links to full duplex, there's
a pretty good chance you're doing something wrong. If you're only forcing one
side, it's virtually guaranteed.

Before you go further, first familiarize yourself with
<http://www.scyld.com/NWay.html>.

Once you've browsed over that, check to make sure that both ends (the switch
and the tlan nic) really are performing actual autonegotiation, not just
autosense. If you're forcing the nic to full duplex, 99.9% of the time that
means that you're also disabling the autonegotiation protocol, meaning the
other end at best can do autosense. Since it's impossible to sense duplex,
only speed, the other end will fall back to half duplex. You end up with a
duplex mismatch; one end sees a bazillion collisions, the other end just sees
lots of crc errors.

The ideal situation is to make sure that both ends really are set for full
autonegotation. If that doesn't work (ie, one end or the other has a design
flaw of firmware bug), and you have no choice but to hardcode, make sure you
do both ends the same.

--
Frank Sweetser fs at wpi.edu
WPI Network Engineer
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC

On Sat, 11 Dec 2004 01:12:32 +0000, Frank Sweetser wrote:

> Stop *right* *there*. If you're forcing ethernet links to full duplex,
> there's a pretty good chance you're doing something wrong. If you're
> only forcing one side, it's virtually guaranteed.
>
> Before you go further, first familiarize yourself with
> <http://www.scyld.com/NWay.html>.
>
> Once you've browsed over that, check to make sure that both ends (the
> switch and the tlan nic) really are performing actual autonegotiation,
> not just autosense. If you're forcing the nic to full duplex, 99.9% of
> the time that means that you're also disabling the autonegotiation
> protocol, meaning the other end at best can do autosense. Since it's
> impossible to sense duplex, only speed, the other end will fall back to
> half duplex. You end up with a duplex mismatch; one end sees a bazillion
> collisions, the other end just sees lots of crc errors.
>
> The ideal situation is to make sure that both ends really are set for
> full autonegotation. If that doesn't work (ie, one end or the other has
> a design flaw of firmware bug), and you have no choice but to hardcode,
> make sure you do both ends the same.

Thank you Frank. I'll check out that link and the config for each NIC. I
bet have something wrong with my network because I used these boxes before
without much issue. I do have some 3c509 cards on the network which I've
read only support half-duplex (unless they're 3c509b). That's the only
thing I can think of that has changed.

-kevin

Kevin Valentine <(E-Mail Removed)> wrote:
> Thank you Frank. I'll check out that link and the config for each NIC. I
> bet have something wrong with my network because I used these boxes before
> without much issue. I do have some 3c509 cards on the network which I've
> read only support half-duplex (unless they're 3c509b). That's the only
> thing I can think of that has changed.

If you're unable to get the cards you have to work, I can reccomend Netgear
FA311 network cards. They're pretty cheap, readily available, and work well.

--
Frank Sweetser fs at wpi.edu
WPI Network Engineer
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC

On Sat, 11 Dec 2004 01:50:49 +0000, Kevin Valentine wrote:

> On Sat, 11 Dec 2004 01:12:32 +0000, Frank Sweetser wrote:
>
>> Stop *right* *there*. If you're forcing ethernet links to full duplex,
>> there's a pretty good chance you're doing something wrong. If you're
>> only forcing one side, it's virtually guaranteed.
>>
>> Before you go further, first familiarize yourself with
>> <http://www.scyld.com/NWay.html>.

I actually read this about a year ago but it didn't sink, perhaps it still
hasn't...

>> The ideal situation is to make sure that both ends really are set for
>> full autonegotation. If that doesn't work (ie, one end or the other has
>> a design flaw of firmware bug), and you have no choice but to hardcode,
>> make sure you do both ends the same.

OK, I went to the office this weekend and verified that all other devices
are configured for auto-negotiation and they are. I also removed any
suspect boxes from the network, i.e. boxes with 3c509 NICs. The tlan
driver displays that it's auto-negotiating yet still it senses half-duplex
mode.

I would prefer not to force full-duplex but I may have to. Actually, I
would prefer not to use these damn NICs but they're integrated into the
mobo so they're cheap. The two non-profit orgs that I'm helping have
mountains of these Compaqs. Getting new cards may not be an option. I'll
have to see if they can budget that in but I'm sure they'll say no. It's
been hard enough getting them to even consider thin clients.

The ideal would be if I could pass both the speed and duplex parameters in
the dhcpd.conf file. Any ideas on that one?

-kevin

On Mon, 13 Dec 2004 01:29:13 +0000, Kevin Valentine wrote:
> The ideal would be if I could pass both the speed and duplex parameters in
> the dhcpd.conf file. Any ideas on that one?

Answering my own question... Looks like any whitespace character other
than actual space (0x20) between parameters should work. I tested it out
with a \n and the linuxrc script takes it. I haven't tested it with all
whitespace chars and don't plan to.

I modified my dhcpd.conf to look like this:

option option-128 code 128 = string;
option option-129 code 129 = text;

....

option option-128 e4:45:74:68:00:00;
option option-129 "NICOPT=duplex=2\nspeed=10";

Too bad it freezes the NICs that didn't default to using full-duplex.

-kevin