Yet another ELK M1XEP Email issue

[RayEatsWorld]

Hi all,
 
So I've never been able to get emails to work with my ELK system, and I'm pretty sure i've exhausted every solution I've found on this (and other) sites. 
 
I recently updated bottler and firmware, that worked flawlessly. I can access the system both locally and remotely via my dons service, have my ISY imported, and associated IOS apps working flawlessly.
 
However I can't get test emails to send! I've tried GMAIL with ports 465/587 and GMX (same ports). Nothing goes out of the XEP.
 
I'm really hoping there are some fresh ideas around, because I've really hit a wall here. I thought for sure the updated firmware would help me out, but I was sadly mistaken.
 
Cheers!

 

[Del91574]

Have you verified your ISP isn't blocking ports?

 

[treo650]

If he's using Gmail 465/587 I believe it should be ok. Not the standard port 25

 

[zenoparadox]

You can easily check whether the port is accessible at all. Try to telnet to it and see whether you get a connection. My telnet client will say "Connected to..." once it is connected. Here's an example of a test I did with gmail:


$ telnet smtp.gmail.com 465
Trying 173.194.204.108...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.

If I did not know how a telnet client reports good connections and failures, I'd try on a known good address (e.g. telnet google.com 80) and a known bad address (e.g. telnet localhost 70, which won't respond unless you happen to be running a Gopher server), and note how it handles successes and failures before doing the actual test.

 
Which version of the firmware are you running?

 

[jpmargis]

The DNS server is not configured or has failed.

 

[Linwood]

Some ideas...
 
It's hard to know how to help without more info, and how much info you can get depends on what you know how to do.  A packet trace is the best - see what it's actually sending and receiving.    Since no one sells hubs anymore only switches, that generally requires knowing how to use "port monitor" or "port mirror" on a switch you can log into.  Wireshark is free and runs on Windows to let you sniff packets if you can get to a port where you can see the packets.
 
Another possibility is, if you have a system to do it, set up an SMTP server locally (some editions of windows can do it in IIS, it's easy in Linux).  Send to it in plain text (no encryption or SSL) and make sure it is communicating.   That checks some basic functions.  Doesn't test SSL or TLS really (it can but that's not worth it as you probably can't duplicate google's precise setup).
 
You might also (as jpmargis implied) look up the IP address of your target server and replace the name with the IP address, that will help you know if it is a DNS resolution problem.  That's the quickest thing to test.  NOt a good idea to leave it that way in case they change addresses.
 
I never got Office 365 working, but gmail worked for me out of the box.
 
Make sure you are running the right firmware and boot.

 

[RayEatsWorld]

Thanks all.

Currently the XEP is connected to a Hitachi router on Bell Canada's fibre network. I don't believe the aforementioned ports are blocked as I have 4 Foscam IP cams all emailing motion detected images using the same gmail settings; wouldn't that mean the XEP should as well?

I'm running v2.0.30 firmware on the XEP.

 

[pete_c]

I don't believe the aforementioned ports are blocked as I have 4 Foscam IP cams all emailing motion detected images using the same gmail settings; wouldn't that mean the XEP should as well?

 
yes

 

[RayEatsWorld]

 
yes

Then the problem should only exist within the XEP? I'm not sure what I would be missing; if I can access remotely then obviously it's communicating, simply not sending the test email (or other emails).

This is confusing as heck

 

[zenoparadox]

Currently the XEP is connected to a Hitachi router on Bell Canada's fibre network. I don't believe the aforementioned ports are blocked as I have 4 Foscam IP cams all emailing motion detected images using the same gmail settings; wouldn't that mean the XEP should as well?
 

 
If the Foscam devices are indeed configured in exactly the same way the XEP is, and they work, then the issue should not be merely that a port is blocked. I had suggested telnet earlier for a simple test because I believe it is installed by default on all systems nowadays and is dead simple to use. Given what you say here, telnet should connect but that's to be expected given that your cameras are working.
 
What I would do then is, as Linwood suggested, use wireshark to see how the XEP tries to talk to the gmail server. You should set a filter so that you see only those packets that originate from the XEP or go to it.

 

[pete_c]

Personally here do not have an Elk panel.
 
You don't really need to use wireshark.  Just put your ELK in a DMZ for a bit and see if it works then.
 
If it does then review what you have configured on your firewall relating to your ELK panel and fix it.
 
Mostly firewalls are basically the same.   IE: a firewall is a firewall is a firewall.
 
My Verizon FIOS ISP connection included firewall, router, switch, connectivity to STBs and AP and used little animated pictures and icons for the configuration. I just bridged one port to a firewall that I was more familiar with and shut off most of the included junk that I saw on the box; leaving the STBs on one network and creating my own network for my stuff.
 
That said any hard coded external (internet) firmware dependencies can cause you grief.  Hate that stuff.