Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Controls Guy on November 10, 2014, 03:18:55 PM
-
I'm trying to send an email but the connection keeps timing out after reaching the point where it says "SMTP connected!", as if the SMTP server isn't acknowledging the DM's logon attempt, but I've tried every option I can think of in the SMTP device config and have tried to replicate the settings in an email client that is working fine. I've attached a screenshot of my DML log of a couple attempts to send one.
-
What is the duration of the manual session? 10 seconds? 60 seconds? 120 seconds? Not sure what the default timeout is for Do-more (but you can adjust it). It needs to be pretty high so you don't get any false timeouts reported.
Make sure the Do-more CPU's subnet mask and its gateway address are consistent with the Do-more's IP Address (assuming your SMTP server is not on your local subnet).
-
When I get a sec I'll Wireshark some transactions from TBird. I also have one of those mirroring switches so I can do a more detailed capture of the Do-More's login attempts. Then we can dissect those.
-
We cross-posted. The timeout for that log was 5 seconds, but I tried as high as 30 seconds, which is far longer than that server typically requires to respond. Subnet and gateway are the same as the working client, plus as you see, it completes a connection to the server to its satisfaction so it must be able to reach it. I'll get some detailed captures and we can look at those.
-
one of the first things i'd try is using a different SMTP server. if you can get to it, Google has one that we use, it's at aspmx.l.google.com. Do a DNSLookup of that name to get the current IP address (they've been known to change it occasionally). Then use that IP address for the SMTP server and send yourself a test email.
if that works then it definitely means the first SMTP server is where the problem lies.
While you are doing that i'll research what we're sending and expecting to receive right after we get the "SMTP Connected!" message.
-
if that works then it definitely means the first SMTP server is where the problem lies.
That doesn't follow. If ANY SMTP server reacts differently to Do-More than it does to another client, that means it can tell which is which. It can only tell which is which if Do-More and the other client are doing something differently. Doesn't necessarily mean that Do-More is the one doing it wrong, but it does mean that it's different than the email client software.
-
at the point its failing for you, the TCP connection on port 25 has been established, and we're waiting on the SMTP server to say it's ok for the client to begin.
So at this point the SMTP server doesn't know what type of client it's talking to, it has simply accepted a connection from a client. Do-more's SMTP client hasn't even sent the "HELO" which initiates the actual email work.
-
I'm told that the ECOM100 treats the initial greeting as optional, although Do-more does not. I haven't spoken to the ECOM100 firmware guy about it yet, so I don't know his reasoning, but the spec is pretty clear on the issue. From RFC 5321:
"4.3.1. Sequencing Overview
The communication between the sender and receiver is an alternating
dialogue, controlled by the sender. As such, the sender issues a
command and the receiver responds with a reply. Unless other
arrangements are negotiated through service extensions, the sender
MUST wait for this response before sending further commands. One
important reply is the connection greeting. Normally, a receiver
will send a 220 "Service ready" reply when the connection is
completed. The sender SHOULD wait for this greeting message before
sending any commands."
Bolding and italics are mine, but the caps are in the spec.
-
So at this point the SMTP server doesn't know what type of client it's talking to, it has simply accepted a connection from a client.
There by definition has to be a difference or the results would be the same. That seems self-evident. It may very well be that the SMTP server is doing something non-spec and the email client has been written to accept it. In turn, that raises the issue that if that particular non-spec behavior is common enough that people are writing their email clients to tolerate it, then perhaps Do-More should as well, or at least allow it as a configuration option. It's also entirely likely that I haven't managed to configure Do-More's authentication options to reproduce what Thunderbird does, and that's the reason for the difference, but rest assured, there has to be a difference.
As I said yesterday, I'll Wireshark the email program and do the same with the Do-More and that will tell us more about whatever may be different.
-
One other important thing to note is that there is an extension of the SMTP spec (RFC 1820) where the greeting starts with ELHO instead of HELO. It is possible that the server is set to only respond to the ELHO command, instead of both HELO and ELHO.
-
I'd give it nearly 100% than the server isn't issuing a greeting upon connection. The fact that Don supported that with the ECOM100 is indicative of there being some popular support for such, but, it is awkward at best. Dang near exactly like when you call someone and they don't say "Hello" or your cell phone broke up when they did. The ensuing "Hello...Hello...you there?" is painful with two humans, and similarly so to codify.
We have been shipping for over 2 years and this is the first I've heard of it, so I'm guessing that it isn't that common a problem. Even so, I would happily fix it...if I weren't eyeballs deep in new platform development.
-
One other important thing to note is that there is an extension of the SMTP spec (RFC 1820) where the greeting starts with ELHO instead of HELO. It is possible that the server is set to only respond to the ELHO command, instead of both HELO and ELHO.
I doubt it. The problem is before the HELO.
-
OK, think I got to the bottom of it.
- Email server POP/SMTP is doing something unusual or unanticipated by Do-More
- Email clients are written to accommodate the behavior (don't know how common it is).
Since nothing else was working I suspected that the correct authentication might possibly be POP before SMTP because TBird automagically checks for email upon startup, so by the time you want to send an email, your IP address will have already been authenticated from the server's point of view.
I changed to POP-before-SMTP mode, and Do-More will then complete a successful authentication with the POP server. Problem IS.....the POP and SMTP servers have different URLs, and while TBird allows for that, Do-More does not. Again I have no idea how common this is, but allowing for separate POP and SMTP URL's might be something you'd want to consider adding if it's easy and if anyone else runs into this issue. Meantime I'll find an email server that doesn't have that issue.
Thanks!
-
It doesn't sound unusual at all. POP before SMTP is common, and apparently the SMTP server is simply refusing to greet when he hasn't first been alerted to the pending SMTP request via POP. That wouldn't be my preferred handling (error code would be better) but I can't say it is wrong.
When you say different URL, what do you mean? Different IP address between POP and SMTP?
-
Yes! POP is pop.myisp.com with one IP, and SMTP is smtp.myisp.com with a different IP.
-
Odd...I just pinged it and got the same IP for both URLs. Is it possible that it is dynamically changing? Google does that.
-
Pinged which? Mine? I never told you what it was unless you're going by my email address. And the IPs were very definitely different the day I posted that. In fact, when I was Wiresharking Thunderbird, I saw the same two servers addressed within seconds of each other, at the same respective IPs that I had got from pinging.
Or were you referring to GMail or some other server?
-
Funny. Pop.myisp.com and SMTP.myisp.com are actual addresses.
-
That IS funny -- guess I should have posted pop.<myisp>.com and smtp.<myisp>.com ;D
It's actually cox.net if you want to try it again. As I posted, I also checked gmail.com, gmx.com and live.com, and in all three cases got differing IP's for POP vs. SMTP.
-
Don't know about the others, but GMail's SMTP will yield different IPs from ping to ping.
It would be painful to change the SMTP device configuration in the SysConfig...forward and backward versioning with both software and firmware is hard. I could easily work around it by adding the POP IP to DEVREAD/DEVWRITE though. The PLC could treat the addresses as the same until you wrote the POP IP, after which POP and SMTP would remain unlinked until the next power cycle/SysConfig update.
-
That sounds perfectly workable to me (especially since I'm probably DEVWRITing everything into the device anyway).
I suspect that a lot of those services don't use or at least don't require POP-before-SMTP, or else with the prevalence of differing addresses, you'd have heard about it before now.
-
Still fighting this one. Found an email service with both POP and SMTP at the same IP. (Shouldn't matter anyway, as the SMTP seems to allow logons). STILL can't log on despite trying every possible combination of settings, even though email client works on the first shot. Weird. Do-More sends some encrypted login and after a few second wait, says that the authentication failed. There's only so many options, this one really has me baffled.
The immediate issue: In trying to troubleshoot this, I've set up a batch of DEVWRITEs so I can dynamically configure the device ("@EMail"), triggered by a physical input. When I trigger the physical input, then check the device config via the Project Browser, the values I've DEVWRITten to aren't changed. What could be the issue here?
-
Interesting! I added some DEVREADs so I could watch the variables in real time and they show my DEVWRITEs are working, but for some reason if I go look at the dialog, it still has the old information. Is this a bug, or am I doing something wrong?
-
So now (with auth set to 0), I get past the username, but then "RCPT to:" is my regular email address, so the smtp server gets mad and says I'm not "authenticated to relay". I can't imagine what in the world is injecting that address. Can anyone help me with that? Is it coming from somewhere within Do-More?