Reports of bad headers using TUN?

[Matthew]

Nigel,
  I don't have ethereal installed on any of the machines. I was able to 
use tcpdump and ngrep to get some info but I'm not sure how to read it.

   I now have 3 more people that are getting either timeouts or internal 
server errors. 2 are behind big corporate firewalls. My office is behind 
a normal Linksys cable/dsl router and we are having no problems doing 
this on our end. The fact that more people are having this issue is 
starting to worry me.

   I sent the sample POST php page from the HOWTO to a couple of the 
users to see if they get anything from it.

This was captured on nodeA (clusterA) when the user clicked on the 
submit button to submit the POST:

her.comp.23087 > clusterA.com.https: S 3498668704:3498668704(0) win 
65535 <mss 1460,nop,nop,sackOK>
her.comp.23087 > clusterA.com.https: . ack 296918962 win 65535
her.comp.23087 > clusterA.com.https: P 0:120(120) ack 1 win 65535
her.comp.23087 > clusterA.com.https: . ack 1 win 65535 <nop,nop,sack 
sack 1 {1461:1594} >
her.comp.23087 > clusterA.com.https: . ack 1594 win 65535
her.comp.23087 > clusterA.com.https: P 120:318(198) ack 1594 win 65535
her.comp.23087 > clusterA.com.https: P 318:963(645) ack 1653 win 65476
her.comp.23087 > clusterA.com.https: P 3883:4546(663) ack 1653 win 65476
her.comp.23087 > clusterA.com.https: P 6006:6871(865) ack 1653 win 65476
her.comp.23087 > clusterA.com.https: . ack 1653 win 65476 <nop,nop,sack 
sack 1 {2175:212} >
her.comp.23087 > clusterA.com.https: P 963:1048(85) ack 2212 win 64917
her.comp.23087 > clusterA.com.https: P 6803:6908(105) ack 2212 win 64917
her.comp.23087 > clusterA.com.https: R 6908:6908(0) ack 2212 win 0
her.comp.23087 > clusterA.com.https: R 3498669753:3498669757(4) win 7740
her.comp.23087 > clusterA.com.https: R 3498669753:3498669757(4) win 7740

The client comp (her.comp) displays "Bad request" after submitting. It 
hangs for about 6 seconds then shows the error.

The tcpdump on the same server with the same POST but when accessed 
directly, is about 3 times longer and responds right away.

Using ngrep accessed via cluster right after POST:

T 24.225.236.13:24629 -> 74.52.166.35:80 [AP]
POST /members/eventmanager.php
HTTP/1.1
Host: www.omnovia.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) 
Gecko/20061206 Firefox/1.5.0.9
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.omnovia.com/members/eventmanager.php?roomID=378
Cookie: membersArea_session=8d8a0934a861869ebe3778de47821256; 
userNo=10314; username=lsivulich; companyID=324..

that's it!

Now when accessed directly:

T 24.225.236.13:26871 -> 74.52.166.130:80 [AP]
POST /members/eventmanager.php
HTTP/1.1
Host: wwwdb2.omnovia.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) 
Gecko/20061206 Firefox/1.5.0.9
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://wwwdb2.omnovia.com/members/eventmanager.php?roomID=378
Cookie: userNo=10314; username=lsivulich; companyID=324; 
membersArea_session=aefbca5d162e4e5d0aa734b99cc44411
Cache-Control: max-age=0..
##
T 24.225.236.13:26871 -> 74.52.166.130:80 [AP]
Content-Type: application/x-www-form-urlencoded
Content-Length: 5709
roomID=378&action=neweventstep2& <remaining data>

Does this help isolate where my problem lies?

-Matthew

Nigel Hamilton wrote:
>> Hi Nigel,
>>
>>>     How big is the size of his POST - does it exceed one packet?
>>
>>     How can I find out?
>>
> 
>     You could use ethereal to watch the incoming packets and see if they 
> fragment but it's probably easier for you and him if he can send to you 
> what he is POSTing and then you try and replicate it.
> 
>>>     This fragmenting may explain why when he goes "direct" to the 
>>> real server there is no problem.
>>
>>     But wouldn't others have a similar experience? Namely myself and 
>> the other technicians here?
>>
> 
>     I think from the discussion on the HowTo this is linked to the "MSS" 
> setting and the nuances of the client's network.
> 
>>     Or could it be this in conjunction with his router/firewall setup?
>>
> 
>     This is something to check too.
> 
>     The first step to solving the problem is reliably replicating it - 
> so finding out what he's POSTing is a good start - hopefully it will 
> happen to you too. Then if the problem is indeed the TUN problem 
> described in the HowTo[1] then the proposed solution is to execute this 
> command on your RealServers:
> 
> iptables -A OUTPUT -s VIRTUAL-IP -p tcp -m tcp --tcp-flags SYN,RST,ACK 
> SYN,ACK -j TCPMSS --set-mss 1440
> 
>     Please let us know how you get on?
> 
> Nige
> 
> [1] http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html
> 
> 
> 
> 
> 
> 
>> Thanks,
>> Matthew
>> _______________________________________________
>> LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
>> Send requests to lvs-users-request at LinuxVirtualServer.org
>> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cluster_debugs.txt
Url: http://lists.graemef.net/pipermail/lvs-users/attachments/20070103/aa404287/attachment.txt