I'm taking a brief look at how osmo-hnbgw would send a Reset to the CN. So I'd like to be notified when osmo-hnbgw first establishes a link to a CN component, and then send a Reset message on it.
I see there's an OSMO_SCU_PRIM_N_CONNECT, but am I right that this is related to actual messages being sent on the link, and can't be used to get notified about a connection per se?
Link establishment traces out as: hnbgw_cnlink_init() osmo_sua_client_connect() osmo_stream_cli_open2() <-- includes a timer that retries connecting
In the osmo_stream_cli_* API, there's a connect_cb, but it isn't used from osmo_sua_client_*.
So I would * add a connect cb to struct osmo_sua_user (and osmo_sua_user_create()) * call it from a static cb fed to osmo_stream_cli_set_connect_cb() in osmo_sua_client_connect()
Yes?
Thanks, ~Neels
Hi Neels,
On Mon, Apr 04, 2016 at 03:57:07PM +0200, Neels Hofmeyr wrote:
I'm taking a brief look at how osmo-hnbgw would send a Reset to the CN. So I'd like to be notified when osmo-hnbgw first establishes a link to a CN component, and then send a Reset message on it.
I see there's an OSMO_SCU_PRIM_N_CONNECT, but am I right that this is related to actual messages being sent on the link, and can't be used to get notified about a connection per se?
Please check the ITU specs for SCCP, specifically the N-CONNECT primitive at the SCCP user SAP. I think it is quite clear that there's a full set of N-CONNECT with full request/confirm (initiator) / indication/response (responder) primitives. For example, Table 1 and Figure 8 of Q.711 should give a good idea.
This should be the guideline against which we implement the SCCP provider underneath our SCCP USER SAP.
On Mon, Apr 04, 2016 at 04:09:05PM +0200, Harald Welte wrote:
Please check the ITU specs for SCCP, specifically the N-CONNECT Figure 8 of Q.711 should give a good idea.
I see those specs, yet it is hard to put them in practical perspective.
My point is, I don't see N-CONNECT primitives in wireshark. So it seems to me there's no use hooking on those ... or is it because the osmo sccp code simply fails to do that negotiation?
When I place debug output (using printf to make sure debug log levels aren't disabled) in the N-CONNECT prim rx code in osmo-hnbgw, I also don't get any hits when connecting omso-hnbgw to the CN.
Assuming osmo-sccp is working correctly, I'm pretty sure the N-CONNECT doesn't help in sending a Reset from omso-hnbgw to the CN upon connecting.
I already have the on-connect callback implemented as described before, which does register when connecting to the CN. So I'll commit it on libosmo-sccp branch sysmocom/iu and use that to send a Reset.
I wouldn't really want to get side-tracked from the side-track, but it's not set in stone: comments welcome!
~Neels
Hi Neels,
On Mon, Apr 04, 2016 at 05:55:50PM +0200, Neels Hofmeyr wrote:
My point is, I don't see N-CONNECT primitives in wireshark.
As a primitive is something between two layers on your local protocol stack, you will never see that in wireshark. The actual protocol message payload at the given layer boundary is one attribute (typically called DATA) of the primitive.
To translate it in IP: The 'connect()', 'bind()', 'recvmsg()' primitive at the TCP/UDP User SAP (BSD socket intreface) between the UDP protocol implementation an your application is also not observed in wireshark.
Instead of calling 'connect()' on a TCP socket, in an ITU primtive world, you send a N-CONNET.request primitive to the TCP Provider.
Instead of getting an incoming connection via 'accept()', you get a N-CONNECT.indication from the TCP provider. Primitives are just a different way of an API to talk to a protocol stack (or rather a layer in a stack).
So it seems to me there's no use hooking on those ... or is it because the osmo sccp code simply fails to do that negotiation?
Which negotiation?
When I place debug output (using printf to make sure debug log levels aren't disabled) in the N-CONNECT prim rx code in osmo-hnbgw, I also don't get any hits when connecting omso-hnbgw to the CN.
This is because the SCCP User SAP apparently is not yet generating those primitives.
Assuming osmo-sccp is working correctly,
As usual, I only implement those bits that were immediately needed/used at the time it was written. Very likely the primitives you need are simply not generated yet.
I already have the on-connect callback implemented as described before, which does register when connecting to the CN. So I'll commit it on libosmo-sccp branch sysmocom/iu and use that to send a Reset.
all communication between the SCCP user (application) and SCCP provider should go through the same SAP interface. A call-bcak from a lower-layer transport library like libosmo-netif should be trasnformed into a SCCP User SAP primitive an then sent to the SCCP User via the SAP.
Dear Neels and others,
I was confused earlier today.
N-CONNECT is a primitive for a connection oriented SCCP-layer connection. You receive it at each time a UE establishes a connection-oriented SCCP for signalling, and it is what carrie RANAP InitialUE and related messages.
What you are talking about for the RANAP Reset is the establishment of a signalling link (underneath SCCP/SUA), so something like the SCTP connection being established and released underneath.
In the SUA RFC 3868 there are: * M-SCTP_ESTABLISH confirm ASP confirms to LM that it has established an SCTP association with its peer * M-SCTP_ESTABLISH indication SUA informs LM that a remote ASP has established an SCTP association. "LM" is the "Layer Manager". This is not the SCCP user, so no luck here.
However, Q.711 / Q.714 contain a N-STATE.indication, which can be sent to a local SCCP user to inform it about the subsystem status.
FRrom 5.3.6.2:
"The local broadcast procedure provides a mechanism to inform local allowed concerned subsystems of any related SCCP/subsystem/signalling point status information received. [...] SCCP management then informs local allowed concerned SCCP subsystems about the subsystem status by invoking N-STATE indication primitive with "User-out-of-service" information."
So once we loose the signalling link, all SCCP users should receive N-STATE.ind with "User-out-of-service".
When the signalling link is (re-)established, all SCCP users should receive N-STATE.ind with "User-in-service". This should then be the trigger to send a N-UNITDATA.req() with a RANAP Reset inside.
Regards, Harald
Excellent, thanks for finding this info!
So I should implement N-STATE ind to be sent from our osmo_sua_* implementation to the SUA user:
* Trigger the N-STATE User-in-service from a callback put in osmo_stream_cli_set_connect_cb().
* Trigger the out-of-service from ... ? It seems we're lacking an osmo_stream_* disconnect cb?
In a side note, this is deviating from what is strictly necessary to get paging working. I could just use the RNC Ids from the InitialUE messages for now and postpone the Reset issue.
Another shortcut could be to send the Reset message "directly" from the osmo_stream_cli_set_connect_cb() without composing N-STATE prims.
Would you say that Reset and the SUA N-STATE primitives are important enough to implement those first?
Thanks, ~Neels
On Mon, Apr 04, 2016 at 08:19:39PM +0200, Harald Welte wrote:
Dear Neels and others,
I was confused earlier today.
N-CONNECT is a primitive for a connection oriented SCCP-layer connection. You receive it at each time a UE establishes a connection-oriented SCCP for signalling, and it is what carrie RANAP InitialUE and related messages.
What you are talking about for the RANAP Reset is the establishment of a signalling link (underneath SCCP/SUA), so something like the SCTP connection being established and released underneath.
In the SUA RFC 3868 there are:
- M-SCTP_ESTABLISH confirm ASP confirms to LM that it has established an SCTP association with its peer
- M-SCTP_ESTABLISH indication SUA informs LM that a remote ASP has established an SCTP association.
"LM" is the "Layer Manager". This is not the SCCP user, so no luck here.
However, Q.711 / Q.714 contain a N-STATE.indication, which can be sent to a local SCCP user to inform it about the subsystem status.
FRrom 5.3.6.2:
"The local broadcast procedure provides a mechanism to inform local allowed concerned subsystems of any related SCCP/subsystem/signalling point status information received. [...] SCCP management then informs local allowed concerned SCCP subsystems about the subsystem status by invoking N-STATE indication primitive with "User-out-of-service" information."
So once we loose the signalling link, all SCCP users should receive N-STATE.ind with "User-out-of-service".
When the signalling link is (re-)established, all SCCP users should receive N-STATE.ind with "User-in-service". This should then be the trigger to send a N-UNITDATA.req() with a RANAP Reset inside.
Regards, Harald --
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Neels,
On Tue, Apr 05, 2016 at 11:29:35AM +0200, Neels Hofmeyr wrote:
Would you say that Reset and the SUA N-STATE primitives are important enough to implement those first?
no. But please make sure that this deficiency and the proper implementation are documented in a ticket so we don't have to have this discussion again in the future :)
On Tue, Apr 05, 2016 at 11:54:47AM +0200, Harald Welte wrote:
no. But please make sure that this deficiency and the proper implementation are documented in a ticket so we don't have to have this discussion again in the future :)
http://osmocom.org/issues/1688
~Neels
-
Harald Welte -
Neels Hofmeyr