SendEMAIL using SIM-5320 (3G) SOLVED

[hendorog]

I've put this one the back burner for now, it was an extra for my own use vs delivering the oroduct...
Thanks for the ideas.
The ping test didn't do what I expected, so I need to see what else is going wrong in the data setup.

cheers

Sounds like it's not getting the IP stack setup then - or else the provider is blocking ping packets.

I'd be also doing the DNS test as that gives you another data point for comparison. Of course you also want to query the DNS servers from the thing and check that they are working.

[amyk]

...It doesn't need to be on a LAN.

I don't get this suggestion...  No problem to implement a local server, but It's a 3G modem, how's it goingt to reach a local server when it can't reach any other server?

Same for Wireshark sniffing on a 3G connection (although my experience is very limited - several years ago...)
What are you suggesting?

Excuse my lack of comprehension here!

The 3G connection is to the Internet, correct? Your server is also connected to the Internet, and thus they can communicate as long as their know each other's IPs.

But as the others here have said, make sure the modem is getting an IP first.

[SL4P]

I thought that's what was being suggested, just (sort of) counterintuitive - adding a number of extra actors in the path...

[janoc]

I don't get this suggestion...  No problem to implement a local server, but It's a 3G modem, how's it goingt to reach a local server when it can't reach any other server?

Well, that is why the APN needs to be checked first, whether any traffic actually gets out of it. Wireshask is then for debugging any SMTP-related issues, once you can actually establish the TCP connection.

The 3G connection is to the Internet, correct? Your server is also connected to the Internet, and thus they can communicate as long as their know each other's IPs.

But as the others here have said, make sure the modem is getting an IP first.

Careful, 3G is not the same as having internet connection! Having 3G connection only means the modem is talking to the wireless base station of the telco. Establishing an Internet connection requires that you have both 3G connection and the internet APN correctly configured (and data enabled, but I guess that's default on a modem), otherwise the telco's network will not "put you through" to the Internet and you won't be able to connect to anything.

[SL4P]

The APN suggestion is becoming more likely, as I'm using a couple of different carrier supplied SIMs, that are 'pre configured" and works fine in *any* data/phone without further configuration (APN from SIM card?).

I made the (perhaps false) assumption that the modem would also pick up the APN from the SIM.

Will look into that today....  getting an IP address assigned was distracting me from this possibility.

[janoc]

I made the (perhaps false) assumption that the modem would also pick up the APN from the SIM.

It may not. Or it could take the wrong one (e.g. the one for wap or MMS services). I had phones that didn't autoconfigure these things and also some carriers don't provide SIMs with the APN preconfigured on them. So better verify it.

[SL4P]

I made the (perhaps false) assumption that the modem would also pick up the APN from the SIM.

It may not. Or it could take the wrong one (e.g. the one for wap or MMS services). I had phones that didn't autoconfigure these things and also some carriers don't provide SIMs with the APN preconfigured on them. So better verify it.

Even though I didn't change it to get it working - I've added the APN to the configurable params in the calling function... just to be safe in the future.  I was trying to reduce the number of customer configured variables - so now there's one more.  I love standards that everyone ignores!

BTW - I learned that the idea of SSL/TLS email - was to get past the anti-relaying debacle - but it seems the telcos ignore it - so they can force people to subscribe to ther email as well as their carrier service.

[Wilksey]

Ho Hum, the joys of GSM modems.
You have to first make sure that the modem is attached to the data channel (AT+CGATT?)
Then you have to set the APN (AT+CSTT="apn","username","password")
Then you have to open the wireless connections (AT+CIICR)
Then you can check your IP to see if you are getting one (AT+CIFSR)

I am assuming the command set is the same or very similar to the SIM900.

Don't forget to close and shutdown the connection! (AT+CIPCLOSE + AT+CIPSHUT)

HTH!

[SL4P]

Ho Hum, the joys of GSM modems.
You have to first make sure that the modem is attached to the data channel (AT+CGATT?)
Then you have to set the APN (AT+CSTT="apn","username","password")
Then you have to open the wireless connections (AT+CIICR)
Then you can check your IP to see if you are getting one (AT+CIFSR)

I am assuming the command set is the same or very similar to the SIM900.

Don't forget to close and shutdown the connection! (AT+CIPCLOSE + AT+CIPSHUT)

HTH!

I wish I'd started out aiming at plain vanilla SMTP, but since the modem supports the 'newer' SSL/TLS secure mail protocols, I wrote around that...  slightly different configuration sentences.. 
... and a learning curve!   but now it's done!

[Wilksey]

Glad you got it all worked out, care to share the final relevant configuration sections in case anyone else runs into these issues?

[hendorog]

Ho Hum, the joys of GSM modems.
You have to first make sure that the modem is attached to the data channel (AT+CGATT?)
Then you have to set the APN (AT+CSTT="apn","username","password")
Then you have to open the wireless connections (AT+CIICR)
Then you can check your IP to see if you are getting one (AT+CIFSR)

I am assuming the command set is the same or very similar to the SIM900.

Don't forget to close and shutdown the connection! (AT+CIPCLOSE + AT+CIPSHUT)

HTH!

I wish I'd started out aiming at plain vanilla SMTP, but since the modem supports the 'newer' SSL/TLS secure mail protocols, I wrote around that...  slightly different configuration sentences.. 
... and a learning curve!   but now it's done!

Awesome! I'm also keen to see what made it work in the end.

[SL4P]

Here's where it ended up...
One critical element is the carriers (more often than not) demand your originating email address is on their domain - I guess that locks in service customers that don't ino enough to work around this stupidity.
The original intent was to implement SSL sessions to minimise spam and other eMail nasties, but they turned it into a commercial lock...

Here's what works...

AT+CGDCONT=1, "IP", "myAPN", "0.0.0.0" >>
AT+CGATT=1 OK
  <takes ~5 secs>
AT+CGACT=1, 1 >>
+CGPADDR: 1,"10.146.90.214"       << == assigned DHCP from carrier
AT+CSMTPSSRV="smtp.optusnet.com.au", 25, 1
AT+CSMTPSAUTH=0
AT+CSMTPSFROM="sendername@optusnet.com.au"
AT+CSMTPSRCPT=0,0,"recipient@destination.net", "Test Report"
AT+CSMTPSSUB=38
  ControlMate [Test Board] Status Report
AT+CSMTPSBODY=66
  Version 160830
  NEW Test message
  body
  on multiple
  lines
Tu 15:44
>> SENDING...
  <takes ~5 secs>
+CSMTPSSEND: 0. <<== result code 0=success

AT+CGACT=0, 1 OK
AT+CGATT=0 OK
AT+CGDCONT=1 OK

In the setup, the only significant difference I can see
is the order of AT+CGATT and AT+CGDCONT
Cheers

[janoc]

Here's where it ended up...
One critical element is the carriers (more often than not) demand your originating email address is on their domain - I guess that locks in service customers that don't ino enough to work around this stupidity.
The original intent was to implement SSL sessions to minimise spam and other eMail nasties, but they turned it into a commercial lock...
...

Cool, I am glad you have managed to make it work.

The originating e-mail address issue is a trivial prevention of various viruses and malware sending spam, which have pretty much always forged envelope MAIL FROM address. For normal user that shouldn't matter - the envelope address is set to the ISP provided address and any decent e-mail client permits to configure the identity so that a custom From: header appears in the mail for the recipient.

Or you mean that the mail service checks the From: headers inside the body of the mail? That would be really strange.

The SSL has little to do with spam prevention, actually. The original original idea was to provide a secure encrypted channel for transferring mail (normal SMTP is plaintext, your mail is free for the taking for anyone who happens to have access to the network used to transport it). Just ask Google why they were so pissed and started to convert everything to SSL/TLS when it was revealed that NSA has been sniffing their networks.

The anti-spam role mainly came into existence after the proliferation of various viruses and worms spreading by e-mail. The ISPs had to lock their networks down thanks to clueless users, because all it takes is one spammer to get your network blacklisted and suddenly none of your customers can send mail - it will get rejected. Not fun and takes ages to clean up all the while you have irate clients screaming at you. If you ever had to deal with one of the spam blacklists then you will understand.

So the ISPs started to block outgoing port 25 (SMTP traffic) from their clients except for their own servers and require authentication before sending (SSL/TLS or POP-before-SMTP). Also many mail servers will refuse mail from servers that are not designated as authorized senders for the given network/domain. Most "mere mortals" don't need to connect anywhere else than to their ISP's e-mail server, so this doesn't limit 99% of the people and cuts down on problems significantly.

However, most ISPs will let you send mail (unblock outgoing SMTP traffic) and even run your own mail server if you ask them. They just don't do it by default (way too many clueless users ...). However, do expect having to sign some paperwork about taking responsibility for any spam or other issues in that case. Some will also require you to upgrade to a "business" type of connection.

Considering that most people don't even use classic e-mail and e-mail clients today, using SMTP services as a form of ISP lock-in would be completely silly.

[SL4P]

Here's where it ended up...
One critical element is the carriers (more often than not) demand your originating email address is on their domain - I guess that locks in service customers that don't ino enough to work around this stupidity.
The original intent was to implement SSL sessions to minimise spam and other eMail nasties, but they turned it into a commercial lock...
...

Cool, I am glad you have managed to make it work.
...
The anti-spam role mainly came into existence after the proliferation of various viruses and worms spreading by e-mail. The ISPs had to lock their networks down thanks to clueless users, because all it takes is one spammer to get your network blacklisted and suddenly none of your customers can send mail - it will get rejected. Not fun and takes ages to clean up all the while you have irate clients screaming at you. If you ever had to deal with one of the spam blacklists then you will understand.
...

This is what I should have written, not specifically spam, but more for general isolation of malware.
I chose the SSL compatible client, because of future/forward compatibility, expecting it to help punch past port 25 blocks - as a known, authenticated sender. 
My expected operation does work in a very few cases...

In an embedded development that can be sold and deployed almost anywhere, it just too hard to 'open' mail routes on every carrier for each of my customers.  I'll leave the SSL/TLS capability in there - as part of the manual configuration.  The content isn't secret, but I do want it to work in another three years when some other threat locks down everyone's bathroom taps !