odd use of 100% of network capacity (100Mbps) when using thunderbird through ssh tunnel
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: rag, Unassigned)
Details
Attachments
(1 file)
55.82 KB,
text/x-log
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0
Steps to reproduce:
As per explanation below would appreciate being instructed how to document the offending solid behavior
Actual results:
Have just upgraded to TB 102.9.0 from 68 and now I note the behavior below that I did NOT have with the previous version.
I connect to another local network machine via ssh to get access to its TB.
It starts just fine except that, now, any interaction (mouse/keyboard event) network usage goes to 100% (full channel capacity of 100Mbps) for a significant chunk of time before the reaction to the event is reflected on the receiving host.
The command used is: 'ssh -X -f <host> thunderbird'
As requested, my UA is: 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0'
Expected results:
As per my experience with the 'old' version, such noted behavior is certainly and unexpectedly new and very strange. If it is a bug I cannot assert, but surely something is out of order.
Updated•2 years ago
|
(Summary). Tks, Mr.Melin; it is much clearer and more objective in reflecting the fact.
In an attempt to document the behavior with macroscopic data, I have logged the running of TB by just starting it and immediately closing it in succession.
The output from the terminal is the following:
<quote>
rag@<host1>:~$ ssh -v -E ssh.log -X -f <host2> thunderbird
rag@<host2>'s password:
[ImapModuleLoader] Using nsImapService.cpp
[NntpModuleLoader] Using NntpService.jsm
[Pop3ModuleLoader] Using Pop3Service.jsm
[GFX1-]: glxtest: libEGL missing methods for GL test
[GFX1-]: glxtest: No visuals found
[GFX1-]: glxtest: libEGL missing methods for GL test
[calBackendLoader] Using Thunderbird's ical.js backend
console.debug: "Found 0 public keys and 0 secret keys (0 protected, 0 unprotected)"
console.warn: services.settings: Failed to load last_modified.json: TypeError: NetworkError when attempting to fetch resource.
console.debug: "Successfully loaded optional OpenPGP library libgpgme.so.11 from system's standard library locations"
console.log: (new Error("couldn't find function symbol in library", "chrome://openpgp/content/modules/GPGMELib.jsm", 447))
console.debug: "Trying to load /usr/lib/thunderbird/libotr.so"
console.debug: "Trying to load libotr.so from system's standard library locations"
console.debug: "Trying to load libotr.so.5 from system's standard library locations"
console.debug: "Trying to load libotr.so from system's standard library locations"
console.log: (new Error("Cannot load required OTR library", "resource:///modules/OTRLib.jsm", 109))
</quote>
and the last 10 lines from 'ssh.log' are:
<quote>
debug1: confirm x11
debug1: channel 2: FORCE input drain
debug1: channel 2: free: x11, nchannels 3
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 2
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 1
Transferred: sent 615092, received 162259672 bytes, in 32.6 seconds
Bytes per second: sent 18842.5, received 4970589.4
debug1: Exit status 0
</quote>
Pls note that 162259672 == 154.7 MiB (!!!), yielding an average of 4.7 MiB/s but during the first ~10+ seconds connection usage went to 100% of the channel capacity.
For having done nothing at all, I wonder what caused ~155 MiB of traffic...
As it seems the only one being 'bugged' by "it" is me... (pun intended)
The cause of the high traffic from the remote host is well established after having logged, onto syslog, debugging info from ssh by way of the following command:
ssh -vvv -y -f <host> thunderbird
In the attached file one can see that the culprit is the concentrated repetition, in quick succession, of 'window adjustments' from X11's channel 1 for a handful of windows but the "winner" surely is for 2031616.
Again, the only activity performed was clicking on a mailbox to see message headers and then quitting. To do that there was a traffic of 300+ MB in a matter of a few seconds.
Gentlemen: the current standing of this issue is unacceptable to me and I wish to downgrade back to 68.
To that extent I ask, to whomever is kind enough and sufficiently knowledgeable, whether there is any reason I should not downgrade, either because of differences of user-associated configuration files or for whichever other technical reason(s) ??? ??? ???
And even when that downgrading is not perceived to be a problem per se, what precautions/preparations should I advisably take (in addition to backing up, of course) before actually downgrading ??? ??? ???
If not obvious, I note that the intention of the above questions is to guarantee the preservation, as much as possible, of the current user-specific configuration and mailboxes data, which incidentally were preserved entirely at the time of upgrading to 102.
TIA for any helpful hints rendered.
Comment 5•2 years ago
|
||
Does this also reproduce when using version 115 started in Help > Troubleshoot Mode?
If it does, and you have not already done so, please list complete steps to reproduce.
Just tested without invoking Troubleshoot Mode: the problem remains intact! Just moving the mouse from section to section within the screen is enough to trigger off the net cap to max... I start to wonder if it is not X actually the real culprit.
Do you still wish me to test in T mode?
Description
•