Conference netcad::hub_mgnt

4385.0. "Trying to resurrect a brain dead DECrepeater 90FS (DR90FS)" by GIDDAY::STANISLAUS () Wed Apr 30 1997 23:25

	A customer has caused a DR90FS failure by probably reseting or powering
it down while flash updating.


	I am trying to resurrect the DR90FS, which is now failing power on self
test. I can see a bootp request coming from the DR90FS's AUI port in the front
by connecting a Network General Sniffer on the LAN. Just one 0.5 metre cable
length away from the sniffer I have my Laptop running NETRIDER version 1.0.003.
I have configured the server address and the file name on NETRIDER as follows:
00-00-F8-41-24-89 (tried with and without the dashes) and the local and remote
file names as default and defmi211.bin respectively. The same time my sniffer
sees a boot packet from my DR90FS, NETRIDER BOOTP count goes up by 1. So I
presume that NETRIDER also saw the BOOTP packet from my DR90FS. although it is
not impossible that NETRIDER saw someone else's BOOTP request. I expect to
see a packet going out of my Laptop giving my DR90FS an IP address. But no
packet goes out and the DR90FS a few seconds later sends another BOOTP 
broadcast again. My Laptop's IP address is 16.153.32.201. I have configured
NETRIDER server list to map 00-00-F8-41-24-89 to 16.153.32.105. The network mask
is 255.255.255.0 on my network. I tried clrVSN's loader as well and had no joy.
Then my colleague tried from his Alpha's tftp server running Digital Unix
version 4.0b and still no luck. The log file says that it did not see the DR90FS
bootp request at all.

	So why my sniffer which is on the same segment sees it, but neither the
Unix System, nor clrVSN tftp loader, nor NETRIDER see the DR90FS request. I
decoded the request packet as I see on the sniffer and it is a standard
broadcast UDP BOOTP request from bootp client port 67 to bootps/DHCP server port
68 as decoded by the sniffer. So the next thing that should have happened is a
bootp response from the server with an IP address 16.153.32.105 being allocated
to my DR90FS and then start of tftp transfer. None of this happens. The TFTP
count field stays zero on the Laptop. 

	Has anyone tried to resurrect a dead DR90FS this way ?

	I have successfully in the past resurrected DS900EFs this way.

Alphonse

	After troubleshooting a bit more I have the following info:

The reason I did not see the bootp response on the sniffer is because the bootp
response is also a BROADCAST. Embedded in this BROADCAST is the MAC ADDRESS of
the DR90FS, IP ADDRESS that the DR90FS should use and FILE NAME DEFMI211.
I wrongly thought that bootp response for a bootp request would be a UNICAST.

Now the symptom is as follows:

	The DR90FS gets the above info from the bootp server and does a TFTP
REQUEST FILE. With IRIS I get a bit more information on the content of this
packet than with SNIFFER.With IRIS it says DEFMI211.octet and then a message
saying Data exceeded message size by 31481 bytes. With SNIFFER it says DEFMI211
Mode=Octet, Normal TFTP file request packet.

	So what does DATA EXCEEDED MESSAGE SIZE BY 31481 mean.? Could it be 
something wrong in the boot code in the DR90FS that is causing this problem ?
Has anyone attempted loading a DR90FS using bootp/tftp successfully ?

Alphonse

    Have you got the path of defmi211.bin specified?
    
    Pedro