[BUG] smsc stop start

Hi All

There is a bug in the smsc stop/start admin interface. Before I fix it, I 
want to check that the soln we propose will work for the list.

The scenario is as follows:
Assume  you have more than one smsc group with the same smsc-id. eg one 
provider with 2 different host.
Ok when you use the stop-smsc code it stops the first smsc in the list with 
that smsc-id and not the others.
If you then start and stop and start again one ends up with both the links 
up, but not necessary to the two different hosts.

eg.. snips from status page
[snip]
     linka8    SMPP:web1.host.com:16252/16252:Clickatell: (online 21s, rcvd 
0, sent 0, failed 0, queued 0 dlrq 1 msgs)
     linka8    SMPP:web2.host.com:26252/26252:Clickatell: (online 24s, rcvd 
0, sent 0, failed 0, queued 0 dlrq 1 msgs)
[end snip]
[snip]
     linka8    SMPP:web1.host.com:16252/16252:Clickatell: (dead, rcvd 0, 
sent 0, failed 0, queued 0 dlrq 1 msgs)
     linka8    SMPP:web2.host.com:26252/26252:Clickatell: (online 73s, rcvd 
0, sent 0, failed 0, queued 0 dlrq 1 msgs)
[end snip]
[snip]
     linka8    SMPP:web2.host.com:26252/26252:Clickatell: (online 107s, 
rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs)
     linka8    SMPP:web1.host.com:16252/16252:Clickatell: (online 1s, rcvd 
0, sent 0, failed 0, queued 0 dlrq 1 msgs)
[end snip]
[snip]
     linka8    SMPP:web2.host.com:26252/26252:Clickatell: (dead, rcvd 0, 
sent 0, failed 0, queued 0 dlrq 1 msgs)
     linka8    SMPP:web1.host.com:16252/16252:Clickatell: (online 16s, rcvd 
0, sent 0, failed 0, queued 0 dlrq 1 msgs)
[end snip]
[snip]
     linka8    SMPP:web1.host.com:16252/16252:Clickatell: (online 31s, rcvd 
0, sent 0, failed 0, queued 0 dlrq 1 msgs)
     linka8    SMPP:web1.host.com:16252/16252:Clickatell: (online 1s, rcvd 
0, sent 0, failed 0, queued 0 dlrq 1 msgs)
[end snip]


I propose that the stop-smsc admin interface should stop ALL smsc links 
with the given smsc-id, similarly start-smsc should start/restart all smsc 
links with the given smsc-id


In addition there is a new memory leak. For each stop/start we end up with 
the following
2002-11-18 15:42:45 [0] DEBUG: Allocated by list_create_real at 
gwlib/list.c:71
2002-11-18 15:42:45 [0] DEBUG: Claimed by smsc2_start at gw/bb_smscconn.c:332


Nisan