http api returns Err: 612 when trying to send sms

[Wouter Camps]

Hi,

Since a couple of days our SF400-G-EU returns ‘Err: 612’ (System Error – Memory Allocation Failure, according to the manual). At the same time ‘Error writing API request to temp file’ lines started to appear in the syslog. The login screen of the admin webinterface still shows up when trying to connect to the device using a web browser, but when we click ‘login’, there’s no response. We tried to power down and power up the isms and even did a reset to factory settings using the reset button at the back of the device, but the problem remains. The firmware level is 1.50.7, but as we are basically stuck at the login screen, we have no way to try to upgrade or even just look around in the logs or settings. Has anyone any experience with this kind of problems and any suggestion what we can still try to do? (e.g. is there any way to access the console of the device using the serial connector and maybe take a look around at the lower level functioning?)

[Bryon Davis]

Hi Wouter,
On the older firmware there can sometimes be issues with temp files building up.

You can try the steps below and see if it resolves your issue. If you still have problems, then you should create a support case at support.multitech.com.

1. Telnet to the IP address of the iSMS on port 2222.

2. Login with admin credentials.

3. At the # prompt enter “cd /usr/local/tmp”

4. Enter “ls” and note how many files are in this directory. If there are several pages, then this may be causing the 608/612 problem, continue on steps below.
5. Enter “cd ..”

6. Enter “rm –r tmp”. Note if it returns an error “rm: unable to remove ‘tmp’: Directory not empty, then enter “cd tmp” and check how many files exist with “ls”. If there are only a handful of files then skip the remaining steps and reboot.

7. Enter “mkdir tmp”

8. Reboot the SF800.

Bryon

[Wouter Camps]

Hi Bryon,

Thanks for your fast response, but because of the time zone difference I guess, it took more time than I wanted to waste (with no more backup device, failure of our second gateway would mean no more alerting at all and the ‘disk space like’ problem seemed a scenario that could also happen to our only remaining device). So I did a grep on ‘ssh’ and ‘telnet’ on the exported config of our other gateway and already figured out there was an open telnet port at 2222 like you said in your post. I logged in and noticed with df -k there was no disk space problem (‘/usr/local’) was only 14% full, but even so, I wasn’t able to make a new file in /usr/local/tmp using ‘touch’. I tried to ‘rm /usr/local/tmp/*’, but I got an error message, saying ‘sh: /bin/rm: Argument list too long’. ‘ls /usr/local/tmp/*’ also took very long and resulted in a huge huge number of files. I found some patterns to rm a lot of files at once (e.g. ‘rm boa-session-V3*’). Next, I retried to log in using the web interface, and this time I got past the login screen! So in the end, the problem didn’t seem to be the disk space, but the sheer number of files.

Can you tell me what we can do to avoid this problem in the future, because as I see it, it’s just a question of time before the number of files in /usr/local/tmp grows too big again and our gateway(s) will cease to function again. Is this firmware related (we’re currently at 1.50.7) and solved in a more recent software version? Or is there a way to clean ‘/usr/local/tmp’ on a regular basis by using some function in the webinterface? It seems there should be at least some sort of cron job in the appliance deleting ‘old’ tmp files after a while.

[Bryon Davis]

Hi Wouter,
The newer firmware resolves this issue.

Please upgrade to the latest firmware from the link below. I’m including a link for SF100 for the convenience of others. The instructions for upgrading is included in the zip file.

SF100 v1.51.28:
https://webfiles.multitech.com/engineering/unofficial-releases/iSMS%20(Formerly%20SMSFinder)/Firmware/SF100/1.51.28/SF100-u-v1.51.28-25Nov2014.zip

SF400 and SF800 v1.51.28:
https://webfiles.multitech.com/engineering/unofficial-releases/iSMS%20(Formerly%20SMSFinder)/Firmware/SF400_SF800/1.51.28/SF400-800-u-v1.51.28-25Nov2014.zip

Bryon

[Wouter Camps]

Hi Bryon,

I upgraded the gateway to the latest firmware as a part of my troubleshooting, but this didn’t seem to change anything about the number of ‘boa-session-*’ files already present in ‘/usr/local/tmp’. More than a day after the upgrade to firmware version 1.51.28, more than 78 000 files were still present in the tmp directory (after I’d already done a lot of manual deleting the previous day). In the end I deleted all ‘boa-session-*’ files manually. Can you confirm that the new firmware is supposed to avoid creating those files in the first place (or cleaning them up immediately) instead of just cleaning up older files like I presumed?

Wouter

[Bryon Davis]

Hi Wouter,
The new firmware won’t clean up the existing ‘/usr/local/tmp’ files, but it should prevent new files from building up over time. To remove the existing ‘/usr/local/tmp’ files, you would need to follow the directions previously given and manually delete the files using a telnet session.

Sorry for the inconvenience.

Bryon

[Wouter Camps]

Bryon,

Thx for clearing out the exact nature of the fix.
All tmp files have already been deleted, it took a while, but luckily our other isms appliance didn’t suffer from the same problem so I didn’t have to do it twice. I guess the ‘boa-session-*’ files on our problematic isms where generated under special circumstances that never occured like that on the second one.

Kind regards,
Wouter

[Author]

Posts