231084 - hangs when typing and iptables INPUT policy is DROP

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Paul van der Hulst]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007


When I set firewall default input policy to DROP and restart mozilla, I can
still browse by mouseclicking, but when I try to enter text, mozilla hangs. 
When I then reset the policy to ACCEPT, mozilla wakes up again.

When mozilla is running while setting the policy to drop, it keeps working (it
is possible to enter text), but after a restart of mozilla, the problem is back.

Reproducible: Always

Steps to Reproduce:
1. start with a clean iptables ruleset
2. run the line 'iptables -P INPUT DROP'
3. (re)start mozilla
4. try to enter a url or try setting up a mail account in the mail client,
anything that requires entering text, including pasting text.
5. 

Actual Results:  
mozilla freezes, no screen updating. Closing mozilla only possible by killing.

Expected Results:  
allow me to enter text and continue working.

I run slackware 9.1 and got the problem in mozilla 1.4 as well as 1.5.
Kernel is 2.4.22 with my own configuration, compiled with gcc 3.2.3
iptables is 1.2.8
Previously I ran a heavily updated SuSE 6.3, with kernel 2.4.21, mozilla 1.5 and
iptables 1.2.7a, which ran the same firewall script. Then I didn't have the problem.
Still, I'm submitting this bug to you because I do not get why entering text is
bothered by a firewall.

Comment 1

[Jerry Talkington]

Are you able to type in any other applications?

I think this is a result of blocking X11 on the loopback, which is going to
cause problems.  I tried playing around with this, just for giggles, and
couldn't get anything done as a result of the iptables line you gave.

Try adding the line
iptables -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
before the -P INPUT DROP line, and the problem should clear up.

Comment 2

[Jerry Talkington]

This should be closed as WORKSFORME, or INVALID, since it was resolved by adding
iptables -P INPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
before the blocking line.

Comment 3

[Frank Wein [:mcsmurf]]

yes invalid