No description
4f675d63e8
We might receive out-of-order ACK packets from the tap device, just like any other packet. I guess I've been overcautious and regarded it as a condition we can't recover from, but all that happens is that we have already seen a higher ACK sequence number, which means that data has been already received and discarded from the buffer. We have to ignore the lower sequence number we receive later, though, because that would force the buffer bookkeeping into throwing away more data than expected. Drop the ACK sequence assignment from tcp_tap_handler(), which was redundant, and let tcp_sock_consume() take exclusive care of that. Now that tcp_sock_consume() can never fail, make it a void, and drop checks from callers. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> |
||
|---|---|---|
| doc | ||
| arp.c | ||
| arp.h | ||
| dhcp.c | ||
| dhcp.h | ||
| Makefile | ||
| ndp.c | ||
| ndp.h | ||
| passt.c | ||
| passt.h | ||
| qrap.c | ||
| siphash.c | ||
| siphash.h | ||
| tap.c | ||
| tap.h | ||
| tcp.c | ||
| tcp.h | ||
| udp.c | ||
| udp.h | ||
| util.c | ||
| util.h | ||