Test SYN-ACK

Good morning all.  I need to know how to test syn-ack command to see if there is a response.  The problem i have is that a printer is not working at remote site that is controlled in belguim.  One of the lads from has tested it and says he is not getting a response although he can ping the ip.  I need some freeware or a way to be able to test this command as i dont have any access to linux
LVL 7
dann47Asked:
Who is Participating?
 
ubigCommented:
If printer can be pinged but cannot be reached by TCP, I would suggest to check packet filtering on routers between source PC and printer. It is possible that ICMP packets are enabled to pass through but not all TCP ports are.
0
 
ubigCommented:
You could use Wireshark to trace network packets: http://www.wireshark.org/about.html. It could be an overkill though.
To check if you have SYN-ACK problem you could try to print something and then check your open TCP connections with netstat -na. If your see active TCP sessions with SYN_SENT status it could mean your workstation does not receive ACK.
0
 
dann47Author Commented:
Thanks, i have tried the netstat approch to no avail.  Be nice if it was a workstation.

Does look a bit overkill for the requirment
0
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

 
Keith AlabasterEnterprise ArchitectCommented:
Can you clarify your comment please? Youy say that the local engineer can ping the device - if it can be pinged, then a reply is being returned. If a reply is being received then syn-ack is pointless.
0
 
dann47Author Commented:
Ok no problems, thanks for responding.  He has raised a test for an ack response, it is not responded his results as below

Oct 12 05:46:39:     TCP src=4059, dst=9100, seq=2235896744, ack=0, win=65535 SYN
Oct 12 05:46:42: IP: tableid=0, s=172.16.10.23 (Serial0.1), d=192.168.101.153 (FastEthernet0), routed via FIB
Oct 12 05:46:42: IP: s=172.16.10.23 (Serial0.1), d=192.168.101.153 (FastEthernet0), g=192.168.101.153, len 48, forward
Oct 12 05:46:42:     TCP src=4059, dst=9100, seq=2235896744, ack=0, win=65535 SYN
Oct 12 05:46:48: IP: tableid=0, s=172.16.10.23 (Serial0.1), d=192.168.101.153 (FastEthernet0), routed via FIB
Oct 12 05:46:48: IP: s=172.16.10.23 (Serial0.1), d=192.168.101.153 (FastEthernet0), g=192.168.101.153, len 48, forward
Oct 12 05:46:48:     TCP src=4059, dst=9100, seq=2235896744, ack=0, win=65535 SYN
Oct 12 05:46:54: IP: tableid=0, s=172.16.10.20 (Serial0.1), d=192.168.101.153 (FastEthernet0), routed via FIB
0
 
Keith AlabasterEnterprise ArchitectCommented:
OK - so he cannot successfully ping the target device.
Interesting that it shows two different source IP's in the three packets sent.

I would be interested in seeing a routing table output and the results of a traceroute from source to destination here.



0
 
dann47Author Commented:
Yep the head office is in Belguim on a different WAN, i can traceroute quite happily and so can he to the final destinations.
0
 
dann47Author Commented:
Also he can ping the device, he has proven that to me
0
 
dann47Author Commented:
UBIG, could you expand please, i as i do feel that it is a firewall problem
0
 
ubigCommented:
Packet filtering is one of technique used by firewalls to restrict network traffic. In reality almost all routers has implemented such a functionality. It is possible to allow some packets to pass through the router and restrict others. If you have firewall between printing PC (or print server if you are using one) and printer itself, that applies to firewall too.

To make sure there are no restriction on TCP or IP level, you should ask your network engineers to check packet filters on each router or firewall between printing PC or print server and printer. You can find out which routers should be checked by issuing command tracert.
0
 
dann47Author Commented:
Ah process of elimitaion states thought that it only stopped when we installed the new firewall
0
 
dann47Author Commented:
In the case of printing what kind of packet would i be looking for, in relation to port 9100 - jet direct
0
 
ubigCommented:
TCP port 9100 is what you should look for. I'm not absolutely sure if that is all you need but your router engineer could log all packets coming back and forth and enable additional ports in case of printing problems by looking at that trace log.
0
 
ubigCommented:
Here is a reference about TCP port usage for JetDirect: http://aplawrence.com/Jeffl/printports.html
0
 
dann47Author Commented:
FOund the problem, got one of junipers engineers to diagnose from the information ubig gave me, problem was indeed a router packet filtering issue - Customer's firewall was dropping packets sent to printer on trust side from untrust. Have disabled TCP-syn-check and it's working.

Thanks all for time and advice
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.