Winsock Error 10066.. maybe MTU related problem ? (wodWebServer / wodWebServer.NET)

Frequently in relaing the component hit 'winsock error 10066', maybe a MTU related problem.. (as you know.. MTU is dynamic on Ms Oses).

I've written a little procedure to intercept this error but i cannot succeed in avoiding it. I think it should be fixed in the source ..i'm only binary licensed

Bye..

Amedeo.

Amedeo,

can you be more specific under which circumstances this error appears, and in which component?

Kreso

can you be more specific under which circumstances this error appears, and in which component? Kreso

..sure

Component: wodSmtpServer 2.3.4
I'm using Visual Basic 6
Operating System tested: WinXP, Win 2k3 server

After the initial smtp dialog (helo, mail from, rcpt to) we have the
message itself .. for example..

---
220 SMTP Server (ready).
helo testing.domain.ext
250 Hello testing.domain.com, nice to meet you
mail from: origin@domain.com
250 origin@domain.com... sender ok
rcpt to: destination@otherdomain.com
250 destination@otherdomain.com... recipient ok
data
354 enter mail, end with . on a line by itself
...
---

At this point the component try to send the message (headers and body) but frequently timeout occurs.
I spent a lot of time in understanding what was going on.. then i try to intercept all winsock errors and ..here.. i found the 10066 winsock error.
Googling i've found that one of the possible timeout reason could be incorrect MTU handshaking. I tried to disable dynamic MTU in windows TCP/IP and i lowered it down to 1480.
Timeouts occurs less frequently now.. but sometimes the problem persists.

I hope the explanation is comprensible .. my english is not so good

Bye..

Amedeo.

Hi Amadeo,

Can you reproduce the same behaviour using our samples?

Is there any chance we could reproduce this on our side?

Regards,
Damba

If it's MTU problem, there's not much application can do about it. It must be set on Windows layer, so this could be problem specific to your copy. Can you lower it even more, to 1200 for example?

Kreso

If it's MTU problem, there's not much application can do about it. It must be set on Windows layer, so this could be problem specific to your copy. Can you lower it even more, to 1200 for example?
Kreso

I'm testing with 1400 now.. for a couple of days.

I can understand your words .. no app can do about.. Windows layer .. .. but i normally work with lots of mailserver products (windows and linux) and this is the first time i have to deal with mtu and timeout problems. So.. i think that those products programmers have dealed with winsock problems; there are no products that suggests to change any parameter on tcp layer.

Maybe it's my fault.. my question is: do you think something could be done on the component to avoid this problem? .. or you think it's a windows layer problem only ? You have the code (me no).. you have coded it (i'm not so skilled).. I only want to know where i have to put my attention on

Bye.. thnx for the help (and sorry for my terrible english).

Amedeo.

Amedeo,

unfortunatelly, nothing can be done from application. Such registry changes, to tweak MTU, would require reboot and would be valid through-out the system for all other connections.

wodSmtpServer does nothing special related to winsock - it accepts connection using regular accept winsock API, reads using recv and sends using send . Besides those (and, of course, listen and bind ) there are no other winsock specific options.

So, I really don't know what I could offer. If you think it's MTU problem on your PC, you should perform some MTU related tests to see what should be correct size for MTU, but that's far beyond wodSmtpServer component.

Regards,
Kreso

Amedeo,
wodSmtpServer does nothing special related to winsock.. (cut)..
..you should perform some MTU related tests .. (cut)
Kreso

In these days i've done lots of tests, then i've turned my two testing PCs (1->WinXP-SP3 and 2->Win2k3-SP2 R2 Server) to their default values (netsh winsock reset && netsh int ip reset) and tested again.

I cannot find any 'logic consequence' ..so i can say that maybe mtu (and related params) doesn't relates the problem (was the unic clue i found googling about similar problems).

As said in past message, i've done a little 'trap' by which i can report myself the problem/event.
App send me back a message in which i can see (tipically):

---------------------------------------------------
Winsock ErrorCode: 10060
Winsock ErrorText: The current connection has timeout.
Relay.State: 0
Relay.StateText: Not yet connected - waiting.
Relay.RetryCount: 4
Relay.LastResponse: 354 Enter mail, end with CRLF.CRLF
---------------------------------------------------

In my little app, after 4 retry, i give up and send back to the sender a NDR (and a debug message to me if winsock error occurs).

So.. the smtp dialog is ok, when it's time to submit the message (354 Enter mail, end with CRLF.CRLF) there is not connection ?!? ..surely caused by the winsock error.

If u have ideas .. thanx

Amedeo,

Can you perhaps check what Transcript for the relay that files returns?

You can do that by checking Relay.Transcript property.

Regards,
Damba

Can you perhaps check what Transcript for the relay that files returns?
You can do that by checking Relay.Transcript property.
Regards,Damba

Sure.. i've already have that debug part ..but i've forgotten to report on the previous message

.. so .. (addresses and hashed-user/pass masked)..

---------------------------------------------------
Winsock ErrorCode: 10060
Winsock ErrorText: The current connection has timeout.
Relay.State: 0
Relay.StateText: Not yet connected - waiting.
Relay.RetryCount: 4
Relay.LastResponse: 354 Enter mail, end with CRLF.CRLF
---------------------------------------------------
Relay.Transcript:
220 smtp.provider.com ESMTP ready
HELO myrelayer.example.com
250 smtp.provider.com
STARTTLS
220 2.0.0 Ready to start TLS
AUTH LOGIN
334 DAN2ce3hbRU6
MTAyFDBcbW9ubSluqSezsLm5ldA==
334 EGF3c3$vcm 6
dXdlcnR£ODg=
235 2.0.0 Authentication successful
MAIL FROM: <amedeo@example.com>
250 2.1.0 Sender <amedeo@example.com> ok
RCPT TO: <myfriend@example.com>
250 2.1.5 Recipient <myfriend@example.com> ok (remote)
DATA
354 Enter mail, end with CRLF.CRLF
---------------------------------------------------

Thanx for your help..

Amedeo.

Amedeo,

Does every relay fail on that machine, or only to certain recepients?

If so, can you send me a working relay transcript?

Regards,
Damba

Does every relay fail on that machine, or only to certain recepients?
If so, can you send me a working relay transcript?

Sorry for the long wait.. but i didn't saw the 2nd page of the forum post

There is no logical scheme in the failures.. the relays fail randomly.
The only thing i've noticed is that some messages (body) persist in failing if i resent them exactly the same, if i change something in the body (so the single message is shorter or longer) tipically the relay succeeds.

I use SSL/TLS trasmission for relay (as you can see in the transcript in my previous message) and i've noticed there is a new relase 2.3.5 which updates the OpenSSL component. It's a simple update or a fix ? ..i'm asking that because i was thinking about a possible broken SSL trasmission ?!? (i know.. i'm desperate)
My subscription is expired so i cannot test the 2.3.5 .. do you think the upgrade could help me?

You ask me a working relay transcript .. obviosly it is 'working' so it is absolutely 'normal'.. so useless to diagnosis (also consider thet is SSL/TSL coded). Trust me .. i've analyzed tons of them (and i've succesfully re-sent tons of them directly in telnet).
There is nothing wrong in the email fomat (headers or body).. is something at a lower level (winsocks, timeouts.. i don't know!)

Bye..

Amedeo,

If you wish you can test with latest DEMO version from our website. In that case please backup somewhere you old licensed version.

Did you maybe try to run wodSmtpServer on some different location and machine? In that case we can be more sure if this is MTU problem or not.

Is there any chance you can try that?

Drazen