I am new to using Wireshark. I captured the pcap file using the following command in our linux server which is a receiver in the below scenario:- tcpdump -ni any -s0 -w <filename> I am seeing TCP Retransmission and Dup Ack packets from the sender in the network which uses a satellite link. The packets use PPPoE in the link layer and TCP on top of it in transport layer. I am seeing TCP Retransmission/Dup Ack for all packets in this link. The first packet shows a PPPoE in the link layer, IP, TCP (Protocols in Frame: sll:pppoes:ppp:ip:tcp:data) whereas,the duplicate/retransmitted packet does not show PPPoE and just show the TCP over IP (Protocols in Frame: sll:ip:tcp:data). The time difference between these packets is few milliseconds. I want to know whether the Retransmission is really happening from the sender or the wireshark is showing incorrectly as Retransmission for the same packet. Any help on this would be really great !!!
asked 08 Dec '10, 03:47  WiresharkNovice edited 08 Dec '10, 03:48 |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
You're capturing on the server and it sees the same packet - one with PPPoE and one without? Take a look at the IP ID field (open up the IP header and you'll see the IP Identification field. I'm not too familiar with PPPoE, but depending on the shim and where it's injecting itself, I guess it can see it with and w/o PPP header. Take a look at the IP header. If they are the same, it's not a real retransmission.
thanks for your comments... I have seen the IP header and the ID is same... but since it is using satellite link i expect some retransmissions.. but i could not spot them.. i see lot of TCP DupAck and TCP Out-of-order as well... wireshark wiki says if TCP DupACK is seen there is a clear indication of packet loss... i m still analysing and trying to understand this..
You see 2 packets : one harvested from the hardware interface, one from the PPPoE virtual interface created by linux. I assume the dup is correctly paired (see packet #). My 2 cents : capture from only one interface (either hardware or PPPoE). The second packet has been delayed due to the PPPoE decapsulation