User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1064 Safari/532.5 Build Identifier: 3.0.4 and 3.1b2 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100430 Lightning/1.0b2pre Thunderbird/3.1b2] While sending mails with attachments that the process bar gets stuck b/w 35-98% and eventually fails with smtp server timeout. (Even for small attachments < 500KB) The smtp debug log shows as follows: 2010-05-18 05:00:57.890000 UTC - 0[1a2e140]: SMTP Connecting to: mysmtp.myserver.com The same mail is sent successfully from Outlook / Webmail. (Even with large attachments over 3MB) 2010-05-18 05:00:59.453000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:00:59.453000 UTC - 0[1a2e140]: SMTP Response: 220 default ESMTP myserver Beehive Gateway; Mon, 17 May 2010 22:00:41 -0700 2010-05-18 05:00:59.453000 UTC - 0[1a2e140]: SMTP entering state: 14 2010-05-18 05:00:59.453000 UTC - 0[1a2e140]: SMTP Send: EHLO [192.168.1.2] 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP Response: 250-default Hello [192.168.1.2] [/122.168.96.225] , Pleased to meet you 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP Response: 250-DSN 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP Response: 250-HELP 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP Response: 250 AUTH LOGIN PLAIN 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP entering state: 4 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP entering state: 21 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP auth: server caps 0x10304, pref 0x300, failed 0x0, avail caps 0x300 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN = 0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400) 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: trying auth method 0x200 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP entering state: 16 2010-05-18 05:00:59.796000 UTC - 0[1a2e140]: SMTP AuthLoginStep1() for sarthak.moghe@myserver.com@@å 2010-05-18 05:01:04.875000 UTC - 0[1a2e140]: PLAIN auth 2010-05-18 05:01:04.875000 UTC - 0[1a2e140]: Logging suppressed for this command (it probably contained authentication information) 2010-05-18 05:01:05.296000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:01:05.296000 UTC - 0[1a2e140]: SMTP Response: 235 Authentication successful 2010-05-18 05:01:05.296000 UTC - 0[1a2e140]: SMTP entering state: 18 2010-05-18 05:01:05.296000 UTC - 0[1a2e140]: SMTP Login response, code 235 2010-05-18 05:01:05.296000 UTC - 0[1a2e140]: SMTP entering state: 3 2010-05-18 05:01:05.296000 UTC - 0[1a2e140]: SMTP Send: MAIL FROM:<sarthak.moghe@myserver.com> 2010-05-18 05:01:05.656000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:01:05.656000 UTC - 0[1a2e140]: SMTP Response: 250 Requested mail action okay, completed 2010-05-18 05:01:05.656000 UTC - 0[1a2e140]: SMTP entering state: 5 2010-05-18 05:01:05.656000 UTC - 0[1a2e140]: SMTP Send: RCPT TO:<sarthak.moghe@myserver.com> 2010-05-18 05:01:06.000000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:01:06.000000 UTC - 0[1a2e140]: SMTP Response: 250 Requested mail action okay, completed 2010-05-18 05:01:06.000000 UTC - 0[1a2e140]: SMTP entering state: 6 2010-05-18 05:01:06.000000 UTC - 0[1a2e140]: SMTP Send: DATA 2010-05-18 05:01:06.343000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:01:06.343000 UTC - 0[1a2e140]: SMTP Response: 354 Start mail input; end with <CRLF>.<CRLF> 2010-05-18 05:01:06.343000 UTC - 0[1a2e140]: SMTP entering state: 7 2010-05-18 05:01:06.343000 UTC - 0[1a2e140]: SMTP entering state: 8 2010-05-18 05:13:59.031000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:13:59.031000 UTC - 0[1a2e140]: SMTP Response: 250 Requested mail action okay, completed 2010-05-18 05:13:59.031000 UTC - 0[1a2e140]: SMTP entering state: 6 2010-05-18 05:13:59.031000 UTC - 0[1a2e140]: SMTP Send: DATA 2010-05-18 05:13:59.375000 UTC - 0[1a2e140]: SMTP entering state: 0 2010-05-18 05:13:59.375000 UTC - 0[1a2e140]: SMTP Response: 354 Start mail input; end with <CRLF>.<CRLF> 2010-05-18 05:13:59.375000 UTC - 0[1a2e140]: SMTP entering state: 7 2010-05-18 05:13:59.375000 UTC - 0[1a2e140]: SMTP entering state: 8 Reproducible: Always Steps to Reproduce: 1.Attach a file (any extn) to the mail 2.Send it. The sending message box hangs between 30-98% (depending on the size of attachment) 3.Even after changing mailnews.tcptimeout to 400, the issue persists 4.Disabling McAfee antivirus makes no difference Actual Results: The mail fails to be sent from TB The same mail is sent successfully from Outlook / Webmail. (Even with large attachments over 3MB) Expected Results: Mail sent successfully and copied to respective folder Verified all options mentioned in Bugzilla 1. Bug 280475 - Unable to send attachments, or mail which contains anything other than plain text. OUTPUT: Disabled Mcafee VirusScan Enterprise, Host Intrusion Prevention and all access scanners. NO RESULT 2. Bug 325649 - "SMTP Send" fails due to SMTP connection drop when relatively large mail size, because SMTP send timeout occurs in 600 msec even when mailnews.tcptimeout=600(seconds) or 60000(60*1000 seconds) is set OUTPUT: Changed the mailnews.tcptimeout to 400, 600 etc. NO RESULT 3. Bug 383299 - Timeout when using SMTP with SSL encryption

For timeout part. I'm uspecting server side fault in Bug 325649 too(it was SMTP of Yahoo Japan inn 2006) - server killed connection silently due to server side error after all mail data is sent to server. Can you see such phenomenon by socket log? > https://wiki.mozilla.org/MailNews:Logging > https://developer.mozilla.org/en/HTTP_Logging > 2.Send it. The sending message box hangs between 30-98% (depending on the size of attachment) Is problem persistent when same mail is re-sent? 1. Compose a mail, send later, copy mail in Outbox to a folder. 2. Send unsent messages => problem occurrs, mail is still kept in Outbox. 3. Restart Tb, and send message in Outbox again. Does problem always occur at step 3? Does issue of high CPU utilization such as bug 538283 occur at same time?

Got the Socket trace but unfortunately couldn't understand much of it (Attached for your reference) Just FYI, this is a corporate mail account (name changed to mycorpmail and mycorpserver in log to protect it from public viewing) and TB 2.0 is one of the supported mail client by the n/w mgmt team. Thus refusing any connection for the server call seems less likely (And if it was the reason, same behaviour should have been exhibited by Outlook, OE or WinMail) For option 2, "Send Later" does no benefit of sending mail.The issue is persistent with almost all the mails with attachments over 200-300KB Error Message: Sending of message failed. The message could not be sent because the connection to SMTP server mycorpmail.mycorpserver.com timed out. Try again or contact your network administrator. Regards, Sarthak

(In reply to comment #3) > For option 2, "Send Later" does no benefit of sending mail.The issue is > persistent with almost all the mails with attachments over 200-300KB Purpose of "Send Later" is for next checking. If same mail, same problem always occurs. If issue like last part of [CRLF].[CRLF] is sent partially by Tb, "reduce mail data size by several bytes" should resolve problem. If issue like "last part of [CRLF].[CRLF] is sent partially by Tb", phenomenon is usually not next one you said. It should occur on mail of partular sizes only. > The issue is persistent with almost all the mails with attachments over 200-300KB > (And if it was the reason, same behaviour should have been exhibited by Outlook, OE or WinMail) I guess Outlook and Winmail has similar capability to OE's one as MS's mailer. Send mail with splitting to multiple small mails. (setting like next) Account Property, Advanced, Send, [ ] split mail if mail size exceeds: 60 KB As default of my OE6 was 60KB, if user simply enables the option, mail is sent in very small mails. Is such option used by OE, Outlook, Winmail?

There is config done by me in Outlook for splitting mails. Even the Webmail option (based on Oracle beehive) works fine and limits no quota to the size of attachments. Did you find anything relevant in the socket debug log? Regards, Sarthak

I am sorry for the typo There is no config done by me in Outlook for splitting mails

Shartak is ipv6 enabled on your network and on your machine ?

Guess not (not sure though) As per the blog http://ipv6blog.net/does-my-computer-have-ipv6-enabled/ pinged ::1 C:\Documents and Settings\samoghe>ping ::1 Ping request could not find host ::1. Please check the name and try again. Should that be a problem?

(In reply to comment #8) > Guess not (not sure though) > As per the blog http://ipv6blog.net/does-my-computer-have-ipv6-enabled/ > pinged ::1 > > C:\Documents and Settings\samoghe>ping ::1 > Ping request could not find host ::1. Please check the name and try again. > > Should that be a problem? Installed Microsoft TCP/IP version 6. The ping works now C:\Documents and Settings\samoghe>ping ::1 Pinging ::1 with 32 bytes of data: Reply from ::1: time<1ms Reply from ::1: time<1ms Reply from ::1: time<1ms Reply from ::1: time<1ms Ping statistics for ::1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

(In reply to comment #2) > SMTP and Socket dbug trace It looks for me that server doesn't return ACK properly if total data size excceds a limit. As no problem with Outlook, it may be a result that, for your server, Tb/NSPR is too aggressive in sending data. It may be phenomenon that Tb(NSPR) fails to detect some kind of response from server. (1) Last sussessful "calling PR_Write [count=4096]" > (Line no = 84296) > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: nsSocketOutputStream::Write [this=65d6bf8 count=4096] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: calling PR_Write [count=4096] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: PR_Write returned [n=4096] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: nsSocketTransport::SendStatus [this=65d6b40 status=804b0005] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: nsSocketOutputStream::Write [this=65d6bf8 count=4096] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: calling PR_Write [count=4096] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: PR_Write returned [n=-1] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: nsSocketOutputStream::AsyncWait [this=65d6bf8] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: STS poll iter [0] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: active [4] { handler=2345d60 condition=0 pollflags=5 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: active [3] { handler=77c9de0 condition=0 pollflags=5 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: active [2] { handler=65d6b40 condition=0 pollflags=6 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: active [1] { handler=77cb040 condition=0 pollflags=5 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: active [0] { handler=77cb820 condition=0 pollflags=5 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [8] { handler=667e520 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [7] { handler=5ea9ba0 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [6] { handler=667e280 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [5] { handler=5ea99e0 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [4] { handler=667e1a0 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [3] { handler=5ea9c80 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [2] { handler=5ea9e40 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [1] { handler=5ea9ac0 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: idle [0] { handler=667e0c0 condition=0 pollflags=0 } > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: calling PR_Poll [active=5 idle=9] > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: poll timeout: 400 > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: timeout = 0 milliseconds > 2010-05-18 12:54:32.250000 UTC - 5200[1a2e3c0]: ...returned after 0 milliseconds (2) Here after, all "calling PR_Write [count=4096]" fails. > nsSocketOutputStream::Write [this=65d6bf8 count=4096] > calling PR_Write [count=4096] > PR_Write returned [n=-1] (3) Finally, error occurs. By max retry count? > (Line no = 448144) > 2010-05-18 12:55:36.296000 UTC - 5200[1a2e3c0]: nsSocketOutputStream::Write [this=65d6bf8 count=4096] > 2010-05-18 12:55:36.296000 UTC - 5200[1a2e3c0]: calling PR_Write [count=4096] > 2010-05-18 12:55:36.296000 UTC - 5200[1a2e3c0]: PR_Write returned [n=-1] > 2010-05-18 12:55:36.296000 UTC - 5200[1a2e3c0]: ErrorAccordingToNSPR [in=-5961 out=804b0014] > 2010-05-18 12:55:36.296000 UTC - 5200[1a2e3c0]: nsSocketTransport::OnMsgOutputClosed [this=65d6b40 reason=804b0014] > 2010-05-18 12:55:36.296000 UTC - 5200[1a2e3c0]: nsSocketOutputStream::CloseWithStatus [this=65d6bf8 reason=0] > 2010-05-18 12:55:36.296000 UTC - 5200[1a2e3c0]: nsSocketOutputStream::CloseWithStatus [this=65d6bf8 reason=80470002]

Sarthak(bug opner), can you check server side log around last sussessful "calling PR_Write [count=4096]" of Tb?

SMTP logs before logs for data sending and error. > (73347) 2010-05-18 12:54:28.343000 UTC - 0[1a2e140]: SMTP entering state: 0 > (73349) 2010-05-18 12:54:28.343000 UTC - 0[1a2e140]: SMTP Response: 250 Requested mail action okay, completed > (73351) 2010-05-18 12:54:28.343000 UTC - 0[1a2e140]: SMTP entering state: 6 > (73353) 2010-05-18 12:54:28.343000 UTC - 0[1a2e140]: SMTP Send: DATA > (73821) 2010-05-18 12:54:28.687000 UTC - 0[1a2e140]: SMTP entering state: 0 > (73823) 2010-05-18 12:54:28.687000 UTC - 0[1a2e140]: SMTP Response: 354 Start mail input; end with <CRLF>.<CRLF> > (73825) 2010-05-18 12:54:28.687000 UTC - 0[1a2e140]: SMTP entering state: 7 > (73834) 2010-05-18 12:54:28.687000 UTC - 0[1a2e140]: SMTP entering state: 8

Logs like next is seen(60 is added when authentication etc.). So, mailnews.tcptimeout is used as expected. > poll timeout: 460 > timeout = 460000 milliseconds > poll timeout: 400 > timeout = 400000 milliseconds However, error is returned by NSPR after 60 seconds. When next occurs and continues because server doesn't return ACK due to sever busy, error is returned from NSPR by max retry count, earlier than Tb's expectation of tcptimeout=400(sec), and the error happens to occur after 60 seconds? > nsSocketOutputStream::Write [this=65d6bf8 count=4096] > calling PR_Write [count=4096] > PR_Write returned [n=-1] If so, Bug 325649 can be explained...

Error log is probably written by next code. http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSocketTransport2.cpp#205 > 205 LOG(("ErrorAccordingToNSPR [in=%d out=%x]\n", errorCode, rv)); As errCode is not written in log, no errorCode is passed to function of ErrorAccordingToNSPR(PRErrorCode errorCode). No log of errCode is fault of caller of ErrorAccordingToNSPR(PRErrorCode errorCode)? "Timeout of 60 seconds" is fault of Tb's SMTP code in errorCode handling? (null, space, ... in this case)

Installed TB 2.0.0.24 to test if issue can be reproduced on all versions. Surprisingly, all the mails with large attachments were transmitted seamlessly. (http://getsatisfaction.com/mozilla_messaging/topics/why_does_tb_3_6_time_out_when_trying_to_send_large_attachments)

Installed TB 2.0.0.24 to test if issue can be reproduced on all versions. Surprisingly, all the mails with large attachments were transmitted seamlessly. Found out few articles on net that suggests the TCP/Socket connection behaviour in TB3.X was changed over 2.X Also check: http://getsatisfaction.com/mozilla_messaging/topics/why_does_tb_3_6_time_out_when_trying_to_send_large_attachments So the assumption of problem with server ACK can be overruled now. Regards, Sarthak

(In reply to comment #16) > Found out few articles on net that suggests the TCP/Socket connection behaviour in TB3.X was changed over 2.X > Also check: (snip) Next post? http://getsatisfaction.com/mozilla_messaging/topics/why_does_tb_3_6_time_out_when_trying_to_send_large_attachments#reply_1921423 http://getsatisfaction.com/mozilla_messaging/topics/why_does_tb_3_6_time_out_when_trying_to_send_large_attachments#reply_1945426 Bug he refers in his comment is : Bug 541367 (issue of "looks hung", not timeout). > So the assumption of problem with server ACK can be overruled now. Really? Above #reply_1921423 states; > This is more like Bug 541367 than the person I worked with yesterday. > However, in this case, even though both sides indicate they support "selective ACK", > I don't see any selective ACKs. This implies that the data stopped getting to the server, > and then when TB attempts retransmissions it gets no response -- until the server responds with RST. Bug 541367 is for bug of router, when server supports dynamic TCP Window size change and when server increases the TCP Window to 128KB exceeding 64KB. I guess it's supported from Tb 3.

(In reply to comment #17) > (In reply to comment #16) > > Found out few articles on net that suggests the TCP/Socket connection behaviour in TB3.X was changed over 2.X > > Also check: (snip) > > Next post? > http://getsatisfaction.com/mozilla_messaging/topics/why_does_tb_3_6_time_out_when_trying_to_send_large_attachments#reply_1921423 > http://getsatisfaction.com/mozilla_messaging/topics/why_does_tb_3_6_time_out_when_trying_to_send_large_attachments#reply_1945426 > Bug he refers in his comment is : Bug 541367 (issue of "looks hung", not > timeout). > > > So the assumption of problem with server ACK can be overruled now. > > Really? > > Above #reply_1921423 states; > > This is more like Bug 541367 than the person I worked with yesterday. > > However, in this case, even though both sides indicate they support "selective ACK", > > I don't see any selective ACKs. This implies that the data stopped getting to the server, > > and then when TB attempts retransmissions it gets no response -- until the server responds with RST. > > Bug 541367 is for bug of router, when server supports dynamic TCP Window size > change and when server increases the TCP Window to 128KB exceeding 64KB. > I guess it's supported from Tb 3. If the problem is with router, why does TB 2.0.0.24 sends the mail without any problem. <Please see the new trace attached>

Michael A. Pasek, who is comment poster of #reply_1921423, was who analyzed phenomenon of Bug 541367 (See bug 541367 comment #17). Sadly, I couldn't understand RST in that bug... CC-ing to Michael A. Pasek. Can you help us? (In reply to comment #18) > If the problem is with router, why does TB 2.0.0.24 sends the mail without any > problem. <Please see the new trace attached> Who said this bug is router problem? I merely said that bug Bug 541367 is for router's problem when both server and client supports dynamic TCP Window size and the size is increased to 128KB exceeding 64KB. I guess common thing between Bug 541367 and this bug is dynamic TCP Window size, because I guess it's supproted from Tb 3. Sarthak, can you read TCP trace? Can you understand TCP packet for Dynamic TCP Window size, Selective ACK, RST etc.?

(In reply to comment #19) > Michael A. Pasek, who is comment poster of #reply_1921423, was who analyzed > phenomenon of Bug 541367 (See bug 541367 comment #17). > Sadly, I couldn't understand RST in that bug... > > CC-ing to Michael A. Pasek. Can you help us? > > (In reply to comment #18) > > If the problem is with router, why does TB 2.0.0.24 sends the mail without any > > problem. <Please see the new trace attached> > > Who said this bug is router problem? I merely said that bug Bug 541367 is for > router's problem when both server and client supports dynamic TCP Window size > and the size is increased to 128KB exceeding 64KB. > I guess common thing between Bug 541367 and this bug is dynamic TCP Window > size, because I guess it's supproted from Tb 3. > Sorry, I didn't mean to offend you, I understand the Dynamic TCP window sizing behaviour and its implementation from TB3, however, is it possible to override/disable this feature to make it work like TB2? > Sarthak, can you read TCP trace? Can you understand TCP packet for Dynamic TCP > Window size, Selective ACK, RST etc.? Well, I am afraid I may am not very well versed in understanding TCP parameters. The best I can do is to give you o/p from Wireshark or Fiddler. Please let me know if required Regards, Sarthak

(In reply to comment #20) > is it possible to override/disable this feature to make it work like TB2? Before answer. Dynamic TCP Window size and Selective ACK was independent. IFAIK, there is no option of Tb to control behaviour around Dynamic TCP Window size nor Selective ACK. Can you check "Selective ACK" is supported and enabled by you SMTP server? Can you check with SMTP server's Selective ACK disabled if enabled? > http://www.opalsoft.net/qos/TCP-90.htm > http://www.networksorcery.com/enp/protocol/tcp/option005.htm By the way, although I'm suspecting "no Selective ACK/no RST for Tb" like #reply_1921423, I can say nothing about which kind of issue; (1) Server doen't send Selective ACK nor RST (2) Selective ACK and/or RST doesn't arrive at PC on which Tb is runnning (3) Selective ACK/RST is not properly passed to Tb (3) Tb looses Selective ACK/RST

(In reply to comment #9) > (In reply to comment #8) > > Guess not (not sure though) > > As per the blog http://ipv6blog.net/does-my-computer-have-ipv6-enabled/ > > pinged ::1 > > > > C:\Documents and Settings\samoghe>ping ::1 > > Ping request could not find host ::1. Please check the name and try again. > > > > Should that be a problem? > > Installed Microsoft TCP/IP version 6. The ping works now > C:\Documents and Settings\samoghe>ping ::1 > > Pinging ::1 with 32 bytes of data: > > Reply from ::1: time<1ms > Reply from ::1: time<1ms > Reply from ::1: time<1ms > Reply from ::1: time<1ms > > Ping statistics for ::1: > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > Minimum = 0ms, Maximum = 0ms, Average = 0ms Just FYI, Oracle Beehive does not support IPv6 Meanwhile I am trying to get ans to whether Beehive server supports SACK or not

FYI. Following were found by Google Search. > http://technet.microsoft.com/en-us/library/cc739819(WS.10).aspx > Appendix A: TCP/IP Configuration Parameters (Windows 2003 server) > http://technet.microsoft.com/en-us/library/cc775859(WS.10).aspx > SackOpts (Windows 2003 server) > http://technet.microsoft.com/en-us/library/cc938200.aspx > SackOpts (Windows 2000 server) If Windows server, SACK looks to be killed by Windows registory setting. Possibly controlable at OS level or network setting level if Linux.

FYI. If Linux, SACK looks to be controlled by /proc/sys/net/ipv4/tcp_sack. > http://www.linuxdocs.org/HOWTOs/Adv-Routing-HOWTO-12.html > http://lartc.org/lartc.html

FYI. Top one by Google search for "Linux bug SACK". > https://bugzilla.redhat.com/show_bug.cgi?id=205966 If Linux, is server OS sufficiently new?

FYI. SACK is possibly disabled at client side. > http://www.speedguide.net/read_articles.php?id=157 > Windows 2k/XP Registry Tweaks > http://fasterdata.es.net/TCP-tuning/linux.html > Linux TCP Tuning Following is a part of above Linux TCP Tuning. Is your SMTP server's max TCP Window size of dynamic TCP Window > 20 MB? > And finally a warning for both 2.4 and 2.6: for very large BDP paths where the TCP window is > 20 MB, > you are likely to hit the Linux SACK implementation problem. > If Linux has too many packets in flight when it gets a SACK event, > it takes too long to located the SACKed packet, and you get a TCP timeout and CWND goes back to 1 packet. > Restricting the TCP buffer size to about 12 MB seems to avoid this problem, > but clearly limits your total throughput. Another solution is to disable SACK.

(In reply to comment #26) > FYI. > SACK is possibly disabled at client side. > > http://www.speedguide.net/read_articles.php?id=157 > > Windows 2k/XP Registry Tweaks > > http://fasterdata.es.net/TCP-tuning/linux.html > > Linux TCP Tuning > > Following is a part of above Linux TCP Tuning. Is your SMTP server's max TCP > Window size of dynamic TCP Window > 20 MB? > > And finally a warning for both 2.4 and 2.6: for very large BDP paths where the TCP window is > 20 MB, > > you are likely to hit the Linux SACK implementation problem. > > If Linux has too many packets in flight when it gets a SACK event, > > it takes too long to located the SACKed packet, and you get a TCP timeout and CWND goes back to 1 packet. > > Restricting the TCP buffer size to about 12 MB seems to avoid this problem, > > but clearly limits your total throughput. Another solution is to disable SACK. Changed the TCP parameters as per http://www.speedguide.net/read_articles.php?id=157 on my local m/c (Couldn't find the SackOpts parameter so manually added the dword value) TB3.1b2 still throws Timeout.

(In reply to comment #27) > Changed the TCP parameters as per (snip) on my local m/c > TB3.1b2 still throws Timeout. Did you re-boot your PC? Such option requires re-boot in many cases. > (Couldn't find the SackOpts parameter so manually added the dword value) I also couldn't find SackOpts in Windows regstry of my Win-XP SP3. As Microsoft's Web pages refer to Windows Server only, SackOpts possibly doesn't work on client MS Win, or it's possibly option for data receiver side(i.e. SMTP servr side).

(In reply to comment #28) > (In reply to comment #27) > > Changed the TCP parameters as per (snip) on my local m/c > > TB3.1b2 still throws Timeout. > > Did you re-boot your PC? Such option requires re-boot in many cases. Yes, I did reboot the m/c after every registry change > > > (Couldn't find the SackOpts parameter so manually added the dword value) > > I also couldn't find SackOpts in Windows regstry of my Win-XP SP3. As > Microsoft's Web pages refer to Windows Server only, SackOpts possibly doesn't > work on client MS Win, or it's possibly option for data receiver side(i.e. SMTP > servr side). As I said earlier, since my company is supporting only Tb 2.x for now, and since it is working with TB 2.0.0.24, may be hard to justify the case to change any parameter on production SMTP server

(In reply to comment #19) > [...] > CC-ing to Michael A. Pasek. Can you help us? > [...] My apologies for not commenting sooner. Yes, this certainly has all the symptoms of one case I analyzed in bug 541367. In that particular case, it was a problem with the router -- apparently TB3's ability to send large TCP windows "overwhelmed" the router's internal buffer. TB2 and OE did not have the problem because they would never have that much unacked data outstanding (apparently unable to transmit as quickly as TB3). It should also be noted in that case that TB3 had no problem sending the same email to an SMTP server (mine) that only allowed a 16KB TCP window size (which then did not overrun the router's buffer). I do not know whether the Selective ACK option has any bearing on the TCP timeout. For the other cases in bug 541367, packet captures were only available from the client end of the connection, so it was not possible to determine if the (re)transmitted data _was_ being received by the server. I would say that the problem is due to a TCP retransmission timeout (approximately 60 seconds) due to either: a) Packets transmitted by TB not being received by the SMTP server; or, b) Acknowledgements for those packets not being received by TB. 'tcpdump' or Wireshark captures -- from both ends of the connection (i.e., at the client and at the SMTP server) -- would conclusively identify whether the client (TB) or server is at fault; note that the problem COULD be caused by an intermediate network component (such as the router noted in bug 541367).

F You&Me I. > http://www.tcpipguide.com/free/t_TCPSegmentRetransmissionTimersandtheRetransmission.htm > http://support.microsoft.com/kb/170359 I looks that TCP retransmission timeout can be controlled by Windows registry setting. Michael A. Pasek, is check with larger TcpMaxDataRetransmissions(number of times TCP retransmits an individual data segment) meaningful?

(In reply to comment #31) > Michael A. Pasek, is check with larger TcpMaxDataRetransmissions(number of > times TCP retransmits an individual data segment) meaningful? It was not, in the cases I have seen; the sessions failed due to lack of ack (retransmissions were attempted). You could try increasing the MaxRetrans value, although I suspect it will not help.

Hi, Any update/fix for the issue. I tried using my notebook over LAN (instead of WLAN) but the issue persists.

(In reply to comment #32) > You could try increasing the MaxRetrans value, although I suspect it will not help. I also guess that retry related setting change won't resolve problem. Another thing I wanted to ask you was; If timeout of 60 sec, 120 secc, 180 sec etc. is observed by TcpMaxDataRetransmissions=5, 10, 15 or increased MaxRetrans, will it help diagnosis?

Hi team, Assuming if it is a problem with router, its not feasible for someone to replace the h/w. Can you please provide a build/patch that can benefit by using the send mail api/logic of TB 2.0.X, in case the 3.X fails? (As I am sure many people must be/will suffer from same problem) Regards, Sarthak

(In reply to comment #35) > Assuming if it is a problem with router, (snip) Please never misunderstand comments from helpers again. No one says that your problem is router problem. Michael A. Pasek(and me) merely says that cause of problem of Bug 541367 was router's bug. Sarthak, what Michael A. Pasek asked you to provide for his effective diagnosis is; (what he requested you in comment #30) > 'tcpdump' or Wireshark captures -- from both ends of the connection (i.e., at the client and at the SMTP server) Can you provide such data for his effective/efficient problem analysis of this bug? Or you can't get such data? Or you are not permitted to open such data to outside of your company? Or you are simply rejecting request by Michael A. Pasek?

(In reply to comment #34) > I also guess that retry related setting change won't resolve problem. Another > thing I wanted to ask you was; If timeout of 60 sec, 120 secc, 180 sec etc. is > observed by TcpMaxDataRetransmissions=5, 10, 15 or increased MaxRetrans, will > it help diagnosis? It would only confirm that the problem is caused by some TCP transmission problem (either the packets aren't getting there, or the acks aren't getting back). (In reply to comment #36) > > 'tcpdump' or Wireshark captures -- from both ends of the connection (i.e., at > the client and at the SMTP server) > > Can you provide such data for his effective/efficient problem analysis of this bug? [...] 'tcpdump' or Wireshark captures -- at least from the Thunderbird client side -- would confirm/refute the TCP-transmission-problem theory. If that theory is sustained, then a simultaneous capture from the SMTP server end would allow isolation of the problem to: a) the client (Thunderbird, or more appropriately, the OS TCP stack); b) the SMTP server (or OS TCP stack); or, c) some piece of network equipment between the client and the server (e.g., a router).

(In reply to comment #37) > (In reply to comment #34) > > I also guess that retry related setting change won't resolve problem. Another > > thing I wanted to ask you was; If timeout of 60 sec, 120 secc, 180 sec etc. is > > observed by TcpMaxDataRetransmissions=5, 10, 15 or increased MaxRetrans, will > > it help diagnosis? > > It would only confirm that the problem is caused by some TCP transmission > problem (either the packets aren't getting there, or the acks aren't getting > back). > > (In reply to comment #36) > > > 'tcpdump' or Wireshark captures -- from both ends of the connection (i.e., at > > the client and at the SMTP server) > > > > Can you provide such data for his effective/efficient problem analysis of this bug? [...] > > 'tcpdump' or Wireshark captures -- at least from the Thunderbird client side -- > would confirm/refute the TCP-transmission-problem theory. If that theory is > sustained, then a simultaneous capture from the SMTP server end would allow > isolation of the problem to: > a) the client (Thunderbird, or more appropriately, the OS TCP stack); > b) the SMTP server (or OS TCP stack); or, > c) some piece of network equipment between the client and the server (e.g., a > router). Hi Michael, WADA, Please do not misinterpret my words as allegations. With my limited knowledge over the subject, I may have misunderstood your comments and was merely looking for a workaround. Please be advised that this was by no means anything against you or your suggestions. For the Wireshark trace, I can only capture it from my client m/c. I did that and can see a lot of "Bad TCP" responses.However, being a corporate a/c, I may not able to publish publicly the dump as it contains a lot of sensitive information. Michael, if you can provide me with your email id, I would like to send it to you in trust. Regards, Sarthak

Email address provided "offline".

Analysis of traffic capture from TB side shows client gets 128KB (approximately) ahead of 'acks' from SMTP server. TB has filled the available TCP window, so quits transmitting. A number of 'acks' are received from the server, all with the same (128KB behind) sequence number. TB retransmits from that sequence number for 60 seconds, with no responses of any kind from the server -- resulting in TCP retransmission timeout. Suggested Sarthak try: 1) A different SMTP server with a smaller TCP window size; 2) Connecting "outside" his local router, if possible; 3) Ensuring router firmware is "latest & greatest"; and, 4) Doing simultaneous packet capture at TB and SMTP server ends.

(In reply to comment #40) > Analysis of traffic capture from TB side shows client gets 128KB > (approximately) ahead of 'acks' from SMTP server. TB has filled the available > TCP window, so quits transmitting. A number of 'acks' are received from the > server, all with the same (128KB behind) sequence number. TB retransmits from > that sequence number for 60 seconds, with no responses of any kind from the > server -- resulting in TCP retransmission timeout. Suggested Sarthak try: > 1) A different SMTP server with a smaller TCP window size; > 2) Connecting "outside" his local router, if possible; > 3) Ensuring router firmware is "latest & greatest"; and, > 4) Doing simultaneous packet capture at TB and SMTP server ends. Hi Michael, I configured Gmail SMTP and could send every mail successfully. I am trying to get the latest firmware for the ADSL modem. However capturing n/w trace from the corporate server is not possible Regards, Sarthak

I may sound a desperate, but can there be a solution within TB 3.X that can emulate the SMTP behaviour of TB 2.X and send msgs with small selective TCP window Regards, Sarthak

(In reply to comment #41) > I configured Gmail SMTP and could send every mail successfully. The success could be for many reasons, but the fact that it DOES work means the problem really doesn't have anything to do with the attachment or SSL. > I am trying to get the latest firmware for the ADSL modem. Having the latest firmware will certainly ensure that the known bugs of some routers (I don't know which routers have the bugs) can be eliminated as a source of the problem. This is not to say that the problem is not caused by an unknown (or unacknowledged) bug in those routers (as in the case of the Linksys WRT54G). > However capturing n/w trace from the corporate server is not possible That's too bad; it could help isolate the failing network component(s). (In reply to comment #42) > I may sound a desperate, but can there be a solution within TB 3.X that can > emulate the SMTP behaviour of TB 2.X and send msgs with small selective TCP > window This would most likely be something that would be configured in the OS's TCP stack. Probably what you want to do is limit the "TCP Send Space" (in Unix terms) to be 65KB (or less). With that limitation, it would be impossible for TB to send more than 65KB of unacknowledged data (and prevent what I assume to be a router buffer overrun).

FYI. Correct name seems "TCP window scale option" or "TCP Window Scaling". (a) http://en.wikipedia.org/wiki/Ethernet (b) http://en.wikipedia.org/wiki/TCP_window_scale_option (c) http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx Follwing is linked document by (b). (d) http://support.microsoft.com/kb/934430 (expnad "More Information" section) Because Vista enabled "TCP Window Scaling" as receiver side by default, similar problem to bug 541367 comment #17 looks to have happened with many routers. I could find option to control "TCP Window Scaling" as receiver side(SMTP server in this bug) which limits maximum size in "TCP Window Scaling" or disables "TCP Window Scaling" itslef. (d) http://msdn.microsoft.com/en-us/library/ms819736.aspx However, I coun't find sender side(client side, Win-XP/Tb in this bug) option to ignore "TCP Window Scaling" by receiver side(reject upon negosiation) or to limit maximum TCP Window size in sending when server uses "TCP Window Scaling". TcpWindowSize=64KB at client side may be a option for such limitation, but I'm not sure.

Correction. Sorry for spam. (a) http://en.wikipedia.org/wiki/Internet_Protocol_Suite I found a web page titled "TCP window scaling and broken routers" in hit pages by Google Search for "TCP Window Scaling". (e) http://lwn.net/Articles/92727/ It's originally [Posted July 7, 2004]. It seems old and well known problem still alives. Some peoples write "setting for workaround", but I can't know it's server side setting or client setting and it's effective or not.

(In reply to comment #45) > [...] > (e) http://lwn.net/Articles/92727/ > [...] The bug noted in this article would cause decreased performance -- but would not allow a window size greater than 65KB. Limiting window size on the sender side will not have any effect, as that will only control what the OTHER end can send (i.e., the SMTP server). If window-scaling can be disabled entirely on the TB side, that should prevent the problem. Another option would be, as noted in comment 43, to limit "send space" (the amount of memory allocated to hold unacknowledged data) to 65KB. I don't know how to do that on Windows systems, but in FreeBSD it would be: sysctl -w net.inet.tcp.sendspace 65536 According to http://www.cromwell-intl.com/security/security-stack-hardening.html, the Linux kernel dynamically adjusts the send/receive space, so it probably can't be "forced" to be < 65KB.

Hi, Sorry for not updating to this bug. Just FYI, I have moved to a different country now, but the SMTP mail send is timing out from office as well as home. This might rule out any possible problem with router or n/w. Since the server is behaving normally with Outlook and Web Interface, can it be possibly be a problem with my OS/TB? Regards, Sarthak

(In reply to comment #47) > [...] > This might rule out any possible problem with router or n/w. Or not. The extensive testing/analysis done for Bug 541367 showed that large emails that failed to one SMTP server would work when using a different SMTP server that did NOT allow the use of large TCP window sizes (and, therefore, would not hit the router bug). It's very possible that the router with the problem is at the SMTP server site; you could move all over the world and never "fix" the problem. > Since the server is behaving normally with Outlook and Web Interface, can it be > possibly be a problem with my OS/TB? Unlikely that it would be a problem with the OS, but that's certainly possible. As noted above, it is unlikely to be a problem with TB; try sending the same email via a different server -- one that does NOT allow TCP window sizes greater than 65KB. Of course, the Web Interface can only send as much data at a time as allowed by the HTTP server; Outlook probably sends data slow enough that it never gets far enough ahead (i.e., 128KB) to cause the problem. Have you tried disabling TCP Window Scaling ? Depending on your OS/version, the following may prove useful: http://www.ecr6.ohio-state.edu/window-scaling.html

I still can't find MS Win's setting around TCP Window Scaling as sender side nor "TCP send space / TCP receive space", but I could find (a) Mozilla's settig of network.tcp.sendbuffer(default looks icreased to 131072 by Tb 3.0), and (b) MS Win's setting of default Winsock send buffer size(at KB, search for "send buffer" was required). (a) network.tcp.sendbuffer > https://bugzilla.mozilla.org/show_bug.cgi?id=454990 ([fixed1.9.1b3]) > network.tcp.sendbuffer = 131072 Decreasing 64KB or 32KB may change phenomenon of this bug. No problem with Tb 2 may be a result of smaller default of this parm. (b) default Winsock send buffer size > http://support.microsoft.com/kb/950326 > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters. Increasing of the size of workaround of KB 950326, so decreasing of it may be a workaround of this bug. Sarthak, can you check with network.tcp.sendbuffer=65536 or 32768 of Tb as sender side of TCP Window Scaling?

FYI. http://proj.sunet.se/E2E/tcptune.html MS Win doesn't look to permit easy control of TCP related setting by user. http://www.psc.edu/networking/projects/tcptune/ http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm The window size advertised by the receiver is just an upper bound. The sender increases the size of the transmit window slowly, and uses packet loss as the indication that the transmit window is too big. TCP doesn't took to prohibit sender's use of larger TCP Window size than advertized TCP Window size by TCP Window Scaling at server(receiver side). (Note: above statements is for 'Don't increase window size to advertized upper bound too fast. Increase window size slowly with checking real packet loss".)

(In reply to comment #49) > I still can't find MS Win's setting around TCP Window Scaling as sender side > nor "TCP send space / TCP receive space", but I could find (a) Mozilla's settig > of network.tcp.sendbuffer(default looks icreased to 131072 by Tb 3.0), and (b) > MS Win's setting of default Winsock send buffer size(at KB, search for "send > buffer" was required). > > (a) network.tcp.sendbuffer > > https://bugzilla.mozilla.org/show_bug.cgi?id=454990 ([fixed1.9.1b3]) > > network.tcp.sendbuffer = 131072 > Decreasing 64KB or 32KB may change phenomenon of this bug. > No problem with Tb 2 may be a result of smaller default of this parm. > > (b) default Winsock send buffer size > > http://support.microsoft.com/kb/950326 > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters. > Increasing of the size of workaround of KB 950326, so decreasing of it may be a > workaround of this bug. > > Sarthak, can you check with network.tcp.sendbuffer=65536 65536 or 32768 of Tb as I changed the network.tcp.sendbuffer to 65536 and now can send mails with big attachments. Thanks all for your unconditional assistance. I really appreciate it! > sender side of TCP Window Scaling?

As server looks to have advertized 128KB as TCP Window Size by TCP Windows Scaling, there is no error like packet loss or huge delay for server(receive side). As next document says, advertized TCP Window Size is merely upperbound. > http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm > The window size advertised by the receiver is just an upper bound. Michael A. Pasek, should client(sender side) increase TCP Window size slowly with watching real packet loss or delay or re-transmission?

(In reply to comment #52) > Michael A. Pasek, should client(sender side) increase TCP Window size slowly > with watching real packet loss or delay or re-transmission? The TCP window size in question is "advertised" by the receiver (the SMTP server), and indicates how much data the sender (Thunderbird) can send. There is a corresponding TCP window size "advertised" by TB indicating how much data the server can send -- but since the server sends very little data, it can be ignored (i.e., it is not relevant to this problem). Yes, there is a "send window" (I don't remember the correct technical term, but that's close enough) that starts at 1 packet and slowly increases as packets are acknowledged by the receiver. The window should "close down" as packets are lost or not acknowledged, but the algorithms controlling this behaviour are complex -- and I don't remember how they're supposed to work without re-reading the RFCs numerous times while examining the data to see if it is following the RFCs correctly. The idea, though, is to keep the network "pipe" as full as possible, without overrunning it or causing congestion. Suffice it to say that while Sarthak has worked around the problem by changing a Thunderbird parameter, this is NOT a Thunderbird problem; it is a problem in either: a) the underlying OS's TCP stack; b) a network component somewhere between TB and the SMTP server; c) a problem in the TCP stack of the SMTP server's OS; or, d) a problem in the SMTP server software's implementation.

Michael A. Pasek, SSL/TLS(or StartTLS) or not is relevant to this kind of problem with Tb3? I guess that OS which is used by SMTP/IMAP/POP3/HTTP(S) server who supports SSL/TLS, is merely relatively newer(supports TCP Window Scaling by default, default of MaxTCPWindowSize is 128KB or larger) than OS which is used by server who doesn't support SSL/TLS.

SSL/TLS is not relevant to this problem; in other words, it is the same problem as Bug 541367.

This bug will be closed as INVALID because not Tb's problem. Changing to NEW for a while, for ease of search.

Time to close?