Subject: RE: thanks for the terminal room!

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 16 Dec 1998 17:17:11 -0500

Make that a platinum star, and also make it 10!

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 681-2318
Defense Information Systems Agency      Fax:           (703) 681-2814 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           (703) 681-2318   
Falls Church, VA 22041-2717        Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Patrik Fältström [SMTP:[email-masked]]
> Sent:	Wednesday, December 16, 1998 1:21 AM
> To:	Keith Moore; Henk Uijterwaal (RIPE-NCC)
> Cc:	[email-masked]
> Subject:	Re: thanks for the terminal room!
> 
> At 00.31 -0500 98-12-16, Keith Moore wrote:
> > Our host, and the terminal room folks, deserve a gold star for this one.
> 
> One from me aswell! Well done!
> 
>   paf

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 17 Dec 1998 11:04:27 +0100

> Make that a platinum star, and also make it 10!

To get platinum, I would have liked a DHCP server which worked also 
for non-Windows boxes.

Because of that, I only have them gold (and they get Gold because 
everyone which had problem with DHCP promptly got fixed IP-addresses).

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 17 Dec 1998 11:04:27 +0100

paf

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 09:25:26 -0500 (EST)

> To get platinum, I would have liked a DHCP server which worked also 

	Huh?  Worked fine for RedHat Linux 5.2 with dhcpcd (HDCP Client
Daemon - almost sounds like an oximoron :-) ).

	One thing in that regard though...  I remember a problem that
I had to patch in an earlier version of dhcpcd when it was used on a
very busy network.  Seems that if it saw enough traffic, it just keep
busy until an alarm went off and caused an abort, even though it had
finished it's task (it was waiting on a select timeout for that
determination).  I discovered this on our corporate lan when dhcpcd would
fail at real busy times but work fine at other times or back on my home
network.  It was a "busy network" problem and had nothing to do with the
dhcp server.

	Just as a back of the cuff survey based on scanning the people
around me, there were a LOT of non-Windows laptops at the walk-up ethernet
connections.  I don't know if the non-Windows laptops outnumbered the
Windows laptops, but I bet it was close and I bet they weren't all
getting static addresses from the terminal room staff...

	Sooo...  Which "non-Windows" flavor box were you using that wouldn't
work with the DHCP server there in the terminal room?

> everyone which had problem with DHCP promptly got fixed IP-addresses).

	Gold or Platinum or what-ever, they did an outstanding job.  I saw
some of the hair pulling and chaos on Sunday when things were going bump
in the night, so one would also have to say "medal of honor for valor under
fire".

>    paf

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 09:25:26 -0500 (EST)

Mike

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 17 Dec 1998 15:30:27 +0100

> work with the DHCP server there in the terminal room?

People which had problems -- for whatever reasons -- with the timeouts in DHCP.

People that think that "I just had to retry a couple of times" are 
also in this category, because I don't think DHCP should time-out to 
get platinum ;-)

As you wrote yourself -- gold or platinum, whatever, they did a good job!

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 17 Dec 1998 15:30:27 +0100

Patrik

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 10:28:48 -0500 (EST)

> also in this category, because I don't think DHCP should time-out to 

	Ah!  But that's not a server problem.  That's a client problem.
You might also consider it to be a protocol problem (no flames from anyone
responsible or irresponsible for that protocol please).  Having looked at
the dhcpcd sources, it seems to depend on timeouts too much.  I'm not
totally sure if that's merely an implimentation problem or an artifact
of the protocol design.

	In that case, the application had set a grand-timer to fire and
abort the operation and then entered a select loop reading from a socket.
As long as it continued to receive packets, it would continue looping.  If
it received a DHCP packet, it would process it.  If it timed out in the
select, it would exit the loop and see if it had received all of the
information it needed.  The problem was that a busy network would keep
it looping, even though it had received all of the DHCP traffic it was
going to, until the grand timer fired and aborted the app.  The fix was
actually pretty simple...

	In this case, a busy network meant seeing a couple of broadcast
packets, from any source, per second.  All it took was a network with
lots of Windows boxen broadcasting a bunch of their broadcast name
datagrams and other such noise.  Gee...  With all of those Windows boxes
at the far half of the room plus any windows laptops, I guess that would
describe the terminal room pretty neatly...

	Mike

---

From: "Michael H. Warfield" <[email-masked]>
Date: Thu, 17 Dec 1998 10:28:48 -0500 (EST)

Mike

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Dec 1998 12:29:23 -0500

> To get platinum, I would have liked a DHCP server which worked also 

I was able to successfully get addresses using DHCP on NetBSD-1.3I
with the ISC dhclient (which is included in the stock NetBSD
distribution); however, I did shorten retransmission timeouts somewhat
in the hope of getting a lease more quickly...

The DHCP server was just exceptionally slow in responding to DISCOVER
messages (which are the initial contact from the client to a server).
It's not clear to me what was going on, but the behavior was
consistent with DISCOVER messages having a high probability of being
dropped.

It seemed to respond reasonably quickly to REQUEST messages, which
confirm/renew a lease.  As someone else noted, the same behavior
happened in Chicago and LA.

					- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Dec 1998 12:29:23 -0500

- Bill

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 17 Dec 1998 15:04:14 -0500

Date: Thu, 17 Dec 1998 12:29:23 -0500
   From: Bill Sommerfeld <[email-masked]>

I was using a static address, and it often took 5-15 seconds before the
!@#!? switch doing VLAN noticed that I was pinging the switch address
and would pay attention to my laptop.  Someone next to me claimed it was
because there was an NT box providing the VLAN support, but I had a lot
of trouble believing that.

The bottom line though is that it might not necessarily have been DHCP's
fault; the problem may have been at the switch level.

							- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 17 Dec 1998 15:04:14 -0500

- Ted

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Dec 1998 15:36:57 -0500

> and would pay attention to my laptop.  

Hmm.  Maybe.  

The initial DISCOVER is broadcast, which should just be flooded to all
switch ports; the OFFER which the server sends in response can either
be unicast or broadcast (I should have checked this at the IETF but
neglected to.  oh well..); if the response was unicast, and the switch
was a slow learner, i can believe that the symptoms we saw could
result.  (having the DHCP server broadcast the response would probably
speed up initial configuration).

> fault; the problem may have been at the switch level.

Given the extreme mobility of laptops at the IETF, it seems poor to
use switches which are such slow learners.

I recall this being a problem as early as the Memphis IETF; I'm
surprised it hasn't been fixed yet.

					- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Dec 1998 15:36:57 -0500

Hmm.  Maybe.  

					- Bill