System error 232: Connection reset by peer

[Jayesh Nishane]

I have at my site Itanium based HP servers running HP Unix 11 V2. I have Rockwell PLC's communicating with my HP servers. I have intermitent communication breaks and get error "System error 232: Connection reset by peer" on my server. Few months back I had Alpha servers with TRU64 Unix as OS. That time there was no such errors. But after migrating to HP Unix on Itanium based servers, communication breaks are intermitent. Can anyone help me?

[skt_skt]

which protocol is used between them ?

[Jayesh Nishane]

Communication between server and PLC is TCP/IP

[Asif Sharif]

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1047978
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=255726

Regards,
Asif Sharif

[Jayesh Nishane]

When I had Digital Unix Tru64, I did not have any communication problem. But after I migrated to HP Unix, this problem started. There is no change in PLC and Network switches and also its configuration. Only change is Server hardware from Alpha server running Tru64 Unix to Itanium based server running HPUX 11 v2.

[Johnson Punniyalingam]

Hi Jay,

How about you LAN Card settings..?

are they 100Full duplex

lanadmin -x


Thanks,
JOhnson

[Jayesh Nishane]

PLC works on 10 half. So on switch I have configured as 10 half and server works on 100 full so configured on switch port too as 100 full. These configurations are same as when I was using Aplha server. Except the servers and OS, everything is similar.

[rick jones]

Connection reset by peer means the peer (in this case the PLCs think that they can no longer effectively communicate with the server(s) or that the server did something "bad" in TCP protocol terms, or in application protocol terms.

The next step is to take a packet trace with say tcpdump and capture one of these connections to see what might be the cause of the reset. Not just the ReSeT segment itself, but as much of the traffic on the connection before it as practical.

Meanwhile, making sure there is no duplex mismatch would be goodness. My personal suggestion/preference is to remain with autoneg unless/until you know you have a bit of broken kit which cannot be repaired or replaced and hardcoding is the only kludge remaining.

Also, if there are stats one can retrieve on the PLCs it would be good to check those. Perhaps there will be a correlation between the connection resets and one or more stats on the PLCs.

[Mel Burslan]

I'd suggest you speak to the folks who manage your network. Possible problems are usually related to firewalls which might be put between your server and the PLC devices, causing this behavior.

Without knowing the TCP/IP communication details, it is hard to say anything more specific.

[Laurent Menase]

It could be due to an other system using the same ip adresse too.

you can check nettl.log

Else the first step is indeed to check network traces
A reset may contain a message with the cause of the reset.
- if you can have a trace from both local & peer system it is usually even better, to check
if the cause could not come from the network itself.

To tcpdump, prefer nettl traces.
nettl traces differenciate inbound and outbound messages, but the command depends of your interface.
you can also use -m option (-m 128 is usually good enough) to limit the size of the acquisition, to help to not lost packets.
and you can analyze the traces using wireshark.


You can also contact HP support to get help on that.