Leggere un pacchetto
Un pacchetto sul cavo è una pila di header, ognuno dei quali dice cosa viene dopo: il campo type di Ethernet indica IPv4, il campo protocol di IP indica TCP, la porta TCP suggerisce DNS o HTTP. Il decodificatore percorre quella catena. Ogni header è mostrato con i suoi campi, i loro offset in byte e, per i campi impacchettati come i flag IP o il data offset TCP, i bit esatti. Passa il mouse su un campo per vedere dove si trova nell’hex dump in fondo.
Ottenere i byte
| Sorgente | Comando / azione | Livello di collegamento |
|---|---|---|
| tcpdump, un pacchetto con header Ethernet | tcpdump -c1 -xx -ni eth0 port 53 | Ethernet |
| tcpdump senza il livello di collegamento | tcpdump -c1 -x -ni eth0 … | IPv4/IPv6 grezzo (rilevato) |
| tcpdump su «any» | tcpdump -c1 -xx -ni any … | Linux cooked (SLL) |
| Wireshark | Clic destro sul pacchetto → Copy → …as a Hex Dump, oppure File → Export Packet Dissections | Ethernet |
| Cattura intera | tcpdump -c100 -w out.pcap port 53 | Letto dal file |
| Scapy / Python | bytes(pkt).hex() | Dipende dal primo livello |
Checksum
IPv4 copre solo il proprio header; TCP, UDP e ICMPv6 coprono il loro header, i dati e uno pseudo-header con gli indirizzi IP, il protocollo e la lunghezza, ed è per questo che un NAT che riscrive gli indirizzi deve riscrivere anche i checksum di trasporto. Un checksum sbagliato in una cattura fatta sulla macchina mittente è quasi sempre checksum offloading: il kernel lascia il campo alla scheda di rete, che lo compila dopo il punto di cattura. In una cattura da un’altra macchina o da una porta mirror, un checksum sbagliato indica una corruzione reale. UDP su IPv4 può legalmente portare 0 per dire «non calcolato».
Cose che il decodificatore segnala
- Valori TTL che rivelano il sistema operativo del mittente (64 Linux/macOS, 128 Windows, 255 apparati di rete) e quanti salti è distante.
- Indirizzi privati, link-local, multicast e di documentazione; MAC amministrati localmente (macchine virtuali, indirizzi Wi-Fi casuali).
- Stato dell’handshake TCP dai flag, window scaling e MSS dalle opzioni, blocchi SACK, timestamp.
- Pacchetti IP frammentati, su cui il decodificatore si ferma (l’header di trasporto è solo nel primo frammento).
- Negli errori ICMP viene decodificato anche il datagramma originale citato, così vedi a quale connessione si riferisce un «port unreachable» o un «TTL exceeded».
- Nel TLS ClientHello, il nome host SNI, le versioni offerte, i gruppi e i protocolli ALPN: tutto ciò che è ancora visibile in chiaro.
Domande
Perché il decodificatore dice che il mio checksum TCP è sbagliato?
Se la cattura è stata fatta sulla macchina che ha inviato il pacchetto, il checksum sarebbe stato compilato dalla scheda di rete dopo la cattura (checksum offloading); Wireshark mostra la stessa cosa. Disattivalo con ethtool -K eth0 tx off quando ti servono valori reali nelle catture, oppure cattura sul lato ricevente.
Può leggere un intero file pcap?
Sì, trascina un .pcap o .pcapng (fino a 8 MB, 5000 pacchetti elencati). Clicca un pacchetto nell’elenco per decodificarlo. Il file non lascia mai il tuo browser.
E i frame Wi-Fi 802.11 o radiotap?
Non ancora decodificati; le catture con quei tipi di collegamento elencano i pacchetti ma mostrano i byte come payload. Ethernet, Linux cooked, IP grezzo e loopback BSD sono supportati.
Riassembla i flussi TCP o segue le conversazioni?
No. Decodifica un pacchetto alla volta. Per l’analisi dei flussi usa Wireshark; per capire esattamente cosa dice un header, questo è più rapido.
Il mio payload compare come «TCP payload» anche se è HTTP.
HTTP viene riconosciuto dai primi byte (un metodo o HTTP/1.x) indipendentemente dalla porta. Il traffico cifrato sulla 443 è mostrato come record TLS, e tutto il resto come byte grezzi con una colonna ASCII.