Martin- Thanks for the follow up.
I am capturing in close proximity to the printer. Our network is comprised of a mid-sized VPN provided by Comcast. My particular local network sits behind a Cisco router with less than 10 devices connected to it. I have a dumb hub connected to the router, and my capture PC and network printer connected to the hub.
You are correct in saying that the problem only happens on the odd occassion that the first SYN+ACK doesn't make it back to the original transmitting machine. However the frequency of these occassions is increasing suggesting that something on my local network may be interfering with my network traffic.
So I guess I'm looking at this problem in 2 parts. The first, what's causing the second packet (SYN+ACK) in the sequence to not make it from the printer back to the sender machine.
Second, during the sending machine's follow up attempts to establish a connection, the 3 or 4 repeated SYN packets are answered by the printer, but are answered with ACK packets instead of ACK+SYN. Only after the 4th SYN packet does the printer respond with the expected SYN+ACK, and the message is finally delivered. Unfortunately, any time sensitivity constraints that may have been in effect are no longer applicable as the final delivery time exceeds 2 mins.
Any other suggestions on how I might proceed would be appreciated.
Regards- Jeff Bruns
Sent from my iPhone
Jeff,
Well, if the Dup ACKs in frames 206,208 etc don't have ACK *and* SYN set (just check the flag details in the middle pane on those frames) then I would say there is a bug in the IP stack of the printer. (Are you capturing this "close" to printer and is there no firewall or something that might be altering the TCP flags in between?)
If this problem only happens on the odd occasion when the first SYN+ACK doesn't make it back to the client then it is possible that this bug (when the client needs to send a followup SYN) may have gone undetected.
Regards, Martin MartinVisser99@xxxxxxxxx
On Sat, Apr 24, 2010 at 12:14 AM, Jeff Bruns <jeff.bruns@xxxxxxxxx> wrote:
Martin-
Thank you for your reply, your information was very helpful. I've attached the wireshark screenshot, hopefully it helps the situation to make more sense.
Regards-
Jeff
On Thu, Apr 22, 2010 at 9:09 PM, Martin Visser <martinvisser99@xxxxxxxxx> wrote:
Jeff,
None of you links seem to be correct at all, only pointing to the top level forum.
As far as seeing SYN attempts at increasing intervals, this is pretty normal if you have connectivity issues. The response should always be a SYN+ACK or a RST, Can't think of why a half-open connection on the printer would respond to another SYN with just an ACK.
Bottlenecks don't usually reveal themselves unless they are stressed. Either you need to test the level that the bottlenecks appears using your native applications, or traffic generator tools such as iperf. By watching the amount of traffic that can pass through the bottleneck (measured by whatever means such as the network equipments stats, the load generator tool or say Wireshark) you can determine at what point it becomes significant.
Regards, Martin
MartinVisser99@xxxxxxxxx
Greetings- I previously posted on the Devshed forums but haven't received any response. Hopefully the wireshark community might be able to help... I wrote a perl program which
acts as a network sniffer, intercepting data sent to a networked laser printer. The resulting data, once
parsed, is formatted and written to a serial port which has connected a
series of scrolling LED signboards. I've recently been experiencing some
issues with my network traffic and I was hoping to get some advice on
how to proceed.
I'm running Windows XP connected to a 10Mbps wired
LAN which is part of a larger VPN. I've been using wireshark in my
effort to better understand my recent network issues.
The following scenario was an attempt to send data to our networked
laser printer. I was able to capture the
corresponding network traffic with wireshark. I've attached a snapshot
of the wireshark traffic.
My first question, which I'm under the assumption is out of my control,
has to do with the 5 repeated SYN packets, despite the SYN, ACK that was
sent immediately following the first SYN. I'm thinking maybe the sender
failed to receive the SYN, ACK and as a result resent the SYN packet??
That being the case, why is the receiver replying with repeated ACK
instead of SYN, ACK?
My next question has to do with the timeframe between each of the
following SYN packets. It would appear that the time doubles after each sent SYN packet.
Given the precision of the time intervals I would assume it has
something to do with the retransmission timer or persistence timer,
although I'm curious as to why the interval doubles after each attempt.
Information sent to our networked printer is time sensitive, and as you
can see from the timestamps shown throughout the network traffic it
takes almost 3 minutes to successfully transmit the data.
My questions are:
1- Is there anything I can do to prevent the redundant SYN attempts in
the future?
2- Is there a way to decrease the timeout so that in the event of future
occurrences, the interval between SYN attempts is expedited?
3- In the event data loss is suspected due to network
congestion or quality, are there any diagnostics I could perform to
identify bottlenecks?
Below is a link to a wireshark screenshot showing the packets within the message. It being my first time posing to the list, I'm not sure if I'm permitted to include attachments, so the screenshot is a link to the devshed post attachment. If it would be helpful and I'm permitted I'd be happy to attach the wireshark pcap dump file.
Any help would be greatly appreciated.
Thanks-
Jeff Bruns
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
|
