Having a bit of a battle would appreciate some second opinions!

[westy]

Hi,

I am having one of those "it's a problem at your end, not ours" issues, with a electronic payment service provider. We are experiencing intermittant problems when a transaction is made from our shop till. The traffic concerned is tiny and runs over port 443, from the till to their servers. In order to PROVE the point that is not our net connection, service provider or anything at all on my side of the fence, I have carried out a plethora of TRACERT tests at different time intervals directly to the ip address of the server the till is hitting.

Whilst generally every tracert is fine, I would say that 1 about every 8 or so comes back on the 9th hop with this (main details removed obviously):-

9 * 8 ms 8 ms the.server.I.am.connecting.to.net [123.456.789.101]

Sometimes I get two *'s. It does actually complete the trace, but those * (from when I went to networking school) indicate packet loss and should not be be happening. It is always the same host affected.

Now as far as I am concerned, this is quite clear in black and white that packet loss is being suffered fairly frequently albeit intermittantly and that this would be my smoking gun and the cause of the troubles we are having.

Before I go all gun-ho and pointing fingers however, I just would appreciate others opinion as to whether this indicative packet loss shown would be enough to cause lag or even fail the data transaction. The trace does actually complete, however, so I guess it is a question of how robust the receiving end is to receiving traffic that has had the packet loss? This is where I get on to slightly grey ground.

Most appreciative of any thoughts or opinions on this. It is a a bit of a David vs Goliath situation, in that they just don't believe their almighty systems could be the cause!

Thanks,

Andrew

[tin]

I would say that * for the last hop in a traceroute is a VERY common event. I forget the details, apologies, but remember reading something like it's a defence mechanism of the destination when you're hitting it repeatedly with packets destined for it with expiring TTL. While it could indicate the problem you describe it can most certainly can occur naturally.

[mac_shinobi]

Just wondering if you try pathping

Get IT Done: Troubleshooting network connections with Windows 2000's Pathping.exe

[oxide54]

ICMP is a different protocol to HTTPS which I'm sure you know, ping / tracert proves network connectivity but does not take into account packet / port filtering for the protocol u wish to connect with in this case HTTPS.

are you connecting via proxy?

[bandit]

You could try a telnet session to the host on port 443 to see if you can connect when the till is having problems.
From a DOS prompt do Telnet ip address 443 (ie Telnet 123.456.789.111 443) This should present you with either a blank dos box or some html code.

[Duke5A]

It's almost as if the quickest/shortest routed path is down or flapping, and it is falling back on a gateway of last resort or a higher cost path. If you don't control that network segment this could be a real pain to fix.