| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1753.1 | Can't upgrade probes with NDU | ROGER::GAUDET | Because the Earth is 2/3 water | Fri Dec 02 1994 17:10 | 4 |
| Please read note 1368 CAREFULLY! We go to great lengths to document as many
restrictions as we know about. This is one of them.
...Roger...
|
| 1753.2 | any TFTP server should work | NAC::FORREST | | Sat Dec 03 1994 00:02 | 8 |
| Any regular TFTP server should work. If you don't have one anywhere,
then you might try the router loader DECrou as I understand that it
provides a TFTP server service. I don't know where to get the kit
though.
You'll have to specify the server address from the probe console.
You might also want to increase the default TFTP timeout value.
Then simply select the menu option to downline load.
|
| 1753.3 | It pays to RTFM! | STKHLM::DUFVA | | Mon Dec 05 1994 05:30 | 15 |
| Thanks,
When I took the time to read, it states that NDU does not load the
DECpacketprobe 90.
I have a customer that wants to upgrade his probes and has no UNIX
systems. I will recommend him to use UCX.
BTW, if I give the command `decndup /u /f 16.181.. filename', it says:
`[TSERVER] Now serving for two minutes.'
What is it doing then?
Regards,
Nils.
|
| 1753.4 | Server timeout maybe? | ROGER::GAUDET | Because the Earth is 2/3 water | Mon Dec 05 1994 12:36 | 10 |
| There is probably some obscure timeout period in NDU's built-in TFTP server. Since
there is no way for NDU to know what kind of device is being loaded, it obediently
attempts to load whichever IP address you give it. However, when the device doesn't
respond, NDU probably goes into a wait-and-retry mode. It looks like that's what is
going on.
FYI, your command line is not complete. The /f switch needs a parameter (that's the
FORCE qualifier).
...Roger...
|
| 1753.5 | re .1 , but it can be done | BRIEIS::BARKER_E | test dummy | Tue Dec 20 1994 14:14 | 6 |
| I've managed to upgrade a packetprobe 90 using NDUplus on a DOS PC,
using the TSERVER option, setting the various addresses on the probe
through the menu and then doing option 10. Took a while but is now
working fine.
Euan
|
| 1753.6 | I stand corrected | ROGER::GAUDET | Because the Earth is 2/3 water | Tue Dec 20 1994 15:00 | 4 |
| Hey that's slick! I hope others read your note and use that method if they need
to.
...Roger...
|
| 1753.7 | More info please. | TROFS::WEBSTER | NIS, London, Canada | Fri Dec 30 1994 18:35 | 13 |
| re .5
Can you post details of how you managed to get this to work.
I have been unable to get this work due to the TSERVER 2 minute
server period, and it takes the PROBE almost 2 minutes to erase the NVRAM
before it requests a new load...but the server timesout and the firmware
load dies.
Tips appreciated.
-Larry
|
| 1753.8 | | BIS5::RUTTENS | | Thu Jan 05 1995 13:55 | 383 |
| 1753.9 | can be done ... | COMICS::REYNOLDS | Mad Dogs and Englishmen | Thu Apr 06 1995 17:38 | 51 |
|
I think I know what the issue is when trying to load the packetprobe
using NDU for DOS - NDU will not respond to the ARP message sent
by the packetprobe to determine the PCs MAC address - use the
following procedure to upgrade:
1. ensure that the Packetprobe has been given the correct TFTP server
address and that this matches the PCs address (set in the SDDF.STP
file). If the Packetprobe and PC are not in the same IP subnet,
check each have default gateway addresses configured (confirm
using ping test before you start the upgrade).
2. Issue a decndup /s command to the Packetprobe. This will
return the current firmware version, but more importantly,
will cause the Packetprobe to send an ARP request to the PC
and get a reply, which it will cache.
3. Issue decndup /u /f tserver <ip address> ns3210.s
(note the file name is hard coded as ns3210.s but ndu insists
you supply this)
ndu should then say 'serving for 2 minutes'
NB: if you quit out of this, you have to re-run ndu -it seems
to like to time out naturally or else gives you a MOP
error when you reissue the command!
4. Use option 10 on the Packetprobe to start the upgrade.
It then talks to the PC (not needing to ARP it since
we got it to cache the last reply) to confirm its ability
to serve the file then erases its flash which takes a few minutes.
This is where the fun starts. The flash erase and reload takes
longer than 2 minutes, so if it times out just as it finishes
the erasure, you have to start again. Or, if it begins the
tftp transfer and times out, you have to restart it within ~30
seconds or it gives up re-requesting the next block.
So it does work, but only just! I certainly don't feel comfortable
suggesting this to a customer.
I think we need ARP reply during serving and a timeout option
on the ndu command to really support the packetprobe. I suspect
Hubloader is going to suffer the same problem
John.
|