Hi,
some problems with latest git clone and nanoBTS 165AU...
<0002> gsm_04_08.c:412 -> LOCATION UPDATE ACCEPT <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. <0002> gsm_04_08.c:754 -> MM INFO <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. <0002> gsm_subscriber.c:337 Subscriber 262620001000026 ATTACHED LAC=10 <0003> gsm_04_08.c:1158 TX APPLICATION INFO id=0x00, len=4 <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0002> gsm_04_08.c:1045 TMSI Reallocation Completed. Subscriber: 262620001000026 <0000> chan_alloc.c:429 (bts=0,trx=0,ts=0,ss=0) starting release sequence <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:618 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0004> bsc_api.c:638 Got data in non active state(RELEASE REQUESTED), discarding. <0019> input/ipaccess.c:454 Bad signalling message,sign_link returned error <0019> input/ipaccess.c:260 Forcing socket shutdown with no signal link set <001b> bsc_init.c:337 Lost some E1 TEI link: 1 0x81e4768 <001b> bsc_init.c:337 Lost some E1 TEI link: 2 0x81e4768
I have no clue if that is a problem of configuration, nanoBTS or abis library. With an old version (Feb 2012), the message... <0019> ipaccess.c:425 Bad signalling message,sign_link returned error. ...appears too, but socket is not being shut down.
Thanks, LM
On Tue, Oct 16, 2012 at 10:44:00AM +0200, Lennart Müller wrote:
Hi,
some problems with latest git clone and nanoBTS 165AU...
<0002> gsm_04_08.c:412 -> LOCATION UPDATE ACCEPT <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x02 to MS. <0002> gsm_04_08.c:754 -> MM INFO <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 05) Sending 0x32 to MS. <0002> gsm_subscriber.c:337 Subscriber 262620001000026 ATTACHED LAC=10 <0003> gsm_04_08.c:1158 TX APPLICATION INFO id=0x00, len=4 <0001> gsm_04_08.c:116 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS. <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0002> gsm_04_08.c:1045 TMSI Reallocation Completed. Subscriber: 262620001000026 <0000> chan_alloc.c:429 (bts=0,trx=0,ts=0,ss=0) starting release sequence <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 0 Type: 1 <0004> abis_rsl.c:618 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0004> abis_rsl.c:1017 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel <0000> abis_rsl.c:1542 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0004> bsc_api.c:638 Got data in non active state(RELEASE REQUESTED), discarding. <0019> input/ipaccess.c:454 Bad signalling message,sign_link returned error <0019> input/ipaccess.c:260 Forcing socket shutdown with no signal link set <001b> bsc_init.c:337 Lost some E1 TEI link: 1 0x81e4768 <001b> bsc_init.c:337 Lost some E1 TEI link: 2 0x81e4768
I have no clue if that is a problem of configuration, nanoBTS or abis library. With an old version (Feb 2012), the message...
<0019> ipaccess.c:425 Bad signalling message,sign_link returned error.
...appears too, but socket is not being shut down.
This was recently changed to perform robust error handling.
But thinking it's too much to close the signalling link on recoverable errors coming from the signalling layer.
Would you give a try to the following patch? Thanks.
2012/10/16 Pablo Neira Ayuso pablo@gnumonks.org
This was recently changed to perform robust error handling.
But thinking it's too much to close the signalling link on recoverable errors coming from the signalling layer.
Would you give a try to the following patch? Thanks.
Hi Pablo, thanks for the patch.
msgb_free(msg); causes signal 6, I tried the following and it works, but might cause a memory leak...
if (e1i_ts->line->ops->sign_link(msg) < 0) { /* Don't close the signalling link if the upper layers report * an error, that's too strict. */ LOGP(DLINP, LOGL_ERROR, "Bad signalling message," "sign_link returned error\n"); ret = -EINVAL; //msgb_free(msg); return(ret); }
LM
On Tue, Oct 16, 2012 at 01:11:34PM +0200, Lennart Müller wrote: [...]
Hi Pablo, thanks for the patch. msgb_free(msg); causes signal 6, I tried the following and it works, but might cause a memory leak...
if (e1i_ts->line->ops->sign_link(msg) < 0) { /* Don't close the signalling link if the upper layers report * an error, that's too strict. */ LOGP(DLINP, LOGL_ERROR, "Bad signalling message," "sign_link returned error\n"); ret = -EINVAL; //msgb_free(msg); return(ret);
I see. I guess you were hitting SIGABRT also before the patch then.
New patch attached. If you're OK with it, I'll push it to git.
On Tue, Oct 16, 2012 at 02:07:14PM +0200, Pablo Neira Ayuso wrote:
I see. I guess you were hitting SIGABRT also before the patch then.
New patch attached. If you're OK with it, I'll push it to git.
Hi Pablo,
please be careful about the semantic. What is the semantic when calling the callback? Does the called one always need to free the msgb? is that the case with all users of libosmo-abis?
thanks holger
Hi Holger,
On Tue, Oct 16, 2012 at 02:23:51PM +0200, Holger Hans Peter Freyther wrote:
On Tue, Oct 16, 2012 at 02:07:14PM +0200, Pablo Neira Ayuso wrote:
I see. I guess you were hitting SIGABRT also before the patch then.
New patch attached. If you're OK with it, I'll push it to git.
Hi Pablo,
please be careful about the semantic. What is the semantic when calling the callback? Does the called one always need to free the msgb? is that the case with all users of libosmo-abis?
->sign_link(...) calls abis_nm_rcvmsg / abis_rsl_rcvmsg that release the msgb.
Still, there some error paths in abis_nm_rcvmsg that leak the msgb:
if (oh->placement != ABIS_OM_PLACEMENT_ONLY) ... if (oh->sequence != 0) ... switch (oh->mdisc): unknown oh->mdisc
But in the general path, the semantic is consistent.
I'll send a patch to fix this for openbsc.
In conclusion, I think my patch is correct, please ack and I'll push to git.
Pablo Neira Ayuso wrote:
+++ b/src/input/ipaccess.c @@ -450,10 +450,13 @@ static int handle_ts1_read(struct osmo_fd *bfd) goto err_msg; } if (e1i_ts->line->ops->sign_link(msg) < 0) {
/* Don't close the signalling link if the upper layers report* an error, that's too strict. BTW, the signalling layer is* resposible for releasing the message.*/
goto err;}
return 0;
If the code flow will be to fall through to the 'return 0' statement then I suggest to also remove the ret = -EINVAL line inside the condition. I think it creates some confusion about what is really intended.
//Peter
On Tue, Oct 16, 2012 at 03:29:38PM +0200, Peter Stuge wrote:
Pablo Neira Ayuso wrote:
+++ b/src/input/ipaccess.c @@ -450,10 +450,13 @@ static int handle_ts1_read(struct osmo_fd *bfd) goto err_msg; } if (e1i_ts->line->ops->sign_link(msg) < 0) {
/* Don't close the signalling link if the upper layers report* an error, that's too strict. BTW, the signalling layer is* resposible for releasing the message.*/
goto err;}
return 0;
If the code flow will be to fall through to the 'return 0' statement then I suggest to also remove the ret = -EINVAL line inside the condition. I think it creates some confusion about what is really intended.
Right Peter, I'll mangle the patch to do so. Thanks.
-
Holger Hans Peter Freyther -
Lennart Müller -
Pablo Neira Ayuso -
Peter Stuge