> > Switching the hash implementations to the new shash API introduced a > > regression. HMACs are created incorrectly if the data is scattered over > > multiple pages, resulting in very unreliable IPsec tunnels. > > What are the symptoms? After doing further tests, it seems that this is additionally related to User-Mode-Linux and/or it's TUN/TAP network driver. I couldn't reproduce the issue on a x64 with e1000. I think the bug is actually in the UML network code, but changing the scatterwalk logic by using the hash_walk functions triggered the issue. I'll try to find out more... More details to the issue I'm seeing on UML hosts: Packets (non fragmented) laying on multiple pages are hashed incorrectly for HMAC calculation. This results in packet drops on HMAC secured tunnels (XfrmInStateProtoError's on the receiving end). Affected are at least 2.6.29, net-2.6, crypto-2.6 and cryptodev-2.6. To reproduce this, try to send large packets (e.g. ping with -s 1400, or iperf with TCP) over a HMAC secured ESP tunnel. Only packets with data on page boundaries are affected. You'll have to try until the kernel allocates the packet on multiple pages, which is more likely with larger packets near MTU. Thanks Martin -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
