Wenn ein Paket größer als seine tatsächliche Größe gesendet wird, sind die zusätzlichen Daten in der Nutzlast ein Stück Nullen. Das sollten Sie theoretisch bei einem solchen Paket sehen, wenn Sie es mit Wireshark (oder tcpdump) untersuchen. Zum Beispiel:
IP 192.168.0.3.17664 > 178.60.128.48.1: tcp 32
0x0000: 4500 0064 f0d0 4000 4006 56ab c0a8 0003 [email protected]@.V.....
0x0010: b23c 8030 4500 0001 0000 0000 ff06 dbe4 .<.0E...........
0x0020: c0a8 0003 b23c 8030 04d2 0050 0000 0000 .....<.0...P....
0x0030: 0000 0000 5002 16d0 b3c4 0000 4142 4344 ....P.......ABCD
0x0040: 4546 4748 494a 4b4c 4d4e 4f50 5152 5354 EFGHIJKLMNOPQRST
0x0050: 5556 5758 595a 0000 0000 0000 0000 0000 UVWXYZ..........
0x0060: 0000 0000 ....
Dies ist TCP-Paket zu google.com (178.60.128.48). Die Payload ist "ABC ... XYZ", aber die IP total_length
wurde manuell erhöht. Das Ergebnis ist ein Null-Padding in der Nutzlast, bis die Gesamtlänge des Pakets abgeschlossen ist.
Das heißt, meine Wette ist, dass das Problem in der sendto
Systemaufruf ist. Dies ist der Anruf, der tatsächlich ein Paket auf dem Socket sendet. Aber dieser Anruf setzt auch die total_length
des Pakets.
ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,
const struct sockaddr *dest_addr, socklen_t addrlen);
Ich vermute, dass Sie das total_length
Feld des Pakets im Header IPv4 gezwickt haben, aber der len
Parameter auf der sendto
Aufruf wurde nicht geändert, so dass die Gesamtlänge des Pakets auf seine ursprüngliche Größe überschrieben wird, wenn gesendet wird.
Das ist mein Verdacht, aber es ist schwer zu sagen, ohne den Code zu überprüfen.
Möglicherweise wurde es vom Betriebssystem oder vom Netzwerkschnittstellentreiber überschrieben. Wo fangen Sie es ein? – Malt
Ich nehme es auf eth0, das ist das Quellgerät, das ich das Paket sende. Diego Pino hat darauf hingewiesen, dass dieses Problem durch die 'sendto'-Funktion verursacht wird, die von mir eingestellte Gesamtlänge wurde dadurch überschrieben. Vielen Dank, dass Sie mir geholfen haben, es herauszufinden. –