l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2011 Feb 21 19:32

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Apache: 2, Me: 0.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Apache: 2, Me: 0.



On Sun, 2011-02-20 at 14:34 -0800, Shwaine wrote:
> Sorry for the late reply, I've been swamped with program reviews, 
> candidate interviews, paper writing and teaching all week.... (the things 
> we do for academia, heh)

A *very* late reply. Where were you in August, to translate the
implications for me when I made the same observations back then?

http://lugod.org/mailinglists/archives/vox-tech/2010-08/msg00006.html

> To follow-up on the TCP 3-way handshake issue, in particular, the ACK 
> packet is not getting through. If you look at the original tcpdump log, 
> the SYN from the outside world gets in, the SYN/ACK from satan gets out, 
> but the final ACK from the outside world never arrives.
> 
> I sincerely doubt this is an Apache issue. It looks more like an iptables 
> issue to me. Try what Troy recommends to confirm that netcat also gets 
> blocked (which I suspect it will) just to be sure it isn't Apache. If you 
> cannot get through with netcat, the next thing to do is check iptables 
> with the following command:
> 
> iptables -L -n
> 
> Forward the output from that command to the list and we can see if its 
> your iptable rules that are preventing the connection from establishing. 
> In particular, I would bet you don't have an "allow RELATED,ESTABLISHED" 
> rule in place. You probably only have an "allow SYN to port 80" in place. 
> Without the corresponding related/established rule, your TCP 3-way 
> handshake would get cut off on sending the final ACK, just as was seen in 
> your tcpdump output.
> 
> For example, for my webserver, you would see the following in the iptables 
> INPUT chain with the above iptables command:
> 
> Chain INPUT (policy DROP)
> target     prot opt source               destination
> ACCEPT     tcp  --  0.0.0.0/0            <my IP address>     tcp spts:1024:65535 dpt:80 flags:0x17/0x02
> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
> 
> If you are missing that second line while having the "flags" on the first 
> line (allow SYN flag only) and your default policy on INPUT is to DROP, 
> then you've found your culprit.
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.