Timeline for check tcp packets reception below tcpdump level
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 8, 2015 at 6:41 | vote | accept | csauvanet | ||
| May 8, 2015 at 0:45 | comment | added | Celada |
@csauvanet I have no experience with XLAT64 but I can say that tcpdump will always show packets exactly as they are on the wire regardless of what happens afterwards, no exceptions... unless something happens in hardware. My quick reading of the information you linked suggests that I guess you'd see IPv6 on the wire and then it becomes IPv4 after it goes through the "clat" daemon so therefore if you tcpdump the wireless interface you'd see IPv6 and if you tcpdump the lo (loopback) interface you'd see IPv4. As I said though, no experience, so I probably haven't got it right.
|
|
| May 7, 2015 at 7:57 | comment | added | csauvanet |
This should be the good answer for general case, in my particular case it happens that architecture is XLAT64. So I have a Clat daemon doing the nat 4->6 translation, maybe there are some other explanation of loosing packets in that clat daemon ? I wonder if tcpdump should still see it or not.
|
|
| Apr 28, 2015 at 14:20 | comment | added | csauvanet | Thanks for the reply, I will investigate further by asking the server side tcpdump and checking the ConfAck size | |
| Apr 28, 2015 at 14:13 | history | answered | Celada | CC BY-SA 3.0 |