TCPIP problem with 7.3-1

TCPIP problem with 7.3-1

Post by Irving F. Snur » Wed, 25 Jun 2003 01:46:31



We upgraded from 7.3 to 7.3-1 and now cannot talk to a TCPIP motor
controller (Parker  CompuMotor 6k).  We cannot telnet or "connect"
(socket code), whereas we could do both with 7.3.  We tried Linux, and
vms 7.2, and they're both able to talk to it.

The motor controller is sort  of stupid; it does not respond to ARP
broadcasts, so we bind the MAC address to the IP number in vms before we
connect, but the source and destination MAC addresses are in the connect
packet.  The motor controller just does not want to respond to 7.3.

Has anyone else had tcpip trouble?  I guess we'll have to go back to 7.3.

        regards, Bill Manwaring, IUCF

 
 
 

TCPIP problem with 7.3-1

Post by Thomas H. Paul » Wed, 25 Jun 2003 03:49:45


Hi,

I think it's not VMS you have problems with, but the TCP/IP stack. Which
version do you run now ($ TCPIP SHOW VERSION) and which did you run before
? Perhaps you've got a TCP/IP upgrade wioth your VMS upgrade!

Thomas



Quote:> We upgraded from 7.3 to 7.3-1 and now cannot talk to a TCPIP motor
> controller (Parker  CompuMotor 6k).  We cannot telnet or "connect"
> (socket code), whereas we could do both with 7.3.  We tried Linux, and
> vms 7.2, and they're both able to talk to it.

> The motor controller is sort  of stupid; it does not respond to ARP
> broadcasts, so we bind the MAC address to the IP number in vms before we
> connect, but the source and destination MAC addresses are in the connect
> packet.  The motor controller just does not want to respond to 7.3.

> Has anyone else had tcpip trouble?  I guess we'll have to go back to 7.3.

> regards, Bill Manwaring, IUCF

--
Thomas H. Pauli
Hammersteinstr. 19
14199 Berlin
Germany

 
 
 

TCPIP problem with 7.3-1

Post by Peter 'EPLAN' LANGSTOEG » Wed, 25 Jun 2003 04:00:12



Quote:>We upgraded from 7.3 to 7.3-1 and now cannot talk to a TCPIP motor
>controller (Parker  CompuMotor 6k).  We cannot telnet or "connect"
>(socket code), whereas we could do both with 7.3.  We tried Linux, and
>vms 7.2, and they're both able to talk to it.

>The motor controller is sort  of stupid; it does not respond to ARP
>broadcasts, so we bind the MAC address to the IP number in vms before we
>connect, but the source and destination MAC addresses are in the connect
>packet.  The motor controller just does not want to respond to 7.3.

>Has anyone else had tcpip trouble?  I guess we'll have to go back to 7.3.

Not likely.
TCPIP communication is done via the TCPIP addon product.
What is the version of your installed stack ?
Did you (re)install it after the VMS upgrade ?
Do you know that TCPIP V5.3 (ECO2, with ECO3 almost here) and TCPIP_SSH
(which updates core components of TCPIP) is current ?
Do you know that other IP stacks (TCPware, Multinet) do also run
(sometimes much better and sometimes much cheaper than TCPIP) on V7.3-1 ?
Did you try to reconfig TCPIP after the VMS and/or TCPIP upgrade ?

--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist

A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist

 
 
 

TCPIP problem with 7.3-1

Post by Irving F. Snur » Wed, 25 Jun 2003 06:36:51


We're running the 5.3 stack, and our systems guy did the "mandatory
TCPIP update" as part of the upgrade to VMS 7.3-1.  We're running on an
alpha DS10. We aren't sure what the stack was under 7.3.  Our alpha can
talk to PLCs and other machines.  Our systems guy broke down the
connect packets and they look the same as the packets coming from
machines that succeed in talking to the motor controller.  He's
scratching his head; I was hoping some resourceful puzzle-solver sys

        Bill Manwaring, IUCF


> Hi,

> I think it's not VMS you have problems with, but the TCP/IP stack.
> Which version do you run now ($ TCPIP SHOW VERSION) and which did you
> run before ? Perhaps you've got a TCP/IP upgrade wioth your VMS upgrade!

> Thomas

> On Mon, 23 Jun 2003 11:46:31 -0500, Irving F. Snurd

>> We upgraded from 7.3 to 7.3-1 and now cannot talk to a TCPIP motor
>> controller (Parker  CompuMotor 6k).  We cannot telnet or "connect"
>> (socket code), whereas we could do both with 7.3.  We tried Linux,
>> and vms 7.2, and they're both able to talk to it.

>> The motor controller is sort  of stupid; it does not respond to ARP
>> broadcasts, so we bind the MAC address to the IP number in vms before
>> we connect, but the source and destination MAC addresses are in the
>> connect packet.  The motor controller just does not want to respond
>> to 7.3.

>> Has anyone else had tcpip trouble?  I guess we'll have to go back to
>> 7.3.

>> regards, Bill Manwaring, IUCF

 
 
 

TCPIP problem with 7.3-1

Post by Michael Austi » Wed, 25 Jun 2003 09:45:32



> We upgraded from 7.3 to 7.3-1 and now cannot talk to a TCPIP motor
> controller (Parker  CompuMotor 6k).  We cannot telnet or "connect"
> (socket code), whereas we could do both with 7.3.  We tried Linux, and
> vms 7.2, and they're both able to talk to it.

> The motor controller is sort  of stupid; it does not respond to ARP
> broadcasts, so we bind the MAC address to the IP number in vms before we
> connect, but the source and destination MAC addresses are in the connect
> packet.  The motor controller just does not want to respond to 7.3.

> Has anyone else had tcpip trouble?  I guess we'll have to go back to 7.3.

>         regards, Bill Manwaring, IUCF

sounds like a routing issue and/or a port speed issue.  If you are
funning 5.3 make you install ECO2 --or you will have more strange
problems than just this one... Been there, done that --- and didn't like
it at all!!!

--
Regards,

Michael Austin            OpenVMS User since June 1984
First DBA Source, Inc.    Registered Linux User #261163
Sr. Consultant            http://www.firstdbasource.com

 
 
 

TCPIP problem with 7.3-1

Post by John Gemignani, Jr » Wed, 25 Jun 2003 11:13:16




> We're running the 5.3 stack, and our systems guy did the "mandatory
> TCPIP update" as part of the upgrade to VMS 7.3-1.  We're running on an
> alpha DS10. We aren't sure what the stack was under 7.3.  Our alpha can
> talk to PLCs and other machines.  Our systems guy broke down the
> connect packets and they look the same as the packets coming from
> machines that succeed in talking to the motor controller.  He's
> scratching his head; I was hoping some resourceful puzzle-solver sys
> admin out there would say, "Oh, yeah, we've seen that; just diddle the

>         Bill Manwaring, IUCF

Try showing some of the counters from the TCPIP utility and see if anything
is being dropped.  You aren't running the two stacks at the same time,
right?  It's possible that you have turned something on/off in the upgrade
that doesn't match your previous configuration.  If the controller is really
dumb, is it possible that it has checksumming turned off?

-John


> > Hi,

> > I think it's not VMS you have problems with, but the TCP/IP stack.
> > Which version do you run now ($ TCPIP SHOW VERSION) and which did you
> > run before ? Perhaps you've got a TCP/IP upgrade wioth your VMS upgrade!

> > Thomas

> > On Mon, 23 Jun 2003 11:46:31 -0500, Irving F. Snurd

> >> We upgraded from 7.3 to 7.3-1 and now cannot talk to a TCPIP motor
> >> controller (Parker  CompuMotor 6k).  We cannot telnet or "connect"
> >> (socket code), whereas we could do both with 7.3.  We tried Linux,
> >> and vms 7.2, and they're both able to talk to it.

> >> The motor controller is sort  of stupid; it does not respond to ARP
> >> broadcasts, so we bind the MAC address to the IP number in vms before
> >> we connect, but the source and destination MAC addresses are in the
> >> connect packet.  The motor controller just does not want to respond
> >> to 7.3.

> >> Has anyone else had tcpip trouble?  I guess we'll have to go back to
> >> 7.3.

> >> regards, Bill Manwaring, IUCF

 
 
 

TCPIP problem with 7.3-1

Post by Peter Flunge » Wed, 25 Jun 2003 22:36:03



Quote:

> Has anyone else had tcpip trouble?  I guess we'll have to go back to 7.3.

Yes, we had a lot of problems after upgrading to VMS7.3 LAN03
and VMS 7.3-1 LAN02 ECOs.
If you have a DE6xxx series card in your DS10 you might find
the following information usefull:

HP implemented a new autosensing algorithm for their DE6xx
series ethernet HBAs. ( EIDRIVER Image )
If you are connected to a port ( switch/hub ) that supports autosensing,
you will have to change the ethernet Card on console level to use
autosenseing as well.
( set ewx0_mode auto_negotiate )
If you set the device to use FastFD and the Port on the switch is configured
for
autonegotiation you will see the oddest things happen. ( huge packet loss
rates,
no communication at all, or communication working but veeeeeer slow, aso )
So either set both sites to a fixed speed or use autonegotiation on both
sides.
HtH , Peter

 
 
 

TCPIP problem with 7.3-1

Post by Carl Karch » Wed, 25 Jun 2003 23:27:13



->We're running the 5.3 stack, and our systems guy did the "mandatory
->TCPIP update" as part of the upgrade to VMS 7.3-1.  We're running on an
->alpha DS10. We aren't sure what the stack was under 7.3.  Our alpha can
->talk to PLCs and other machines.  Our systems guy broke down the
->connect packets and they look the same as the packets coming from
->machines that succeed in talking to the motor controller.  He's
->scratching his head; I was hoping some resourceful puzzle-solver sys
->admin out there would say, "Oh, yeah, we've seen that; just diddle the

TCPIP 5.3 did change quite a few stack settings to be consistent with
TCPIP on TRUE64. One of the changes that affected us was increasing
tcp_keepidle from 150 (75 seconds) to 14400 (2 hours). You can set that
back to the 5.1 value with:


  $ sysconfig -r inet tcp_keepidle=150

To list all inet settings:

  $ sysconfig -q inet

Others were changed too. The trouble is without a TCPIP 5.1 system
around you won't know what the 5.1 values were as I've never found any
documentation of the changes.

--
-- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison

 
 
 

TCPIP problem with 7.3-1

Post by John Travel » Thu, 26 Jun 2003 05:15:49




> ->We're running the 5.3 stack, and our systems guy did the "mandatory
> ->TCPIP update" as part of the upgrade to VMS 7.3-1.  We're running on an
> ->alpha DS10. We aren't sure what the stack was under 7.3.  Our alpha can
> ->talk to PLCs and other machines.  Our systems guy broke down the
> ->connect packets and they look the same as the packets coming from
> ->machines that succeed in talking to the motor controller.  He's
> ->scratching his head; I was hoping some resourceful puzzle-solver sys
> ->admin out there would say, "Oh, yeah, we've seen that; just diddle the

> TCPIP 5.3 did change quite a few stack settings to be consistent with
> TCPIP on TRUE64. One of the changes that affected us was increasing
> tcp_keepidle from 150 (75 seconds) to 14400 (2 hours). You can set that
> back to the 5.1 value with:


>   $ sysconfig -r inet tcp_keepidle=150

You need to know why you want to set tcp_keepidle to any particular value.

What tcp_keepidle does is control the elapsed time between successive checks
to see if the application initiating the IP connection is still alive.
Example problem:
I used to have a dial-back-on-demand ISDN connection. This was intended to
be connected only when activity actually required it to be, and remain as a
'virtual' connection when idle. The problem was that I was getting the line
re-connected after only a minute's idle time even when I was at lunch.
After eliminating all of the suspected Windoze trash, the problem turned to
be tcpip on VMS, caused by a tcp_keepidle setting of 150.
My ISDN disconnect timer was set to 90 seconds, so when the line was
connected to do a keepalive check, it was still alive for the next keepalive
75 seconds later. The line was dropped at 90 seconds, then a minute later
was picked up again for the next keepalive...
Setting tcp_keepidle to 14400 saved over a thousand pounds a year in ISDN
phone bills !

Before you set tcp_keepidle back to 150, you really need to know exactly WHY
this is the right way to solve whatever problem you have.

--
John Travell
VMS crashdump expertise for hire

http://www.travell.uk.net/

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 10/06/2003

 
 
 

TCPIP problem with 7.3-1

Post by Carl Karch » Thu, 26 Jun 2003 06:45:23



->Before you set tcp_keepidle back to 150, you really need to know exactly WHY
->this is the right way to solve whatever problem you have.

That's why I wish they had documented this major change. This is a big
difference between TCPIP 5.1 and 5.3 which is related to this thread.
I don't know what other parameters were changed but am told this was
not the only one (I have no 5.1 system to compare with).

Quote:> Setting tcp_keepidle to 14400 saved over a thousand pounds a year in ISDN
> phone bills !

In our case the change to 14400 resulted in leaving a file open after
a PC application (Eudora with mailboxes on a pathworks share)
abnormally terminated. This essentially caused the user to be locked
out of the application for 2 hours. Goes to show how "your mileage may
vary".

--
-- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison

 
 
 

TCPIP problem with 7.3-1

Post by HARANGOZO CSAB » Thu, 26 Jun 2003 08:37:39


[...snip...]

Quote:> To list all inet settings:

>  $ sysconfig -q inet

> Others were changed too. The trouble is without a TCPIP 5.1 system
> around you won't know what the 5.1 values were as I've never found any
> documentation of the changes.

        The following are the inet default values in TCPIP 5.1, *except*
        tcp-recvspace & tcp_sendspace.

$tcpip show ver

  Compaq TCP/IP Services for OpenVMS Alpha Version V5.1 - ECO 3
  on a AlphaServer 8200 5/300 running OpenVMS V7.3-1  

$sysconfig -q inet
inet:
inifaddr_hsize = 32
ipdefttl = 64
ipdirected_broadcast = 0
ipforwarding = 0
ipfragttl = 60
ipgateway = 0
ipport_userreserved = 65535
ipport_userreserved_min = 49152
ipqmaxlen = 1024
ipqs = 1
ipsendredirects = 1
ipsrcroute = 1
pmtu_decrease_intvl = 1200
pmtu_enabled = 1
pmtu_increase_intvl = 240
pmtu_rt_check_intvl = 20
subnetsarelocal = 1
tcbhashnum = 1
tcbhashsize = 512
tcbquicklisten = 1
tcp_compat_42 = 1
tcp_cwnd_segments = 2
tcp_dont_winscale = 0
tcp_keepalive_default = 0
tcp_keepcnt = 8
tcp_keepidle = 150
tcp_keepinit = 150
tcp_keepintvl = 150
tcp_msl = 60
tcp_mssdflt = 536
tcpnodelack = 1
tcp_recvspace = 49152
tcp_rexmit_interval_min = 2
tcp_rexmtmax = 128
tcprexmtthresh = 3
tcp_rttdflt = 3
tcp_sendspace = 49152
tcp_ttl = 60
tcptwreorder = 0
tcp_urgent_42 = 1
udpcksum = 1
udp_recvspace = 42080
udp_sendspace = 9216
udp_ttl = 30
ovms_nobroadcastcheck = 0
$
                                        Cheers,   Csaba

 -------------------------------------------------------------------------
  CSABA I. HARANGOZO  |d|i|g|i|t|a|l|  csabah(at)zipworld(dot)com(dot)au
 -------------------------------------------------------------------------
   EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:

 Wood's Axiom :
  As soon as a still-to-be-finished computer task becomes a life-or-death
          situation, the power fails.

 
 
 

TCPIP problem with 7.3-1

Post by Michael Ric » Thu, 26 Jun 2003 08:59:02




> ->Before you set tcp_keepidle back to 150, you really need to know exactly WHY
> ->this is the right way to solve whatever problem you have.

> That's why I wish they had documented this major change. This is a big
> difference between TCPIP 5.1 and 5.3 which is related to this thread.
> I don't know what other parameters were changed but am told this was
> not the only one (I have no 5.1 system to compare with).

>>Setting tcp_keepidle to 14400 saved over a thousand pounds a year in ISDN
>>phone bills !

> In our case the change to 14400 resulted in leaving a file open after
> a PC application (Eudora with mailboxes on a pathworks share)
> abnormally terminated. This essentially caused the user to be locked
> out of the application for 2 hours. Goes to show how "your mileage may
> vary".

The 14400 value is the normal setting for most platforms.  The setting
is only used when TCP keepalive packets are being sent (i.e., the
SO_KEEPALIVE option is set for the socket).

I'm surprised that setting it back to 75 seconds was sufficient for you.
  I've always seen (on other operating systems) the tcp_keepidle used in
combination with other parameters such as tcp_keepcnt (usual default is
8) and tcp_keepintvl (usual default is 75 seconds).  I wonder how these
parameters are used in VMS TCPIP.  IIRC, under "default" conditions, the
stack will wait for 2 hours (tcp_keepidle) of inactivity before issuing
the first keepalive.  It will then try 8 times (tcp_keepcnt), issuing 1
keepalive every 75 seconds (tcp_keepintvl).  This gives a "default"
keepalive timeout of 7800 seconds.  Just changing tcp_keepidle to 75
seconds should have resulted in a timeout of 675 seconds.

 
 
 

TCPIP problem with 7.3-1

Post by JF Meze » Fri, 27 Jun 2003 03:54:45


re: machine controller not reachable.

Have you checked the routing tables to make sure that VMS knows how to send a
packet t that device ?

Have you used TCPTRACE to see if VMS sends out the packets to the machine
properly (or perhaps the machine does reply, but packets go seomewhere else ?)

 
 
 

TCPIP problem with 7.3-1

Post by JF Meze » Fri, 27 Jun 2003 04:34:23



>   $ sysconfig -q inet

> Others were changed too. The trouble is without a TCPIP 5.1 system
> around you won't know what the 5.1 values were as I've never found any
> documentation of the changes.

Here is the output of the above on a 5.0a system and 5.3- ECO 2 (VAX)
(interesting that 5.0 had some parameters no longer shown). Note that I have
not removed those lines that are the same since it gives a better idea of how
much has and hasn't changed.

 5.0A                                     5.3-2
inet:                                   inet:
                                        icmp_rejectcodemask = 0
inifaddr_hsize = 32                     inifaddr_hsize = 32
ipdefttl = 64                           ipdefttl = 64
ipdirected_broadcast = 0                ipdirected_broadcast = 0
ipforwarding = 1                        ipforwarding = 1
ipfragttl = 60                          ipfragttl = 60
ipgateway = 1                           ipgateway = 1
ipport_userreserved = 5000              ipport_userreserved = 65535
                                        ipport_userreserved_min = 49152
                                        ipqmaxlen = 1024
                                        ipqs = 1
ipsendredirects = 1                     ipsendredirects = 1
ipsrcroute = 1                          ipsrcroute = 1
route_round_robin = 0
ipv6router = 0
ipv6forwarding = 0
ipv6_tunnel_default_mtu = 1280
ipv4_tunnel_default_mtu = 1280
pmtu_decrease_intvl = 1200              pmtu_decrease_intvl = 1200
pmtu_enabled = 1                        pmtu_enabled = 1
pmtu_increase_intvl = 240               pmtu_increase_intvl = 240
pmtu_rt_check_intvl = 20                pmtu_rt_check_intvl = 20
subnetsarelocal = 1                     subnetsarelocal = 1
                                        tcbhashnum = 1
tcbhashsize = 32                        tcbhashsize = 512
tcbquicklisten = 0                      tcbquicklisten = 1
tcp_compat_42 = 1                       tcp_compat_42 = 1
tcp_cwnd_segments = 2                   tcp_cwnd_segments = 2
tcp_dont_winscale = 0                   tcp_dont_winscale = 0
tcp_keepalive_default = 0               tcp_keepalive_default = 0
tcp_keepcnt = 8                         tcp_keepcnt = 8
tcp_keepidle = 150                      tcp_keepidle = 14400
tcp_keepinit = 150                      tcp_keepinit = 150
tcp_keepintvl = 150                     tcp_keepintvl = 150
tcp_msl = 60                            tcp_msl = 60
tcp_mssdflt = 536                       tcp_mssdflt = 536
tcpnodelack = 0                         tcpnodelack = 0
tcp_recvspace = 32768                   tcp_recvspace = 61440
tcp_rexmit_interval_min = 2             tcp_rexmit_interval_min = 2
tcprexmtthresh = 3                      tcp_rexmtmax = 128
tcp_rttdflt = 3                         tcprexmtthresh = 3
                                        tcp_rttdflt = 3
tcp_sendspace = 32768                   tcp_sendspace = 61440
tcp_ttl = 60                            tcp_ttl = 60
tcptwreorder = 1                        tcptwreorder = 0
tcp_urgent_42 = 1                       tcp_urgent_42 = 1
udpcksum = 1                            udpcksum = 1
udp_recvspace = 41920                   udp_recvspace = 42080
udp_sendspace = 9216                    udp_sendspace = 9216
udp_ttl = 30                            udp_ttl = 30
                                        ovms_nobroadcastcheck = 0
                                        ovms_printf_to_opcom = 1

 
 
 

1. oracle/telnet-tcpip 5.3/vms 7.3-1

I'm having a strange problem that I hope someone can help with.

In our test cluster, we were running vms E7.3-1 (field test) with tcpip 5.3
and oracle
7.3.3.6 (and also oracle 8.1.7.3).  Yesterday, I upgraded vms to the
production version of
 V7.3-1.  Nothing else changed.  When the cluster came back up, everything
worked
 fine...except SVRMGRL and SQLPLUS.  When you telnet into the node, or come
in via
 reflection X, invoking svrmgrl produces the following two lines (after the
normal header):

MGR-11401: input error, unable to read input line
MGR-01508: unable to close the current file

Invoking sqlplus, without a username/password, is supposed to prompt and
wait for the
 username.  It comes up with the username prompt, and then immediately exits
back to dcl
 without waiting.  Invoking sqlplus with a username/password gets into the
program, but then
 the sql> prompt then keeps appearing and scrolling up the screen as if you
were holding
 down the RETURN key!  So, it seems to me these programs are acting like
sys$input is not
 defined, or something like that.  

Here's the kicker...everything works fine if you SET HOST into the node.
SVRMGRL and
 SQLPLUS both work as expected.

Argh!

Everything else seems to work fine, any other program I run, just not
oracle.  I've tried
logging in with /nocom, in case there was some interaction there, I've tried
defining sys
$input, I've done this in oracle 7.3 and 8i, and I also booted off the
backup copy of the
 system disk, to see if the problem was in oracle, but it worked fine there!

It seems to be some interaction with TELNET and oracle, but the tcpip
version DID NOT
change!  I also reinstalled tcpip 5.3 and the mup for 5.3, but that didn't
change anything.
Oh, and I didn't have the mup in place right away, so this happened both
with and without
 the mup.

I've logged a call, but Colorado support is also not sure what else to look
at.

Does anyone here have any ideas?

Thanks,
Ron

2. Relevant?

3. 7.2-1 and 7.3-1 NFS and block size

4. Naming Spec

5. Trouble with NFS since upgrade 7.3 -> 7.3-1

6. Hardware IO under NT/2000

7. Going 7.2-1 -> 7.3-1

8. Help with 'net send'...

9. Release date for 7.3 (and 7.3-1??)

10. VMS 7.3-1 DIR tape problem

11. Telnet problem after 7.3-1 Upgrade.

12. First 7.3-1 problem detected

13. Poor disk i/o performance on DS10L (scsi) OpenVMS 7.3-1