From 1035d90c1761d4ab94c998908a475a8dbc09b50c Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Fri, 28 Dec 2018 21:22:32 +0100 Subject: fix vlr ops.subscr_assoc re-association In rare cases, a conn is already associated with a subscriber. So far, we abort()ed on that, bringing the entire osmo-msc down. Rather log an error and keep the service running. In vlr.ops.subscr_assoc, add success/failure return value, and abort the LU/PARQ on error. I haven't figured out in detail yet why/how a subscriber would re-launch a LU/PARQ on a conn that is already associated, so far it is merely clear that we do not want to crash the MSC if that happens. A log is in OS#3742. Related: OS#3742, OS#3743 Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f --- include/osmocom/msc/vlr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include') diff --git a/include/osmocom/msc/vlr.h b/include/osmocom/msc/vlr.h index 20a9c0f24..3c778a96b 100644 --- a/include/osmocom/msc/vlr.h +++ b/include/osmocom/msc/vlr.h @@ -235,7 +235,7 @@ struct vlr_ops { void (*subscr_update)(struct vlr_subscr *vsub); /* notify MSC/SGSN that the given subscriber has been associated * with this msc_conn_ref */ - void (*subscr_assoc)(void *msc_conn_ref, struct vlr_subscr *vsub); + int (*subscr_assoc)(void *msc_conn_ref, struct vlr_subscr *vsub); /* Forward a parsed GSUP message towards MSC message router */ int (*forward_gsup_msg)(struct vlr_subscr *vsub, struct osmo_gsup_message *gsup_msg); -- cgit v1.2.3