Moin Daniel :)
(1) About ebd4d820b3b0d7ba5db3b25a14f407d0c7276044 "libiu: Use custom setupormodifieditemies function"
It seems you forgot to commit the actual function definition of ranap_decode_rab_setupormodifieditemies_fromlist() I got the caller of it only and thus can't compile as-is.
(2) About 38e2f1bca4e43414ed39a938d7c5d8bafe5e8533 " Revert "iu.c: avoid warning by declaring ranap_free_rab_setupormodifieditemies()"
There should be no need to silence this warning, the ranap_free_* functions are declared in libranap headers. In any case this will only obscure any real issue. Maybe osmo-iuh was not rebuilt completely (including generation of the c files from the python script).
This reverts commit 05ae5b1245f95bf765b42e49af7b2596e013f0a0. "
I declared ranap_free_rab_setupormodifieditemies() like that because it is indeed not declared in a header that is installed. Also a grep tells me that no ranap_free_* is found in any osmo-iuh header file at all. I also did a 'make regen' in osmo-iuh/src/ to no avail. By 'libranap headers' I assume you mean libosmo-ranap, or is there a libranap I'm not aware of yet?
If the ranap_free_* aren't in headers yet, I agree that they should be. I wanted to silence the warning without being sucked down the rabbit hole of autogenerated asn1 stuff. Any suggestions: more than welcome.
(3) In general, I would welcome to see more of your WIP work in publicly visible private branches, maturing as you go and merged to sysmocom/iu once ready. For one, having a backup of your work-in-progress in the git repos makes it harder to lose it due to hardware failure. More important for me though is that I can see what you're up to, e.g. I could possibly find the ranap_..._fromlist() function defintion now. It's of course opening up your "most private" code developments to the outside world, possibly some stupid commits will be seen by one or two hacker peers, but I think it's a healthy premise that we all commit mostly bollocks and all needs refinement anyway... once again: push it! :)
Ah, push it Push it good Ah, push it Pu-Push it real good -- Salt N Pepa (1987)
As always I'm open to opinions and suggestions...
~Neels
Hey Neels,
On Thu, 2016-02-18 at 23:45 +0100, Neels Hofmeyr wrote:
Moin Daniel :)
(1) About ebd4d820b3b0d7ba5db3b25a14f407d0c7276044 "libiu: Use custom setupormodifieditemies function"
It seems you forgot to commit the actual function definition of ranap_decode_rab_setupormodifieditemies_fromlist() I got the caller of it only and thus can't compile as-is.
osmo-iuh commit 635fac0c3eef has both the function and the declaration.
(2) About 38e2f1bca4e43414ed39a938d7c5d8bafe5e8533 " Revert "iu.c: avoid warning by declaring ranap_free_rab_setupormodifieditemies()"
There should be no need to silence this warning, the ranap_free_* functions are declared in libranap headers. In any case this will only obscure any real issue. Maybe osmo-iuh was not rebuilt completely (including generation of the c files from the python script). This reverts commit 05ae5b1245f95bf765b42e49af7b2596e013f0a0."
I declared ranap_free_rab_setupormodifieditemies() like that because it again) to add the function declarations to the ies_defs.h file.is indeed not declared in a header that is installed. Also a grep tells me that no ranap_free_* is found in any osmo-iuh header file at all. I also did a 'make regen' in osmo-iuh/src/ to no avail. By 'libranap headers' I assume you mean libosmo-ranap, or is there a libranap I'm not aware of yet? If the ranap_free_* aren't in headers yet, I agree that they should be. I wanted to silence the warning without being sucked down the rabbit hole of autogenerated asn1 stuff. Any suggestions: more than welcome.
Bummer, you're right. It seems the script doesn't generate the free() declarations. I'll fix that.
(3) I think it's a healthy premise that we all commit mostly bollocks and all needs refinement anyway... once again: push it! :)
Yeah, well, this time I did ;-)
On 19 Feb 2016, at 17:03, Daniel Willmann dwillmann@sysmocom.de wrote:
Hey Neels,
Yeah, well, this time I did ;-)
gsm_04_11.c: In function 'sms_route_mt_sms': gsm_04_11.c:318: error: 'struct gsm_subscriber_connection' has no member named 'bts' make[3]: *** [gsm_04_11.o] Error 1
progress.. new error.. whoever makes the build blue/green for a week.. will get some homemade chocolate cookies...
On Fri, Feb 19, 2016 at 08:23:15PM +0100, Holger Freyther wrote:
gsm_04_11.c: In function 'sms_route_mt_sms': gsm_04_11.c:318: error: 'struct gsm_subscriber_connection' has no member named 'bts' make[3]: *** [gsm_04_11.o] Error 1
Interesting, I don't see any reference to 'bts' anywhere in that file. My line 318 looks like:
osmo_counter_inc(conn->network->stats.sms.no_receiver);
And I changed it in d03faa4bacd4d2a8b9155faf5219a948b73f481c
- osmo_counter_inc(conn->bts->network->stats.sms.no_receiver); + osmo_counter_inc(conn->network->stats.sms.no_receiver);
which is part of the sysmocom/iu branch.
Does that help??
(BTW I also fixed a test expectation in osmo-iuh today, maybe that's worth half a chocolate cookie?)
~Neels
On 20 Feb 2016, at 16:39, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
which is part of the sysmocom/iu branch.
Does that help??
go left, pick up compiler-error
smpp_openbsc.c: In function 'deliver_to_esme': smpp_openbsc.c:536: error: 'struct gsm_subscriber_connection' has no member named 'lchan' smpp_openbsc.c:537: error: 'struct gsm_subscriber_connection' has no member named 'lchan'
this is an interesting case. We want to annotate the SMPP message with extra values of from where the SMS came from. This is possible in the osmo-nitb and should probably remain possible. Do you see a way to make this work?
I am really late with this but as part of the bsc_api, I envisioned that we would have a msc_subscriber_connection if we ever split things up :}
holger
On Sat, Feb 20, 2016 at 07:54:11PM +0100, Holger Freyther wrote:
go left, pick up compiler-error
smpp_openbsc.c: In function 'deliver_to_esme': smpp_openbsc.c:536: error: 'struct gsm_subscriber_connection' has no member named 'lchan' smpp_openbsc.c:537: error: 'struct gsm_subscriber_connection' has no member named 'lchan'
Argh, my own build excludes SMPP for some reason, so I didn't catch that one with my "guaranteed to catch all" method.
Anyway:
this is an interesting case. We want to annotate the SMPP message with extra values of from where the SMS came from. This is possible in the osmo-nitb and should probably remain possible. Do you see a way to make this work?
I haven't really investigated at all about plugging osmo-bsc back to osmo-cscn with an A-interface, because the focus is so far firmly on IuCS.
Worst case we could introduce a "vendor specific" DTAP message sent to the MSC, possibly a feature enabled by a vendor specific BSSMAP message sent by the MSC fist?? (wildly guessing)
But I'll start off by enabling SMPP in my build ... :/
I am really late with this but as part of the bsc_api, I envisioned that we would have a msc_subscriber_connection if we ever split things up :}
Not that late really, I looked at bsc_api briefly but saw that it wasn't helping for IuCS, so I postponed dissecting the (numerous) details of it to another day. It should come naturally when the A-interface is created. But in fact my foggy vision so far is that the struct bsc_api will not actually survive, since the A-interface rx, like IuCS rx, will call functions directly instead of keeping a struct of function pointers... IMHO A clearly structured header file would do a nicer job at highlighting the MSC<->BSC entry points. I am also presuming that we will drop osmo-nitb as such and replace it with "please run osmo-bsc plugged into osmo-cscn", BTW.
Thoughts welcome.
~Neels
On Sun, Feb 21, 2016 at 11:16:45AM +0100, Neels Hofmeyr wrote:
But I'll start off by enabling SMPP in my build ... :/
I've pushed a commit that disables the Osmocom SMPP TLVs for now. The build should work now. Maybe this time it actually will ;)
~Neels
On 21 Feb 2016, at 12:26, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
On Sun, Feb 21, 2016 at 11:16:45AM +0100, Neels Hofmeyr wrote:
But I'll start off by enabling SMPP in my build ... :/
I've pushed a commit that disables the Osmocom SMPP TLVs for now. The build should work now. Maybe this time it actually will ;)
i triggered the coverity build.. we will see in a couple of minutes.
On 21 Feb 2016, at 12:26, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
On Sun, Feb 21, 2016 at 11:16:45AM +0100, Neels Hofmeyr wrote:
But I'll start off by enabling SMPP in my build ... :/
I've pushed a commit that disables the Osmocom SMPP TLVs for now. The build should work now. Maybe this time it actually will ;)
osmo_bsc_main.c: In function 'main': osmo_bsc_main.c:206: error: too few arguments to function 'bsc_vty_init' osmo_bsc_main.c:221: warning: implicit declaration of function 'bsc_bootstrap_network'
then maybe disable the osmo-bsc right now?
On Sun, Feb 21, 2016 at 01:57:27PM +0100, Holger Freyther wrote:
then maybe disable the osmo-bsc right now?
Yeah in fact that's also disabled in my build. I'm looking at it now for a few minutes, but why not disable it until we got it back on its feet...
~Neels
On Mon, Feb 22, 2016 at 10:48:10AM +0100, Neels Hofmeyr wrote:
On Sun, Feb 21, 2016 at 01:57:27PM +0100, Holger Freyther wrote:
then maybe disable the osmo-bsc right now?
Yeah in fact that's also disabled in my build. I'm looking at it now for a few minutes, but why not disable it until we got it back on its feet...
sysmocom-iu's osmo-bsc is compiling now. At least for me :P verbose comments in c01abec.
~Neels
On 21 Feb 2016, at 11:16, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
Not that late really, I looked at bsc_api briefly but saw that it wasn't helping for IuCS, so I postponed dissecting the (numerous) details of it to another day. It should come naturally when the A-interface is created. But in fact my foggy vision so far is that the struct bsc_api will not actually survive, since the A-interface rx, like IuCS rx, will call functions directly instead of keeping a struct of function pointers... IMHO A clearly structured header file would do a nicer job at highlighting the MSC<->BSC entry points. I am also presuming that we will drop osmo-nitb as such and replace it with "please run osmo-bsc plugged into osmo-cscn", BTW.
The initial idea was that at the "MSC" the "Complete Layer3 message" (the initial message) would arrive. The MSC would then create an instance of a msc_subscriber_connection (and add a backpointer to the gsm_subscriber_connection which then probably should be called bsc_subscriber_connection). The MM, CC and other code should then refer to the msc_subscriber_connection. In case of osmo-cscn the msc_subscriber_conn would point to the "Iu" definition and for osmo-nitb it would still have the gsm_subscriber_conn backpointer.
The other part was that there should be something like msc_api inside the MM/CC code that either directly maps to the BSC code or in case of osmo-cscn send it to the HNBGW.
anyway, you will come up with something that makes sense too
holger
On Sun, Feb 21, 2016 at 02:10:32PM +0100, Holger Freyther wrote:
The initial idea was that at the "MSC" the "Complete Layer3 message" (the initial message) would arrive. The MSC would then create an instance of a msc_subscriber_connection (and add a backpointer to the gsm_subscriber_connection which then probably should be called bsc_subscriber_connection). The MM, CC and other code should then refer to the msc_subscriber_connection. In case of osmo-cscn the msc_subscriber_conn would point to the "Iu" definition and for osmo-nitb it would still have the gsm_subscriber_conn backpointer.
The other part was that there should be something like msc_api inside the MM/CC code that either directly maps to the BSC code or in case of osmo-cscn send it to the HNBGW.
The thing is, I need to get to know most of the code first. And I'm so far just trying "to reach the other side" and would like to look at the rackety bridge I built in a second iteration. I presume the basic building blocks will be useful to rearrange them in a bigger picture, which I'm in my head still busy enriching with the details.
So I would first like to see IuCS do something useful and then let's look at the hopefully limited madness I created to obtain that.
Today I'm going to hunt segfaults in hnbgw so I can continue testing.
~Neels
whoever got what wrong and when, I did get it all working now, thanks :)
~Neels
-
Daniel Willmann -
Holger Freyther -
Neels Hofmeyr