Test SYN-ACK

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.

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

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.

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

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.

Yep the head office is in Belguim on a different WAN, i can traceroute quite happily and so can he to the final destinations.

Also he can ping the device, he has proven that to me

UBIG, could you expand please, i as i do feel that it is a firewall problem

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.

Ah process of elimitaion states thought that it only stopped when we installed the new firewall

In the case of printing what kind of packet would i be looking for, in relation to port 9100 - jet direct

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.

Here is a reference about TCP port usage for JetDirect: http://aplawrence.com/Jeffl/printports.html

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