transmission overwrites it's network connections -- seems to stop issuing traffic msgs to tracker.

[Astara]

I was looking for tracker messages in wireshark and having around 285 torrents, I thought I should be seeing one about every 10 seconds or so if they were distributed randomly. I was seeing 'GET requests for 'scratches' to transmission, that were responded to, but nothing indicating any of my download traffic (or upload traffic) was being recorded with the tracker.

After several minutes of viewing, and seeing no traffic with my upload or download data counts, I restarted transmission. Then I saw several messages indicating traffic counts (all 0, as it was just starting).

I let it run for 15 minutes before stopping the trace.

I saw about 15 TCP Dup AC's, 3 out-of-order ACKS, about 25 TCP Retransmissions, and

2 messages saying "TCP Port numbers reused (ports 37940 and 54006).

I also saw 2 messages that connections had been closed from the other end (but they were on different port numbers).

Sorting by port number, sure enough -- I looked at the 54006 case and found that no more than 3 minutes earlier, transmission had opened a connection on 54006, then about 3 minutes later -- with out any intervening traffic from my host to the tracker on that port, I saw another 'open' go through -- but no close of that port for the first one.

I noticed, coincidentally, that my stats on this tracker were incrementing a few days ago when I only had 30-70 torrents, but now with transmission hosting about 280 torrents to the same tracker, I *thought* I was seeing my rate of stats changing slowing down -- I suppose I should write script to keep track of daily/hourly changes so I can more quickly detect this problem, since when it just slows down, it's hard for me to tell.

But it appears that my client was no longer sending progress messages for active torrents to the tracker site, though I was seeing 'scratch' messages go through. So from the torrent site, it would look like I really had no traffic -- and not look that suspicious, even though the transmission client is able to upload and download traffic at this point without having such stats reported to the remote tracker.

Just because I don't know how to tell you how to repeat it, doesn't mean it isn't a real problem. It's not going away. I regard this as a severe problem, but I can't expect it to be a high priority given its difficult to reproduce nature.

It appears I have enough torrents, now, to generate the problem! ;-)

(not to mention the other people who seem to be running into problems that look like this).

At *this* point, I haven't had any added torrents stay in the 0-peers state for very long (no longer than it might take for a long-web request to finish). Perhaps enough connections have to get overwritten before that problem is triggered. It could be a different problem -- but a different problem with multiple causes -- one of which could be this bug...but that's just another guess at this point.

[livings124]

#3829

Don't duplicate post. Do you realize that you're blatantly trolling?

[jordan]

As I've requested six times already, please provide a TR_CURL_VERBOSE log. Chasing ghosts like "I saw 3 out-of-order ACKS, about 25 TCP retransmissions" is like trying to diagnose an engine problem by counting how many blue cars drive down the road.

KyleK has told you exactly how to create this log... you replied that you no longer had the time or interest to work on that ticket. Then you wrote another 1600 words in the ticket but still no TR_CURL_VERBOSE log. Now, four days later, you open a duplicate ticket with some pseudorandom details but still no TR_CURL_VERBOSE log.

[Astara]

Replying to livings124:

#3829 Don't duplicate post. Do you realize that you're blatantly trolling?

From Wikipedia definition of 'Trolling':

In Internet slang, a troll is someone who posts inflammatory, extraneous, or off-topic messages in an online community, such as an online discussion forum, chat room, or blog, with the primary intent of provoking other users into a desired emotional response or of otherwise disrupting normal on-topic discussion.

1) This isn't a discussion forum, chat room or blog. 2) The post wasn't inherently inflammatory, extraneous or off-topic -- it was a bug report in a bug-report database. It wasn't designed to disrupt 'normal, on-topic discussion', since it is its own subject. It was not my intent to provoke an emotional response, in fact, I was hoping to get NO response from you as you have consistently shown hostility and an attack & tear down mentality that no one would want to elicit, let alone, be around. I realize in reading through your responses to others, that its not strictly personal, but that you treat many people like some lower form of life. Assuming you know how to program (many socially inept people are stellar programmers) you'd really best exercise your talents in focusing on engineering/programming tasks and minimizing your contact and responses to users, because purposefully or not, you come off, at best, as short or abrupt, and at worst, down right insulting & hostile.

But given you are marking this as a duplicate...then this would seem to be an admission that it's a duplicate of a specific symptom in which transmission over-writes it's connections to trackers, and in doing so, stops reporting downloaded (and uploaded) amounts to the trackers.

How can any of the developers claim that transmission overwriting it's own connections and violating the TCP specification is NOT a bug?

I know of no bug-databases -- NONE! that close out bugs as invalid just because there isn't sufficient information, yet, to reproduce it. In any case, the bug is put into a "need more information" state or closed for lack of a response, after some sufficiently long period -- usually two weeks. It also isn't closed if the person has asked a question and the bug-responder hasn't yet answered the question (as in that bug).

Replying to jorden:

As I've requested six times already....

And as I responded 6 times, where does it go, and does output come out if it is a non-devel version of transmission. Not once did you answer.

Then Kylek suggested another way to get the output, namely letting it go to the screen. There was no reason to believe that his suggestion would work any better than yours -- I still didn't know where the output was supposed to end up, nor under what circumstances it would be turned off.

My response to him at the time was based on having no way to reproduce the problem -- which was true at the time. Since then I've downloaded well over 100-200 more torrents and am now beginning to be able to reproduce the problem. But when I answered him, I had no interest in going out of my way to reproduce the problem. I knew, given some time, I'd run into the problem again -- just so happens it was much sooner than I realized.

Another thing that changed -- I didn't realize that all output was shut off when the client goes into background. Many daemons continue to put messages out on stderr or in the system log when they are in background and it is common for 'startproc' to capture both stdout and stderr of such programs. Unfortunately, I got nothing from transmission, because some rocket scientist decided to throw away all the output.

THAT is why, it appears, I got NO output -- you never answered my questions because you didn't want to admit how stupid your debug messages were -- that under normal operation, all of those messages are written to /dev/null. Brilliant!

No wonder you harped on me for a CURL VERBOSE LOG -- it was impossible to produce with the daemon as one would normally run it. You guys -- are such a laugh...probably laughing it up a storm when I can't find the output -- because you send it to /dev/null....

You are so *funny*!!!

Needless to say, that's another bug that needs fixing so users can trap stderr and stdout and send them to a debug log.

It would also be appropriate for transmission to use 'syslog', so its messages can be logged and filtered with all the syslog tools that are already out there. You have the ability to turn on logging for levels 'error' 'info' and 'debug' -- are they marked so they can be directed into different files?

If syslog was used, they could be sent out with the appropriate priority (error/notice/info/debug...etc)....

But now I see why you never answered my question about where the messages were supposed to end up. Because in the daemon, they are normally sent to /dev/null.!!!

And you wanted me to send you a copy of them! *WHAT A JOKE!!***

[livings124]

tldr: noise without reasonable content

This ticket is a rephrase of the other. It is a duplicate.

[livings124]

And might I add that you are the one that have been doing the personal attacks.

[livings124]

Replying to Astara:

But given you are marking this as a duplicate...then this would seem to be an admission that it's a duplicate of a specific symptom in which transmission over-writes it's connections to trackers, and in doing so, stops reporting downloaded (and uploaded) amounts to the trackers.

I'm not going to respond to the flame bait, but I should make clear that this is a duplicate of a ticket about the same issue. It is not confirming any symptoms, issues, etc.; it is simply stating that there is a ticket open (valid or invalid) with the same exact topic.

[jordan]

Replying to livings124:

Replying to Astara:

But given you are marking this as a duplicate...then this would seem to be an admission that it's a duplicate of a specific symptom in which transmission over-writes it's connections to trackers, and in doing so, stops reporting downloaded (and uploaded) amounts to the trackers.

I'm not going to respond to the flame bait, but I should make clear that this is a duplicate of a ticket about the same issue. It is not confirming any symptoms, issues, etc.; it is simply stating that there is a ticket open (valid or invalid) with the same exact topic.

And, I would add, the other ticket was also opened by Astara.

The meaning of "duplicate" in a bug tracker is well known. livings listed the ticket number when he closed this ticket as a dupe, and also chastised Astara for double-posting. This seems unambiguous to me.

[jordan]

Replying to Astara:

How can any of the developers claim that transmission overwriting it's own connections and violating the TCP specification is NOT a bug?

Because there's no evidence. This ticket has same content-to-drama ratio as an episode of "ghost hunters."

As I've requested six times already....

And as I responded 6 times, where does it go, and does output come out if it is a non-devel version of transmission. Not once did you answer.

That's incorrect. You did not ask six times. Also, KyleK and I both gave you answers.

Let's look back at one of my answers. It was an example for transmission-gtk because I didn't know you were using the daemon, but let's look at it anyway:

Try it this way:

$ TR_CURL_VERBOSE=2 transmission-gtk 2>log

You're telling me you can't figure out what file that invocation is going to store its log output in and that's why you can't move forward on this? Seriously?

Then Kylek suggested another way to get the output, namely letting it go to the screen. There was no reason to believe that his suggestion would work any better than yours -- I still didn't know where the output was supposed to end up, nor under what circumstances it would be turned off.

My response to him at the time was based on having no way to reproduce the problem -- which was true at the time.

Your response was "If I had the time and interest to work on this right now, that might be a good idea." That was your way of saying you had no way to reproduce the problem? :)

Since then I've downloaded well over 100-200 more torrents and am now beginning to be able to reproduce the problem. But when I answered him, I had no interest in going out of my way to reproduce the problem. I knew, given some time, I'd run into the problem again -- just so happens it was much sooner than I realized.

Another thing that changed -- I didn't realize that all output was shut off when the client goes into background. Many daemons continue to put messages out on stderr or in the system log when they are in background and it is common for 'startproc' to capture both stdout and stderr of such programs. Unfortunately, I got nothing from transmission, because some rocket scientist decided to throw away all the output.

THAT is why, it appears, I got NO output -- you never answered my questions because you didn't want to admit how stupid your debug messages were -- that under normal operation, all of those messages are written to /dev/null. Brilliant!

No wonder you harped on me for a CURL VERBOSE LOG -- it was impossible to produce with the daemon as one would normally run it. You guys -- are such a laugh...probably laughing it up a storm when I can't find the output -- because you send it to /dev/null....

You are so *funny*!!!

Needless to say, that's another bug that needs fixing so users can trap stderr and stdout and send them to a debug log.

It would also be appropriate for transmission to use 'syslog', so its messages can be logged and filtered with all the syslog tools that are already out there. You have the ability to turn on logging for levels 'error' 'info' and 'debug' -- are they marked so they can be directed into different files?

If syslog was used, they could be sent out with the appropriate priority (error/notice/info/debug...etc)....

But now I see why you never answered my question about where the messages were supposed to end up. Because in the daemon, they are normally sent to /dev/null.!!!

And you wanted me to send you a copy of them! *WHAT A JOKE!!***

You are (intentionally?) confusing different levels of debug messages. If you calm down instead of throwing yet another fit maybe something useful will happen.

Here is the example I gave you before ($ TR_CURL_VERBOSE=2 transmission-gtk 2>log) translated into transmission-daemon:

TR_CURL_VERBOSE=1 ./transmission-daemon -f 2>log

Does this answer your questions?

[Astara]

All the examples you gave me had me setting CURL_VERBOSE to 1 or 2 -- which I did and got no output -- that's why I kept asking where it was suppose to end up.

The problem is that your instructions *DON'T WORK* for the daemon in default mode.

By default, the daemon runs in background.

All of your examples before today (not counting Kyle's as I don't think he's a dev) don't take into consideration that file descriptions 1 and 2 (the ones you kept telling me to use) are both closed when transmission starts up and redirected to '/dev/null'.

When Kyle gave his idea of running it in foreground to capture, I didn't think it would work any better than your directions which were BROKEN.

IT's your own damn fault for giving me lame instructions. It's also the fault of whoever decided tacitly redirect stdout and stderr to /dev/null -- NOT normal practice.

That's why 'startproc' (among others) has an option "-l" to capture the output of stdout and stderr, so if the daemon want/need to report something and the programmers didn't use syslog, then startproc could grab those messages and log them in some coherent fashion.

But not only does transmission not use the system-logging facility (where the user can control where 'info/debug/and various levels of error messages go and how to process them, up to, and including doing things like sending a message to multiple 'ops' via a pager, cellphone or twitter or shut down the system in a real emergency), but transmission-daemon also redirects all standard error and output to /dev/null -- guaranteeing that the devs can ask for such logs from users and then place the blame on the user when they can't find the output. Brilliant!

No. I don't think you did it on purpose, but I find it odd that none of the devs would think about the fact that stderr and out are redirected to /dev/null. Especially when I kept asking where I should expect the output!

So you tell me, how was I supposed to give you a log when it had been redirected to /dev/null? Do you think it was even close to 'fair' to pour salt in the wound and claim the bug was invalid because I coudn't find the output that you'd redirected to /dev/null?

Yes, someone from the outside -- not a dev, AFAIK, made a suggestion that would have, by accident(?) worked around the problem, but since no one knew the source of the problem and no one could tell me where I should be getting the output, I wasn't interested in trying things at random, especially since my easy source of duplicating the error had disappeared. I was more interested in recovering my data than tracking down a transmission bug that no longer affected me. Better use of my time would be to recover data and when I hit the bug again file a new bug (since the old one was closed as invalid, not open 'awaiting further input' -- something I suggested before filing this as a new bug).

I'll suggest it again. If you want more data filed under that bug then re-open it. I have problem trying to submit data against a bug that has already been judged to be invalid.

As for telling me to calm down -- I'm not the one who closed the bug. AS I mentioned before. That ball is in your hands. If you want calm rational discussion, then you might try not to engage in 'power-over' dynamics and use the arbitrarily closing bugs that are under discussion and/or investigation as a way to prove your power.

Go back and look at the discussion up to the point the bug was unilaterally closed (as a wontfix, no less) -- I wasn't *demanding* that you investigate or fix anything. I was reporting symptoms as I found them and asking where the supposed output that I was supposed to be seeing was supposed to be because I wasn't seeing it! Because I didn't jump high enough for you -- you closed the bug -- not because I was being demanding -- if I was pressuring you, sure, you might feel a need to retaliate -- but your actions were unwarranted, thus my response. You are welcome to retract your actions at any time -- something you might want to consider since your directions to get output were absolutely wrong.

To paraphrase you: did you actually try your directions before telling me to do them?

[jordan]

Another day, another pile of angry words about how incompetent I am and how mean livings was to close this rambling ticket. Still no TR_CURL_VERBOSE log in sight, and that's everybody's fault except Astara, who didn't even try KyleK's instructions and has three conflicting excuses: (1) didn't think they would work (2) thought it was a good idea but didn't have the time or interest to investigate the ticket (3) couldn't reproduce the bug.

As for the instructions I gave...

IT's your own damn fault for giving me lame instructions

<snip>

I didn't think it would work any better than your directions which were BROKEN.

<snip>

Your directions to get output were absolutely wrong.

<snip>

did you actually try your directions before telling me to do them?

I've given you instructions twice. Let's test out these lame, BROKEN, absolutely wrong instructions and see how they go:

Lame, BROKEN, absolutely wrong instructions from three weeks ago:

Window 1:

$ TR_CURL_VERBOSE=2 transmission-gtk 2>log

Window 2:

$ less log
* Expire cleared
* About to connect() to torrent.ubuntu.com port 6969 (#0)
*   Trying 91.189.90.143... > GET /announce?info_hash=%bc%f2%e5%87%af%d4%d3%b1%bd%d8%ec%e5%15%0d%9f%b4%d2%95%8a%f4&peer_id=-TR2210-ws4ijsizno9e&port=51413&uploaded=0&downloaded=0&left=0&numwant=80&key=k4m6cb13&compact=1&supportcrypto=1&requirecrypto=1&event=started HTTP/1.1
User-Agent: Transmission/2.21
Host: torrent.ubuntu.com:6969
Accept: */*
Accept-Encoding: gzip;q=1.0, deflate, identity

* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Length: 415
< Content-Type: text/plain
< Pragma: no-cache
< Content-Encoding: gzip
< 
* Expire cleared
* Closing connection #0
Announce response:
< {
    "complete": 3311, 
    "crypto_flags": "0x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x01", 
    "incomplete": 165, 
    "interval": 1800, 
    "peers": "U<\bL;\u0541^U^FWS^AXM]\t^?eS]sM
* Expire cleared

Huh. Well it must be coincidence. Let's the instructions I gave yesterday; those couldn't possibly work.

---

Lame, BROKEN, absolutely wrong instructions from yesterday:

Window 1:

TR_CURL_VERBOSE=1 ./transmission-daemon -f 2>log

Window 2:

$ less log
* Expire cleared
* About to connect() to torrent.ubuntu.com port 6969 (#0)
*   Trying 91.189.90.143... > GET /announce?info_hash=%bc%f2%e5%87%af%d4%d3%b1%bd%d8%ec%e5%15%0d%9f%b4%d2%95%8a%f4&peer_id=-TR2210-dag1huc9v1eq&port=51413&uploaded=0&downloaded=0&left=0&numwant=80&key=upampk7z&compact=1&supportcrypto=1&requirecrypto=1&event=started HTTP/1.1
User-Agent: Transmission/2.21
Host: torrent.ubuntu.com:6969
Accept: */*
Accept-Encoding: gzip;q=1.0, deflate, identity

* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Length: 413
< Content-Type: text/plain
< Pragma: no-cache
< Content-Encoding: gzip
< 
* Expire cleared
* Closing connection #0
Announce response:
< {
    "complete": 3657, 
    "crypto_flags": "0x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x010x01", 
    "incomplete": 185, 
    "interval": 1800, 
    "peers": "@a~vN^T'u\\4FLI~fzkWBU):t@o^TV1^BRXKR/M);bD^Fg\u0572^Z!MJ;-U|f^?^2r\u057ds^X1qv\u0572&}PyGd\u02ebQ\fCG{2QM%^R79^Y\u057a=u`\u00f1y]_\u03e4^ZR^P\u057e.\bg]^W^VW^F/a\u0558^BS7Ov_X^ZS^UBim4k^ZZ^AmWDM!^E\\^WoiS^AN//G\u02a6{]\\_^ZZY^Xj^]QJ"
}

Well what do you know... those worked, too.

[Astara]

Nice try but you knew I was using the daemon (#3829, comments 29, 32, and your example in 36 had no '-f').

Try being consistent with what you are writing.

Anyway, doesn't matter now.

As for posting a curl-verbose log, was looking for an open bug to post against rather than opening a new one -- but if you insist, I'll get too it shortly! I.e. I'll post it against an open bug report, you can choose which.

[jordan]

Xref: The fun & games continue at #4007