close
Comments you submit will be routed for moderation. If you have an account, please log in first.
Modify

Opened 8 months ago

Last modified 4 weeks ago

#530 accepted bug

Initialize TLSv1/SSLv3 session error during "GetMail"

Reported by: stellan Owned by:
Priority: high Milestone: YAM 2.10
Component: TCP/IP interface Version: nightly build
Severity: major Keywords:
Cc: opiopi, chzigotzky@…, supernobby, JosDuchIt OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Using YAM.debug 2.10-dev [OS3/m68k, date 16.02.2014 (build 20140216)

I`ve two active email accounts and when I click on "Get" I get initialize SSL errors. If I do "Check single account" most times I get the same error but somtimes it works. I guess that the slow internet connection (56k modem) might be responsilbe for this. At least if e.g. IBrowse is downloading something I always get the error.

Attached are debug logs (Yam_SSL_Error.txt and Yam_SSL_Works.txt) where I get the error and when it works. If I need to change debug flags/classes for the lop, please let me know.

Attachments (17)

GetMail_logs.lha (4.0 KB) - added by stellan 8 months ago.
2 debug logs
newLog.lha (2.0 KB) - added by stellan 8 months ago.
New log
SSL_21.02.14_log (2.1 KB) - added by stellan 8 months ago.
Log_25.02.14.lha (2.2 KB) - added by stellan 8 months ago.
Yam&SnoopDos_log.lha (3.2 KB) - added by stellan 8 months ago.
SnoopDos.log (17.5 KB) - added by opiopi 8 months ago.
GetMails.rexx (137 bytes) - added by opiopi 8 months ago.
YAM-getMailsLog-ed.txt (31.3 KB) - added by opiopi 8 months ago.
YAM-Debug-16.03.2014.txt (33.4 KB) - added by opiopi 7 months ago.
tcp-ip_settings.lha (38.3 KB) - added by stellan 6 months ago.
screenshots
YAM-Debug.log-11.05.2014.txt (15.9 KB) - added by opiopi 6 months ago.
YAM-Console.log-11.05.2014.txt (379 bytes) - added by opiopi 6 months ago.
Yam_Getmail.txt (13.6 KB) - added by stellan 5 months ago.
new
YAM-Debug.log-25.05.2014.txt.ED.txt (18.7 KB) - added by opiopi 5 months ago.
yam_debug_2014-06-12_winuae_fast.txt (14.6 KB) - added by supernobby 5 months ago.
sending mail worked
yam_debug_2014-06-12_amiga.txt (6.7 KB) - added by supernobby 5 months ago.
sending mail failed
Certificate.rtf (36.4 KB) - added by JosDuchIt 4 weeks ago.

Download all attachments as: .zip

Change History (111)

Changed 8 months ago by stellan

2 debug logs

comment:1 Changed 8 months ago by damato

In 7728:

  • tcp/ssl.c: added some more debug output to the SSL connection routines to be able to better debug problematic situations. This refs #530.

comment:2 Changed 8 months ago by damato

Thanks for the nice debug logs. Unfortunately the debug logs don't contain all required information, so I added some more debug output which will be available with the next nightly build (17.02.2014). So please wait for the next nightly build to appear and then rerun your tests and attach the debug log again to this ticket.

In addition, please state which TCP/IP stack you are using on OS3/m68k.

Changed 8 months ago by stellan

New log

comment:3 in reply to: ↑ description Changed 8 months ago by stellan

I`ve add the debug log from the new nightly build. The image warnings in the log are removed by me. TCP/IP stack is MiamiDx.

comment:4 Changed 8 months ago by damato

Thanks for the new log file. Unfortunately, this log doesn't reveal any new information. So I had to add more debug output to YAM. So please wait for the next nightly build to appear and retry again and submit that log here again.

comment:5 Changed 8 months ago by stellan

Attached the new log (nightly build form 20.02.2014). I fear there still isn`t enough info in the log.

Changed 8 months ago by stellan

comment:6 Changed 8 months ago by damato

Thanks for the log again. In fact, it has some slightly more information which seems to point at least the finger at your currently used TCP/IP Stack -> MiamiDX. To better understand the reasonings for the issue, I just added some more debug information. So please download the upcoming nightly build again and send in the debug log again. This version then hopefully provide some final information why exactly parallel downloads seem to not work for you.

In addition, please answer the following questions so that we better understand what exactly are you doing to reproduce the problem:

  1. Does the problem also occur if you force yam to download from one account only (via the menu)? Please test even fast/many executions of a single download from one gmx account only.
  2. Have you tried to download from two different servers as well? In your current configuration you are initiating two parallel downloads from the same server (gmx.de). So do you have another account somewhere else (e.g. web.de) which you might test? Reason might be that gmx only allows one single connection at a time.
  3. Does the error immediately occur or is there some time delay between yam trying to connect to the gmx server and the error message? That would point at some timeout being executed.

Changed 8 months ago by stellan

comment:7 Changed 8 months ago by stellan

Attached new log.

  1. Yes it can also happen when download from on account (that is the way I`m using). Further, it can also happen when sending emails. I mentioned this already.
  1. I dont have another account to test. But the problem isnt restricted to seriell or parallel download. I don`t think that gmx only allows one single connection at a time.
  1. In the "progress window" I can see what happens and how long (appox) each part (connect to mail server, inizialize TLSv1/SSLv3 session) takes. My subjective feeling is that the error occurs when it takes too much time. The internet connection speed here (I don`t know why) is variable (e.g. while downloading the yam.debug archive IBrowse shows sometimes 0cps to 2000cps and it goes like a sawtooth diagram up and down but sometimes there is a straight ~4000cps). That is the reason why I guess that at slow speed the error happens. So a timeout makes sense to me.

Seldom: Connection fails already when connect to mail server.

With Yam 2.5 and GMX ther weren`t any problems. Only since GMX changed SSL connection.

comment:8 Changed 8 months ago by damato

Thanks again for the log file. In fact, after having done some analysis and research on the internet I would like to ask you to create another log file and at the same time also generate a SnoopDOS log file because the log you catches points the finger at some file access problems AmiSSL might be having (e.g. with the random number generator).

So please rerun your tests and catch a SnoopDOS log at the same time. Then please upload both log file again here. Thanks in advance.

comment:9 Changed 8 months ago by tboeckel

A bit off-topic regarding this ticket, but there are some messages in the debug log which should be handled by you:

00:E: YAM.c:575:error on XpkQuery() of packer 'BLZW': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'CRMS': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'DMCB': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'ILZR': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'LHLB': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'NUID': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'PWPK': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'RDCN': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'SASC': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'SHID': 'Kann benötigte XPK Library nicht finden'
00:E: YAM.c:575:error on XpkQuery() of packer 'SHSC': 'Kann benötigte XPK Library nicht finden'

Check your XPK setup. Several compression modules are definitely not working correctly.

00:W: Config.c:3629:cannot resolve incoming folder ID 0x46012149 of POP3 server 'Stellan'
00:W: Config.c:3629:cannot resolve incoming folder ID 0x46012149 of POP3 server 'StellanInDerMailingListe'
00:W: Config.c:3629:cannot resolve incoming folder ID 0x46012149 of POP3 server 'N/A blakkhar nwn'
00:W: Config.c:3629:cannot resolve incoming folder ID 0x46012149 of POP3 server 'N/A stellan nwn'
00:W: Config.c:3629:cannot resolve incoming folder ID 0x46012149 of POP3 server 'N/A 1&1'

Check the Incoming folders of all configured POP3 servers. Some servers seem to use an Incoming folder which does not exist in your configuration.

comment:10 follow-ups: Changed 8 months ago by stellan

Yam log and SnoopDOS log are attached. SnoopDOS log starts with hit on yam`s "Get" button.

I noticed the access to ENV:AmiSSL/SSL_CLIENT_VERSI0N in the SnoopDOS log. Some days ago Ive created the env var. It seems Yam dont get the var. Envhandler should "copy" the var to ENV: if a programm tries to access it.

Thanks for the hits Thore!

I noticed the xpk messages in the log. The loged packer dont work since ages here. I had a look. They seem to be corrupt (no/wrong header, no description). I copied new LHLB but didnt helped (might be need lh.library as well?). I guess I can delete the faulty packer if they aren`t required by something?

incoming folder logs:
All accounts had an empty incoming folder setting (changed now). Nevertheless new messages are stored to incoming folder. I guess the empty incoming folder setting is a result of loading/converting yam2.5 .config to yam2.9.

Changed 8 months ago by stellan

comment:11 in reply to: ↑ 10 Changed 8 months ago by tboeckel

Replying to stellan:

I noticed the xpk messages in the log. The loged packer dont work since ages here. I had a look. They seem to be corrupt (no/wrong header, no description). I copied new LHLB but didnt helped (might be need lh.library as well?). I guess I can delete the faulty packer if they aren`t required by something?

I cannot tell if it is save to delete them. Only you can know if you used one of these compressions libs for anything.

comment:12 in reply to: ↑ 10 Changed 8 months ago by damato

  • Resolution set to worksforme
  • Status changed from new to closed

Replying to stellan:

Yam log and SnoopDOS log are attached. SnoopDOS log starts with hit on yam`s "Get" button.

I am sorry Stellan, but I am totally out of ideas why SSL connections behave so strange on your installation of YAM and AmiSSL. The log files you supplied don't really explain why the connections fail. So the only guess that is left is that it must have something todo with your slow internet connection. To verify that you would have to connect your Amiga to a faster connection and see if the problems are gone. So, I am sorry, but I have to close that ticket for the time being until you can provide more hints or test connectivity with a faster internet connection.

I noticed the access to ENV:AmiSSL/SSL_CLIENT_VERSI0N in the SnoopDOS log. Some days ago Ive created the env var. It seems Yam dont get the var. Envhandler should "copy" the var to ENV: if a programm tries to access it.

This env variable is completely harmless and not required for AmiSSL to perform correctly. So either it is really your internet connection or some shortcoming/bug in MiamiDX, I am afraid.

comment:13 Changed 8 months ago by opiopi

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Hi
I reopen this bug because i have the exactly the same problems like Stellan since YAM use threads for get mails. As workaround i use an Arexx script using 'Mailcheck pop xx' in a loop for getting mails.
I have here a fast DSL connection, so Stellan's slow connection can't be the cause.
I have 8 Mail accounts e.g. yahoo.de, web.de, gmx.net, arcor.de and some more. So using only one mail provider can't be the cause.

I just had a short look at the file ssl.c and my guess is that the MakeSecureConnection() function is not really thread save. Maybe it helps to put all used local variables (e.g. the variable 'res') for the connection to the struct Connection?
It may be possible that the current implementation works for you because it seems your computer are a little bit faster as our computers. ;-)

comment:14 Changed 8 months ago by damato

  • Cc opiopi added
  • Milestone set to YAM 2.9p1
  • Priority changed from undecided to high
  • Status changed from reopened to accepted

Hi Frank,

thanks for your comments. Good to hear that more than one person seem to suffer from that problem. Interesting is also the use of an ARexx script to workaround that problem. Now that more than one person seem to have the same problems I will reinvestigate the issue and schedule it for 2.9p1 to be fixed/analysed.

To better understand the implications can you please

  1. state which TCP/IP Stack you are using
  2. generate a debug output which I can potentially see and compare the error to the one stellan reported so that we can make sure that this is really the same problem.

Regarding the issue itself, I think you had a very good point in mentioning "multithreading" as a keyword. This in fact gave me some hints in where I do have to look at and actually I already found one situation regarding missing OpenSSL function locking which might be the reason for your problems.

However, the locale variables in the function MakeSecureConnection() are perfectly thread-safe. You were mentioning the 'res' variable, but this is a normal local variable without being declared as "static". Only static variable will be a problem regarding thread-safety. But in this case this is not the point.

Nevertheless, as I point out I think I already identified a potential case which might be a reason for suboptimal multithreading when doing multiple SSL connections. I will investigate that shortly and report back then.

comment:15 Changed 8 months ago by stellan

Also thanks from me to you Frank for the comment. :-) Btw. I thought already you left amiga activity.

Do you also get the error when you check a single email account or only if you use the normal "Get"?

Just for information:
Im also using a ARexx script as workaround. Its not really a workaround because I use for two accounts two scripts (start with shortcut) what does similar like "Check single account" via menu. I use "MAILCHECK POP <n> MANUAL". MAILCHECK at least with MANUAL (what I need) dont wait for finish and it always returns 0 or 1 (cant remember 0 or 1). So I didnt found a way to check both accounts via one script but that isnt really a problem because of the SSL error behaviour it is better to check single account. Frank, can you show me your loop (maybe I miss soemthing)?

comment:16 Changed 8 months ago by damato

In 7753:

  • tcp/ssl.c, YAM.c: slightly reworked the AmiSSL initialization part to initialize the library and the global error strings right after opening amissl library and not within the connection process of each thread. This could potentially fix some runtime problems. This refs #530.

comment:17 Changed 8 months ago by damato

As you can see, I have slightly reworked/revised the initialization routines in YAM regarding AmiSSL. So please retry your tests with the next upcoming nightly build. Also please catch again some debug output which might potentially should be more verbose now.

comment:18 Changed 8 months ago by opiopi

Sorry for the late message from me about this issue but i have really much to do in my real life.

I use here Miami DX too. I attach the follow files to this ticket:

  1. a SnoopDos Log while getting mails
  2. a net debug log from YAM
  3. the simple arexx script for getting mails

Maybe the patch from Jens fix this issue. I'll test it on the weekend...

BTW: Do you ever start YAM.debug with Snoopdos running? Here i get over 2000 entries like "YAM.debug GetVar codeset_default Global Fail" :-(

Changed 8 months ago by opiopi

Changed 8 months ago by opiopi

Changed 8 months ago by opiopi

comment:19 Changed 7 months ago by opiopi

No change, i get still the errors with the latest nightly build.
I add a debug log. see also the comment in the first line.

The errors about the images are because the archives doesn't contain contain such images. :-(

Changed 7 months ago by opiopi

comment:20 Changed 7 months ago by damato

  • Milestone changed from YAM 2.9p1 to YAM 2.10

Thanks for the latest debug logs. However, after having studied them I still don't know and don't understand what might actually be the reason why parallel download fails when using SSL connections. As it currently stands the problem boils down to be only existing when using AmigaOS3 in combination with MiamiDX. Other users seem to not be affected by the problem. Even WinUAE users don't seem to have problems.

So I am sorry, but I have to move that ticket to the 2.10 milestone as I currently don't see a way to fix it as I am out of ideas. Perhaps someone with some other information might come up so that we can revisit the issue again later. However, if you have more valuable information for us please don't hesitate to share it with us.

comment:21 Changed 7 months ago by stellan

Just for the record. Here the Initialize TLSv1/SSLv3 session error happens:

  • When try to check single account (often, seems it depends on internet speed)
  • When try to check mutliple accounts (always)
  • When send two mails (always I guess)
  • When send one mail (often, seems it depends on internet speed)

comment:22 Changed 6 months ago by stellan

I read more User have/had the same problem but didnt report it. It seems MiamiDX isnt the only stack with the problem and also under WinUAE it happen. According to this: http://www.amiga-news.de/forum/thread.php?id=35093&BoardID=1#363869

For me, after reading that I changed to STARTTLS and sometimes (yes, sorry) it works more often (check single account) then using SSL/TLS but not always.

comment:23 Changed 6 months ago by damato

In 7825:

  • tcp/Connection.c: added some more debug output to the setsockopt() and getsockopt() function uses to identify potential TCP/IP stack related problems. This refs #530.

comment:24 Changed 6 months ago by damato

Thanks for the links. I read through that forum entry and must say that I am still not convinced that MiamiDX is not the root of the problem and that it should be a general problem. However, to further investigate the issue please do the following:

  1. Provide a screenshot of your TCP/IP settings of all your accounts you have configured (after stripping private information of course)
  2. Please regenerate a recent debug output using the NET debug option with the next upcoming nightly build and attach it to this ticket again like you did in the past. Please try to generate this debug log by trying to trigger the problem with a "single account" only and not by parallel downloads.
  3. Please also try to install plain AmiTCP and try to reproduce the problem with that TCP/IP stack as well.

Changed 6 months ago by stellan

screenshots

comment:25 Changed 6 months ago by stellan

1, 2: Attached
3: AmiTCP 4.0 Demo installed but I dont know (docs didnt helped) how to connect to INet via modem (basic stuff like where to place device, tel.-nr., login user/pass).

comment:26 Changed 6 months ago by tboeckel

I think Jens is a bit too busy at the moment.

The TCP/IP settings look ok. At least they match my own GMX settings.

But the log seems to be a bit malformed and contains garbage characters. This might be a formatting error by YAM which I hopefully fixed recently. So please create a new NET debug log.

comment:27 Changed 6 months ago by opiopi

I do some tests and disable some of my accounts to make the logfile more readable.
The results of my tests:

  1. Yahoo (first account opionline) seems to use a wrong certificate and i click long time ago at "Dauerhaft akzeptieren"
  2. The first Mailaccount is always working, all follow accounts throw a error. Stellan seems to get an error also for the first account.
  3. The console (debug argument) show only the conversation with this first account but i am sure here are more conversation with the other servers.
  4. If i disable the first account and enable another (non yahoo) account all 3 accounts throw an error and the console show nothing.
  5. I add the logs for test 1 here with changed account names and password.

used version: YAM 2.10-dev [OS3/m68k, r7878, GCC 2.95.x] date 11.05.2014 (build 20140511)

comment:28 Changed 6 months ago by opiopi

Beim klicken auf "Datei anhängen" erscheint folgende Seite:

Oops …
Trac hat einen internen Fehler festgestellt:

IndexError: pop from empty list

Es ist ein interner Fehler aufgetreten. Bitte benachrichtigen Sie Ihren Trac-Administrator und fügen Sie eine Beschreibung an, wie der Fehler reproduziert werden kann.

Zu diesem Zweck können Sie auch ein Ticket .

Die Aktion, die den Fehler ausgelöst hat, war:

GET: /attachment/ticket/530/

comment:29 follow-up: Changed 6 months ago by opiopi

Wenn auf der Fehlerseite auf "Ticket erstellen" geklickt wird erscheint folgender Fehler:
Request-URI Too Long

The requested URL's length exceeds the capacity limit for this server.
Apache Server at light-speed.de Port 443

comment:30 in reply to: ↑ 29 ; follow-up: Changed 6 months ago by damato

Replying to opiopi:

Wenn auf der Fehlerseite auf "Ticket erstellen" geklickt wird erscheint folgender Fehler:
Request-URI Too Long

The requested URL's length exceeds the capacity limit for this server.
Apache Server at light-speed.de Port 443

Thanks for the info. This is, however, already known an I am working on it.

comment:31 in reply to: ↑ 30 Changed 6 months ago by damato

Replying to damato:

Replying to opiopi:

Wenn auf der Fehlerseite auf "Ticket erstellen" geklickt wird erscheint folgender Fehler:
Request-URI Too Long

The requested URL's length exceeds the capacity limit for this server.
Apache Server at light-speed.de Port 443

Thanks for the info. This is, however, already known an I am working on it.

Ok, all trac related problems should now be fixed again. Thus you should be able to upload any files to our bug tracker.

comment:32 Changed 6 months ago by tboeckel

In 7880:

  • tcp/Connection.c include the server description in each printed line when running in debug mode. This refs #530.

Changed 6 months ago by opiopi

Changed 6 months ago by opiopi

comment:33 Changed 6 months ago by opiopi

Thx, upload is working again and i just upload the both files.

comment:34 Changed 6 months ago by damato

Thanks for the log files. However, I still don't know exactly why this is happening at all. The only fact that seems to be verified is that this has been reproducible only with the Miami TCP/IP stack. So I would be curious to see you testing a different TCP/IP stack to verify that. So do you have that possibility? If so, please do.

Another thing that I stumbled over the debug log you were attaching is the following:

67      01:D:      Connection.c:266:set SO_KEEPALIVE in socket
68	01:D:      Connection.c:279:set TCP_NODELAY in socket
69	01:D:      Connection.c:292:set IPTOS_LOWDELAY in socket
70	01:D:      Connection.c:305:set SO_SNDBUF in socket
71	01:D:      Connection.c:318:set SO_RCVBUF in socket
72	01:D:      Connection.c:360:set SO_SNDTIMEO in socket
73	01:D:      Connection.c:376:set SO_RCVTIMEO in socket
74	01:D:      Connection.c:387:opened socket 00000000
75	01:D:      Connection.c:393:SO_KEEPALIVE..: 8 [bool]
76	01:D:      Connection.c:397:TCP_NODELAY...: 4 [bool]
77	01:D:      Connection.c:401:IPTOS_LOWDELAY: 1 [bool]
78	01:D:      Connection.c:405:SO_SNDBUF.....: 16384 bytes
79	01:D:      Connection.c:409:SO_RCVBUF.....: 16384 bytes
80	01:D:      Connection.c:413:SO_SNDLOWAT...: 2048 bytes
81	01:D:      Connection.c:417:SO_RCVLOWAT...: 1 bytes
82	01:D:      Connection.c:421:SO_SNDTIMEO...: 100.0 s
83	01:D:      Connection.c:425:SO_RCVTIMEO...: 100.0 s

There are several things that irritate me here:

  1. in line 75 and 76 the SO_KEEPALIVE and TCP_NODELAY value are different from 1 where 0 and 1 should be the only possibilities. I can, however also see from line 67 and 68 that you yam configuration explicitly sets these two options. So can you please show us your socket options line in the [Advanced] part of your configuration?
  1. In addition, in line 80 the SO_SNDLOWAT value seems to be set to 2048 bytes where AFAIR it should be set to 1 bytes like the RCVLOWAT value. Can you also please test if setting that SO_SNDLOWAT value to 1 in your socket options config line in the yam config file? Perhaps that fixes the problem already.

comment:35 follow-ups: Changed 5 months ago by chzigotzky@…

I have the same problem with YAM 2.9p1.

Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server

System: AmigaOS 4.1 Update 6

comment:36 in reply to: ↑ 35 Changed 5 months ago by damato

Replying to chzigotzky@…:

I have the same problem with YAM 2.9p1.

Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server

System: AmigaOS 4.1 Update 6

This is actually the first time I read about that the issue also happens on AmigaOS4.

Are you really sure that your problem is exactly the same problem like reported here? Just because the end-user error message is called the same "Fehler beim Initialisieren..." doesn't mean it is exactly the same. So please go ahead and try to generate some debugging information using the debug version of YAM so that we can verify together that it is exactly the same and then potentially find a way how we (the developers) can reproduce the issue on our own machines if the issue is really happening with OS4 as well.

comment:37 Changed 5 months ago by tboeckel

  • Cc chzigotzky@… added

comment:38 in reply to: ↑ 35 Changed 5 months ago by tboeckel

Replying to chzigotzky@…:

I have the same problem with YAM 2.9p1.

Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server

System: AmigaOS 4.1 Update 6

Sorry for the delay, but apparently you didn't get Jens' first answer. Please reread his comment 35.

comment:39 follow-up: Changed 5 months ago by chzigotzky@…

Some debug information:

** YAM 2.10-dev [OS4/PPC, r7943, GCC 4.9.0] build: 20140516 startup **********************
Exec version: v53.58
01:W:       ssl.c:106:ssl: verify callback @ 1 => 7:'certificate signature failure'
01:W:       ssl.c:147:ssl: Unhandled certification verification error: SSL_CERT_ERR_UNHANDLED
01:E:     ssl.c:842:SSL_connect() returned -1 with SSL_get_error() = 1
01:E:     ssl.c:857:strerror_r(errno=0) failed
01:E:     ssl.c:860:errno(0) = ''
01:E:     ssl.c:863:strerror_r(errnosv=0) failed
01:E:     ssl.c:866:errnosv(0) = ''
01:E:     ssl.c:872:querying ERR_get_error() stack:
01:E:     ssl.c:876:ERR_get_error()=218665121 stack: 'error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm'
01:E:     ssl.c:876:ERR_get_error()=336134278 stack: 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed'
01:D:      YAM_[ER.c:130:pushing ER.c:130:pushing] error 'Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server 'pop3.xxxxxx.ie' von Konto 'XXXXXX'.'
00:D:    YAM_[ER.c:115:added ER.c:115:added] error message #1 'Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server 'pop3.xxxxxx.ie' von Konto 'XXXXXX'.

(20.05.2014 12:31:53)'
00:D:    YAM_[ER.c:162:showing ER.c:162:showing] error message #1 'Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server 'pop3.xxxxxx.ie' von Konto 'XXXXXX'.

comment:40 in reply to: ↑ 39 ; follow-up: Changed 5 months ago by tboeckel

Replying to chzigotzky@…:

Some debug information:

This is exactly the same failure as in #559. There is nothing that YAM can do about this (except ignoring failed certificate checks) as this is the responsibility of AmiSSL. However, it is yet unclear whether both tickets refer to the same problem or if there are differences.

comment:41 in reply to: ↑ 40 Changed 5 months ago by damato

Replying to tboeckel:

Replying to chzigotzky@…:

Some debug information:

This is exactly the same failure as in #559. There is nothing that YAM can do about this (except ignoring failed certificate checks) as this is the responsibility of AmiSSL.

I agree. This is definitely the same problem like in #559 and is related to the point that some providers switched their certificates to use SHA-256 which is not supported in the latest official AmiSSL 3.6 version. However, YAM should also not catch this exception as an error but throw a warning requester instead to allow users to continue instead of aborting the connection altogether.

However, it is yet unclear whether both tickets refer to the same problem or if there are differences.

There are definitely differences and these two issues (#559 and #530) seem not to be connected to each other. For example in https://yam.ch/attachment/ticket/530/YAM-Debug.log-11.05.2014.txt#L163 of this ticket you can see

03:E:     ssl.c:842:SSL_connect() returned 0 with SSL_get_error() = 5

while in ticket #559 you see

01:E:     ssl.c:842:SSL_connect() returned -1 with SSL_get_error() = 1

you see that the error messages are substantially different. However, unfortunatly YAM simply displays the same error message to the end-user instead of differentiating between these two issues.

So in the end we are still at the same state regarding the issue reporting in this ticket:

  • it only seem to happen with MiamiDX

So please, everyone using MiamiDX and having this issue should please try out the points I raised in comment:34 and also please try out a different TCP/IP stack.

comment:42 Changed 5 months ago by damato

In 7976:

  • YAM.c: slightly changed the OpenSSL/AmiSSL initialization and added a call to OpenSSL_add_all_algorithms(). This hopefully improves verbosity of error output and perhaps improves cipher/digest handling. This refs #530 and #559.

comment:43 Changed 5 months ago by opiopi

SocketOptions was set here to:

SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=16384 SO_RCVBUF=16384 SO_SNDTIMEO=100 SO_RCVTIMEO=100

Please don't ask me why!

Setting this Opition to the default value (empty) makes no changes.
Even setting this Option to the suggested value (= SO_SNDLOWAT=1) makes no changes.

Next step is to try another TCP/IP Stack.
Any suggestions which one is free, easy to install and configure?

Last edited 5 months ago by damato (previous) (diff)

comment:44 Changed 5 months ago by stellan

You can try Roadshow demoversion from amigafuture.de. I read it should be easy to use/install. If get it downloaded (failed) I`ll try it.

comment:45 follow-up: Changed 5 months ago by opiopi

Stellan thanks for the hint about Roadshow.
Now a hint from me: If you have connection breaks maybe httpresume (aminet) can help you!?
Back to topic:
I installed and configure Roadshow and it works (AddNetInterface throw 2 MuTools Hits here, i'll write a mail to Olaf about that) but i can get mails with my script from all of my accounts.
Using the "Holen" button i get the same results as with MiamiDX, so it seems the TCP/IP Stack is not the cause for the Problem. I'll make new logs and upload them here ASAP. The Used Version is YAM 2.10-dev (25.05.2014) ... [OS3/m68k, r8010].

comment:46 in reply to: ↑ 45 ; follow-up: Changed 5 months ago by tboeckel

Replying to opiopi

Using the "Holen" button i get the same results as with MiamiDX, so it seems the TCP/IP Stack is not the cause for the Problem. I'll make new logs and upload them here ASAP. The Used Version is YAM 2.10-dev (25.05.2014) ... [OS3/m68k, r8010].

Please do not assume but better provide a NET debug log when trying to connect with RoadShow. This will prove if it is the same problem or not.

Changed 5 months ago by stellan

new

comment:47 Changed 5 months ago by stellan

New log attached. I`ve to test some more days but with yam 2.10-dev 25.05.2014 check single accounts seems to work better (i.e. less SSL errors).

@opiopi:
Unfortunately, amigafuture.de download don`t support resume.

comment:48 in reply to: ↑ 46 Changed 5 months ago by opiopi

Replying to tboeckel:

Replying to opiopi

Using the "Holen" button i get the same results as with MiamiDX, so it seems the TCP/IP Stack is not the cause for the Problem. I'll make new logs and upload them here ASAP. The Used Version is YAM 2.10-dev (25.05.2014) ... [OS3/m68k, r8010].

Please do not assume but better provide a NET debug log when trying to connect with RoadShow. This will prove if it is the same problem or not.

Please read my Comment again!
I wrote "I'll make new logs and upload them here ASAP"
so your comment is IMHO superfluous...

Changed 5 months ago by opiopi

comment:49 Changed 5 months ago by opiopi

I add the log 'YAM-Debug.log-25.05.2014.txt.ED.txt' made with RoadShow and YAM 2.10-dev (25.05.2014) ... [OS3/m68k, r8010].
The log contain obfuscated account names. Same letters means same accounts and the length of the account names are preserved.

comment:50 Changed 5 months ago by stellan

There are some people where sending mails dont work (SSL sucks). For me I cant send mails for about 3 weeks (I mentioned it already at #538 or here). Because telephoneline was/is broken here and nobody else reported this I thought I`m the only one with the problem). Have a look at:
http://www.a1k.org/forum/showthread.php?t=44491

If I use Port 25 instead then the SSL error message appears after about 3 seconds. So it differs to the usual Port set by YAM.

Btw. someone knows a freemailer that support not using SSL?

comment:51 follow-up: Changed 5 months ago by supernobby

Hello all!
seems like I have the same problem. And I really hope, this can be resolved.

I have this when trying to send emails via GMX. Receiving mails works.
I use AmiTCP/IP (GENESiS). Roadshow demoversion behaves the same in this regard.
Network card is X-Surf-100, but also some other sana2 device behaves the same.
So, I can't blame the issue on the network stack, nor the sana2 device.

I run the YAM.debug version 2.9.1 and got this:

01:E: ssl.c:842:SSL_connect() returned 0 with SSL_get_errror() = 5
01:E: ssl.c:853:errno(22) = ''
01:E: ssl.c:855:errnosv(0) = ''
01:E: ssl.c:861:querying ERR_get_error() stack:

The STARTTLS negotiation seems to work fine but the SSL connection fails most likely because of the errors shown in the log.

I am not so familiar with SSL, but think, SSL_get_error result 5 means:

SSL_ERROR_SYSCALL.

And if this:

http://www.virtsync.com/c-error-codes-include-errno

is correct, errno(22) is: EINVAL 22 /* Invalid argument */

I also tried to trace this with NetworkSnoop. There I found maybe one suspicious log entry:

######################
Socket: 0, buf: $905de79, length: $11c2 (4546) flags: 0
Inputs for recv():
bsdsocket.library base: $8dec9a4
process name/pointer: YAM thread [1]/$9682518
Function result: 4546 ($11c2)
dump binary:
length for bufor is too big! (4546/$11c2)
$0000:  0b 00 11 be 00 11 bb 00 07 70 30 82 07 6c 30 82 06 54 a0 03   __¾__»__p0__l0__T _
$0014:  02 01 02 02 09 00 9e f8 12 4f 54 68 0d 13 30 0d 06 09 2a 86   _______ø_OTh__0___*_
$0028:  48 86 f7 0d 01 01 05 05 00 30 81 c9 31 0b 30 09 06 03 55 04   H_÷______0_É10___U_
$003c:  06 13 02 44 45 31 25 30 23 06 03 55 04 0a 13 1c 54 2d 53 79   ___DE1%0#__U____T-Sy
$0050:  73 74 65 6d 73 20 49 6e 74 65 72 6e 61 74 69 6f 6e 61 6c 20   stems International 
$0064:  47 6d 62 48 31 1f 30 1d 06 03 55 04 0b 13 16 54 2d 53 79 73   GmbH1_0___U___T-Sys
$0078:  74 65 6d 73 20 54 72 75 73 74 20 43 65 6e 74 65 72 31 0c 30   tems Trust Center10
$008c:  0a 06 03 55 04 08 13 03 4e 52 57 31 0e 30 0c 06 03 55 04 11   ___U____NRW1_0__U__
$00a0:  13 05 35 37 32 35 30 31 10 30 0e 06 03 55 04 07 13 07 4e 65   __572501_0___U____Ne
$00b4:  74 70 68 65 6e 31 20 30 1e 06 03 55 04 09 13 17 55 6e 74 65   tphen1 0___U____Unte
$00c8:  72 65 20 49 6e 64 75 73 74 72 69 65 73 74 72 2e 20 32 30 31   re Industriestr. 201
$00dc:  20 30 1e 06 03 55 04 03 13 17 54 65 6c 65 53 65 63 20 53 65    0___U____TeleSec Se
$00f0:  72 76 65 72 50 61 73 73 20 44 45 2d 31 30 1e 17 0d 31 33 31   rverPass DE-10___131
$0104:  31 31 32 31 30 31 36 34 37 5a 17 0d 31 36 31 31 31 37 32 33   112101647Z__16111723
$0118:  35 39 35 39 5a 30 81 9d 31 0b 30 09 06 03 55 04 06 13 02 44   5959Z0__10___U____D
...
...
######################

Note: "length for bufor is too big!". Not really sure if this is relevant. But with the comments here:

http://www.openssl.org/docs/ssl/SSL_get_error.html

regarding "If ret == 0, an EOF was observed ...", could one get the idea, that some data could have been lost because of too small buffer for recv?!? If yes, probably only AmiSSL can be blamed?!?
In the NetworkSnoop log for receiving email, a similar sized recv entry with similar received data does not have this buffer problem.

Anyhow, if this helps or not, please ask, what else I can contribute to solve the issue. I will do what I can to help.

Thank you, also in general for maintaining YAM!

Last edited 5 months ago by damato (previous) (diff)

comment:52 Changed 5 months ago by damato

  • Cc supernobby added

comment:53 in reply to: ↑ 51 Changed 5 months ago by damato

Replying to supernobby:

Anyhow, if this helps or not, please ask, what else I can contribute to solve the issue. I will do what I can to help.

Thank you for this very valuable comment! And thank you for joining the discussion. We really need help from more people to get the problem sorted out and fixed.

In fact, my current suspicion is also that AmiSSL on OS3/m68k has to be blamed for being the root reason for it. First, I thought that this might be a MiamiDX specific problem but as you (and others) have reported also other TCP/IP stacks are showing the same problem a specific TCP/IP stack problem can be ruled out, I guess. In fact, your NetworkSnoop output pretty much supports that. However, we would need more similar NetworkSnoop outputs from different people to really support this observation. Unfortunately, I also don't have a new AmiSSL version ready yet (still working on it) and I also don't have a debug version of it so that we can see if the problem really is related to AmiSSL. But until I have that version ready you can do the following to provide more information to us:

  1. Please install the latest nightly 2.10 build from http://nightly.yam.ch/ and catch a NET debug log with it please. We quite significantly changed the debug output there to output somewhat more information. So please report this here afterwards.
  1. Please try to increase or lower the SO_RCVBUF and SO_SNDBUF SocketOptions buffers by adding the following to your [Advanced] section of your .config file:
    SocketOptions = SO_SNDBUF=X SO_RCVBUF=X
    

Please use numbers for X from 2048 till 65536 and always run NetworkSnoop to verify if the output changes regarding the warning message there. Perhaps this might allow to work around the problem. Furthermore, I would be curious to see what NetworkSnoop output others report and especially people which don't have that problem so that we can compare the output.

And again, thanks for your contribution. I know that we are only progressing slowly regarding this problem – however, it seems to be a complex problem and only related to OS3 classic systems as no MorphOS, OS4 or even WinUAE users seem to have these kind of problems. So we definitely need help from the OS3 classic community to get the issue sorted out.

comment:54 Changed 5 months ago by stellan

I tried NetworkSnoop but faild saving the log. I onnly get "Log start"/"Log end" entries. Please tell me how to save.

comment:55 follow-up: Changed 5 months ago by supernobby

Hi,
I tried YAM.debug from 2014-06-05 and used different SocketOptions. But unfortunately no change, sending still fails now with this log messages:

01:E:     ssl.c:908:SSL_connect() returned 0 with SSL_get_error() = 5
01:E:     ssl.c:923:strerror_r(errno=0) failed
01:E:     ssl.c:926:errno(0) = ''
01:E:     ssl.c:929:strerror_r(errnosv=0) failed
01:E:     ssl.c:932:errnosv(0) = ''
01:E:     ssl.c:938:querying ERR_get_error() stack:
01:D:      YAM_ER.c:130:pushing error 'Fehler beim Initialisieren der TLSv

Then I moved over to WinUAE and I am not sure, if now the problem is just computing power, which would be very sad. Because, it works on WinUAE, even with emulated a2065 card and same GENESiS, and even with the suspicious NetworkSnoop message at the same point in the NetworkSnoop log. So, very strange.

When comparing WinUAE and the real AMIGA I noticed, up to a recv() of 4 bytes, the NetworkSnoop logs look similar (not checked in the very detail). Then the AMIGA makes a quite long delay with 100% CPU usage according to Scout, and after the sends a message of 326 bytes. On WinUAE there is a message with same size but different content. Then comes the real difference. On AMIGA, does another recv() and then shutdown of the socket. On WinUAE, it goes on.

Here the refereed NetworkSnoop log of the AMIGA :

*-------------------------------------------------------*

Socket: 0, buf: $9273a41, length: $4 (4) flags: 0
Inputs for recv():
bsdsocket.library base: $8e09c4c
process name/pointer: YAM thread [1]/$8ef3a98
Function result: 4 ($4)
dump binary:
$0000:  0e 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __   _____

*-------------------------------------------------------*

Socket: 0, buf: $91c9edc, length: $146 (326) flags: 0
Inputs for send():
bsdsocket.library base: $8e09c4c
process name/pointer: YAM thread [1]/$8ef3a98
Function result: 326 ($146)
dump binary:
$0000:  16 03 01 01 06 10 00 01 02 01 00 1d 8c 93 dd e8 ca 94 80 58   ______________ÝèÊ__X
$0014:  19 02 db 2b 50 61 0b 3c 19 75 a5 b6 aa 88 d1 15 11 c2 c8 ef   __Û+Pa <_u¥¶ª_Ñ__ÂÈï
$0028:  ec 1e d1 89 87 1d 93 c4 b3 6c f4 bc a2 9d 11 fe 05 5e 9c b0   ì_Ñ____ijlô¼¢__þ_^_°
$003c:  56 4c 0d 34 93 e2 3b 22 22 01 4e 3d 65 43 6b 20 fa 2d 21 95   VL_4_â;""_N=eCk ú-!_
$0050:  bd b5 2d ae c0 2f 84 16 96 0e ee b1 d0 94 06 4f 40 bc c9 0d   ½µ-®À/____î±Ð__O@¼É_
$0064:  d6 04 f1 80 d8 e4 e6 5e 52 c7 9e 9a e6 f2 8e 23 b8 be 5c 28   Ö_ñ_Øäæ^RÇ__æò_#¸¾\(
$0078:  3a cd d2 9b d4 53 70 33 ff ea 9b c2 ab a7 69 5b 2b 5e 88 d1   :ÍÒ_ÔSp3ÿê_«§i[+^_Ñ
$008c:  a2 b3 49 fd 6e 91 69 1f f3 bf cd 8f ce 03 b5 13 14 01 1c 27   ¢³Iýn_i_ó¿Í_Î_µ____'
$00a0:  87 a6 7c 6c 6d 3b 23 ca 7f 73 6d 26 b9 6a bf a3 d0 42 e3 cd   _¦|lm;#Ê_sm&¹j¿£ÐBãÍ
$00b4:  2c ca 7e ad 83 11 b1 6d 02 49 47 f5 24 59 e9 e5 75 6f 86 cb   ,Ê~­__±m_IGõ$Yéåuo_Ë
$00c8:  69 14 a5 d7 a1 02 2d ef 84 bb 54 87 5e 46 65 22 b7 df 2a 95   i_¥×¡_-ï_»T_^Fe"·ß*_
$00dc:  55 c3 54 cf 69 cc 2d d0 26 f9 f6 85 30 c8 34 f2 78 0d f0 5e   UÃTÏiÌ-Ð&ùö_0È4òx_ð^
$00f0:  fb 25 82 5d f9 88 f7 34 d5 6d d6 ec 88 b9 57 b4 2a 9b 30 20   û%_]ù_÷4ÕmÖì_¹W´*_0 
$0104:  9e c4 da 86 e4 52 0b 14 03 01 00 01 01 16 03 01 00 30 ef 93   _ÄÚ_äR __________0ï_
$0118:  c7 df 5b 2a 09 d8 be bb 6a 8e 53 bc e5 11 21 78 04 1d e9 f5   Çß[*_ؾ»j_S¼å_!x__éõ
$012c:  48 17 4e fb 0f a0 e4 49 ab 1a 99 7e a1 27 81 f7 a3 f5 8e fa   H_Nû_ äI«__~¡'_÷£õ_ú
$0140:  74 99 d5 0d 70 04 __ __ __ __ __ __ __ __ __ __ __ __ __ __   t_Õ_p__

*-------------------------------------------------------*

Socket: 0, buf: $9273a3c, length: $5 (5) flags: 0
Inputs for recv():
bsdsocket.library base: $8e09c4c
process name/pointer: YAM thread [1]/$8ef3a98
Function result: 0 ($0)
*-------------------------------------------------------*

shutdown()

And here the refereed NetworkSnoop log of WinUAE:

*-------------------------------------------------------*

Socket: 0, buf: $7f59fd9, length: $4 (4) flags: 0
Inputs for recv():
bsdsocket.library base: $7a5a8e4
process name/pointer: YAM thread [1]/$780f790
Function result: 4 ($4)
dump binary:
$0000:  0e 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __   _____

*-------------------------------------------------------*

Socket: 0, buf: $7ba3dac, length: $146 (326) flags: 0
Inputs for send():
bsdsocket.library base: $7a5a8e4
process name/pointer: YAM thread [1]/$780f790
Function result: 326 ($146)
dump binary:
$0000:  16 03 01 01 06 10 00 01 02 01 00 28 f8 96 9f 03 20 9d 9b 9c   ___________(ø___ ___
$0014:  97 fd e5 53 80 3f c5 5c 23 ea ef a1 1e 14 65 c3 34 d0 4b d4   _ýåS_?Å\#êï¡__eÃ4ÐKÔ
$0028:  5b 17 fb cd 24 5c 84 24 a8 af 64 6f a6 ea 80 6b da ed 80 41   [_ûÍ$\_$¨¯do¦ê_kÚí_A
$003c:  36 be 18 c9 3a e5 b8 d3 3b 23 ed 65 c9 ea 24 9c f1 c2 0c 30   6¾_É:å¸Ó;#íeÉê$_ñ 0
$0050:  16 44 87 57 dd ed be dc 75 1e 2b ae 9a 47 c9 b2 f4 80 30 e7   _D_WÝí¾Üu_+®_Gɲô_0ç
$0064:  ce 6b 25 63 bb a0 94 32 25 9a 4d bc 8c d7 d7 f7 b6 3a 58 45   Îk%c» _2%_M¼_××÷¶:XE
$0078:  f4 67 c8 d6 09 36 6d 53 2e 3d 07 94 e9 a8 a3 1a 93 d6 95 ec   ôgÈÖ_6mS.=__騣__Ö_ì
$008c:  2b 9b fa 70 1d 46 5c 5c 13 59 c3 35 cf 8e 42 95 b7 08 57 0f   +_úp_F\\_YÃ5Ï_B_·_W_
$00a0:  b4 a4 69 9d c4 ae 6a f8 98 66 45 63 64 1e 8b 42 97 40 e8 17   ´¤i_Ä®jø_fEcd__B_@è_
$00b4:  ae 58 b2 2b ca 68 7f ef 3c be 57 0a b8 31 75 1c c5 a9 ac b9   ®X²+Êh_ï<¾W_¸1u_Å©¬¹
$00c8:  58 c0 e3 22 d7 9a 02 ce 7f 78 a3 43 23 23 ef 5d b9 70 26 05   XÀã"×__Î_x£C##ï]¹p&_
$00dc:  0e b1 d4 7b a7 f8 4a 7e e1 40 b1 1e 2d 55 37 34 0a 03 53 15   _±Ô{§øJ~á@±_-U74__S_
$00f0:  12 16 38 6f fe e1 3a 30 32 8e d0 07 6d 73 29 3a 7d b8 59 b3   __8oþá:02_Ð_ms):}¸Y³
$0104:  11 3a 40 e7 e1 ab 2c 14 03 01 00 01 01 16 03 01 00 30 5e a0   _:@çá«,__________0^ 
$0118:  ea 71 ce 93 2f 22 44 86 51 26 35 39 eb e6 70 20 c7 cc 68 e2   êqÎ_/"D_Q&59ëæp ÇÌhâ
$012c:  dc a3 7d bc 83 9b 7f 90 4e d3 b6 0e 35 94 0d 2a 56 d4 ba fc   Ü£}¼____NÓ¶_5__*VÔºü
$0140:  cb 3b 2d a1 3e 55 __ __ __ __ __ __ __ __ __ __ __ __ __ __   Ë;-¡>UÞ

*-------------------------------------------------------*

Socket: 0, buf: $7f59fd4, length: $5 (5) flags: 0
Inputs for recv():
bsdsocket.library base: $7a5a8e4
process name/pointer: YAM thread [1]/$780f790
Function result: -1 ($ffffffff)
*-------------------------------------------------------*

WaitSelect() has released context with result 1 ($1).
Inputs for WaitSelect():
bsdsocket.library base: $7a5a8e4
process name/pointer: YAM thread [1]/$780f790
struct timeval {
	u_int tv_sec 30;
	u_int tv_usec 0;
};
*-------------------------------------------------------*

Socket: 0, buf: $7f59fd4, length: $7 (7) flags: 0
Inputs for recv():
bsdsocket.library base: $7a5a8e4
process name/pointer: YAM thread [1]/$780f790
Function result: 7 ($7)
dump binary:
$0000:  16 03 01 00 4a 02 00 __ __ __ __ __ __ __ __ __ __ __ __ __   ____J___

*-------------------------------------------------------*

If AMIGA does no miss calculation (can this be verified somehow?), is it then really too slow :-(. Or is YAM just too impatiently, because the delay on the AMIGA takes about 30 seconds?

comment:56 in reply to: ↑ 55 Changed 5 months ago by damato

Replying to supernobby:

[...]

If AMIGA does no miss calculation (can this be verified somehow?), is it then really too slow :-(. Or is YAM just too impatiently, because the delay on the AMIGA takes about 30 seconds?

Thanks for the intensive testing and the nice report/summary here. It is also very interesting that a real AMIGA system seems to behave really different compared to a WinUAE installation. Also very interesting and unbelievable that on a real AMIGA there is a 30 seconds delay. So two questions popup in my mind:

  1. Can you tell something about when exactly the recv() call with return value 0 occurs relative to the delay? I mean, is the 30 seconds delay between the rev() call with buffer length 326 and the subsequent recv() call with buffer length 5, or is the delay afterwards or somewhere else? I really want to understand when exactly the 30 seconds delay occurs to better understand what might be the reason for that.
  1. How long is the delay on WinUAE? Is there any visible delay at all? Is the delay at the same time in the NetworkSnoop output or not?
  1. Can you please try to correlate the NetworkSnoop output to the debug output of YAM? Where in the YAM debug output does the 30 second delay occur and when does it continue?

In fact, after having studied your output I really believe we need an AmiSSL debug version somehow to more deeply investigate the issue in AmiSSL. Unfortunately I haven't one ready yet, so please be a bit more patient. However, looking at your NetworkSnoop output of your real AMIGA I can see that the recv() call with buffer length 5 returns zero instead of -1 like on WinUAE. Reading the documentation of recv() I could find the following statement:

The return value will be 0 when the peer has performed an orderly shutdown.

In my understanding this could also point out that the peer (the mail server on the other end) simply terminated the connection because it believed the connection to be dead (perhaps due to the 30 seconds delay). Therefore I would be really interested in finding out *when* exactly the delay occurs (before or after that recv()) so that we could understand what AmiSSL might be doing.

And to answer your question regarding if there is a timeout in YAM. No there isn't all that YAM does is calling SSL_connect() and waiting for it to return a valid return value. However, on a real Amiga it seems to return the already mentioned error code. That's at least what I can read from the debug output people supplied.

comment:57 Changed 5 months ago by supernobby

Hello damato,
I made some more testes with WinUAE. I did slow down the emulator and after that, sending mails on WinUAE also fails. Depending on the emulator speed, I can also create similar logs compared to the real AMIGA. If I make the emulator even slower, connection fails sooner in the connect procedure.

Luckily, as we are now on the PC, I can also use Wireshark to log the communication. From there I can see, then probably while the AMIGA (this now also covers WinUAE) is calculating the next message, the server sends a FIN packet. The AMIGA may not respect this and sends its encrypted packet, what the server replies with a RST packet.

So, it seems like, GMX has some sort of timeout (not sure if for overall connect procedure or an individual rely) for establishing the connection. To answer your questions might not be relevant any more. But I try.

1) The recv() 0 happens quite at the end of the delay. It seems like, it takes the AMIGA so long (on WinUAE this times are different depending on the emulator speed, it was 30 on real AMIGA) to "produce" the 326 bytes message. One of the YAM threads consume max CPU cycles on the AMIGA during that time.

2) As said, depends on the emulator speed. If too long, remote sends FIN packet and if AMIGA still sends on, then RST.

3) I try to comment the YAM debug output:

...
...
02:W:     Connection.c:998:using literal string '[192.168.178.101]' instead

-> NetworkSnoop output starts and halts after recv() 4.
-> sending 326 byte message starts almost simultaneously with YAM error in the log

02:E:     ssl.c:908:SSL_connect() returned 0 with SSL_get_error() = 5
02:E:     ssl.c:923:strerror_r(errno=0) failed
02:E:     ssl.c:926:errno(0) = ''
02:E:     ssl.c:929:strerror_r(errnosv=0) failed
02:E:     ssl.c:932:errnosv(0) = ''
02:E:     ssl.c:938:querying ERR_get_error() stack:
02:D:      YAM_ER.c:130:pushing error 'Fehler beim Initialisieren der TLSv1/SSLv3 

So, finally I would now say, AmiSSL is not wrong. But the AMIGA in general is too slow. Maybe we need to ask GMX to extend the timeouts for older computers. Else the classic AMIGA takes one more switch towards insignificance, which creates a really bad feeling for me to see this happening live. Or would a new AmiSSL version be faster?

Last edited 5 months ago by supernobby (previous) (diff)

comment:58 follow-ups: Changed 5 months ago by supernobby

Hi,
it looks like, the sever sends the FIN (request to close the connection) about 10 seconds after the start of the connection, if the SSL connection / authentication (not fully sure, what the criteria is) was not done within this time. WinUAE can make it with max speed, but the real AMIGA currently not, as SSL stuff computations take longer. So, if someone is working on a new AmiSSL version, can we expect some speedup? Probably not. Contacting GMX regarding this might become a problem, but I will try. Or what do others think about it? Thank you!

One other thing. For now I tried all with STARTTLS at port 25. Similar results I get with SSL/TLS at port 465. But if I try, what GMX suggests, SST/TLS at port 587, then what gets send by the AMIGA looks strange and YAM.debug log is different, even with fasted WinUAE settings:

02:E:    ssl.c:908:SSL_connect() returned -1 with SSL_get_error() = 1
02:E:    ssl.c:923:strerror_r(errno=0) failed
02:E:    ssl.c:926:errno(0) = ''
02:E:    ssl.c:929:strerror_r(errnosv=0) failed
02:E:    ssl.c:932:errnosv(0) = ''
02:E:    ssl.c:938:querying ERR_get_error() stack:
02:E:    ssl.c:942:ERR_get_error()=336031996 stack: 'error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol'
02:D:     YAM_ER.c:130:pushing error 'Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server 'mail.gmx.net'.'

And this error appears quite fast. So, probably there is something wrong with AmiSSL. But, not sure if fixing this would help, as long as there is the timeout issue.

Andreas

comment:59 Changed 5 months ago by damato

In 8070:

  • added somewhat more debug output to output internal OpenSSL timeout and time values. This refs #530.

comment:60 in reply to: ↑ 58 Changed 5 months ago by damato

Hi,

again thank you supernobby for your very nice and detailed debug output and analysis. I would really love to see more such professional dealing of reporting and following-up on things than simply stating "something doesn't work" like most people do.

Replying to supernobby:

it looks like, the sever sends the FIN (request to close the connection) about 10 seconds after the start of the connection, if the SSL connection / authentication (not fully sure, what the criteria is) was not done within this time. WinUAE can make it with max speed, but the real AMIGA currently not, as SSL stuff computations take longer. So, if someone is working on a new AmiSSL version, can we expect some speedup? Probably not. Contacting GMX regarding this might become a problem, but I will try. Or what do others think about it? Thank you!

Well, after having read you last two posting I can hardly believe that a real Amiga shouldn't be fast enough to calculate these 326 bytes of encrypted data. But we will have to proof that, of course. That's the reason why I have added more debug output to the latest nightly build now. So please repeat your tests and please make sure to generate a NET debug log. This can be performed by running

setenv yamdebug net

on the command-line before you actually start the debug version of YAM. This will cause yam to output even more detailed debug output which might help us in understanding where exactly the classic Amiga system gets stuck. In fact, please do the following:

  1. Try it with your classic Amiga and have a look at the timeout output around SSL_connect(). I am especially curious to see what the actual processing time for SSL_connect() is in the debug output.
  1. Repeat the same on WinUAE and compare.
  1. Please post your exact WinUAE setup regarding the slowdown so that we can try to reproduce the problem here on our WinUAE setups because it will help a lot if we can reproduce the problem ourself, especially if we have a debug version of AmiSSL at hand.

So as a net result I would say it is still to early to say that AmiSSL is not the reason for the problem. In fact, I really doubt that the classic amiga hardware isn't fast enough to calculate these few encrypted bytes. However, there might be something wrong in AmiSSL which causes SSL_connect() to being stalled. So either we can fix that or we can try to find a work-around for it. But for doing that we definitely need more help from people like you reporting so nice and detailed debug output and descriptions. So please keep up the pace!

comment:61 in reply to: ↑ 58 Changed 5 months ago by damato

Even if we are starting to mixing up several different things (as that issue is definitely a different one), let me quickly comment on that one:

Replying to supernobby:

One other thing. For now I tried all with STARTTLS at port 25. Similar results I get with SSL/TLS at port 465. But if I try, what GMX suggests, SST/TLS at port 587, then what gets send by the AMIGA looks strange and YAM.debug log is different, even with fasted WinUAE settings:

02:E:    ssl.c:908:SSL_connect() returned -1 with SSL_get_error() = 1
02:E:    ssl.c:923:strerror_r(errno=0) failed
02:E:    ssl.c:926:errno(0) = ''
02:E:    ssl.c:929:strerror_r(errnosv=0) failed
02:E:    ssl.c:932:errnosv(0) = ''
02:E:    ssl.c:938:querying ERR_get_error() stack:
02:E:    ssl.c:942:ERR_get_error()=336031996 stack: 'error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol'
02:D:     YAM_ER.c:130:pushing error 'Fehler beim Initialisieren der TLSv1/SSLv3 Session mit Server 'mail.gmx.net'.'

And this error appears quite fast. So, probably there is something wrong with AmiSSL. But, not sure if fixing this would help, as long as there is the timeout issue.

No, this is totally normal. Port 587 is reserved to be used with STARTTLS only. See here

http://en.wikipedia.org/wiki/STARTTLS

As you will see only port 465 is supposed to be used with 'SMTPS' which in fact is the SSL/TLS option in YAM. So if you want to use SMTPS (SSL/TLS) please use port 465 and not 587.

comment:62 Changed 5 months ago by damato

In 8073:

  • added some more debug output to better analyze SSL related connection problems. This refs #530 and #568.

comment:63 Changed 5 months ago by damato

In 8074:

  • revised some parts of the SSL certificate verification code to be a bit more robust. In addition, more debug output had been added to identify potential problems more easily. This refs #530 and #568.

comment:64 Changed 5 months ago by tboeckel

In 8078:

  • Debug.c: each debug message will now include the current time to be able to spot long delays more easily. This refs #530 and #568.

comment:65 follow-up: Changed 5 months ago by supernobby

Hi!
ok, then we leave the port 587 issue for now.
I now recorded new logs with YAM.debug 2014-06-12. I hope this helps. I will try to attach them, as they are much longer now. But to summarize:

1) In case of the real Amiga I get:

'SSL_connect()' took 30.920568 seconds

2) in case of the fastest Winuae setting I get 2 entries for SSL_connect:

'SSL_connect()' took 0.030851 seconds
'SSL_connect()' took 5.360807 seconds

I hope the full logs help.

3) To slow down my Winuae, simply went to Winuae Settings -> Hardware -> CPU and FPU -> CPU Emulation Speed and switched from "Fastest possible" to Approximate A500/A1200 or cycle-exact" and used the CPU speed slider to reduce the speed until the send problem occurred.

And also thanks for your efforts to solve the issue.
Andreas

Changed 5 months ago by supernobby

sending mail worked

Changed 5 months ago by supernobby

sending mail failed

comment:66 Changed 4 months ago by tboeckel

Everybody with these timeout issues could please try to disable some of the encryption cipher algorithms which might take too much time for the calculation.

Just change this line of your .config

DefaultSSLCiphers = ALL:!LOW:!SSLv2:!EXP:!aNULL:@STRENGTH 

to this:

DefaultSSLCiphers = ALL:!AES:!LOW:!SSLv2:!EXP:!aNULL:@STRENGTH 

This will exclude the AES encryption algorithms which might be too slow on certain machines. I am curious if this might be a feasible workaround. It is definitely no solution as it excludes the stronger encryption algorithms and leaves you with the weaker ones.

Last edited 4 months ago by damato (previous) (diff)

comment:67 Changed 4 months ago by tboeckel

Just in case anybody wants to play around a bit more with the available ciphers a description of all possible options for the setting can be found in the OpenSSL documentation https://www.openssl.org/docs/apps/ciphers.html.

comment:68 in reply to: ↑ 65 Changed 4 months ago by damato

Replying to supernobby:

I now recorded new logs with YAM.debug 2014-06-12. I hope this helps. I will try to attach them, as they are much longer now. But to summarize:

1) In case of the real Amiga I get:

'SSL_connect()' took 30.920568 seconds

2) in case of the fastest Winuae setting I get 2 entries for SSL_connect:

'SSL_connect()' took 0.030851 seconds
'SSL_connect()' took 5.360807 seconds

I hope the full logs help.

Indeed, these logs helped a lot in understanding the reasons and allowed us to actually find the root cause of the problem. So let me explain it in more detail after having reproduced the issue here myself:

First of all I found out that only GMX and web.de users seem to be affected by this issue. Just have a look at the track record of this ticket and ticket #568. Only GMX and web.de users have been complaining about this issue.

After having seen your SSL_connect() times I just thought myself that it might be due to the mail server (GMX, web.de) implementation and some potential timeouts there. And in fact, this was actually the reason. So if you do the following:

$ telnet mail.gmx.net 25
Trying 212.227.17.190...
Connected to mail.gmx.net.
Escape character is '^]'.
220 gmx.com (mrgmx003) Nemesis ESMTP Service ready
$ telnet mail.web.de 25
Trying 213.165.67.108...
Connected to smtp.web.de.
Escape character is '^]'.
220 web.de (mrweb004) Nemesis ESMTP Service ready

You can see, both GMX and web.de are using the exact same mail server software (so-called 'Nemesis'). After having identified this I did the following tests to see if the mail server in question is actually dropping the connection due to a timeout:

$ telnet mail.gmx.net 25
Trying 212.227.17.190...
Connected to mail.gmx.net.
Escape character is '^]'.
220 gmx.com (mrgmx002) Nemesis ESMTP Service ready
EHLO localhost
250-gmx.com Hello localhost [178.25.233.61]
250-SIZE 69920427
250-AUTH LOGIN PLAIN
250 STARTTLS
STARTTLS
220 OK
Connection closed by foreign host.

And BINGO. After I typed STARTTLS as the initiating command to start a SSL connection I waited for about 8 - 10 seconds and then the server immediately dropped the connection without waiting for me to actually send anything. The same happens when you try the same with "mail.web.de" or "mail.1und1.de" which is the mother company of GMX and web.de using the same 'Nemesis' mail server software. In fact, the same does NOT happen when connecting to mx.freenet.de or any other mail server not using Nemesis. There the mail server waits way longer (> 60 seconds) for the SSL connection to be initiated by the client. I also repeated the same for POP3 connections to GMX and web.de and ended up with the same result: As soon as I try to initiate an SSL connection but I am not replying fast enough with a valid SSL negotiation the connection is immediately dropped. I could even reproduce the problem now on faster systems and even on AmigaOS4 by simply adding a sleep delay in the order of 8 seconds right before the initial SSL_connect() call resulting in the exact same error like above

So coming back to your debug information and the SSL_connect() time outputs. The above fact that the mail server of GMX and web.de are dropping connections completely after about 8 - 10 seconds waiting for a valid SSL negotiation really perfectly matches why you are seeing the SSL_get_error() with result 5 in your debug output. The server has simply dropped the connection before SSL_connect() was able to finalize the SSL negotiation.

So who is to blame?
Well, that's pretty clear. The mail server of GMX and web.de (aka Nemesis) is dropping connections way too fast compared to other mail server implementation. While one could argue that only slow systems might be affected by this even faster systems could run into the same problem if (for some reason) the system itself is under higher load (due to parallel computations) and it reaches this 8 seconds limit before it could finalize the SSL_connect(). In addition, right after a STARTTLS command being send SSL connections are usually initialized by also loading the SSL certificate chain via SSL_CTX_load_verify_locations() which could easily take several seconds depending on how large a certificate chain file is and then starting the SSL negotiations afterwards via SSL_connect(). So in principle any system (even non-amiga systems) could be affected as 8 - 10 seconds are really way to short due to the native a SSL connection is being setup.

What to do about it?
Well, apart from reporting this shortcoming in the Nemesis mail server software of GMX, web.de and 1und1 there is unfortunatly only little we can do about it. Thore has already stated above that limiting the allowed encryption ciphers by excluding AES might help due to the fact that then SSL_connect() itself will be faster due to less computational time required to initiate the SSL negotiations. This, however, is clearly just a work around since the timeout could in principle also happen if your system is also simply busy with other stuff at the time you try to connect to the mail server easily approaching the 8 seconds limit. Of course, best would be to move away from GMX, web.de or 1und1 since changes are probably pretty low that they will adapt their mail server (its closed source and very proprietary) to the needs of their users. Having understood the root cause of the problem we will also see if we can optimize the way SSL connections are currently initiated in YAM so that there is as less delay as possible between the STARTTLSor similar commands and the actual call to SSL_connect(). However, please understand that this is also just a workaround for the real problem: GMX, web.de and 1und1 are using too strict timeout values for SSL negotiations.

Last edited 4 months ago by damato (previous) (diff)

comment:69 follow-up: Changed 4 months ago by antibike

hmm, i don't understand why a Pegasos2 G4 with 1Ghz is not fast enough.
If a Classic Amiga has problems here i can understand, but Pegasos2?
Realy too slow?

comment:70 in reply to: ↑ 69 ; follow-up: Changed 4 months ago by damato

Replying to antibike:

hmm, i don't understand why a Pegasos2 G4 with 1Ghz is not fast enough.
If a Classic Amiga has problems here i can understand, but Pegasos2?
Realy too slow?

Obviously that's the case. Or to be more precise, in your case it is sometimes fast enough and sometimes not. In fact, looking at your latest debug output from ticket #568 you can see that for the case where the SSL connection didn't work the last SSL_connect() call is > 8 seconds and for the call when it works it took only < 8 seconds. As said, it is also a matter of what you do in background at the time of connecting to the mail server. In addition, keep in mind that on MorphOS you still use the 68k emulated version of AmiSSL which might not run at optimal speed. And there are of course chances that as soon as I get an updated AmiSSL version that this will also improve computation times. But for the time being I don't really see and way to improve things substantially :(.

comment:71 follow-up: Changed 4 months ago by stellan

I tried with:

DefaultSSLCiphers = ALL:!AES:!LOW:!SSLv2:!EXP:!aNULL:@STRENGTH

but that doesn't help here (send mails still fails). Removing ALL seems not working too. Also with eNULL added. If there is a faster way of using ciphers please tell me. I read the openssl link mentioned by damato but don't know how to get "fastest" cipher config.

Which freemailer would you recommend that use longer timeouts? At least as a workaround I need a new email account.

Last edited 4 months ago by damato (previous) (diff)

comment:72 in reply to: ↑ 71 Changed 4 months ago by damato

Replying to stellan:

I tried with:

DefaultSSLCiphers = ALL:!AES:!LOW:!SSLv2:!EXP:!aNULL:@STRENGTH

but that doesn't help here (send mails still fails). Removing ALL seems not working too. Also with eNULL added. If there is a faster way of using ciphers please tell me. I read the openssl link mentioned by damato but don't know how to get "fastest" cipher config.

Well, thats hard to say. I guess that's simply due to the fact that you use a real amiga and thus you currently always end up with > 8 seconds no matter which ciphers you use.

Which freemailer would you recommend that use longer timeouts? At least as a workaround I need a new email account.

As I said, only GMX, web.de and 1und1 seems to be affected because they have an own proprietary mail server implementation. Thus, I could recommend gmail and freenet which should work fine (as far as I could test them). So please try one of them and report back if your problem is solved then.

Last edited 4 months ago by damato (previous) (diff)

comment:73 follow-up: Changed 4 months ago by supernobby

Can someone please clarify, where to add the line with "DefaultSSLCiphers" exactly (my .config file does not have one yet) and how it can be verified, that it really got considered? Thanks!

comment:74 in reply to: ↑ 73 Changed 4 months ago by tboeckel

Replying to supernobby:

Can someone please clarify, where to add the line with "DefaultSSLCiphers" exactly (my .config file does not have one yet) and how it can be verified, that it really got considered? Thanks!

You can put it anywhere. Although YAM saves its config in sections it will recognize any option in any line when loading the config, no matter which section is currently the "active" one. So just put that line at the bottom.

comment:75 in reply to: ↑ 70 ; follow-up: Changed 4 months ago by antibike

Replying to damato:

Replying to antibike:

hmm, i don't understand why a Pegasos2 G4 with 1Ghz is not fast enough.
If a Classic Amiga has problems here i can understand, but Pegasos2?
Realy too slow?

Obviously that's the case. Or to be more precise, in your case it is sometimes fast enough and sometimes not. In fact, looking at your latest debug output from ticket #568 you can see that for the case where the SSL connection didn't work the last SSL_connect() call is > 8 seconds and for the call when it works it took only < 8 seconds. As said, it is also a matter of what you do in background at the time of connecting to the mail server. In addition, keep in mind that on MorphOS you still use the 68k emulated version of AmiSSL which might not run at optimal speed. And there are of course chances that as soon as I get an updated AmiSSL version that this will also improve computation times. But for the time being I don't really see and way to improve things substantially :(.

it seems i found the solution for my configuration.
thanks to your troubleshooting i tried another AmiSSL binary.
i changed all AmiSSL libs to the 68020/40 build and now i have a delay around 1,5 seconds without CPU load and with CPU load (~50%) i get a delay around 3 seconds.
Thanks for your investigation.

comment:76 in reply to: ↑ 75 Changed 4 months ago by damato

Replying to antibike:

it seems i found the solution for my configuration.
thanks to your troubleshooting i tried another AmiSSL binary.
i changed all AmiSSL libs to the 68020/40 build and now i have a delay around 1,5 seconds without CPU load and with CPU load (~50%) i get a delay around 3 seconds.

That's actually a good thing, because it shows that there is potential that as soon as I have updated AmiSSL sources which will also be compiled with GCC that an optimized version would improve AmiSSL encryption times significantly. In addition, we will then also have a native MorphOS version of AmiSSL which should even improve performance somewhat more.

However, the root cause of the problem remains: The mail server of GMX, web.de and 1und1 (Nemesis) have to be blamed for being to strict and not allowing more than 8 - 10 seconds for the client to return with a SSL negotiation.

comment:77 follow-up: Changed 4 months ago by stellan

I had a short test with gmail account. Sending and receiving works just fine here on 040/40. I used tha last saved yam config with:

DefaultSSLCiphers = ALL:!AES:!LOW:!SSLv2:!EXP:!aNULL:@STRENGTH

So I can confirm that GMX sucks. Someone asked GMX about timeouts and answer was just because of some kind of email attack they want avoid. They said we should may trie to use a proxy. Bla blaa.

If they don`t change I cannot use my three GMX accounts more. :(

comment:78 in reply to: ↑ 77 Changed 4 months ago by damato

Replying to stellan:

I had a short test with gmail account. Sending and receiving works just fine here on 040/40. I used tha last saved yam config with:

DefaultSSLCiphers = ALL:!AES:!LOW:!SSLv2:!EXP:!aNULL:@STRENGTH

You can even remove that line from your .config file if you use gmail because the gmail mail server really waits long enough for your client to calculate the SSL negotiation. Thus it should even work with AES encryption enabled.

So I can confirm that GMX sucks. Someone asked GMX about timeouts and answer was just because of some kind of email attack they want avoid. They said we should may trie to use a proxy. Bla blab.

Well, who actually asked GMX and how? I really would like to ask GMX or better the makers of the Nemesis mail server the same question again because I feel 8 - 10 seconds is really way too fast and even people on other more modern systems might run into the same problems under certain circumstances. So can you please provide the contact to the person having asked GMX as I really want to see that conversation and potentially get an email address from GMX where I can send a direct request to.

If they don`t change I cannot use my three GMX accounts more. :(

Well, then you either have to wait until I have a new AmiSSL version for OS3 ready which might potentially run a bit faster or you will have to switch to gmail or freenet which doesn't have these problems.

comment:79 Changed 4 months ago by stellan

With default setting:
DefaultSSLCiphers = ALL:!LOW:!SSLv2:!EXP:!aNULL:@STRENGTH
it also works. SSL error message don`t appear so often. Only sometimes it occurs.
About the GMX stuff read this thread:
http://www.a1k.org/forum/showthread.php?t=44491&highlight=yam
GMX answer at post number 45

Last edited 4 months ago by stellan (previous) (diff)

comment:80 Changed 4 months ago by damato

In 8086:

  • tcp/ssl.c: added new InitSSLConnections() and CleanupSSLConnection() functions which will now be called from the global startup routines in YAM. These new InitSSL/CleanupSSL functions will take care now to initialize+cleanup a single global SSL_CTX structure rather than having to create such a structure for every SSL connection being initiated. Apart from reducing the connection overhead in general this change also allowed to load the ca-bundle.crt once upon starting YAM rather than on every SSL connection. In fact, this should slightly reduce the SSL negotation delay by 2-3 seconds on slow m68k systems and should perhaps increase the probability that SSL negotiations to mail servers from gmx.de, web.de and 1und1.de are not timing out. This refs #530.

comment:81 Changed 4 months ago by damato

Anyone having problems with SSL negotiations to gmx.de, web.de and 1und1.de are encouraged to retry with the next nightly build. While not being able to actually fix the problem, I slightly improved the way SSL connections are initialized and setup in YAM. This change should somewhat reduce the burden and thus reduce the time between initiating a SSL connection and actually finishing it so that perhaps the 8 - 10 seconds timeout will not be reached. So please report back if this change improves the current state of affairs.

comment:82 Changed 4 months ago by damato

Any news from OS3/m68k users if my latest change improved anything? Would even be good to know if it actually didn't break anything at all :)

comment:83 Changed 4 months ago by stellan

Receiving works much better now. At least I could check three (2x gmx, gmail) accounts parallel. Only if a download was running and checking mails error occurs.

Sending mails (gmx) still fails. 100% cpu usage for around 1 minute then ssl error message.

comment:84 Changed 4 months ago by jerseywurzel

Hi,

I too, have a problem with Gmail: "Couldn't initialize TLSv1/SSLv3 session with host 'pop.gmail.com' of account ..."

However this only occurs when checking ALL accounts at once. If I get mail from the Gmail account singly, it works fine.

I have 1 x Gmail, 1 x Hotmail, 1 x Outlook and 1 x Jerseymail accounts.

Using OS3.9+2 Boingbags on a real Amiga A1200 with an 060 and 452mb RAM with fibre Broadband (download speed of 50mb).

I have tried to attach 2 logfiles (Snoopdos and YAM debug 2.9p1) but IBrowse doesn't seem to want to do it? I can email them if you would like.

Hope this is useful.

comment:85 Changed 4 months ago by jerseywurzel

Addition:

Sorry, forgot to add that I use Miami, NOT Miami DX. Not sure if my system is using MiamiSSL, OpenSSL or AmiSSL, as all are on my system. MY knowledge in this area is very weak so would need to be guided if this is important to have information.

comment:86 follow-up: Changed 4 months ago by stellan

I`ve to correct myself. Seems I was to quick. GMX accounts now hangs (100% cpu usage for at least 1 minute with ssl error message) also when I try to get mails (check single account or multi). Strange that it worked when I first tried it. Get from gmail account still works.

@jerseywurzel:
I use IBrowse and uploading files here works. So it should also work for you.

comment:87 in reply to: ↑ 86 Changed 4 months ago by damato

Replying to stellan:

I`ve to correct myself. Seems I was to quick. GMX accounts now hangs (100% cpu usage for at least 1 minute with ssl error message) also when I try to get mails (check single account or multi). Strange that it worked when I first tried it. Get from gmail account still works.

I never said it should work now. The root cause of the problem still exists: the mail server of GMX, web.de and 1und1.de are too strict in enforcing a timeout for the SSL negotiation. The only thing that could potentially fix the situation is a new AmiSSL version with improved computation times. However, this is not guaranteed and might not be the case (m68k is simply too slow for todays encryption ciphers). Thus, the only permanent solution that I feel would be to switch to gmail or to force GMX, web.de and 1und1 to increase their timeout to something like 60 secs.

comment:88 follow-up: Changed 4 months ago by stellan

Seems GMX has changed things again. Receiving mails now completely fails like sending before. So they go worse and worse instead of better. Just an info.

comment:89 in reply to: ↑ 88 Changed 4 months ago by damato

Replying to stellan:

Seems GMX has changed things again. Receiving mails now completely fails like sending before. So they go worse and worse instead of better. Just an info.

I just tested the mail servers of GMX again, but I cannot see any difference. SSL/TLS negotiations are still terminated after about 8 – 10 seconds inactivity. Thus, the problem should be exactly the same. So it have to be your internet connection or your system was more busy at the time you tested it again. As I said, I currently see no other possibility than to switch your email provider, sorry.

comment:90 follow-up: Changed 4 months ago by stellan

Unfortunately, nobody else report problems. They just write in a forum. At least 2-3 user reported the same: "Receiving doesn't work more with GMX." This happens (I can only guess) at the very same time. So GMX changed someting again. However, it is just an info for you that it happened. Of course you can't do anything against this.

Your changes from 26.06.2014 helped a lot as I wrote already. Alas one or two days later after I tried the version from 26.06 GMX sucked with the change to let it not work.

I won`t wonder, if some YAM user just switch to an other system/programm. What is pity IMHO.

BTW. do you know already or can say when you are able to deliver some new AmiSSL version for testing?

Last edited 4 months ago by damato (previous) (diff)

comment:91 in reply to: ↑ 90 Changed 4 months ago by damato

Replying to stellan:

BTW. do you know already or can say when you are able to deliver some new AmiSSL version for testing?

The OS4 version of AmiSSL with updated openssl 1.0.1h is almost finished. After that I will see how fast I can get it compiled for OS3 as well. However, I can't promise anything.

comment:92 Changed 3 months ago by supernobby

Hi,
I was a while away, no Internet, no AMIGA.

After trying again today with nightly build 2014-07-10 and the regular 2.9p1, I also can't receive mails anymore via my GMX account. That also makes me think, GMX changed something. The problem is most likely the same that sending has now for some while. But receiving still worked while sending already failed. Now both fail.

May I ask again about the usage of DefaultSSLCiphers in the .config file and especially, how one can confirm, that it makes any difference. I mean, if I look in the yam log, it also prints "ssl.c:767:available SSL ciphers:". And the list of ciphers is always the same, regardless of what I have in the .config file.

Changed 4 weeks ago by JosDuchIt

comment:93 Changed 4 weeks ago by JosDuchIt

Till a few days ago all went well with my RAM 2.9p1 with my SAM460ex OS4.1 update 6 system, then i got the problem not being able to download from my scarlet.be acccount. (one of 2 providers checked in sequence) . I reported the problem in another thread.

i downloaded 2.10NB debug version

here are my observations:

  1. first error message after using the 'get' button

Error validating server certificate for pop.scarlet.be:995

  • The certificate is not issued by a trusted authority, use the fingerprint to validate the ertificate manually
  • The signature of the certificate is invalid

Certificate information
-Hostname *.scarlet.be
-Valid: 10/09/2014 14h33 until 10/09/2016 14h33

  • Issuer GlobalSign nv-sa, BE
  • Fingerprint: 71:8A:78:79:74:E2:92:1C:82:4C:5F:01:C8:2F:70:38:FC:7A:FB:C6

if you continue the data will be encrypted, (protection from interception), but the identity of the server cannot be guaranteed (NO protection from fraud)
Do you still want to accept the connection

  1. After hitting the "accept" button:

Bad reponse from mail server 'pop.scarlet.be of account 'xxxxxxx" to command 'USER'

the mail server could not execute the command and replied with the above error message

  1. In a new session i instead hit the "show certificate button'

which gives more info but does confirms that contrary to the message the certificate is still valid.

comment:94 Changed 4 weeks ago by tboeckel

  • Cc JosDuchIt added

Add Comment

Modify Ticket

Action
as accepted .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • Andreas Barth(Subscriber, Participant)
  • chzigotzky@…(Subscriber, Participant)
  • Frank Weber(Subscriber, Participant)
  • Joseph Duchâtelet(Subscriber, Participant)
  • Stellan Pistoor(Reporter, Participant)