[Info-vax] Update to TCP/IP problem with Alpha VMS 8.4

Sun Apr 15 18:40:28 EDT 2012

On Apr 14, 5:10 pm, "vmsmang... at earthlink.net"
<vmsmang... at earthlink.net> wrote:
> On Apr 14, 9:37 am, Neil Rieck <n.ri... at sympatico.ca> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 4, 6:58 pm, "vmsmang... at earthlink.net"
>
> > <vmsmang... at earthlink.net> wrote:
> > > I am really embarassed about my original post. I know I should have
> > > provided a great deal more information. Since I have been working with
> > > and using VMS since 5.4 I know how important it is to have complete
> > > information. So, here goes.
>
> > > The Alphaserver DS20 has 1 GB memory, 1 cpu, and a mylex raid
> > > controller. DRA0 is the VMS 7.3.2 system disk, DRA1 is a spare disk,
> > > and DRA2 is a 3 member RAID 5 device with a spare drive.
>
> > > The Apple iMac G5 is a Power Mac with 1 GB memory.
>
> > > Both systems have a hosts file, TCPIP$HOST.DAT on the DS20 and etc/
> > > hosts on the iMac. Here is the contents of that file and is the same
> > > for both systems.
>
> > > 10.1.1.1 cougar Cougar COUGAR
> > > 10.1.1.3 imacg5 Imacg5 IMACG5
> > > 10.1.1.10 printserver Printserver PRINTSERVER
>
> > > Both systems and the Printserve are connected to a 5 port network
> > > switch. 2 printers are attached to the Printserver, a laserjet and an
> > > inkjet.
> > > Both systems can print to both printers and can also ping each other
> > > and the Printserver.
>
> > > To prepare for the 8.4 upgrade I did an image backup from DRA0: to
> > > DRA1:. I also did an image backup of DRA0: to mag tape.
> > > The intent is to Upgrade DRA0: from 7.3-2 to 8.4.
>
> > > This will be fairly long so I am going to break it down into several
> > > smaller posts.
>
> > > Again, my apologies to everyone who replied.
>
> > > Bill LaCounte, aka VMSmangler
>
> > Not sure if you are still having a problem, but remember than PING is
> > a low level tool which does not involve TCP or UDP. This means if you
> > can't "PING by ADDRESS" (pinging by name sometimes introduces other
> > problems like typos in your host file, DNS problems, etc.) then you
> > can forget about all the other stuff. At this point there are only a
> > few things that make any difference:
>
> > 1) your IP address
> > 2) your NET mask
> > 3) maybe your MAC address
>
> > Going back to basics for a moment, remember that there are only a
> > couple of decision points here:
> > 1) use the netmask to compare your address with the destination
> > address. This tells the stack if the destination is on is on your
> > subnet or not.
> > 2) if the destination device is not on your subnet, then you need to
> > locate the nearest gateway which will handle the request for you. If
> > you know the address of the gateway then you will still need to use
> > ARP to locate the gateway's MAC address.
> > 3) if on your subnet, then use ARP to determine the MAC address of he
> > destination device.
> > (I still remember a 5-day Synoptics class on networking back in 1992
> > where the instructor forced us to learn the following mantra which was
> > recited before every lecture: "All communications is done at the MAC
> > layer)
>
> > Okay so you say the Mac it working properly. Get a copy of WireShark
> > (replaces Ethereal) and use it to monitor the traffic between the
> > Alpha and the Printserver. Can you see the ARP request and response?
> > Can you see the MAC-to-MAC ping and response?
>
> > p.s. be sure to inspect the netmask of all devices involved.
>
> > Just my 2 cents worth :-)
>
> > Neil Rieck
> > Kitchener / Waterloo / Cambridge,
> > Ontario, Canada.http://www3.sympatico.ca/n.rieck/
>
> On April 5th I submitted this information:
>
> @sys$manager:tcpip$config
> I selected Core services and got this information:
>
> HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu
> Hostname Details: Configured=cougar, Active=cougar
> Configuration options:
>    0  -  Set The Target Node (Current Node: COUGAR)
>    1  -  WE0 Menu (EWA0: TwistedPair 100mbps)
>    2  -  10.1.1.1/24         COUGAR                Configured,Active
>   [E] -  Exit menu
> Enter configuration option:
>
> I then did this:
>
> TCPIP> ifconfig -a
> LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
>      inet 127.0.0.1 netmask ff000000 ipmtu 4096
> TN0: flags=80<NOARP>
> TN1: flags=80<NOARP>
> WE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
>     *inet 10.1.1.1 netmask ffffff00 broadcast 10.1.1.255 ipmtu 1500
>
> localhost is set to 127.0.0.1
>
> Herre is the host database:
>
> 10.1.1.1 cougar Cougar COUGAR
> 10.1.1.3 imacg5 Imacg5 IMACG5
> 10.1.1.10 printserver Printserver PRINTSERVER
>
> I am back in the Seattle area and have the iMac with me. I won't be
> able to use the DS20 until Tuesday when I get home to Coeur d'Alene,
> Idaho.

This part looks OKAY to me. Nice to see that device WE0 does not
display "NOARP". Most people will already notice that the netmask is a
bit restrictive for a "10" network but that setting is not wrong (the
RFCs just consider it not-natural). Anyway, when I executed the same
command on an OpenVMS-7.3-2 system, it produced almost identical
results:

TCPIP> ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
     inet 127.0.0.1 netmask ff000000 ipmtu 4096
TN0: flags=80<NOARP>
TN1: flags=80<NOARP>
WE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX>
    *inet 142.180.221.220 netmask ffffe100 broadcast 142.180.223.255
ipmtu 1500

BTW, you might have produced a similar display by typing:
TCPIP> sho config inter

###

If you displayed the contents of the host database like this:
TCPIP> sho host/local
then I am surprised that you did not see a line like:
127.0.0.1       LOCALHOST, localhost

But as I said previously, PING is a very low level tool which uses
almost none of this stuff when pinging by address. The command looks
like this:

TCPIP> ping /address=142.180.221.226/noroute

PING 142.180.221.226 (142.180.221.226): 56 data bytes
64 bytes from 142.180.221.226: icmp_seq=0 ttl=64 time=7 ms
64 bytes from 142.180.221.226: icmp_seq=1 ttl=64 time=0 ms
64 bytes from 142.180.221.226: icmp_seq=2 ttl=64 time=0 ms
64 bytes from 142.180.221.226: icmp_seq=3 ttl=64 time=0 ms

The "/noroute" switch is only valid when staying on the same subnet
(which is what you are doing)

next you would want to check your arp tables like so right after your
PING:

TCPIP>sho arp

If you do not see an entry for your printserver, then
1) either an arp request never went out
2) the printserver never received the arp
3) the printserver ignored the arp
4) the printserver never answered back with a MAC
5) the Alpha wasn't able to place the MAC in the arp table

That's why you need to check further with a sniffer.

###

Stuff for hackers: if you were certain the OpenVMS platform was okay,
you might want to sniff from within VMS like so:

$ tcpdump :== $sys$system:tcpip$tcpdump.exe
$ tcpdump -?
Version 2.2.1
Usage: tcpdump [-BdeflmnNOqStvxX] [-s snaplen] [-c count] [-b buffers]
                [-r filename] [-w filename] [-F filter] [expr]
$ tcpdump
tcpdump: listening on WE0
Filtering in user process

Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/