|
|
SMS Server Tools 3 Community |
Welcome, Guest. The forum is currently read-only, but will open soon. |
Sun Dec 08, 2024 15:05 |
Login and Post Reply
Page: 1
Author |
Post |
|
#1 Thu Mar 18, 2010 11:36, 179 months ago.
|
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, 179 months ago. »
|
|
#2 Thu Mar 18, 2010 13:19, 179 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.
|
|
#3 Thu Mar 18, 2010 14:18, 179 months ago.
|
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
|
|
#4 Thu Mar 18, 2010 16:20, 179 months ago.
|
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.
|
|
#5 Thu Mar 18, 2010 16:33, 179 months ago.
|
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, 178 months ago. »
|
|
#6 Fri Mar 19, 2010 10:13, 179 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?
|
|
#7 Fri Mar 19, 2010 10:28, 179 months ago.
|
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
|
|
#8 Mon Mar 22, 2010 19:03, 179 months ago.
|
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.
|
|
#9 Tue Mar 23, 2010 08:31, 179 months ago.
|
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
|
|
#10 Tue Mar 23, 2010 08:35, 179 months ago.
|
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
|
|
#11 Tue Mar 23, 2010 18:40, 179 months ago.
|
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:
|
|
#12 Wed Mar 24, 2010 08:56, 179 months ago.
|
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.
|
|
#13 Wed Mar 24, 2010 10:35, 179 months ago.
|
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?
|
|
#14 Wed Mar 24, 2010 13:10, 179 months ago.
|
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
|
|
#15 Mon Mar 29, 2010 12:49, 178 months ago.
|
Administrator
Registered: May 2009
Location: Jyväskylä, Finland
|
Feel free to try the new 3.1.7beta2.
|
Login and Post Reply
Page: 1
Time in this board is UTC.
|
|
|
|
|
|
|