Re: Network Pausing during Streaming/File Sharing

[Martin Visser <martinvisser99 () gmail com>]

I doubt that the DHCPv6 query is the issue. All modern Windows machines do
this, and should do no harm, provided you don't explicitly configure IPv6 on
your router, etc.

During the pause period show in Wirehark screen shot, the frames from both
clients server are either pure ACKs or jsut keep-alive (data length is 0 or
1) is being presented.

Did you capture the TCP session from the start? It is just that the
advertised window from your client is shown at only 266 bytes, which
basically would indicate to the server that it's buffers are full. (If you
did not capture at the start however this would not show the effect of the
missing Windows scaling parameter that is only seen on the initial SYN).
Check before and after pause and see how the advertised Windows from the
client is varying. (You can use IO graph to plot this as well)

Regards, Martin

MartinVisser99 () gmail com


On Mon, Mar 15, 2010 at 4:45 AM, Hobbe <my1listmail () gmail com> wrote:

> Hi
> I meant the computer that tries to get a DHCP address on IP version 6.
> if you are not using IP v6, then uninstall it or atleast put in a static ip
> v6 address.
> solicit = the ip v6 dhcp client tries to get in contact with a dhcp server.
>
> HTH
>
> Regards
>
> Hobbe
>
>
>
>
> 2010/3/14 Stephen Salter <wireshark () stephensalter co uk>
>
> >  Thanks for the reply.
> >
> >
> >
> > The server has a Static IP, I assigned it within the Teams TCP/IP settings
> > under network settings. The Static IP is set to be outside the range of the
> > routers DHCP allowed IP address range. I had tried to use the router to
> > assign the Static IP, except this caused my VPN link to fail with a 733
> > error on login, never got round to diagnosing why.
> >
> >
> >
> > Thinking about this now, the VPN link is using a DHCP assigned IP for the
> > client machine connecting in, doesn't affect the servers IP Address however.
> > Hmm perhaps I should set this to a fixed IP Address too, to see if it has
> > any effect.
> >
> >
> >
> > Should the server not be receiving these DHCP packets?
> >
> >
> >
> > *From:* wireshark-users-bounces () wireshark org [mailto:
> > wireshark-users-bounces () wireshark org] *On Behalf Of *Hobbe
> > *Sent:* 14 March 2010 13:54
> > *To:* Community support list for Wireshark
> > *Subject:* Re: [Wireshark-users] Network Pausing during Streaming/File
> > Sharing
> >
> >
> >
> > Just a simple guess on the top of my head.
> >
> > DHCP is checking its status and during that time it does not send/recieve
> > packets wich gets buffered up and released after the second solicit and.
> >
> >
> >
> > Just for a test try to put a static address instead of a DHCP address.
> >
> >
> >
> >
> >
> > HTH
> >
> > good luck
> >
> >
> >
> > Hobbe
> >
> > 2010/3/14 Stephen Salter <wireshark () stephensalter co uk>
> >
> > Hi,
> >
> > I have been trying to track down an intermittent pause in network activity
> > between my Windows Home Server and HTPC .
> >
> >
> >
> > I noticed the pause was occurring as the movies I was watching
> > periodically stuttered/froze before bursting back into life, like fast
> > forward turned on, then settling down to normal viewing speed. The
> > occurrence of the pauses seem to be random, but I would say it happens
> > between 10 to 15 times over a typical movie length.
> >
> >
> >
> > I have used wireshark to record the traffic between the two servers during
> > the pause period, this is as follows:
> >
> >
> >
> > "4379","19.617874","7.168.1.16","7.168.1.253","SMB","Read AndX Request,
> > FID: 0x400d, 61440 bytes at offset 778371072"
> >
> > "4380","19.759785","7.168.1.253","7.168.1.16","TCP","microsoft-ds > 49178
> > [ACK] Seq=23546138 Ack=45235 Win=56589 Len=0"
> >
> > "4381","19.791285","IntelCor_7c:06:c0","Broadcast","ARP","Who has
> > 7.168.1.1?  Tell 7.168.1.3"
> >
> >
> > "4382","20.173328","fe80::b8fb:ec8a:5b36:bf57","ff02::1:2","DHCPv6","Solicit"
> >
> > "4383","20.412176","7.168.1.252","255.255.255.255","UDP","Source port:
> > filenet-peior  Destination port: 22330"
> >
> > "4384","23.561347","7.168.1.252","255.255.255.255","UDP","Source port:
> > filenet-peior  Destination port: 22330"
> >
> > "4385","23.757630","7.168.1.253","7.168.1.16","TCP","[TCP Keep-Alive]
> > dbstar > 49165 [ACK] Seq=0 Ack=2 Win=64856 Len=1"
> >
> > "4386","23.757785","7.168.1.16","7.168.1.253","TCP","[TCP Keep-Alive ACK]
> > 49165 > dbstar [ACK] Seq=2 Ack=1 Win=275 Len=0 SLE=0 SRE=1"
> >
> >
> > "4387","28.078082","fe80::b8fb:ec8a:5b36:bf57","ff02::1:2","DHCPv6","Solicit"
> >
> > "4388","29.554158","7.168.1.253","7.168.1.16","TCP","[TCP segment of a
> > reassembled PDU]"
> >
> >
> >
> > The Wireshark IOGraph flat lines between the two Solicit packets.
> >
> >
> >
> > Some other info for you to hopefully help diagnose:
> >
> >
> >
> > 1. 7.168.1.253 is the server (Two Intel CT Desktop Adapters Teamed - Load
> > balanced - Jumbo Frames 9014)
> >
> > 2. 7.168.1.16 is the HTPC (One Intel CT Desktop Adapter - Jumbo Frames
> > 9014)
> >
> > 3. 7.168.1.1 is the ADSL Router
> >
> > 4. 7.168.1.3 is my laptop that I have used to RDP into my server
> >
> > 4. 7.168.1.252 is a wireless ycam camera and it uses the server via FTP to
> > store alarmed captured files.
> >
> > 5. I don't know what the source application of dbstar is, but this occurs
> > many times in the wireshark capture and doesn't cause pauses every time it
> > appears.
> >
> > 6. The only thing that seems consistent with other flat line captures I've
> > done is the Broadcast events, but they are usually something like:
> >
> > "17107","61.452598","IntelCor_7c:06:c0","Broadcast","ARP","Who has
> > 7.168.1.251?  Tell 7.168.1.3"
> >
> > 7.168.1.251 is my printer.
> >
> >
> >
> > Anybody have any ideas where I go from here, I am still scratching my
> > head?
> >
> >
> >
> > Thanks
> >
> > Stephen
> >
> >
> >
> > ___________________________________________________________________________
> > 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
>
>
> ___________________________________________________________________________
> 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