239639 - Firefox kills ppp connection when opening multiple images/pages simultaneously

Status: RESOLVED EXPIRED

(Firefox :: General, defect)

Description

[Kaoru Nagisa]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225 Firefox/0.8

A very weird bug that haunted me for a while, even weirder because I managed to
narrow it to Firefox. 

PC : Athlon Thunderbird 1200, 256 MB RAM
OS : Gentoo Linux, arch=i686, kernel 2.4.25, KDE 3.2.1, firefox-0.8, all
packages compiled from default gentoo ebuilds or taken from 2004.0 prebuilt
packages distribution, all installed packages are up-to-date.
DSL modem : AVM Fritz! Card DSL, proprietary driver 03.11.02 + Lehrke patch
(note that this is an internal combo ISDN/DSL modem, and communication with the
driver goes over CAPI 2.0 layer, PPPoE only exists virtually within driver)
ISP/connection : ADSL, D768/U128kbps, (T-DSL-768), provider: T-Online

Problem description : Ever since installation of Linux (about 3 weeks ago), I
was having really annoying DSL modem hangups when using Internet. For a last
couple of days I tried to investigate this problem thorougly. I contacted my
provider and let my line checked for errors overnight, but nothing was detected,
and my connection was stable the whole time.

To my surprise, connection was stable even when completely loaded with
Bit-Torrent traffic, or when downloading using wget, but once I launched Firefox
and started browsing, my connection crashed eventually. I tried the same thing
with Konqueror, but it didn't affect my connection. It doesn't happen under
Win98SE on the same computer,provider,Firefox version, either.

This problem, as crazy as it sounds, is always reproductible, and of all
applications, it only occurs when using Firefox. I haven't tried other browsers
besides Firefox 0.8 and Konqueror, but mldonkey, bit torrent (standard, shadows
and azureus clients), wget, ftp and scp. If there's any other log or
configuration information that could be useful, I would be glad to supply it.


Reproducible: Always
Steps to Reproduce:
1. connect to internet using pppd "pppd call provider-script"
2. open firefox and browse some kind of site with lots of images linked via
thumbnails. You can go to http://www.1chan.net and enter one of the image boards.
3. open multiple images linked via thumbnails in new tabs by Ctrl+clicking on
them. Do it as fast as possible.

Actual Results:  
After a while, some images will stall, or you'll be getting "host not found"
errors. In the same time, tail -f /var/log/daemon.log will show that PPP
protocol no longer receiving echo replies from peer and connection will terminate.


Expected Results:  
PPP connection is not disturbed by browsing.

An excerpt from /var/log/daemon.log during connection crash

Apr  4 21:26:56 tsunami pppd[3736]: sent [LCP EchoReq id=0x23 magic=0xf8e3f297]
Apr  4 21:26:56 tsunami pppd[3736]: rcvd [LCP EchoRep id=0x23 magic=0x523be205]
Apr  4 21:27:01 tsunami pppd[3736]: sent [LCP EchoReq id=0x24 magic=0xf8e3f297]
Apr  4 21:27:06 tsunami pppd[3736]: sent [LCP EchoReq id=0x25 magic=0xf8e3f297]
Apr  4 21:27:11 tsunami pppd[3736]: sent [LCP EchoReq id=0x26 magic=0xf8e3f297]
Apr  4 21:27:16 tsunami pppd[3736]: No response to 3 echo-requests
Apr  4 21:27:16 tsunami pppd[3736]: Serial link appears to be disconnected.
Apr  4 21:27:16 tsunami pppd[3736]: capiplugin: phase terminate (was running).
Apr  4 21:27:16 tsunami pppd[3736]: cbcp_lowerdown
Apr  4 21:27:16 tsunami pppd[3736]: capiplugin: phase network (was terminate).
Apr  4 21:27:16 tsunami pppd[3736]: Script /etc/ppp/ip-down started (pid 30488)
Apr  4 21:27:16 tsunami pppd[3736]: capiplugin: phase terminate (was network).
Apr  4 21:27:16 tsunami pppd[3736]: sent [LCP TermReq id=0x2 "Peer not responding"]
Apr  4 21:27:16 tsunami pppd[3736]: Script /etc/ppp/ip-down finished (pid
30488), status = 0x0
Apr  4 21:27:19 tsunami pppd[3736]: sent [LCP TermReq id=0x3 "Peer not responding"]
Apr  4 21:27:22 tsunami pppd[3736]: capiplugin: phase dead (was terminate).
Apr  4 21:27:22 tsunami pppd[3736]: controller 2: listen_change_state 0 -> 1
Apr  4 21:27:22 tsunami pppd[3736]: ncci_change_state:0x10102 4 -> 6 event=12
Apr  4 21:27:22 tsunami pppd[3736]: contr 2: listenconf Info=0x0000 (No
additional information) infomask=0x144 cipmask=0x0 capimask2=0x0
Apr  4 21:27:22 tsunami pppd[3736]: controller 2: listen_change_state 1 -> 0
Apr  4 21:27:24 tsunami pppd[3736]: ncci_change_state:0x10102 6 -> 7 event=10
Apr  4 21:27:24 tsunami pppd[3736]: ncci_change_state:0x10102 7 -> 0 event=13
Apr  4 21:27:24 tsunami pppd[3736]: plci_change_state:0x102 3 -> 7 event=8
Apr  4 21:27:24 tsunami pppd[3736]: plci_change_state:0x102 7 -> 8 event=9
Apr  4 21:27:24 tsunami pppd[3736]: plci_change_state:0x102 8 -> 0 event=11
Apr  4 21:27:24 tsunami pppd[3736]: capiplugin: disconnect(local): "" -> ""
outgoing (pcli=0x102/ncci=0x10102) 0x0000 (0x3312) - No additional information
Apr  4 21:27:24 tsunami pppd[3736]: Connection terminated.
Apr  4 21:27:24 tsunami pppd[3736]: Modem hangup
Apr  4 21:27:24 tsunami pppd[3736]: Connect time 195.7 minutes.
Apr  4 21:27:24 tsunami pppd[3736]: Sent 122464722 bytes, received 1010274477 bytes.
Apr  4 21:27:24 tsunami pppd[3736]: capiplugin: phase disconnect (was dead).
Apr  4 21:27:25 tsunami pppd[3736]: capiplugin: phase holdoff (was disconnect).
Apr  4 21:27:55 tsunami pppd[3736]: capiplugin: phase dormant (was holdoff).
Apr  4 21:27:55 tsunami pppd[3736]: capiplugin: phase serialconn (was dormant).
Apr  4 21:27:55 tsunami pppd[3736]: plci_change_state:0x0 0 -> 1 event=1
Apr  4 21:27:55 tsunami pppd[3736]: capiplugin: leased line (adslpppoe)
Apr  4 21:27:55 tsunami pppd[3736]: plci_change_state:0x102 1 -> 2 event=3
Apr  4 21:27:55 tsunami pppd[3736]: plci_change_state:0x102 2 -> 3 event=6
Apr  4 21:27:55 tsunami pppd[3736]: ncci_change_state:0x102 0 -> 1 event=1
Apr  4 21:27:55 tsunami pppd[3736]: ncci_change_state:0x10102 1 -> 3 event=3
Apr  4 21:27:58 tsunami pppd[3736]: ncci_change_state:0x10102 3 -> 7 event=10
Apr  4 21:27:58 tsunami pppd[3736]: ncci_change_state:0x10102 7 -> 0 event=13
Apr  4 21:27:58 tsunami pppd[3736]: plci_change_state:0x102 3 -> 7 event=8
Apr  4 21:27:58 tsunami pppd[3736]: plci_change_state:0x102 7 -> 8 event=9
Apr  4 21:27:58 tsunami pppd[3736]: plci_change_state:0x102 8 -> 0 event=11
Apr  4 21:27:58 tsunami pppd[3736]: capiplugin: disconnect(remote): "" -> ""
outgoing (pcli=0x102/ncci=0x10102) 0x0000 (0x3312) - No additional information
Apr  4 21:27:58 tsunami pppd[3736]: capiplugin: couldn't make connection
Apr  4 21:27:58 tsunami pppd[3736]: controller 2: listen_change_state 0 -> 1
Apr  4 21:27:58 tsunami pppd[3736]: contr 2: listenconf Info=0x0000 (No
additional information) infomask=0x144 cipmask=0x0 capimask2=0x0
Apr  4 21:27:58 tsunami pppd[3736]: controller 2: listen_change_state 1 -> 0
Apr  4 21:27:58 tsunami pppd[3736]: capiplugin: exit
Apr  4 21:27:58 tsunami pppd[3736]: Exit.
---------------------------------------------------------------------------
PPP script /etc/ppp/peers/t-dsl:

# Ondemand Verbindung zu T-DSL über die Fritz!Card DSL
debug
sync
noauth
defaultroute
lcp-echo-interval 5
lcp-echo-failure 3
lcp-max-configure 50
lcp-max-terminate 2
noccp
noipx
#
persist
#demand
connect ""
#
mru 1492
mtu 1492
ipcp-accept-local
ipcp-accept-remote
#
#
#
plugin userpass.so
# Anschlusskennung T-Online-Nummer Mitbenutzerkennung
#          |           |           |
#user 000000000000\#000000000000\#0001\#@t-online.de
user xxxxxxxxxxxx\#xxxxxxxxxxxx\#0001\#@t-online.de
password xxxxxxx
linkname t-dsl
ipparam internet
plugin capiplugin.so
avmadsl
:
/dev/null
-------------------------------------------------------------------------

Comment 1

[Kaoru Nagisa]

Update : Tried following today :
1. tried opera-7.23-r1 (official ebuild) : no disconnects
2. tried mozilla-1.6   (official binary 2004.0) : no disconnects
3. uninstalled mozilla-firefox-0.8, and re-emerged with complete recompilation -
problem occured again as described, fully reproducible

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.