The issue
- Newer emulated RTL8169 NIC doesn't provide working network with
tap_linux backend and a Linux guest
Problem investigation
- Older OpenCores Ethernet NIC didn't support checksum offload; The guest would compute proper TCP/IP checksum in software
- Newer (and default) Realtek RTL8169 NIC supports checksum offload, which is turned on by default; The guest (rightfully so) doesn't compute the checksum in transmitted packets and just gives them to NIC like that
- The RVVM TAP API receives the TX packet, at which point it's either parsed by
tap_user which doesn't care about checksums, or it is passed to TUN/TAP Linux interface via tap_linux
- Finally, the TUN/TAP Linux interface doesn't have means of "checksum offload"; It simply drops those packets since the checksum is bad and leaves no option to compute the checksum by the kernel, or better offload it to the host NIC and omit any overhead from software checksumming at all
Workarounds
- Disable TX checksum offload in the guest via
ethtool -K enp1s0 tx off
Possible proper fixes
- Find a way to ask the host TUN/TAP device for TX checksum offload; No piece of documentation has a clue on that, it could be simply a limitation on Linux side...
- Implement software TX checksumming in
tap_linux implementation; Slightly complicated and carries some overhead
If anyone has an advice on proper TUN/TAP TX checksum offload, it would be nice to point out here. Otherwise it should fallback to (arguably, more ugly) approach of working around the system interface limitations, or simply deprecate the TUN/TAP backend when tap_user is at more usable state.
The issue
tap_linuxbackend and a Linux guestProblem investigation
tap_userwhich doesn't care about checksums, or it is passed to TUN/TAP Linux interface viatap_linuxWorkarounds
ethtool -K enp1s0 tx offPossible proper fixes
tap_linuximplementation; Slightly complicated and carries some overheadIf anyone has an advice on proper TUN/TAP TX checksum offload, it would be nice to point out here. Otherwise it should fallback to (arguably, more ugly) approach of working around the system interface limitations, or simply deprecate the TUN/TAP backend when
tap_useris at more usable state.