0

I have a weird problem when I try to post contents or upload files by php to my server.

After submitting the form it sleeps for a while then shows a page loading error. I tried different contents and files with different sizes and found that it only can post/upload contents/files with size bellow 530 bytes! (approximately).
I can upload/post to the other sites, so I'm pretty sure the issue is on the server somewhere.

  • upload_max_filesize is 2M
  • post_max_size is 8M
  • Apache's LimitRequestbody is 3M

The server is connected to the internet via a PPPoE connection, and I've previously had problems with FTP which I solved by reducing the server's MTU to 1460, however now even changing MTU doesn't help.

When I monitor the network through WireShark the lines below are shown (checksum error and bad tcp)

1170    53.165583000    192.168.1.2 78.39.102.77    TCP 1506    [TCP segment of a reassembled PDU]

1293    57.661244000    192.168.1.2 78.39.102.77    TCP 1506    [TCP Retransmission] 60849 > http [ACK] Seq=1 Ack=1 Win=66792 Len=1452

in the details of lines it says the error occurs on IP packets and mainly because of incorrect checksum (its 0x0000), and suggests that it may be caused by the TCP/IP checksum offload functionality.

Could this be related to my issue? If so, how should I solve it? Should I disable checksums? Change the NIC? Something else?


Update: I disabled the ip checksum in my computer (client) and now I see another message on TCP retransmission which is suspected to be the cause of the problem

[This frame is a (suspected) retrasmission]

under

[TCP Analysis Flags]

it seems to me a congestion error, but I don't know how to solve it

5
  • You need to check your PHP error logs. Aug 12, 2013 at 17:01
  • There is no error about the test in the error log /var/log/httpd/error_log
    – Ahmad
    Aug 12, 2013 at 18:22
  • I didn't assign any domain name to this IP (DNS), could it be the routing problem?
    – Ahmad
    Aug 12, 2013 at 18:30
  • I checked routing by sending a ping (ping -l 1024 78.39.102.77) I had no packet lost
    – Ahmad
    Aug 12, 2013 at 18:47
  • I checked it from other computers and it worked from them, others can connect to the server except me (then no server problem possibly) I can connect to other servers except it (then no client problem possibly). how can you explain this paradox
    – Ahmad
    Aug 13, 2013 at 16:29

2 Answers 2

2

DO NOT DISABLE TCP CHECKSUMS.

Your TCP stack should automatically handle recovery albeit that this will drag down the throughput of the network. If you can reproduce the same fault then there is a very serious defect in the TCP stack of the sending or receiving machine or something in between. Have you run wireshark at both ends?

Have you got TCP offloading configured on the sending end? Have you tried switching it off?

Is the NAT by router or HTTP proxy?

I'd like to think some at the Sirjan Universoty of Technology would be able to give you more specific advice on how their system's are configured than here on serverfault.

2
  • I run Wireshark on the client end (my computer). as I updated my original question, after disabling IP Checksum offload on my computer now I see another message on why TCP packetes are retransmitted. [This frame is a (suspected) retrasmission]. what this say?
    – Ahmad
    Aug 20, 2013 at 6:37
  • I ran tcpdump on the receiving end when retransmission occurs I get no packet at this end. does it means some routers in between get congested? why I can post to other sites except my site
    – Ahmad
    Aug 20, 2013 at 14:09
1

I guessed the problem is tcp congestion, so I followed the tcp parameters tuning and increased tcp_wmem, tcp_rmem, wmem_max, ..... and restart the server

till now I still haven't encounter the problem

Here I should point out since WireShark captures tcp packetes before they go throuhg NIC, if the checksum is calculated in NIC then the incorrect checksum in WireShark is not usually a real issue

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .