SMS Server Tools 3
This site is hosted by Kekekasvi.com
 Menu
Basic information:
Additional information:
Support:
Get SMS Server Tools 3:
Additional Options

 Sponsored links

 Search
Custom Search

 Visitor locations
 
 SMS Server Tools 3 Community
Welcome, Guest. Please login or register. Fri Mar 29, 2024 09:36
SMSTools3 Community » Feature requests Bottom

[included in 3.1.7] i wrote code to connect to network modems, is somebody interested in it?

Login and Post Reply

Page:  1

Author Post
Member
Registered:
Mar 2010
Location: Germany
Hello,

i wrote a quick hack (to be precise, i copied it from interceptty) to enable smsd to connect directly to network modems like multitechs multimodem MTCBA-G-EN.

I just didn't want to use additional software like interceptty or socat to connect to the network port. If somebody is interested, i would like to donate this code because i think this is a common problem.

Hubert


« Last edit by hgilch on Thu Mar 18, 2010 11:38, 170 months ago. »
Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
That would be great! I do not know how widely network port's are in use, but I know that some users have that kind of setup, for example when there is no coverage inside the server room and therefore a modem is running outside. I also have tested interceptty, but do not have it on a daily use.

Please feel free to publish the patch (or changes and additions in some form) here. While I'm checking how to implement this enhancement to the next official version, users may apply the patch without waiting for the new version.

Member
Registered:
Mar 2010
Location: Germany
Topic owner
keke wrote
Please feel free to publish the patch (or changes and additions in some form) here. While I'm checking how to implement this enhancement to the next official version, users may apply the patch without waiting for the new version.

I'd like to, but i cannot find some means to upload the patch (about 4KB), or am i missing something?
:-(

Hubert

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
As it's an ASCII file (or files), just paste it into you new post and surround it with Code tags.

Member
Registered:
Mar 2010
Location: Germany
Topic owner
keke wrote
As it's an ASCII file (or files), just paste it into you new post and surround it with Code tags.

OK, here it is (diff against version 3.1.6):



File examples/smsd.conf.net is an example conf file with network modems, the syntax is easy,
every device which starts with "@" is treated as a socket device you have to supply hostname or ip number and a port: @<host_or_ip>:<port>

Hubert


« Last edit by keke on Mon Mar 29, 2010 08:58, 170 months ago. »
Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Thank's for the patch. It looks good and very straight forward. I will try to test it during the weekend.

Some questions:

You have used rtscts = no setting, probably this is mandatory and should default to "no" when a socket is used?

Did you got some errors with higher baudrate than 2400, or without send_delay of 10 milliseconds?

What is your opinion about the reliability of the connection?

Member
Registered:
Mar 2010
Location: Germany
Topic owner
keke wrote
Thank's for the patch. It looks good and very straight forward. I will try to test it during the weekend.

Some questions:

You have used rtscts = no setting, probably this is mandatory and should default to "no" when a socket is used?

Did you got some errors with higher baudrate than 2400, or without send_delay of 10 milliseconds?

I'm afraid i didn't test it without those settings. I found those configuration entries at netways.de but those were with an external interceptty. I think they are meaningless and the ioctl-calls will do nothing, but i have to test it. Unfortunately, i sent the two modems i had to our customer, so i have to wait till they have arrived to test this.

keke wrote
What is your opinion about the reliability of the connection?

Oh, very good, i had it running for some days and disconnected the modems from power and they always came back online after some timeout. smsd itself is very good at closing and reopening the device in case of timeouts ;-)

I really was astonished how good it works because it seemed too easy :-)

Hubert

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Your patch works very well :).

Because of some reason, on one machine (Debian GNU/Linux) smsd always starts with single communication timeout. After this everything works well, even when connection is closed while smsd is idle.

On Cygwin, it seems that fcntl() opens the connection. After this, connect() will fail with EISCONN error (Transport endpoint is already connected). This errno can be tested in the loop, but moving fcntl()'s after the while loop, the issue does not happen and everything works well on Cygwin too. ( In the loop there is tries = 1; which obviously should be tries++; ),

With a socket, setmodemparams() can be skipped because those settings does not have any effect.

If a connection breaks while it's in use, smsd cannot recover it. Calls write() and/or read() will never return, and the modem process goes <defunct>. This however is not a very bad issue, because it can be detected by the watchdog which is watching the ps list.

Member
Registered:
Mar 2010
Location: Germany
Topic owner
keke wrote
Your patch works very well :).

Thanks.
keke wrote
Because of some reason, on one machine (Debian GNU/Linux) smsd always starts with single communication timeout. After this everything works well, even when connection is closed while smsd is idle.

I saw this also sometimes in my setup (SLES 9), but it is nothing to worry about, it just means that it takes more than 5 sec. to establish the connection
keke wrote
On Cygwin, it seems that fcntl() opens the connection. After this, connect() will fail with EISCONN error (Transport endpoint is already connected). This errno can be tested in the loop, but moving cntl()'s after the while loop, the issue does not happen and everything works well on Cygwin too.

I could only test my SLES setup.
keke wrote
In the loop there is tries = 1; which obviously should be tries++;

No, it should be an endless loop because if it times out, modeminit returns with a valid device handle but the connection does not work and smsd hangs. So tries is only used to suppress the first timeout message in the logfile, which is always meaningless.
keke wrote
With a socket, setmodemparams() can be skipped because those settings does not have any effect.

That's true
keke wrote
If a connection breaks while it's in use, smsd cannot recover it. Calls write() and/or read() will never return, and the modem process goes <defunct>. This however is not a very bad issue, because it can be detected by the watchdog which is watching the ps list.

Is there a watchdog in smsd itself? (I didn't have to go very deep into the source because it, at least the modeminit part, is very well structured)

Hubert

Member
Registered:
Mar 2010
Location: Germany
Topic owner
hgilch wrote
keke wrote
In the loop there is tries = 1; which obviously should be tries++;

No, it should be an endless loop because if it times out, modeminit returns with a valid device handle but the connection does not work and smsd hangs. So tries is only used to suppress the first timeout message in the logfile, which is always meaningless.

I forgot: only the && (tries <= 12) part of the while-statement ist superfluous because tries never reaches 12 ;-)

Hubert

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
hgilch wrote
keke wrote
If a connection breaks while it's in use, smsd cannot recover it. Calls write() and/or read() will never return, and the modem process goes <defunct>. This however is not a very bad issue, because it can be detected by the watchdog which is watching the ps list.

Is there a watchdog in smsd itself? (I didn't have to go very deep into the source because it, at least the modeminit part, is very well structured)

No there is not. External watchdog is needed, also because a process should not "watch itself".

hgilch wrote
hgilch wrote
keke wrote
In the loop there is tries = 1; which obviously should be tries++;

No, it should be an endless loop because if it times out, modeminit returns with a valid device handle but the connection does not work and smsd hangs. So tries is only used to suppress the first timeout message in the logfile, which is always meaningless.

I forgot: only the && (tries <= 12) part of the while-statement ist superfluous because tries never reaches 12 ;-)

I will still test this more, but I assume that lot of failed connections means a permanent problem. To detect this, something should be done. Usually the alarmhandler is called and it can do the actions which are required. Because of this, I have slightly changed the function. There is no more infinite loop, after too many errors it will return without a device handle and the caller function will write the log and call the alarmhandler. The "indent" is from version 3.2:



Member
Registered:
Mar 2010
Location: Germany
Topic owner
keke wrote
I will still test this more, but I assume that lot of failed connections means a permanent problem. To detect this, something should be done. Usually the alarmhandler is called and it can do the actions which are required. Because of this, I have slightly changed the function. There is no more infinite loop, after too many errors it will return without a device handle and the caller function will write the log and call the alarmhandler. The "indent" is from version 3.2:

OK, but will smsd then try to initialize the device again? The customer for whom i have implemented this has to modems for redundancy, one is located 700km away from the server with leased line/VPN connections between. It would be bad if in case of a temporary network outage one of the modems would be permanently disabled.

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
hgilch wrote
keke wrote
I will still test this more, but I assume that lot of failed connections means a permanent problem. To detect this, something should be done. Usually the alarmhandler is called and it can do the actions which are required. Because of this, I have slightly changed the function. There is no more infinite loop, after too many errors it will return without a device handle and the caller function will write the log and call the alarmhandler. The "indent" is from version 3.2:

OK, but will smsd then try to initialize the device again? The customer for whom i have implemented this has to modems for redundancy, one is located 700km away from the server with leased line/VPN connections between. It would be bad if in case of a temporary network outage one of the modems would be permanently disabled.

By default smsd (modem process) creates an alarm and stops. While being stopped, that process is <defunct> in the ps list and can be detected if watchdog is used.

I change this functionality to:



Or perhaps we should use retries term...

With this kind of a setting a value -1 means "forever". Value 9999 means, with a previous code too, almost 14 hours of trying.

However, how it can be known that the network outage is temporary only? I mean that network comes back without any actions required. Perhaps in some cases some devices should be replaced, or some services restarted. Because of this, I wanted that an alarm is created using the alarmhandler.

With a long time of retrying we do not get any alarm with the current code. Probably there should be an additional setting socket_connection_alarm_after = <number of retries>, which could create an alarm while smsd still continues retrying?

Member
Registered:
Mar 2010
Location: Germany
Topic owner
keke wrote
Or perhaps we should use retries term...

Yes, it sounds better ;-)

keke wrote
With this kind of a setting a value -1 means "forever". Value 9999 means, with a previous code too, almost 14 hours of trying.

However, how it can be known that the network outage is temporary only? I mean that network comes back without any actions required. Perhaps in some cases some devices should be replaced, or some services restarted. Because of this, I wanted that an alarm is created using the alarmhandler.

With a long time of retrying we do not get any alarm with the current code. Probably there should be an additional setting socket_connection_alarm_after = <number of retries>, which could create an alarm while smsd still continues retrying?

I am satisfied with the infinite setting and you know smsd certainly better than me. If it is possible to create an alarm in this loop, it would be great.
For me, it is important that after an even prolonged network outage the modem comes online again because, unlike a directly connected modem, a network modem is most probably not defect if it is not reachable.

Hubert

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Feel free to try the new 3.1.7beta2. :)

Login and Post Reply

Page:  1

SMSTools3 Community » Feature requests Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.