TCP packet sizes

[Keith Rooks]

TCP/IP V5.1 - ECO 4 / DS10 466 MHz OpenVMS V7.2-1

A 3rd party is trying to send data via HTTP from a solaris machine to an application triggered by a TCPIP service on the AlphaServer.

We have this option working with other sources using windows apps, internet explorer, or even another alphaserver.

However, the connection is not being made from the Solaris box, firewalls and settings have been checked and rechecked. We placed a reject from our firewall which showed them being rejected, then allowed them back in. Sometimes TCPTRACE will show that packet(s) have been lost due to size. Often there's no indication of any TCP traffic.

We have 2 interfaces set up.

Interface LO0 WE0
Packets
Receive 14609 2099958
Send 14609 3273469
MTU 4096 1500

The alphaserver ipaddress is on the WE0 interface, and the service set up:

Service: XDI
State: Enabled
Port: 17496 Protocol: TCP Address: 0.0.0.0
Inactivity: 10 User_name: ADVDECNET Process: XDI
Limit: 32 Active: 0 Peak: 1

File: XDI_SERVER
Flags: Listen

Socket Opts: Rcheck Scheck
Receive: 0 Send: 0


Log Opts: Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr
File: ADV$DECNET:XDI_EVENT.LOG

Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0


The 3rd party has suggested that we change the packet size, however, there's no clear indication how or where/what to set.

Any suggestions would be very welcome.

Many thanks

Keith Rooks

[Antoniov.]

Keith,
I'm not sure what you intend for packet size; TCP/IP standard make frames for long record size, so large data could not is a problem.
Perhaps, you can increase MTU: in this way alpha server manager socket bigger than 1500 bytes but I guess doesn't solve your problem because the other devices in your network could not manage socket larger than 1500 bytes.
However, Willem's thread postes a trouble like yours
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=613658

Antonio Vigliotti

[Art Wiens]

What does TCPIP> show int we0 /full show for error counts?

Art

[Willem Grooters]

Keith,
If you have a service, it will only start if there has been a write to the port it has been designed for. That means the Solaris box MUST send out something before the service op VMS can even start.

First question: DOES it really start? There should be a logfile ADV$DECNET:XDI_EVENT.LOG
which should give you at least some clue.
But as you stated:

the connection is not being made from the Solaris box

I would think the message isn't even sent, and you wouldn't find a logfile. If you do, what does it say?

One easy way to find out IF something gets in, is to create a as XDI_SERVER.COM like this:

$ OPEN/READ SYS$NET IN
$loop:
$ READ/END=loopend/ERR=ReadErr IN LINE
$ write sys$output LINE
$ goto loop
$ReadErr:
$ write sys$output "ReadError: ''$STATUS'"
$loopend:
$ close sys$net
$ exit

If you already have a logfile, what does it show?

(The suggestion to "change the packet size" is a typical response, and to be considered "last resort". The 3rd party should have their program be able to quope with different packet sizes. If it's TCP, it shouldn't matter at all!)

Antonio,
My problem wasn't I didn't get nothing, just 23K of the 40. and my communication was vms-to-vms. OTOH, it may give the 3rd party a clue what they did wrong ;-))

Willem

[Keith Rooks]

TCPIP> show int we0/fu
Interface: WE0
IP_Addr: 192.168.100.19 NETWRK: 255.255.255.0 BRDCST: 192.168.100.255
Ethernet_Addr: AA-00-04-00-EA-07 MTU: 1500
Flags: UP BRDCST RUN MCAST SMPX
RECEIVE SEND
Packets 3666019 5953083
Errors 0 0
Collisions: 0

No errors.

The firewall showed the 'hit' from the solaris box, but, either nothing registers or tcptrace will say it cannot save x packets.

I think that the advise about others saying that it's our problem is very sound. Even they have stated their experiences with other services like 'Tomcat' have been less than fruitful. They want us to change to using Appache or IIS, which will involve more work.

[Willem Grooters]

Keith,

have you bypassed the firewall and have the solaris box talk directly to VMS? DOES the logfile (as mentioned in the earlier message) actually exist - meaning: the service has been started?
If TCPDUMP doesn't see anything, I doubt it will leave the firewall.

Some other thought: be sure that the firewall transfers the packets to the right machine. Use TCPDUMP (or whatever sniffer) to see what's going OFF the firewall...

I cannot state anything on using a webserver (whatever brand) without knowing the third party software and your receiving application, and their interfacing connection. But it does make sense to use a webserver if they use plain HTML for passing information. I would rather go for Apache on OpenVMS, and just forget IIS. IIS is known to be quite leaky and insecure, and is known to be less stable, and far more expensive, than Apache (which comes free with VMS)

Willem
Willem

[Keith Rooks]

Many thanks to all your efforts.

Previously we had set up the comms to the customers machine on port 60001, however, we were experiencing similar problems to the above, and transferred to our development machine whilst trying to track down the problem.

The 3rd party wanted to communicate on port 80, as the machine was restricted to that for security reasons. Which we already use for the appache server that is used for other business on our dev machine. So we had to transfer testing back to our customer's machine.

Setting the port to 80, seems to have made them communicate.

[Ian Miller.]

if changing only port number fixes the problem then I would suspect some thing through which the link passes such as firewall.