18 Feb
2016
18 Feb
'16
11:45 p.m.
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
19 Feb
19 Feb
5:03 p.m.
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 ;-)
--
- Daniel Willmann <dwillmann(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
8:23 p.m.
On 19 Feb 2016, at 17:03, Daniel Willmann
<dwillmann(a)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...
20 Feb
20 Feb
4:39 p.m.
New subject: no member named 'bts' -- was: sysmocom/iu: your commits from today
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
7:54 p.m.
New subject: no member named 'bts' -- was: sysmocom/iu: your commits from today
On 20 Feb 2016, at 16:39, Neels Hofmeyr
<nhofmeyr(a)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
21 Feb
21 Feb
11:16 a.m.
New subject: no member named 'bts' -- was: sysmocom/iu: your commits from today
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
12:26 p.m.
New subject: no member named 'bts'
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
12:29 p.m.
New subject: no member named 'bts'
On 21 Feb 2016, at 12:26, Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> wrote:
On Sun, Feb 21, 2016 at 11:16:45AM +0100, Neels Hofmeyr wrote:
i triggered the coverity build.. we will see in a couple of minutes.
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 ;)
1:57 p.m.
New subject: no member named 'bts'
On 21 Feb 2016, at 12:26, Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> wrote:
On Sun, Feb 21, 2016 at 11:16:45AM +0100, Neels Hofmeyr wrote:
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?
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 ;)
22 Feb
22 Feb
10:48 a.m.
New subject: no member named 'bts'
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
12:20 p.m.
New subject: no member named 'bts'
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:
sysmocom-iu's osmo-bsc is compiling now. At least for me :P
verbose comments in c01abec.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
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...
21 Feb
21 Feb
2:10 p.m.
New subject: no member named 'bts' -- was: sysmocom/iu: your commits from today
On 21 Feb 2016, at 11:16, Neels Hofmeyr
<nhofmeyr(a)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
22 Feb
22 Feb
10:46 a.m.
New subject: no member named 'bts' -- was: sysmocom/iu: your commits from today
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
20 Feb
20 Feb
3:43 p.m.
whoever got what wrong and when, I did get it all working now, thanks :)
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
2988
days inactive
2992
days old
13 comments
3 participants
participants (3)
-
Daniel Willmann -
Holger Freyther -
Neels Hofmeyr