socket shutdown not recognized

[Thomas Prause]

Hi all,

I've a problem w/ a client-server application. Sometimes the client (on 5.1B patchkit 3) is still waiting for data while the remote part has already shutdown the connection. netstat on remote system shows NO open connection to the client machine, but netstat on the client shows the connection to the server still as ESTABLISHED.

client use the "select()" call to check if there is data available on the socket, but get's always rc EWOULDBLOCK=35.

Has anybody seen something similar?
This looks like a bug to me or is there anything I've missed.

BTW The application runs fine on 4.0F and some other platforms.


Any pointers are welcome.

Thomas Prause

[Ralf Puchner]

EWOULDBLOCK warnings come from the underlying network and indicate (normally) a transient throughput bottleneck. If they are more consistent then I would recommend doing some network tuning.

If the socket will be closed from the other side, check if keepalive is activated on the system (have a look into previous postings explaining the subsystem parameters of keepalive).

Another approach is to check that the application have an error handling implemented for the used sockets. If the remote side exits, there must be some code dealing with this kind of event.

Be sure you have installed the latest patchkit of 5.1B with keepalive bugfix (problems occures after uptime of 96 days).

[Thomas Prause]

netstat on this machine shows a lot of errors for incoming pakets:
-> netstat -I tu0
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
tu0 1500 00:00:f8:75:b9:89 1943669 62414 1470436 0 0
tu0 1500 DLI none 1943669 62414 1470436 0 0
tu0 1500 192.168.1.0 hostname 1943669 62414 1470436 0 0


This indicates the OS recognize the errors, but why doesn't my application get notified?

[Michael Schulte zur Sur]

Hi,

could you please post netstat -Itu -s
? As Ralf said, it might be a result of a bug, so check on that. I am not too firm in that, but I would think, that because of the different layers it does not get reported to the application.

hth,

Michael

[Ralf Puchner]

Thomas,

it seems your machine is not properly configured with full/half duplex speed.

Please be sure you have set the tulip cards to fixed mode (ewa0_mode=fast or ewa0_mode=fastfd on srm console) instead of autoneg. The switch must also been set to the same settings.

If this doesn't help disable full duplex - not all switches works properly with the tulip cards.

The TCP/IP stack is based on RFC's which are available on the internet. Read the section about keepalive and you can answer your question by yourself....

[Thomas Prause]

@Micheal

thanks for the cmd, that's what I was looking for some weeks ago ;-)
here's the output:

--snip
netstat -Itu -s

tu0 Ethernet counters at Mon May 3 07:10:56 2004

161792 seconds since last zeroed
3894978107 bytes received
7886699073 bytes sent
5318505 data blocks received
6810812 data blocks sent
11253987 multicast bytes received
103904 multicast blocks received
715365 multicast bytes sent
5247 multicast blocks sent
0 blocks sent, initially deferred
0 blocks sent, single collision
0 blocks sent, multiple collisions
1 send failures, reasons include:
1 user buffer unavailable
402757 receive failures, reasons include:
891 frame too long
208369 frame check sequence errors
193497 frame error

---snip

@Ralf
We had some problems w/ ftp after the initial setup of the system. The admin pretends they have been fixed by setting the NIC to half duplex - but I'll check.

Thank's for your responses.

[Ralf Puchner · Accepted solution]

"frame too long" and "frame error" indicates a hardware problem (cabling, switch, ports etc.)

[Thomas Prause]

setting the card to half duplex let the tests run w/o any problem since monday

I'll dig into the code, to check how to improve the app to make it recognizing such errors

thanks for your support
Thomas Prause