NetBurner Community Forum

I have a difficult situation that I don't know how to troubleshoot, so I was hoping someone might have an idea. We have sold a product based on the SB70LC for several years. It sends emails to its user and hosts a simple configuration web server.

I came across one of them in the field that locked up frequently, even though they all use the same firmware (now based on NNDK v2.7.6). After much troubleshooting, we figured out that the static IP address of the cellular modem to which it's attached had been blacklisted for spam, and hence Gmail would not accept email requests from our device. I think that Gmail rejected the socket connection outright. The odd part is that not only was the email not sent, but the web server would stop working (the remote firmware task still worked which allowed for clunky, remote rebooting).

The customer quickly requested a new IP address from his provider, so I can no longer discover why the lock-up occurred. Does anyone have any thoughts as to why this might happen, or an easy way to recreate such a scenario locally?

I have had a problem with a blacklisted IP on a remote system over a cell network. I have a MOD5270B behind a NIC, so the webserver never went down. It was just not accessible from outside and email went nowhere. I set up a DDNS to be able to access the modem. The MOD5270B runs a program that requests the DDNS server to return the address of the modem and then checks to see if the modem IP has changed. If it has changed, the MOD5270B sends an update request to the DDNS server. The DDNS server would reject the blacklisted IP and send back status code in the 400 series. If it sees that, the MOD5270B will re-boot the modem, which results in a new IP being assigned. Power to the modem goes through a relay controlled by a GPIO on the MOD5270B.

It is a bit elaborate, but perhaps you could send a get request to some server that would send back a reject code indicating blacklisted IP and then handle it to alert someone.

Ed

Thanks for the reply, Ed, but like I said, I don't have the problem anymore. Since the customer "fixed" it on me by getting a new IP address, I can't recreate the scenario that made the NetBurner crash in the first place. I don't know why it crashes when its connection request is rejected... Once bitten, twice shy, perhaps?

Which send email function are you using? Are you sending the email to a common server like Google, Outlook, Yahoo, etc? Are you calling the send email function from the web server task? Are other tasks able to run other than the firmware update task? What does your send email fail condition logic look like? Are you retrying several times upon failure? Have you tried IsMailError() and PrintNBError() defined in mailto.h to print the error of your last mail attempt?

SendMail() makes calls to some functions that pend. It's possible the send mail function could be suffocating your web server task, if your attempting several retries -- again, only if your send mail is being called from your web server task. Consider testing your app against a mail server you can manage and block an IP from.

Are you sending the email to a common server like Google, Outlook, Yahoo, etc?

Yes, Gmail.

Are you calling the send email function from the web server task?

No, from the main task I call StartHTTP(), EnableAutoUpdate(), and then the main task loop sends emails when needed.

Are other tasks able to run other than the firmware update task?

The only other thing I have, which continued to work, is EnableAutoUpdate, which I assume starts in its own task.

Which send email function are you using?
What does your send email fail condition logic look like?
Are you retrying several times upon failure?
Have you tried IsMailError() and PrintNBError() defined in mailto.h to print the error of your last mail attempt?

I'm using your SSL_SendMail(). If it fails/returns with error a few times in a row, my code idles for several minutes before trying again. I could not try the email error functions because the customer quickly "fixed" his problem by changing the IP address - my (our?) problem remains, of course.

I agree, I'll have to come up with my own rejecting server somehow; I just thought you guys might have an idea off the top of your heads of something to check/try. Maybe our IT department has a simple way of doing this without my writing something.