Network Problems - Clients in Christchurch affected
Hi there, We are running a LAMP stack and we have multiple clients in CHCH and a handful other parts of the world who have time out issues. We have done traceroutes from CHCH, QLD, and other places back to the data centre in Adelaide and the results is that there are no problems in CHCH. There are two clients in CHCH with a few branches and both claim to have issues. They are both hitting the same server (with many others) but only they are reporting problems. We have given the "talk to your ISP" response but I would like to: 1) remove all doubt it is our end 2) Provide any investigative support to our clients as possible. Can some network guru or packet sniffing blood hound give me some ideas of where else to explore in the digital underworld? Cheers P
On Thu, 5 Jun 2014 20:07:21 Piers Rowan wrote:
We have done traceroutes from CHCH, QLD, and other places back to the data centre in Adelaide and the results is that there are no problems in CHCH. There are two clients in CHCH with a few branches and both claim to have issues.
By default traceroute uses UDP packets while your problems concern HTTP or HTTPS. First try tcptraceroute. It could be related to large TCP MSS and network gear that doesn't support replying to the DF bit. Try getting them to access simple web sites (IE static files of various sizes) in the data center and look for anomalies, use a different port and/or server so it's easy to run tcpdump and record the packets for viewing with wireshark. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 05/06/14 21:01, Russell Coker wrote:
By default traceroute uses UDP packets while your problems concern HTTP or HTTPS. First try tcptraceroute.
They are on windows does a suitable cmd exist?
It could be related to large TCP MSS and network gear that doesn't support replying to the DF bit.
Any ideas why the MMS would change all of a sudden? We use output buffering in PHP. One of the complaints is that the user submits a $_POST of a text note and "it doesn't save" which can only be a PHP session error or "lost in transmission" type error
Try getting them to access simple web sites (IE static files of various sizes) in the data center and look for anomalies, use a different port and/or server so it's easy to run tcpdump and record the packets for viewing with wireshark.
Thanks I will take that idea forward. Cheers P
On Thu, 5 Jun 2014 21:10:50 Piers Rowan wrote:
On 05/06/14 21:01, Russell Coker wrote:
By default traceroute uses UDP packets while your problems concern HTTP or HTTPS. First try tcptraceroute.
They are on windows does a suitable cmd exist?
Try tcptraceroute, if that command doesn't exist then look for an option to make traceroute use TCP. If it's not built in then you should be able to download one.
It could be related to large TCP MSS and network gear that doesn't support replying to the DF bit.
Any ideas why the MMS would change all of a sudden?
It wouldn't, but network gear can change.
We use output buffering in PHP.
One of the complaints is that the user submits a $_POST of a text note and "it doesn't save" which can only be a PHP session error or "lost in transmission" type error
First try reproducing the simplest version of the problem. If you try my suggestion below and it doesn't work then try writing a very simple PHP script that triggers the problem.
Try getting them to access simple web sites (IE static files of various sizes) in the data center and look for anomalies, use a different port and/or server so it's easy to run tcpdump and record the packets for viewing with wireshark. Thanks I will take that idea forward.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 5 June 2014 21:44, Russell Coker <russell@coker.com.au> wrote:
They are on windows does a suitable cmd exist?
Try tcptraceroute, if that command doesn't exist then look for an option to make traceroute use TCP. If it's not built in then you should be able to download one.
The native Windows traceroute, tracert, uses ICMP packets. You can download tracetcp from sourceforge (you'll need to install WinPCap as well). An alternate could be to use nmap and on Windows particularly zenmap that gives the user a GUI and when invoked with the --traceroute switch can produce a nice looking topology map. Another option might be to get the client to install the Win version of wireshark and have them capture packets for analysis. -- Colin Fee tfeccles@gmail.com
participants (3)
-
Colin Fee -
Piers Rowan -
Russell Coker