Romney, again thanks for discussing this. I did not know that more than one
packet (small as my datagrams may be) might be "pushed" in big chunks over
the CTC from TCP/IP on Linux to TCP/IP on VM.
In doing some more research on this, I see in the IBM Linux for S/390 Device
Drivers and Installation Commands doc for kernal 2.2.16 there is a note in
the CTC/ESCON device driver chapter which says:
It is important that you have IOBUFFERSIZE 32678 defined because the
LINUX for S/390 CTC driver works with 32k internally. This is configurable
for each device by writing the value to the buffersize file for that
device
(proc/net/ctc/<devicename>/buffersize ), for example
echo 32768 >/proc/net/ctc/ctc0/buffersize
I don't see folder "ctc" under /proc/net. I do understand that the echo
command shown above will create it. And I will try that next.
Restating what I think you mentioned earlier, it seems that TCP/IP on VM is
limited to a 32K buffer. I've looked in the TCP/IP for VM doc and I don't
see any records which control the size of that buffer. Have I misunderstood
you or misread the doc?
Thanks for your assistance!
William P. Scully
Systems Programmer
Computer Associates International, Inc
[EMAIL PROTECTED]
-----Original Message-----
From: Romney White [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 13, 2002 12:17 PM
To: [EMAIL PROTECTED]
Subject: Re: FW: TCP/IP and Linux
Bill:
This has nothing to do with MTU size. MTU size determines the maximum
size of a datagram. The datagrams are packed into a 32K buffer for
transport across the CTCA. That's where the problem is occurring.
Romney
On Wed, 13 Feb 2002 11:49:03 -0500 Scully, William said:
>Thanks for the info Romney! On one of the Linux servers where I get the
>error, I did an IFCONFIG and I find:
>
>
>linux017:~ # ifconfig
>ctc0 Link encap:Serial Line IP
> inet addr:141.202.232.131 P-t-P:141.202.198.101
>Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
> RX packets:7407345 errors:0 dropped:0 overruns:0 frame:0
> TX packets:13113625 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:3924 Metric:1
> RX packets:2629004 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2629004 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
>
>
>I see an MTU of 1500 on ctc0. So how did such a large packet end up on the
>CTC between Linux and VM?
>
>-----Original Message-----
>From: Romney White [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 13, 2002 11:02 AM
>To: [EMAIL PROTECTED]
>Subject: Re: TCP/IP and Linux
>
>
>Bill:
>
>The message is documenting the fact that Linux sent a malformed block
>of packets across the CTCA. The blocks may be up to 32K (32768 bytes)
>long, so a packet starting at 33134 is clearly an error. The offending
>packet is at offset 31628 in the buffer.
>
>I presume that there is a mismatch in the buffer size between Linux
>and VM TCP/IP and hope there is a control you can set on the Linux
>side to use a buffer size of 32K.
>
>Romney
>
>On Wed, 13 Feb 2002 10:55:27 -0500 Scully, William said:
>>(Cross-posted to the VM and Linux on 390 lists)
>>
>>We find a lot of the following messages on TCP/IP's console (FL 3A0)
>>regarding the CTCs for Linux servers:
>>
>>22:50:10 DTCCTC008E CTCA device LINUX016: UnpackReads: Inv blk hdr 33134
>>from input position 31628. Last blk hdr 0. Discarding remainder of block.
>>
>>
>>Are others of you out there seeing this? The message doesn't seem to be
>>documented. What does it mean? It appears that some (but not all)
servers
>>loose connectivity when this happens.
>>
>>William P. Scully
>>Systems Programmer
>>Computer Associates International, Inc
>>[EMAIL PROTECTED]
