TFTP server & HP Procurve switch?

[Christoph Gartmann]

Hello,

is there any known problem with Multinet V5.1 (plus most patches) and HP
ProCurve switches? The problem is that I cannot upgrade the software on the
switch via Multinet's TFTP server. What I see:
- no problem saving or loading the configuration file
- trying to load the system image gives: 00000K Request failed.
- trying to load a non-existent file gives: 00000K Transport error.
- trying to load a non-suitable file gives: 00000K Wrong file.
- loading the image from a PC with 3Com's TFTP server works as expected.
The VMS host and the PC have a similar network setup, that is they have a
different IP address than the switch and use the same gateway and the network
path to the Procurve is identical. So what is wrong here?

Regards,
Christoph Gartmann

[Ken Connelly]

The obvious things to look for first are TFTP requirements:

* the file must exist (to get it or put it)
* the file must be world-readable (world-writeable if you're storing it)

Everything that I have of this nature is stored on the VMS host as a
stream-lf file. That includes router and switch image files.

- ken

Post by Christoph Gartmann
Hello,
is there any known problem with Multinet V5.1 (plus most patches) and HP
ProCurve switches? The problem is that I cannot upgrade the software on the
- no problem saving or loading the configuration file
- trying to load the system image gives: 00000K Request failed.
- trying to load a non-existent file gives: 00000K Transport error.
- trying to load a non-suitable file gives: 00000K Wrong file.
- loading the image from a PC with 3Com's TFTP server works as expected.
The VMS host and the PC have a similar network setup, that is they have a
different IP address than the switch and use the same gateway and the network
path to the Procurve is identical. So what is wrong here?
Regards,
Christoph Gartmann

[Christoph Gartmann]

Post by Ken Connelly
* the file must exist (to get it or put it)
* the file must be world-readable (world-writeable if you're storing it)
Everything that I have of this nature is stored on the VMS host as a
stream-lf file. That includes router and switch image files.

Same here. I even tried a FIX512 format, the error remains and it is very fast,
immediately after pressing RETURN at the switch. Has anybody a similar setup,
e.g. a HP Procurve switch and Multinet and can confirm/deny the problem?

Regards,
Christoph Gartmann

[Bob Blum]

If the file works from the PC to the ProCurve switch, can you use TFTP to
transfer it to the VMS machine? Then compare it to the (renamed) existing
file?

Also, is there anything else that requires TFTP from the VMS machine that
has worked in the past, or is this the first attempt to use TFTP on the VMS
host?

Bob Blum

Post by Ken Connelly
* the file must exist (to get it or put it)
* the file must be world-readable (world-writeable if you're storing

it)

Post by Ken Connelly
Everything that I have of this nature is stored on the VMS host as a
stream-lf file. That includes router and switch image files.
- ken

Post by Christoph Gartmann
Hello,
is there any known problem with Multinet V5.1 (plus most patches) and HP
ProCurve switches? The problem is that I cannot upgrade the software on

the

Post by Ken Connelly

Post by Christoph Gartmann
- no problem saving or loading the configuration file
- trying to load the system image gives: 00000K Request failed.
- trying to load a non-existent file gives: 00000K Transport error.
- trying to load a non-suitable file gives: 00000K Wrong file.
- loading the image from a PC with 3Com's TFTP server works as expected.
The VMS host and the PC have a similar network setup, that is they have

a

Post by Ken Connelly

Post by Christoph Gartmann
different IP address than the switch and use the same gateway and the

network

Post by Ken Connelly

Post by Christoph Gartmann
path to the Procurve is identical. So what is wrong here?
Regards,
Christoph Gartmann

--
- Ken
=================================================================
Ken Connelly Associate Director, Security and Systems
ITS Network Services University of Northern Iowa
It's much more important to know what you don't know than what you do

know!

[Richard Whalen]

Was TFTP being successfully used from the VMS system earlier?
Have you tried turning on packet tracing (the TRACE command) to get more specific information about where the error occurs in the process?

-----Original Message-----
From: Christoph Gartmann [mailto:***@nonsense.immunbio.mpg.de]
Sent: Thursday, March 02, 2006 3:45 AM
To: info-***@process.com
Subject: TFTP server & HP Procurve switch?


Hello,

is there any known problem with Multinet V5.1 (plus most patches) and HP
ProCurve switches? The problem is that I cannot upgrade the software on the
switch via Multinet's TFTP server. What I see:
- no problem saving or loading the configuration file
- trying to load the system image gives: 00000K Request failed.
- trying to load a non-existent file gives: 00000K Transport error.
- trying to load a non-suitable file gives: 00000K Wrong file.
- loading the image from a PC with 3Com's TFTP server works as expected.
The VMS host and the PC have a similar network setup, that is they have a
different IP address than the switch and use the same gateway and the network
path to the Procurve is identical. So what is wrong here?

Regards,
Christoph Gartmann

[Christoph Gartmann]

Post by Richard Whalen
Was TFTP being successfully used from the VMS system earlier?

Yes, it is working with Cisco devices, 3Com devices and others but not with
the (only) ProCurve.

Post by Richard Whalen
Have you tried turning on packet tracing (the TRACE command) to get more
specific information about where the error occurs in the process?

I don't know about the TRACE command. Where do I use it?

Regards,
Christoph Gartmann

[Michael Corbett]

Post by Christoph Gartmann
I don't know about the TRACE command. Where do I use it?

Try -

$ mu tcpdump/hex/num port tftp

You might also want to turn on debugging for the TFTP service and
see what is generated for OPCOM messages -

$ mu netc tftp debug 15
$ reply/en/temp

regards
Mike

[Christoph Gartmann]

Post by Michael Corbett

Post by Christoph Gartmann
I don't know about the TRACE command. Where do I use it?

Try -
$ mu tcpdump/hex/num port tftp
You might also want to turn on debugging for the TFTP service and
see what is generated for OPCOM messages -
$ mu netc tftp debug 15
$ reply/en/temp

Now I opened a call through Multiware. In addition I put the above information,
both the dump and the debug, here:
http://www.immunbio.mpg.de/groups/gartmann/tftp.zip

Regards,
Christoph Gartmann

[Mo Boukantar]

I have also seen some TFTP clients to request the entire filename with the
extention and some that do not. Make a copy of the same file to have
filename.ext and filename.

Thanks,
Mo,

[Christoph Gartmann]

I have also seen some TFTP clients to request the entire filename with =
the
extention and some that do not. Make a copy of the same file to have
filename.ext and filename.

Tried but didn't help.

Regards,
Christoph Gartmann

[Jim Glassford]

Greetings,

This may be all worked out but debug 7 will supply a lot of information to
OPCOM.

$ mu netcontrol tftp debug 7

Just in case this was over looked, I had to setup the
tftp.filename-translations file to map the files. The example below show it
has been a while since we have used tftp on VMS. ;-)

MULTINET_ROOT:[MULTINET]

$ type TFTP.FILENAME-TRANSLATIONS
#
RESTRICT-ACCESS
#
mneng1.sys MULTINET_COMMON_ROOT:[MULTINET]mneng1.sys
mneng2.sys MULTINET_COMMON_ROOT:[MULTINET]mneng2.sys
wweng1.sys MULTINET_COMMON_ROOT:[MULTINET]wweng1.sys
wweng2.sys MULTINET_COMMON_ROOT:[MULTINET]wweng2.sys
s2s02_69.bin MULTINET_COMMON_ROOT:[MULTINET]s2s02_69.bin
s2s02_70.bin MULTINET_COMMON_ROOT:[MULTINET]s2s02_70.bin
psh02_16.bin MULTINET_COMMON_ROOT:[MULTINET]psh02_16.bin
fma03_17.slx MULTINET_COMMON_ROOT:[MULTINET]fma03_17.slx
lsdt3_23.slx MULTINET_COMMON_ROOT:[MULTINET]lsdt3_23.slx
ls1k3_23.slx MULTINET_COMMON_ROOT:[MULTINET]ls1k3_23.slx
ls3k3_23.slx MULTINET_COMMON_ROOT:[MULTINET]ls3k3_23.slx

good-luck!
jim




----- Original Message -----
From: "Christoph Gartmann" <***@nonsense.immunbio.mpg.de>
To: <info-***@process.com>
Sent: Friday, March 03, 2006 3:49 AM
Subject: Re: TFTP server & HP Procurve switch?

Post by Christoph Gartmann

Post by Michael Corbett

Post by Christoph Gartmann
I don't know about the TRACE command. Where do I use it?

Try -
$ mu tcpdump/hex/num port tftp
You might also want to turn on debugging for the TFTP service and
see what is generated for OPCOM messages -
$ mu netc tftp debug 15
$ reply/en/temp

Now I opened a call through Multiware. In addition I put the above
information,
http://www.immunbio.mpg.de/groups/gartmann/tftp.zip
Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : [phone] Fax: -452
Immunbiologie
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html

[Richard Whalen]

n the TCPDUMP I see the following:

A Read Request (RRQ) (from the Procurve switch? 192.168.1.61)
Data block 1 is sent in response (good) (192.129.30.3 > 192.168.1.61)
An Ack for block 1 is received (good) (192.129.30.3 < 192.168.1.61)
Data block 2 is sent (good) (192.129.30.3 > 192.168.1.61)
An Ack for block 1 is received (should be ignored because it is a duplicate) (192.129.30.3 < 192.168.1.61)
An Ack for block 2 is received (good)
Data block 2 is retransmitted,
2 more ack packets for block 2
Data block 3
2 more ack packets, 1 for block 2, 1 for block 3
data block 3
data block 3
4 more ack packets, all for block 3
data block 3
2 more ack packets for block 3
data block 4
ack for block 3
data block 4
two packets for block 4
data block 4
2 more ack packets for block 4
data block 4
ack for block 4
data block 4
3 more ack packets for block 4
data block 4
2 more ack packets
data block 4
ack for block 4
data block 4
2 ack packets
data block 5
2 ack packets
data block 5
ack for block 5
15 packets of data block 5
4 packets of data block 6

The basic problem is that the two systems got out of the lock step alternation that RFC 1350 describes and while they tried to continue, they eventually gave up because of too many errors.

I don't deal with TFTP on a regular basis, so I don't know any of its quirks. To me, there look like possible timing errors here. One side seems to be to aggressive in timing out of packets. The MultiNet TFTP client has a REXMIT command to specify the number of seconds before timing out a request. The default value for this is 5 seconds.

The trace shows the second ack for data block 1 occurring about .01 seconds after the first. Assuming that Data block 2 was transmitted at approximately the same time (it effectively acks the reception of the ack for data block 1), it seems that the timeout value for 192.168.1.61 is too aggressive.


-----Original Message-----
From: Christoph Gartmann [mailto:***@nonsense.immunbio.mpg.de]
Sent: Friday, March 03, 2006 3:49 AM
To: info-***@process.com
Subject: Re: TFTP server & HP Procurve switch?

Post by Michael Corbett

Post by Christoph Gartmann
I don't know about the TRACE command. Where do I use it?

Try -
$ mu tcpdump/hex/num port tftp
You might also want to turn on debugging for the TFTP service and
see what is generated for OPCOM messages -
$ mu netc tftp debug 15
$ reply/en/temp

Now I opened a call through Multiware. In addition I put the above information,
both the dump and the debug, here:
http://www.immunbio.mpg.de/groups/gartmann/tftp.zip

Regards,
Christoph Gartmann

[Christoph Gartmann]

Post by Richard Whalen
A Read Request (RRQ) (from the Procurve switch? 192.168.1.61)

Correct, this is a Procurve 3400cl (J4905A).

[...]

Post by Richard Whalen
The basic problem is that the two systems got out of the lock step
alternation that RFC 1350 describes and while they tried to continue,
they eventually gave up because of too many errors.

Ok.

Post by Richard Whalen
I don't deal with TFTP on a regular basis, so I don't know any of its
quirks. To me, there look like possible timing errors here. One side
seems to be to aggressive in timing out of packets. The MultiNet TFTP
client has a REXMIT command to specify the number of seconds before
timing out a request. The default value for this is 5 seconds.

The Procurve responds with the error immediately after I hit RETURN to start
the TFTP transfer.

Post by Richard Whalen
The trace shows the second ack for data block 1 occurring about .01
seconds after the first. Assuming that Data block 2 was transmitted at
approximately the same time (it effectively acks the reception of the
ack for data block 1), it seems that the timeout value for 192.168.1.61
is too aggressive.

The strange thing is that the switch keeps sending packets even after the error
at the switch console appeared and the input prompt is back.

Regards,
Christoph Gartmann