| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3644.1 | How odd. | NETCAD::MCCRORY | | Thu Jun 20 1996 14:15 | 24 |
|
>Here's the question, does disabling BOOTP on the repeater just stop
>the BOOTP requests going out ? Is the BOOTP receiver function left
>enabled ?
Disabling BOOTP prevents the requests from going out but it doesn't
disable the receiver. It never occurred to me that I would be getting
a response without sending a request.
>If the receiver is still enabled would a broadcast or unicast bootp
>response sent in error from another system cause the repeater to
>read in an IP address ?
If somebody sends a BOOTP response to us we will configure with the
ip address information in that message.
Sounds like I need to disable the receiver.
What is going on in that network where you have a BOOTP server sending
out responses without getting a request?
-Eileen
|
| 3644.2 | Non-DEC X-Terms causing problems | COMICS::BUTT | Give me the facts real straight. | Fri Jun 21 1996 04:52 | 20 |
| Eileen
Thanks for your response, it confirms what I suspect.
In the network are many different vendor systems. Our repeaters only
take on-board the IP addresses of one type of device. This is a non-DEC
X-Terminal.
My theory is that occasionally, the X-Terminals send out a BOOTP
response either to the broadcast address or to the MAC of our
repeaters. I cannot see why they would pick on a unicast but it is
possible. Your information confirms that the theory is reasonable. I
will try to get the customer to take a LAN trace to see what really
happens and to contact the X-Terminals supplier. It maybe that the
these X-Terms are using BOOTP responses as a kind of "sysid".
In the next cut of the code it would be good to disable the bootp
receiver on the grounds that you just can't trust anyone !
Thanks R.
|
| 3644.3 | Do we check the reply/request bits ? | COMICS::BUTT | Give me the facts real straight. | Fri Jun 21 1996 05:13 | 8 |
| Eileen
One more point I forgot..
Does the receiver check the "OP" field to check for a request sent to
the BOOTP Client UDP port (68) and reject it ?
R.
|
| 3644.4 | | NETCAD::MCCRORY | | Fri Jun 21 1996 16:40 | 10 |
| >Does the receiver check the "OP" field to check for a request sent to
>the BOOTP Client UDP port (68) and reject it ?
Do you mean ... do I make sure that I'm processing a bootp response
and not a bootp request? ... The bootp rcv code makes sure it's got
a bootp response.
-Eileen
|
| 3644.5 | Exactly ! | COMICS::BUTT | Give me the facts real straight. | Mon Jun 24 1996 05:35 | 9 |
| >Do you mean ... do I make sure that I'm processing a bootp response
>and not a bootp request? ... The bootp rcv code makes sure it's got
>a bootp response.
Yes, that what I meant. This means that the fault must be in the
third-party X-term.
Thanks R.
|
| 3644.6 | Transaction ID. | COMICS::BUTT | Give me the facts real straight. | Wed Jul 17 1996 09:54 | 10 |
| When bootp is disabled the repeater stops sending bootp requests so
the transaction ID should be invalidated. The fact that IP addresses
still get assigned seems to suggest that the transaction ID is not
checked. As some bootp server implementations send responses to the
broadcast address this will cause problems.
If the transaction ID is checked what scheme is used to generate them ?
Pseudo random or start at 1 and increment.
R
|
| 3644.7 | same problem also . | AKOCOA::DTHOMAS | | Fri Aug 30 1996 11:59 | 9 |
| I am also seeing the same problem. PortSwitch 900tp and DECconcentrator
900 MX modules with Bootp disabled are receiving IP addresses from a WNT server
running DHCP. At times I've seen as many a 5 devices on the LAN using the same
IP address. This is causing many problems.
Any help would be appreciated.
thanks
Dave
|
| 3644.8 | any progress? | MROA::BOUTHIETTE | | Thu Sep 12 1996 11:57 | 5 |
| Has any progress been made on this problem? This is happening an many
sites In new England where Windows-Nt DHCP servers and 900ef's
both reside on the same LAN segments
Jb.
|
| 3644.9 | can anyone help ? | AKOCOA::DTHOMAS | | Thu Oct 03 1996 14:02 | 10 |
| 3644.10 | Fixed in the next versions. | NETCAD::GALLAGHER | | Thu Oct 03 1996 16:36 | 12 |
| 3644.11 | | NETCAD::GALLAGHER | | Thu Oct 03 1996 16:56 | 16 |
| 3644.12 | analyzer trace information | AKOCOA::DTHOMAS | | Wed Oct 16 1996 16:51 | 10 |
| 3644.13 | Status. | NETCAD::GALLAGHER | | Thu Mar 27 1997 10:46 | 7 |
| The bug is fixed in our hub common code. New products will have the
fix. New firmware releases of old products will have the fix. I need
to contact the folks who do maintenance releases for the repeaters to
see if they've picked up this change, and if there are maintenance releases
available.
I'll post the results.
|
| 3644.14 | More status. | NETCAD::GALLAGHER | | Thu Apr 03 1997 12:26 | 9 |
|
I hear that there might be a maintenance release for the PORTswitch900 TP
in a month or two. This fix would be in that release.
I will update this thread if this turns out not to be true. If it is
true, I'll post an update as the release date firms up.
-Shawn
|