Wireshark mailing list archives
Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes
From: Martin Visser <martinvisser99 () gmail com>
Date: Sat, 23 Mar 2013 23:26:47 +1100
Jaap, yes, as a networking consultant over the years I have on many occasions had to check and double-check when speaking to colleagues and customers about exactly what the specifics are of the physical connections they are referring to. Just the word "trunk" (as you have seen from WP) is totally ambiguous. (Apart from bonding/teaming/aggregation, trunk is also often used for 802.1q capable links). Regards, Martin MartinVisser99 () gmail com On 23 March 2013 22:00, Jaap Keuter <jaap.keuter () xs4all nl> wrote:
Talking about a cacophony of terms. From Wikipedia: ------------------------8<--------------------------------- In addition to the IEEE link aggregation substandards [802.3ad, 802.1ax], there are a number of proprietary aggregation schemes including Cisco's EtherChannel and Port Aggregation Protocol, AVAYA's Multi-Link Trunking, Split Multi-Link Trunking, Routed Split Multi-Link Trunking and Distributed Split Multi-Link Trunking, ZTE's "Smartgroup", or Huawei's "EtherTrunk". Most high-end network devices support some kind of link aggregation, and software-based implementations – such as the *BSD lagg package, Linux' bonding driver, Solaris' dladm etc. – also exist for many operating systems. ------------------------8<--------------------------------- http://en.wikipedia.org/wiki/Link_aggregation Thanks, Jaap On 03/22/2013 12:09 PM, Sake Blok wrote:A teamed physical interface is when you combine two network cards intoonelogical network card. Cisco calls it Etherchannel, other network vendorscall ittrunking and linux calls it bonding while in is called teaming in thewindows world.Of course the SYN/ACK could not have been on the network before the SYNto whichit was a response, therefor for some reason the capture process saw theSYN/ACKearlier than the SYN. This can be caused by using two network interfacesfor thesame TCP session. As the timestamping is done in the OS and not on thenetwork card.Cheers, Sake On 22 mrt 2013, at 10:48, wen lui wrote:what do you mean for this : " a teamed physical interface" there are many virtual machines in one PlanetLab nodes, are there any implications? but from the time, the second packet arrives at a minus time, it meansitarrives earlier than the first? I don't know why they are out order? any reasons? 2013/3/21 Martin Visser <martinvisser99 () gmail com <mailto:martinvisser99 () gmail com>> Very simply, you have have captured the packets 1 and 2 out oforder.Packet 2 it would seem is the SYN, that initiated the SYN-ACK inpacket1. (At least it seems that way to me - a sane stack wouldn't reusethesame TCP source port at such a small interval). Are you running ateamedphysical interface, and hence why you are capturing packets out oforder?.Regards, Martin MartinVisser99 () gmail com <mailto:MartinVisser99 () gmail com> On 21 March 2013 00:18, wen lui <esolvepolito () gmail com <mailto:esolvepolito () gmail com>> wrote: I run a simple TCP client on machine A and a simple TCP serveronmachine B (machine B is a Planetlab node while machine A isnot).Then the client establishes a tcp connection with machine B andsendsome data. I capture packets on both A and B, on A the wireshark showsthat it isa normal 3-Way handshaking, but on B, it shows as below: |1 0.000000 138.46.116.22 138.46.201.109 TCP 7454000 > 57182 [SYN, ACK] Seq=0 Ack=0 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=1751648211 TSecr=1119925943 WS=128 0.0000002 -0.000062 138.46.201.109 138.46.116.22 TCP 74[TCP Port numbers reused] 57182 > 54000 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=1119925943 TSecr=0 WS=128 -0.0000623 0.000308 138.46.201.109 138.46.116.22 TCP 6657181 > 54000 [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=1119737278 TSecr=1751459556 0.000308| while I see on machine B, actually the tcp connection isestablished.before the client sends the SYN and ACK, I checked machine Band found no TCP connection|netstat -tnp (Not all processes could be identified, non-owned process infowill not be shown, you would have to be root to see it all.)Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign AddressState PID/Program nametcp 0 0 138.46.116.22:54000 <http://138.46.116.22:54000/> 138.46.201.109:57181 < http://138.46.201.109:57181/> ESTABLISHED 17879/tcp_serveranyway, I can send data to the tcp server and it receives itcorrectly.|| why wireshark shows TCP Port numbers reused? and the time is'-0.000062'? |___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- wireshark shows: TCP Port numbers reused on PlanetLab nodes wen lui (Mar 20)
- Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes Martin Visser (Mar 21)
- Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes Sake Blok (Mar 21)
- Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes wen lui (Mar 22)
- Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes Sake Blok (Mar 22)
- Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes Jaap Keuter (Mar 23)
- Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes Martin Visser (Mar 23)
- Re: wireshark shows: TCP Port numbers reused on PlanetLab nodes Martin Visser (Mar 21)