Itanium OpenVMS 8.1 FTP experiences?

[Robert Young_13]

No change. I can "direct connect" between a laptop (client) and the rx2600(server) w/ nothing else on the network but them, and try telnet and ftp. Telnet usually goes through. FTP may get as far as taking a username/password (and it does authenticate because I gave it some bogus usernames), but then it simply times out.

[Alex Daniels]

What does 'mc lancp sh dev/coun' give you? Is this showing errors on the lan devices?

Can you try connecting the laptop to the Itanium via a crossover cable? It would rule out the switch then..

Alex

[Willem Grooters]

Robert,
CDRECORD requires a CD-writer on your VMS box, and AFAIK there is a limit number of drives that are supported.
I did start a tread on CD recoding on VMS: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=611786, you may find some answers there.

To Engineering: Will the LD-verb and all HELP be included in a 7.3-x patch, please.

Willem

[Robert Young_13]

Here are the results of the mcr lancp command:
Device Counters EIA0:
Value Counter
----- -------
240945 Seconds since last zeroed
5067 Bytes received
292 Bytes sent
54 Packets received
6 Packets sent
4875 Multicast bytes received
168 Multicast bytes sent
51 Multicast packets received
4 Multicast packets sent
0 Unrecognized unicast destination packets
23 Unrecognized multicast destination packets
0 Unavailable station buffers
0 Unavailable user buffers
0 Alignment errors
0 Frame check errors
0 Frame size errors
0 Frame status errors
0 Frame length errors
0 Frame too long errors
0 Data overruns
0 Send data length errors
0 Receive data length errors
0 Transmit underrun errors
0 Transmit failures
0 Carrier check failures
0 Station failures
0 Initially deferred packets sent
0 Single collision packets sent
0 Multiple collision packets sent
0 Excessive collisions
0 Late collisions
0 Collision detect check failures




Device Counters EWA0:
Value Counter
----- -------
240945 Seconds since last zeroed
3004070 Bytes received
764681 Bytes sent
39681 Packets received
7408 Packets sent
1920078 Multicast bytes received
126574 Multicast bytes sent
26552 Multicast packets received
827 Multicast packets sent
0 Unrecognized unicast destination packets
13288 Unrecognized multicast destination packets
0 Unavailable station buffers
0 Unavailable user buffers
0 Alignment errors
0 Frame check errors
0 Frame size errors
0 Frame status errors
0 Frame length errors
0 Frame too long errors
0 Data overruns
0 Send data length errors
0 Receive data length errors
0 Transmit underrun errors
0 Transmit failures
4 Carrier check failures
0 Station failures
4 Initially deferred packets sent
1 Single collision packets sent
1 Multiple collision packets sent
0 Excessive collisions
0 Late collisions
0 Collision detect check failures

I doubt that it is the switch since telnet is generally successful in getting through. If it were the switch, wouldn't all TCP/IP be equally affected? A few of these errors (like carrier check) are me plugging/unplugging cables.

If the laptop and rx2600 are directly connected, it gets "farther"...at leat I get a request for username/pwd . But the actual file transfer attempts still timeout.

[Alex Daniels]

As you said a ping test is giving you a 75% packet loss, I am guessing that telnet would be equally effected.

As in effect the problem is replicating (or at least you have problems) with both FTP and PING (ICMP) it suggests the problem is probably not due to FTP confiuration or bug.

Which is why it would be nice to rule out the switch, by using a crossover cable.

[Alex Daniels]

Also try 'mc lancp sh dev eia0/char' or obviously ewa0, if thats the one you are now using.

For the line speed is it set to 10?? And if you keep repeating the command does it flip between 10 and 100??

I have just tried a few :

LANCP> set dev eia0/speed=100
LANCP> set dev eia0/speed=10

With my port set to auto-negoitate on the switch, as expected during the change I get packet loss.

You may be experiencing the same, if your switch port isn't auto-negotiating correctly, this could explain the packet loss on ping.

Alex

[Robert Young_13]

Well I tried a cross over cable between 2 systems directly, and got the same FTP problems. Telnet works, and ping works now 100% of the time.

FTP still times out or only gets as far as username/pwd. Anything one attempts ( a dir listing, etc) after the pwd is accepted ( on those times when it gets that far) times out.

I switched it between the (2) ethernet ports on the rx2600 with the same results.

I also tried a client cpu that has a 10/100 interface. The speeds automatically switched as expected on the rx2600 between 10 and 100Mb as expected depending on the settings so auto-negotiation seems to be working.

I also tried FTP clients from Windows and a Vax running Multinet. No difference in behavior. I also tried going to the Multinet server from the rx2600, with no improvement.

Is there something to the FTP setup on VMS 8.1 that I have missed that anyone can think of that might cause this type of behavior?

[Robert Young_13]

Odd pings....

Ping shows odd behavior. Going to Itanium from Mac/X looses every other packet (based on icmp_seq). Pinging Vax ( also ran it against Alpha with same results) on same network ( same switches, etc) works fine. Thoughts?

[ROBERT-YOUNGS-C:~] robertyo% ping 208.246.88.73 {Itanium}
PING 208.246.88.73 (208.246.88.73): 56 data bytes
64 bytes from 208.246.88.73: icmp_seq=0 ttl=64 time=0.53 ms
64 bytes from 208.246.88.73: icmp_seq=2 ttl=64 time=0.469 ms
64 bytes from 208.246.88.73: icmp_seq=4 ttl=64 time=0.467 ms
64 bytes from 208.246.88.73: icmp_seq=6 ttl=64 time=0.474 ms
64 bytes from 208.246.88.73: icmp_seq=8 ttl=64 time=0.463 ms
64 bytes from 208.246.88.73: icmp_seq=10 ttl=64 time=0.479 ms
64 bytes from 208.246.88.73: icmp_seq=12 ttl=64 time=0.479 ms
64 bytes from 208.246.88.73: icmp_seq=14 ttl=64 time=0.463 ms
64 bytes from 208.246.88.73: icmp_seq=16 ttl=64 time=0.468 ms
64 bytes from 208.246.88.73: icmp_seq=18 ttl=64 time=0.485 ms
64 bytes from 208.246.88.73: icmp_seq=20 ttl=64 time=0.47 ms
64 bytes from 208.246.88.73: icmp_seq=22 ttl=64 time=0.5 ms
64 bytes from 208.246.88.73: icmp_seq=24 ttl=64 time=0.474 ms
64 bytes from 208.246.88.73: icmp_seq=26 ttl=64 time=0.487 ms
64 bytes from 208.246.88.73: icmp_seq=28 ttl=64 time=0.465 ms
^Y64 bytes from 208.246.88.73: icmp_seq=30 ttl=64 time=0.467 ms
64 bytes from 208.246.88.73: icmp_seq=32 ttl=64 time=0.474 ms
64 bytes from 208.246.88.73: icmp_seq=34 ttl=64 time=0.478 ms
^C
--- 208.246.88.73 ping statistics ---
35 packets transmitted, 18 packets received, 48% packet loss
round-trip min/avg/max = 0.463/0.477/0.53 ms

[ROBERT-YOUNGS-C:~] robertyo% ping 208.246.88.249 {Vax w/ Multinet}
PING 208.246.88.249 (208.246.88.249): 56 data bytes
64 bytes from 208.246.88.249: icmp_seq=0 ttl=255 time=0.9 ms
64 bytes from 208.246.88.249: icmp_seq=1 ttl=255 time=0.67 ms
64 bytes from 208.246.88.249: icmp_seq=2 ttl=255 time=0.64 ms
64 bytes from 208.246.88.249: icmp_seq=3 ttl=255 time=0.646 ms
64 bytes from 208.246.88.249: icmp_seq=4 ttl=255 time=0.633 ms
64 bytes from 208.246.88.249: icmp_seq=5 ttl=255 time=0.636 ms
64 bytes from 208.246.88.249: icmp_seq=6 ttl=255 time=0.649 ms
64 bytes from 208.246.88.249: icmp_seq=7 ttl=255 time=0.682 ms
64 bytes from 208.246.88.249: icmp_seq=8 ttl=255 time=0.637 ms
64 bytes from 208.246.88.249: icmp_seq=9 ttl=255 time=0.644 ms
64 bytes from 208.246.88.249: icmp_seq=10 ttl=255 time=0.643 ms
64 bytes from 208.246.88.249: icmp_seq=11 ttl=255 time=0.654 ms
64 bytes from 208.246.88.249: icmp_seq=12 ttl=255 time=0.637 ms
^C
--- 208.246.88.249 ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 0.633/0.667/0.9 ms

[Cass Witkowski]

Please check that the duplex setting at both sides are the same. We have seen interesting behavior when one side was half and the other was full duplex. Use MC LANCP SHOW DEVICE xxxx /CHAR

[Robert Young_13]

Very odd behavior.....I plugged in BOTH the 10/100 and the 10/100/1000 RJ45 ports (giving them different IP numbers). Now I do not loose pings, and FTP appears to work!!!???

I will not look a gift horse in the mouth (it may stop working in 10 min), but does anyone have an idea as to why???