Is pfSense corrupting my radius IPV4 checksum requests?
-
I am getting bad checksums on packets to the radius server's for authentication at the captive portal. I have already disabled IP Checksum offloading to no avail. This is the second system I have brought up. The first was on a virtual platform with no issues. The second was a standalone ibm platform.
I have compared packet captures on the working machine to verify the checksum errors are not present.
Anyone seen this before?
-
What is showing you that there are bad checksums?
And are the bad checksum values actually incorrect, or 0?
-
The Checksum is zero.
I went down this route since radius was showing:
krb5_g_i_t_w_p failed: Decrypt integrity check failed
-
If the checksum is zero, the NIC that captured the packet must have been doing checksums in hardware. That's the only way it will be set to 0 that I'm aware of.
If they were corrupt they'd have some other incorrect (or byte-swapped) value in there.
-
Do you think this is a red herring (only showing up in the capture) or really the issue? I didnt do a capture on the radius side. Just did it though pfsense. I think I am going to give up on this hardware platform and try something different.
-
I'm not familiar with the error to say for sure. Typically unless a checksum is non-zero and wrong, it's not worth worrying about. It's probably a red herring and not the root cause.
To know more you'd have to capture on the other side.
-
0 checksum would just be hardware checksum offloading. Can capture from the destination to get the checksum that's actually on the wire.
