On 01/22/2013 09:40 AM, 温金超 wrote:
>
>
> 2013/1/22 温金超 <wenjinchao0418@xxxxxxxxx <mailto:wenjinchao0418@xxxxxxxxx>>
>
> Thanks. and I add comments inline.
>
> On Jan 21, 2013, at 6:41 PM, 温金超 <wenjinchao0418@xxxxxxxxx> wrote: > Is
> should be three-way handshaking or not when trying to establishe a new
> connection? > but I tcpdump following: > > 19:23:12.688758 IP
> 10.1.164.64.51350 > 10.13.220.4.80: S 3779651860:3779651860(0) win 8192 <mss
> 1260,nop,wscale 8,nop,nop,sackOK> > 19:23:12.688776 IP 10.13.220.4.80 >
> 10.1.164.64.51350: S4133937230:4133937230(0) ack 3779651861 win 5840 <mss
> 1460,nop,nop,sackOK,nop,wscale 9> > 19:23:12.688779 IP 10.13.220.4.80 >
> 10.1.164.64.51350: S4133937230:4133937230(0) ack 3779651861 win 5840 <mss
> 1460,nop,nop,sackOK,nop,wscale 9> > 19:23:12.689716 IP 10.1.164.64.51350 >
> 10.13.220.4.80: . ack 1 win 260 > > 10.13.220.4 ack twice for syn. any idea ?
> >Are you sniffing on the machine that's sending the two SYN+ACK packets (i.e., >sniffing on 10.13.220.4), on the machine to which they're being sent (i.e., sniffing on >10.1.164.64), or on some other machine (passively sniffing)?
>
>
>
> I'm sniffing on machine 10.13.220.4.
>
>
> >Do the two SYN+ACK packets have the same IP packet ID value? Perhaps it's >getting retransmitted, either at the link layer or the TCP layer, for some reason. If it's at the >link layer, they'll probably have the same IP ID value; if it's at the TCP layer, they probably will >have different IP ID values. For tcpdump, use the -v flag to get the IP ID printed.
>
>
>
> Confirm that they have the same IP ID value.
>
>
> And I sniffing again both on client(10.1.164.64) side and server(10.13.220.4) side, get followings:
>
>
>
> On client(10.1.164.64) side, it's normal three-way handshaking.
>
>
>
>
>
>
> and on server side(10.13.220.4)
>
>
>
> 13:57:39.659310 IP (tos 0x0, ttl 124, id 27852, offset 0, flags [DF], proto: TCP (6), length: 52) 10.1.164.64.59211 > 10.13.220.4.80: S, cksum 0xc08c (correct), 563933632:563933632(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>
> 13:57:39.659389 IP (tos 0x0, ttl 64,* id 0*, offset 0, flags [DF], proto: TCP (6), length: 52) 10.13.220.4.80 > 10.1.164.64.59211: S, cksum 0x8bf2 (correct), 3096740955 <tel:3096740955>:3096740955(0) ack 563933633 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 9>
> 13:57:39.659413 IP (tos 0x0, ttl 64, *id 0*, offset 0, flags [DF], proto: TCP (6), length: 52) 10.13.220.4.80 > 10.1.164.64.59211: S, cksum 0x8bf2 (correct), 3096740955 <tel:3096740955>:3096740955(0) ack 563933633 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 9>
>
> 13:57:39.660220 IP (tos 0x0, ttl 124, id 27853, offset 0, flags [DF], proto: TCP (6), length: 40) 10.1.164.64.59211 > 10.13.220.4.80: ., cksum 0xe292 (correct), 1:1(0) ack 1 win 260
>
>
>
>
>
> Both SYN+ACK have the same IP id 0.
> Why the sniffing result is different between client side and server side?
>
>
>>Hi,
>
>>It would be interesting to know what kind of network interface is installed on
>>the server 10.13.220.4. Is there some kind of bonding interface? On what
>>interface is this server capture taken?
>
>>Thanks,
>>Jaap
>
>
>
> Hi Jaap,
>
> The server 10.13.220.4 have 2 physcial network interface, eth0 and eth1, who have the save ip: 10.13.220.4. And eth1 has been configed serval virtural ip.
>
> and my tcpdump commend:
>
> tcpdump -i any -nn -vvv -v -s 0 tcp and host 10.13.220.4 and port 80
>
>
> Thanks,
>
> jinchao
>
Hi,
Well, then obviously you are capturing *below* the bonded interface. Therefore
the *outgoing* frames are seen twice, one for each physical interface, and the
*incoming* frames once, because they come from a switch, which uses a single
port to send the frame[*].
You can't really fall back to capturing a single physical interface (eth0, eth1)
because you do not know where the switch will send the returned frames. To get
rid of the duplicates you can either:
1) capture on the bonding interface (bond0 or whatever name it takes)
2) use editcap -d to remove the duplicates from the capture file afterwards.
[*] unless flooding, multicast, MAC table miss.
Thanks,
Jaap
