Hello Teltonika Support,
I have a question about the syntax for event reporting.
Case 1:
Event text:
“Router name:%rn; Event type:%et; Event text:%ex; Time stamp:%ts”
Test email (correct format):
“Router name:RUT955; Event type:DHCP; Event text:Test email; Time stamp:2024-12-29 10:56:27”
Live email (correct format):
“Router name:RUT955; Event type:DHCP; Event text:Leased IP address for client - MS-Surface-Pro-2-LAN in LAN; Time stamp:2024-12-29 10:52:26”
Case 2:
Event text:
“Router name:%rn;%nl Event type:%et;%nl Event text:%ex;%nl Time stamp:%ts”
Test email (correct format):
“Router name:RUT955;
Event type:DHCP;
Event text:Test email;
Time stamp:2024-12-29 10:55:44”
Life email: not sent!
What can be noted is that if a “%nl” is included in the text, no event report is sent.
Yet, the events appear in the System>Maintenance>Events menu.
Hello Marija,
first of all a Happy New Year and thanks for reply.
In the initial support request I just gave you an example of my test results. Yet, all four event reports listed below behave like described if a %nl is configured. I tried different positions of %nl within the text but this did not help.
Event type: “New DHCP client”
Event subtype: “Connected from WiFi”
Event type: “New DHCP client”
Event subtype: “Connected from LAN”
Event type: “WAN failover”
Event subtype: “Switched to main”
Event type: “WAN failover”
Event subtype: “Switched to failover”
RUT955 is in phase out. Did you test with RUT955 and 07.06.16?
Could you please create a backup for your device to avoid losing your configurations? You can find instructions on how to do that here. Once you’ve done that, for testing purposes, please reset your device to factory defaults as described here. After the reset, check if the same issue occurs.
Additionally, while testing events reporting, you can log in to SSH/CLI (CLI Guide) and execute thelogread -fcommand. This will show logs in real-time, allowing you to see if the email was sent or if there are any additional logs that could help identify the cause of the issue.
Good morning Marija,
Thank you for your answer. I carried out the test according to your instructions. I would like to point out that I had already reset the device to factory defaults and reconfigured it after flashing 07.06.16. But no matter, I did the factory reset again. I only carried out the tests with the failover events; that seemed sufficiently significant to me. The test sequences follow.
Test preparation:
User: Backup created
User: Restore to factory defaults via WebUI
System: Erases the configuration partition
User: Run through wizard
User: Restore config
User: Checked some settings, OK.
Test1 with %nl
User: Event reporting rules Failover Switched to main and Switched to failover configured with %nl
User: Logged in to CLI, executed logread -f
User: Wired WAN plug unplugged
System: Failover to WiFi0
User: Screenshot from CLI saved in file “Error_Failover_Switched to Failover.PNG”
User: Test email from configuration dialog for this case successfully sent via WiFi0 (if connection had not worked)
User: Wired WAN plug plugged in
User: Screenshot from CLI saved in file “Error_Failover_Switched to Main.PNG”
User: Test email from configuration dialog for this case successfully sent via wired WAN
Test2 without %nl
User: Event reporting rules Failover Switched to main and Switched to failover configured without %nl
User: Logged in to CLI, executed logread -f
User: Wired WAN plug pulled
System: Failover to WiFi0
User: Screenshot from CLI saved in file “Success_Failover_Switched to Failover.PNG”
User: Wired WAN plug plugged in
User: Screenshot from CLI saved in file “Success_Failover_Switched to Main.PNG”
Hopefully these tests will help you narrow down the problem.
I want to clarify that when resetting the device to factory defaults, please avoid uploading the backup file to restore configurations. Instead, configure only the recipients and events reporting on the reset device to test whether it works correctly in a clean setup.
Regarding the tests you provided, it’s challenging to fully understand the situation without additional details, such as pictures or logs. Therefore, I’ve sent you a form to fill out. Once completed, I will contact you privately via email regarding this issue. For reference, please use the ticket ID “11425”.
Whoever it may concern or may be interested: I’ve done tests in detail and Teltonika support has handed over the issue to R&D team for further investigation.
Once this phenomenon has been clarified, I will report further.
Good morning, Marija,
another week has passed without a response from your R&D. I put a lot of work into resetting my router and carrying out and documenting tests; it was your request to do this. The least I can expect is a statement from R&D about what the problem is and, if applicable, an indication of whether and when it will be corrected. I would like you to proactively approach R&D and ask about the status of things.
Kind regards, Guenther
Good morning Marija, thank you for your email. No problem, I just wanted to remind you before your system simply closes the error case and stops communication.
I will answer your questions as follows.
1)
Not until yesterday. Yesterday I then carried out tests with a different provider and - you wouldn’t believe it - the event reports with the “%nl formatting” arrived.
2)
With the above result in mind, this question is also answered. It was not an update of the RUT955 firmware, but a coincidentally simultaneous change of the provider.
3)
I configured and tested an event rule “Config change, All”. The result was the same: test emails with %nl arrived for both providers, while the live emails only arrived for the alternative Provider (not Posteo).
I then copied the respective text strings from the emails (CTRL+A) and pasted them into a special editor that can display all control characters. Apart from the ASCII characters CR and LF, nothing was visible in either text string, and in particular there were no differences in the characters used.
As part of my extensive tests at the time, I sent you excerpts from the CLI communication. In the event of an error, the last two lines were three seconds apart: “Sending Email to …” and “Failed to send email to …” I think that only analyzing the cause of the second message will help us.
Last note: yesterday I received an email on my Posteo account before your email. Sender: testas1@zohomail.eu, Recipient: guenther.gredy@posteo.de, Subject: “Test-New DHCP Client_Connected from WiFi”, Content: a text formatted with %nl. I don’t know the background, but it wasn’t a test email and it was correctly formatted.
That’s it for now. I look forward to hearing from you again.
The email you received was sent by our developer to test whether Posteo can receive emails from other platforms. If using other platforms does not cause any issues, and if Posteo received the update and the correct email from another mail platform, we can assume that the problem lies with how Posteo’s POP3 server formats the email.
Unfortunately, this issue is on Posteo’s side, which we are unable to resolve from our end.
Hello Marija,
thank you for your email and your continuous support.
Thanks to the tests carried out by your development department, the problem was clearly
narrowed down.
Now this is probably the classic issue of two technical systems from different manufacturers communicating with each other.
We now know that my provider’s outgoing mail server is not able to send the email with the event text of your router formatted with %nl.
Right at the beginning I already pointed out that it is not clear to me why my provider’s outgoing mail server can send the test email, which was also formatted with %nl, but not the email of a real event (e.g. failover). So there must be another difference between the texts generated in RUT955 for the test email and the live email.
I will not get any further without your help; I can’t go to my provider and say, “Something is wrong with your outgoing mail server.” So I repeat my request to you to explain to me the difference between a test email and a live event email in terms of their content. Perhaps you can also explain to me the cause of the error message in the RUT955, “Failed to send email to guenther.gredy@posteo.de.”; my provider’s outgoing mail server must have sent an error message to the RUT955. I would be very grateful for an answer to these two questions. With this information I could then go to my provider with a good chance of success.
Thank you very much for your effort.
Kind regards, Guenther
This difference arises because test emails and event emails are sent via two separate programs—test emails are sent using the sendmail service, while event emails are sent via curl.
Unfortunately, we cannot determine the exact cause of the error as we have access to the same information as you do. More in-depth debugging would require modifying the program’s code, recompiling, and reinstalling it.
If you’d like to obtain a more detailed error message, you can try sending test emails using the curl tool—the same one used by the Events Reporting feature. Here’s a basic tutorial that might help: Using curl to send email.
Hello Marija,
thank you for answering my questions. I understand that the problem is not caused by problematic characters within the event messages, but obviously by using this curl program in RUT955 which seems - for any reason - not to be compatible with the software of my email provider, if the event message contains %nl. Strange!
That’s the point were I have to give up hope solving the problem.
Hello Marija,
the problem is still bothering me. There is a way to experiment with CURL under Windows 10. To get further, I would need two things from Teltonika:
The text string of a message with %nl that is passed to the CURL program for sending
The complete command line of the CURL call in question
That would be a help.
Thanks in advance.
Best regards
Guenther
Good morning Marija, do you think there is still a way to give me this information? My request is not about information that can only be obtained by modifying the code, recompiling and reinstalling, but simply by inspecting the code, i.e. searching the source code. This would enable me to ask Posteo more specifically. Please let me know so that I can move forward. Many thanks and best regards, Guenther
Hello Marija, although Teltonika is not prepared to continue the communication regarding this problem, I would like to ask you to keep the case open and extend the period for automatic closing of the case by, say, 14 days. With your tip about CURL, I was able to reproduce the problem and came to an interesting result. Before I share this with you and the community, however, I would like to wait for confirmation from my email provider. Many thanks and best regards, Guenther
