TCP checksum calculation issue on HP-UX 11i v3

[Kuzmin Konstantin]

Hi.

I have a network STREAMS module, which does some transformation of ip-data of outgoing network packets. So the problem is that something calculates tcp checksum after the transformation does. The result is that on the receiving side I receive the corrupted packets (with correct tcp checksum).

I've already tried to disable TCP/UDP checksum offload, but it gave no effect.


Any suggestions?

Regards,
Konstantin.

Sending system: rp3440
ethernet: lan0: igelan 1000BaseT
OS: HP-UX 11.31

[rick jones]

Precisely where in the stack are you inserting your module?

IIRC CKO is by default disabled on all the 1G NICs under HP-UX.

Also, "ip-data" would seem to be the entire TCP segment - that is what IP would consider data. Are you manipulating the TCP headers? Or are you actually manipulating the data in the TCP segment?

BTW, is this data being sent by a normal "send" call, or is sendfile() being used? Sendfile() attempts to point the mblks at actual filesystem buffer cache buffers, so arbitrarily changing _that_ data might be bad... Not that that would lead to TCP checkum mismatches, but it could lead to some data corruption. It has however been some time since I've looked at UX networking internals, so perhaps the sendfile() call is already detecting non-standard modules in the stream and doing copies...

[Kuzmin Konstantin]

I've inserted my module between dlpi and ip as described here:
http://h21007.www2.hp.com/portal/site/dspp/PAGE.template/page.document?ciid=6b08a8ea6ce02110a8ea6ce02110275d6e10RCRD&jumpid=reg_R1002_USEN

I manipulate the whole ip-data, means that both tcp-header and tcp-data.

I've already tried the same test on HP-UX 11.23 (rx2620-2 IA-64, 1000Base-T), and there was not such problem. I intercept ip packet, transform it (output the tranformed result), and on the receiving side I get exactly the same transformed ip-packet.

But in situation with the first stand, described in the previous post, on receiving side I get transformed packet, but with recalculated TCP checksum. That have been rather a headache for me for several weeks of debug.

So I desided that there are some differences in configuration between my stands.

Thanks.

[Laurent Menase · Accepted solution]

You can contact DSPP team for help on that.
I don't understand completely why do you need to modify the frame to monitore traffic :D


The easiest way to prevent the problem:
recalculate completely the checksum and remove the cko header and MSGCKO b_flag.

[Laurent Menase]

Because there is a precalculated value in the udp checksum field itself.

[Kuzmin Konstantin]

Thanks, Laurent!!!

Your advice was just the one I needed.

Thanks a lot.

[Kuzmin Konstantin]

Thanks.

Regards,
Konstantin.