[9fans] DHCP weirdness?

[9fans] DHCP weirdness?

[Dan Cross]

After pulling to my fileserver yesterday for the first time in a couple
of weeks and rebooting, I found that DHCP was no longer working.
Here's the configuration: I have a standalone file server on the same
network with a diskless CPU server (well, it boots locally and has a
disk to hold swap and a secstore, but I don't think that's relevant).

 From what I can see, dhcpd on the CPU server responds to the client,
but the client ignores the response.  That is, I can see dhcp requests
and on the network while running snoopy, and /sys/log/ipboot shows that
responses are being sent, but the client eventually times out and asks
me for other boot information.

I rebuilt everything on the system, including kernels and 9load (on the
client), but no luck.  Has anyone else seen this behavior?

	- Dan C.

Re: [9fans] DHCP weirdness?

[David Presotto]

I think rob saw this also.  Could you send me the ip/ipconfig line
that you're using.  I changed it to fix arg processing and sysname
defaulting (i.e. setting something useful in /net/ndb's sys= entry)
but can't see what would have caused things to be completely ignored.

All our systems run at boot.  Perhaps I broke something for systems
running ipconfig out of termrc.

Re: [9fans] DHCP weirdness?

[Sam]

Oddly enough, we're currently experiencing problems
that we only just discovered about 30 minutes ago.
It started with Brantley noting that our clients
were sending dhcp request messages on average about
one every two seconds.  He rebooted to see if it
would go away and now he can't get a terminal.
We replaced dhcpd on April 20 via replica/pull.
I guess we haven't rebooted our terminals since then.

We're using the ``proper'' plan9 setup with diskless
terminals and separate cpu/fs servers.

/sys/log/ipboot contains lines of the form:
	edsac Apr 24 12:42:37 not bootrequest

We replaced dhcpd with an older version, restarted it,
and all seems to be back to normal.  It is indeed
hard to use yesterday without singing. :)

Sam

On Thu, 24 Apr 2003, David Presotto wrote:

> I think rob saw this also.  Could you send me the ip/ipconfig line
> that you're using.  I changed it to fix arg processing and sysname
> defaulting (i.e. setting something useful in /net/ndb's sys= entry)
> but can't see what would have caused things to be completely ignored.
>
> All our systems run at boot.  Perhaps I broke something for systems
> running ipconfig out of termrc.
>

Re: [9fans] DHCP weirdness?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

Odd, our sources for dhcpd haven't changed since sep 2002 and our
binary was last made Feb 15th.  However, I see that the dhcpd on
sources was made Apr 20th by rsc.  It looks like there's something
rotten in sources, perhaps a library.

[-- Attachment #2: Type: message/rfc822, Size: 2657 bytes --]

From: Sam <sah@softcardsystems.com>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] DHCP weirdness?
Date: Thu, 24 Apr 2003 12:50:13 -0400 (EDT)
Message-ID: <Pine.LNX.4.30.0304241236160.25655-100000@athena>

Oddly enough, we're currently experiencing problems
that we only just discovered about 30 minutes ago.
It started with Brantley noting that our clients
were sending dhcp request messages on average about
one every two seconds.  He rebooted to see if it
would go away and now he can't get a terminal.
We replaced dhcpd on April 20 via replica/pull.
I guess we haven't rebooted our terminals since then.

We're using the ``proper'' plan9 setup with diskless
terminals and separate cpu/fs servers.

/sys/log/ipboot contains lines of the form:
	edsac Apr 24 12:42:37 not bootrequest

We replaced dhcpd with an older version, restarted it,
and all seems to be back to normal.  It is indeed
hard to use yesterday without singing. :)

Sam

On Thu, 24 Apr 2003, David Presotto wrote:

> I think rob saw this also.  Could you send me the ip/ipconfig line
> that you're using.  I changed it to fix arg processing and sysname
> defaulting (i.e. setting something useful in /net/ndb's sys= entry)
> but can't see what would have caused things to be completely ignored.
>
> All our systems run at boot.  Perhaps I broke something for systems
> running ipconfig out of termrc.
>

Re: [9fans] DHCP weirdness?

[Charles Forsyth]

the change to dhcpd.c was to set and use oldheaders
which would explain the diagnostic (it's reading
part of the udp header as a boot request), but on the other
hand, the modified code looks all right to me.

which udp implementation are you using in /sys/src/9/ip? nudp.c or udp.c?

Re: [9fans] DHCP weirdness?

[Russ Cox]

You might check which ipconfig binary you have.
The correct one is

--rwxrwxr-x M 543586 glenda sys 102975 Apr 24 12:27 /n/sources/plan9/386/bin/ip/ipconfig

There was a bad one on sources for a little while,
and the current source code (if you were to compile it)
doesn't quite work for reasons I don't know.

[9fans] ipconfig

[Sam]

Just to clarify this for me, is there any reason
ipconfig needs to be in termrc for bootp'd terminals?

I think our termrc has been around since 3rd ed
which had ipconfig by default (iirc).  If it's
redundant I'd like to pull it.

Sam

Re: [9fans] ipconfig

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 163 bytes --]

9load doesn't currently pass the IP address it got to the kernel
Therefore, the booted kernel runs dhcp when it comes up (and can
get more info than bootp does).

[-- Attachment #2: Type: message/rfc822, Size: 1693 bytes --]

From: Sam <sah@softcardsystems.com>
To: <9fans@cse.psu.edu>
Subject: [9fans] ipconfig
Date: Thu, 24 Apr 2003 16:03:06 -0400 (EDT)
Message-ID: <Pine.LNX.4.30.0304241556210.26650-100000@athena>

Just to clarify this for me, is there any reason
ipconfig needs to be in termrc for bootp'd terminals?

I think our termrc has been around since 3rd ed
which had ipconfig by default (iirc).  If it's
redundant I'd like to pull it.

Sam

Re: [9fans] ipconfig

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

if booting with root from the network the kernel
will run it using /ipconfig in order to dial the file
server.  it doesn't need to be in termrc.  if you
want a termrc that works in both places you can
do

if(! test -e /net/ipifc/0/ctl) ip/ipconfig

[-- Attachment #2: Type: message/rfc822, Size: 3453 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 163 bytes --]

9load doesn't currently pass the IP address it got to the kernel
Therefore, the booted kernel runs dhcp when it comes up (and can
get more info than bootp does).

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1693 bytes --]

From: Sam <sah@softcardsystems.com>
To: <9fans@cse.psu.edu>
Subject: [9fans] ipconfig
Date: Thu, 24 Apr 2003 16:03:06 -0400 (EDT)
Message-ID: <Pine.LNX.4.30.0304241556210.26650-100000@athena>

Just to clarify this for me, is there any reason
ipconfig needs to be in termrc for bootp'd terminals?

I think our termrc has been around since 3rd ed
which had ipconfig by default (iirc).  If it's
redundant I'd like to pull it.

Sam

Re: [9fans] DHCP weirdness?

[ron minnich]

On Thu, 24 Apr 2003, Dan Cross wrote:

> >From what I can see, dhcpd on the CPU server responds to the client,
> but the client ignores the response.  That is, I can see dhcp requests
> and on the network while running snoopy, and /sys/log/ipboot shows that
> responses are being sent, but the client eventually times out and asks
> me for other boot information.

check the mac-level addressing too, not just IP level. Are the mac
addresses correct?

ron

Re: [9fans] ipconfig

[presotto]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

The options have to happen before any of the ppsitional arguments.
You really want

ip/ipconfig -g 192.168.0.1 ether /dev/ether0 192.168.0.2 255.255.255.0

Alternately, you could leave out the '-g 192.168.0.1' and just use

echo -n 'add 0 0 192.168.0.1' > /net/iproute

I think the ipconfig is easier but the other lets you change it later.

[-- Attachment #2: Type: message/rfc822, Size: 2792 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 218 bytes --]

Does ip/ipconfig ether /dev/ether0 192.168.0.2 -g 192.168.0.1 255.255.255.0

give me an interface with 192.168.0.2 and with default gateway 192.168.0.1 ?

Or how do I set my default gateway ?

/Michael Grunditz

[-- Attachment #2.1.2: Type: text/html, Size: 663 bytes --]

[9fans] ipconfig

[Grunditz Mikael - migu]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

Does ip/ipconfig ether /dev/ether0 192.168.0.2 -g 192.168.0.1 255.255.255.0

give me an interface with 192.168.0.2 and with default gateway 192.168.0.1 ?

Or how do I set my default gateway ?

/Michael Grunditz

[-- Attachment #2: Type: text/html, Size: 663 bytes --]