This is the same sort of problem I’ve mentioned previously but I have investigated a bit further now.
Normally I start off investigating obvious network errors (eg ping < 100 bytes works but ping >= 100 bytes doesn’t) with tools like tcpdump and wireshark, looking for errors that way. In this case though, the ESP (ip proto 50) packets never show up in wireshark, which says to me that the cisco vpn driver grabs them at a fairly low level in the network stack.
My driver often receives packets from xen with the eth+ip(+udp/tcp/etc) header in one buffer and the rest of the data in another. Is it possible that cisco vpn (testing with latest version) simply cannot handle packets with more than one attached buffer? Do other network adapters never do this? I see under Linux that packets appear to come from the hardware like this indicating that the hardware is doing header/data split, but maybe they never split non-tcp/udp packets.
I’m really hoping that it’s just something else dumb I’m doing but I can’t think what. NDISTest doesn’t tell me anything is wrong.
I won’t be able to support packets > 4096 bytes if cisco vpn can’t handle the split either, although I suspect that jumbo frames end-to-end between the vpn client and the concentrator would be an unlikely scenario.
I’m testing with NDIS5 under 2003 but have been told that the same problem exists with my NDIS6 driver, which would make sense as the cisco vpn client is fundamentally the same afaik.
Any suggestions appreciated, especially someone who can tell me authoritatively that cisco vpn cannot handle packets than span more than one buffer!
Thanks
James