2016-08-17 23:03:44 +00:00
|
|
|
/* HNB-GW interface to quagga VTY */
|
|
|
|
|
|
|
|
/* (C) 2016 by sysmocom s.f.m.c. GmbH <info@sysmocom.de>
|
|
|
|
* All Rights Reserved
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU Affero General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU Affero General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Affero General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2017-11-21 07:14:37 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
#include <osmocom/core/socket.h>
|
2016-08-17 23:03:44 +00:00
|
|
|
#include <osmocom/vty/command.h>
|
|
|
|
|
2016-08-18 00:15:56 +00:00
|
|
|
#include <osmocom/iuh/vty.h>
|
|
|
|
|
2016-08-18 11:13:55 +00:00
|
|
|
#include <osmocom/iuh/hnbgw.h>
|
|
|
|
#include <osmocom/iuh/context_map.h>
|
2016-10-13 13:12:18 +00:00
|
|
|
#include <osmocom/sigtran/protocol/sua.h>
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
#include <osmocom/sigtran/sccp_helpers.h>
|
|
|
|
#include <osmocom/netif/stream.h>
|
2016-08-17 23:03:44 +00:00
|
|
|
|
|
|
|
static void *tall_hnb_ctx = NULL;
|
|
|
|
static struct hnb_gw *g_hnb_gw = NULL;
|
|
|
|
|
2016-08-18 00:15:56 +00:00
|
|
|
static struct cmd_node hnbgw_node = {
|
|
|
|
HNBGW_NODE,
|
|
|
|
"%s(config-hnbgw)# ",
|
|
|
|
1,
|
|
|
|
};
|
|
|
|
|
|
|
|
DEFUN(cfg_hnbgw, cfg_hnbgw_cmd,
|
|
|
|
"hnbgw", "Configure HNBGW options")
|
|
|
|
{
|
|
|
|
vty->node = HNBGW_NODE;
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct cmd_node iuh_node = {
|
|
|
|
IUH_NODE,
|
|
|
|
"%s(config-hnbgw-iuh)# ",
|
|
|
|
1,
|
|
|
|
};
|
|
|
|
|
|
|
|
DEFUN(cfg_hnbgw_iuh, cfg_hnbgw_iuh_cmd,
|
|
|
|
"iuh", "Configure Iuh options")
|
|
|
|
{
|
|
|
|
vty->node = IUH_NODE;
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-10-13 13:12:18 +00:00
|
|
|
static struct cmd_node iucs_node = {
|
|
|
|
IUCS_NODE,
|
|
|
|
"%s(config-hnbgw-iucs)# ",
|
|
|
|
1,
|
|
|
|
};
|
|
|
|
|
|
|
|
DEFUN(cfg_hnbgw_iucs, cfg_hnbgw_iucs_cmd,
|
|
|
|
"iucs", "Configure IuCS options")
|
|
|
|
{
|
|
|
|
vty->node = IUCS_NODE;
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct cmd_node iups_node = {
|
|
|
|
IUPS_NODE,
|
|
|
|
"%s(config-hnbgw-iups)# ",
|
|
|
|
1,
|
|
|
|
};
|
|
|
|
|
|
|
|
DEFUN(cfg_hnbgw_iups, cfg_hnbgw_iups_cmd,
|
|
|
|
"iups", "Configure IuPS options")
|
|
|
|
{
|
|
|
|
vty->node = IUPS_NODE;
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-10-13 14:58:04 +00:00
|
|
|
int hnbgw_vty_go_parent(struct vty *vty)
|
|
|
|
{
|
|
|
|
switch (vty->node) {
|
|
|
|
case IUH_NODE:
|
2016-10-13 13:12:18 +00:00
|
|
|
case IUCS_NODE:
|
|
|
|
case IUPS_NODE:
|
2016-10-13 14:58:04 +00:00
|
|
|
vty->node = HNBGW_NODE;
|
|
|
|
vty->index = NULL;
|
|
|
|
break;
|
|
|
|
case HNBGW_NODE:
|
|
|
|
vty->node = CONFIG_NODE;
|
|
|
|
vty->index = NULL;
|
|
|
|
break;
|
|
|
|
case CONFIG_NODE:
|
|
|
|
vty->node = ENABLE_NODE;
|
|
|
|
vty->index = NULL;
|
|
|
|
break;
|
2017-07-31 11:13:24 +00:00
|
|
|
default:
|
|
|
|
osmo_ss7_vty_go_parent(vty);
|
|
|
|
break;
|
2016-10-13 14:58:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return vty->node;
|
|
|
|
}
|
|
|
|
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
DEFUN(show_cnlink, show_cnlink_cmd, "show cnlink",
|
|
|
|
SHOW_STR "Display information on core network link\n")
|
|
|
|
{
|
|
|
|
struct osmo_ss7_route *rt;
|
|
|
|
struct osmo_ss7_instance *ss7 = osmo_sccp_get_ss7(g_hnb_gw->sccp.client);
|
|
|
|
#define GUARD(STR) \
|
|
|
|
STR ? STR : "", \
|
|
|
|
STR ? ":" : ""
|
2020-03-20 19:35:06 +00:00
|
|
|
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
vty_out(vty, "IuCS: %s <->",
|
|
|
|
osmo_sccp_user_name(g_hnb_gw->sccp.cnlink->sccp_user));
|
|
|
|
vty_out(vty, " %s%s%s%s",
|
|
|
|
GUARD(g_hnb_gw->config.iucs_remote_addr_name),
|
|
|
|
osmo_sccp_inst_addr_name(g_hnb_gw->sccp.client, &g_hnb_gw->sccp.iucs_remote_addr),
|
|
|
|
VTY_NEWLINE);
|
|
|
|
|
|
|
|
rt = osmo_ss7_route_lookup(ss7, g_hnb_gw->sccp.iucs_remote_addr.pc);
|
|
|
|
vty_out(vty, " SS7 route: %s%s", osmo_ss7_route_name(rt, true), VTY_NEWLINE);
|
|
|
|
|
|
|
|
vty_out(vty, "IuPS: %s <->",
|
|
|
|
osmo_sccp_user_name(g_hnb_gw->sccp.cnlink->sccp_user));
|
|
|
|
vty_out(vty, " %s%s%s%s",
|
|
|
|
GUARD(g_hnb_gw->config.iups_remote_addr_name),
|
|
|
|
osmo_sccp_inst_addr_name(g_hnb_gw->sccp.client, &g_hnb_gw->sccp.iups_remote_addr),
|
|
|
|
VTY_NEWLINE);
|
|
|
|
|
|
|
|
rt = osmo_ss7_route_lookup(ss7, g_hnb_gw->sccp.iups_remote_addr.pc);
|
|
|
|
vty_out(vty, " SS7 route: %s%s", osmo_ss7_route_name(rt, true), VTY_NEWLINE);
|
|
|
|
|
|
|
|
#undef GUARD
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void vty_out_ofd_addr(struct vty *vty, struct osmo_fd *ofd)
|
|
|
|
{
|
2017-12-26 20:38:49 +00:00
|
|
|
char *name;
|
|
|
|
if (!ofd || ofd->fd < 0
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
|| !(name = osmo_sock_get_name(vty, ofd->fd))) {
|
|
|
|
vty_out(vty, "(no addr)");
|
|
|
|
return;
|
2017-12-26 20:38:49 +00:00
|
|
|
}
|
2017-12-26 20:39:53 +00:00
|
|
|
vty_out(vty, "%s", name);
|
2017-12-26 20:38:49 +00:00
|
|
|
talloc_free(name);
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
}
|
|
|
|
|
2017-12-24 23:35:05 +00:00
|
|
|
static void vty_dump_hnb_info__map_states(struct vty *vty, const char *name, unsigned int count,
|
|
|
|
unsigned int state_count[])
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
if (!count)
|
|
|
|
return;
|
|
|
|
vty_out(vty, " %s: %u contexts:", name, count);
|
|
|
|
for (i = 0; i <= MAP_S_NUM_STATES; i++) {
|
|
|
|
if (!state_count[i])
|
|
|
|
continue;
|
|
|
|
vty_out(vty, " %s:%u", hnbgw_context_map_state_name(i), state_count[i]);
|
|
|
|
}
|
|
|
|
vty_out(vty, VTY_NEWLINE);
|
|
|
|
}
|
|
|
|
|
2016-08-17 23:03:44 +00:00
|
|
|
static void vty_dump_hnb_info(struct vty *vty, struct hnb_context *hnb)
|
|
|
|
{
|
|
|
|
struct hnbgw_context_map *map;
|
2017-12-24 23:35:05 +00:00
|
|
|
unsigned int map_count[2] = {};
|
|
|
|
unsigned int state_count[2][MAP_S_NUM_STATES + 1] = {};
|
2016-08-17 23:03:44 +00:00
|
|
|
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
vty_out(vty, "HNB ");
|
|
|
|
vty_out_ofd_addr(vty, hnb->conn? osmo_stream_srv_get_ofd(hnb->conn) : NULL);
|
|
|
|
vty_out(vty, " \"%s\"%s", hnb->identity_info, VTY_NEWLINE);
|
2017-12-25 14:24:33 +00:00
|
|
|
vty_out(vty, " MCC %u MNC %u LAC %u RAC %u SAC %u CID %u SCTP-stream:HNBAP=%u,RUA=%u%s",
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
hnb->id.mcc, hnb->id.mnc, hnb->id.lac, hnb->id.rac, hnb->id.sac, hnb->id.cid,
|
|
|
|
hnb->hnbap_stream, hnb->rua_stream, VTY_NEWLINE);
|
2016-08-17 23:03:44 +00:00
|
|
|
|
|
|
|
llist_for_each_entry(map, &hnb->map_list, hnb_list) {
|
2017-12-24 23:35:05 +00:00
|
|
|
map_count[map->is_ps? 1 : 0]++;
|
|
|
|
state_count[map->is_ps? 1 : 0]
|
|
|
|
[(map->state >= 0 && map->state < MAP_S_NUM_STATES)?
|
|
|
|
map->state : MAP_S_NUM_STATES]++;
|
2016-08-17 23:03:44 +00:00
|
|
|
}
|
2017-12-24 23:35:05 +00:00
|
|
|
vty_dump_hnb_info__map_states(vty, "IuCS", map_count[0], state_count[0]);
|
|
|
|
vty_dump_hnb_info__map_states(vty, "IuPS", map_count[1], state_count[1]);
|
2016-08-17 23:03:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void vty_dump_ue_info(struct vty *vty, struct ue_context *ue)
|
|
|
|
{
|
|
|
|
vty_out(vty, "UE IMSI \"%s\" context ID %u%s", ue->imsi, ue->context_id, VTY_NEWLINE);
|
|
|
|
}
|
|
|
|
|
2018-10-29 17:19:14 +00:00
|
|
|
DEFUN(show_hnb, show_hnb_cmd, "show hnb all", SHOW_STR "Display information about all HNB")
|
2016-08-17 23:03:44 +00:00
|
|
|
{
|
|
|
|
struct hnb_context *hnb;
|
2017-12-24 23:35:05 +00:00
|
|
|
unsigned int count = 0;
|
2016-08-17 23:03:44 +00:00
|
|
|
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
if (llist_empty(&g_hnb_gw->hnb_list)) {
|
|
|
|
vty_out(vty, "No HNB connected%s", VTY_NEWLINE);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-08-17 23:03:44 +00:00
|
|
|
llist_for_each_entry(hnb, &g_hnb_gw->hnb_list, list) {
|
|
|
|
vty_dump_hnb_info(vty, hnb);
|
2017-12-24 23:35:05 +00:00
|
|
|
count++;
|
2016-08-17 23:03:44 +00:00
|
|
|
}
|
|
|
|
|
2017-12-24 23:35:05 +00:00
|
|
|
vty_out(vty, "%u HNB connected%s", count, VTY_NEWLINE);
|
|
|
|
|
2016-08-17 23:03:44 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-10-29 17:19:14 +00:00
|
|
|
DEFUN(show_one_hnb, show_one_hnb_cmd, "show hnb NAME ", SHOW_STR "Display information about a HNB")
|
|
|
|
{
|
|
|
|
struct hnb_context *hnb;
|
|
|
|
const char *identity_info = argv[0];
|
|
|
|
|
|
|
|
if (llist_empty(&g_hnb_gw->hnb_list)) {
|
|
|
|
vty_out(vty, "No HNB connected%s", VTY_NEWLINE);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2019-08-22 22:26:52 +00:00
|
|
|
hnb = hnb_context_by_identity_info(g_hnb_gw, identity_info);
|
2018-10-29 17:19:14 +00:00
|
|
|
if (hnb == NULL) {
|
|
|
|
vty_out(vty, "No HNB found with identity '%s'%s", identity_info, VTY_NEWLINE);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
vty_dump_hnb_info(vty, hnb);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-08-17 23:03:44 +00:00
|
|
|
DEFUN(show_ue, show_ue_cmd, "show ue all", SHOW_STR "Display information about a UE")
|
|
|
|
{
|
|
|
|
struct ue_context *ue;
|
|
|
|
|
|
|
|
llist_for_each_entry(ue, &g_hnb_gw->ue_list, list) {
|
|
|
|
vty_dump_ue_info(vty, ue);
|
|
|
|
}
|
|
|
|
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFUN(show_talloc, show_talloc_cmd, "show talloc", SHOW_STR "Display talloc info")
|
|
|
|
{
|
|
|
|
talloc_report_full(tall_hnb_ctx, stderr);
|
|
|
|
talloc_report_full(talloc_asn1_ctx, stderr);
|
|
|
|
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-12-24 23:01:37 +00:00
|
|
|
DEFUN(cfg_hnbgw_rnc_id, cfg_hnbgw_rnc_id_cmd,
|
|
|
|
"rnc-id <0-65535>",
|
|
|
|
"Configure the HNBGW's RNC Id, the common RNC Id used for all connected hNodeB. It is sent to"
|
|
|
|
" each hNodeB upon HNBAP HNB-Register-Accept, and the hNodeB will subsequently send this as"
|
|
|
|
" RANAP InitialUE Messages' GlobalRNC-ID IE. Takes effect as soon as the hNodeB re-registers.\n"
|
|
|
|
"RNC Id value\n")
|
|
|
|
{
|
|
|
|
g_hnb_gw->config.rnc_id = atoi(argv[0]);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-09-25 23:07:19 +00:00
|
|
|
DEFUN(cfg_hnbgw_iuh_local_ip, cfg_hnbgw_iuh_local_ip_cmd, "local-ip A.B.C.D",
|
2016-08-18 00:18:00 +00:00
|
|
|
"Accept Iuh connections on local interface\n"
|
2016-10-13 12:43:49 +00:00
|
|
|
"Local interface IP address (default: " HNBGW_LOCAL_IP_DEFAULT ")")
|
2016-08-18 00:18:00 +00:00
|
|
|
{
|
2016-10-13 12:43:49 +00:00
|
|
|
talloc_free((void*)g_hnb_gw->config.iuh_local_ip);
|
|
|
|
g_hnb_gw->config.iuh_local_ip = talloc_strdup(tall_hnb_ctx, argv[0]);
|
2016-08-18 00:18:00 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-10-13 13:11:07 +00:00
|
|
|
DEFUN(cfg_hnbgw_iuh_local_port, cfg_hnbgw_iuh_local_port_cmd, "local-port <1-65535>",
|
|
|
|
"Accept Iuh connections on local port\n"
|
|
|
|
"Local interface port (default: 29169)")
|
|
|
|
{
|
|
|
|
g_hnb_gw->config.iuh_local_port = atoi(argv[0]);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
hnbap: accept UE Register Requests with TMSI and pTMSI
Add the option to allow UE Register Requests with a TMSI identity.
Add VTY command to enable this option, 'hnbap-allow-tmsi'.
Add hnbgw_tx_ue_register_acc_tmsi().
HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
UE registers with only a TMSI, we obviously can't store an IMSI. However, since
we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
accept the TMSI registration and carry on as usual. All that is needed for
proper operation is a valid UE context.
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected. So far this caused failures and the need to
make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
different network), so that UE registration switched back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current code
state.
For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
upon first registration to the network.
Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
does include a page-to-all-HNBs in case the first HNB paging fails. But we must
be aware that UEs that register by TMSI will simply not have an IMSI recorded
in the list of UE contexts, so a lookup based on IMSI may fail.
Patch-by: Harald Welte <laforge@gnumonks.org>, me
Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589
2016-04-25 13:05:32 +00:00
|
|
|
DEFUN(cfg_hnbgw_iuh_hnbap_allow_tmsi, cfg_hnbgw_iuh_hnbap_allow_tmsi_cmd,
|
|
|
|
"hnbap-allow-tmsi (0|1)",
|
|
|
|
"Allow HNBAP UE Register messages with TMSI or PTMSI identity\n"
|
|
|
|
"Only accept IMSI identity, reject TMSI or PTMSI\n"
|
|
|
|
"Accept IMSI, TMSI or PTMSI as UE identity\n")
|
|
|
|
{
|
|
|
|
g_hnb_gw->config.hnbap_allow_tmsi = (*argv[0] == '1');
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2020-12-30 12:36:20 +00:00
|
|
|
DEFUN(cfg_hnbgw_log_prefix, cfg_hnbgw_log_prefix_cmd,
|
|
|
|
"log-prefix (hnb-id|umts-cell-id)",
|
|
|
|
"Configure the log message prefix\n"
|
|
|
|
"Use the hNB-ID as log message prefix\n"
|
|
|
|
"Use the UMTS Cell ID as log message prefix\n")
|
|
|
|
{
|
|
|
|
if (!strcmp(argv[0], "hnb-id"))
|
|
|
|
g_hnb_gw->config.log_prefix_hnb_id = true;
|
|
|
|
else
|
|
|
|
g_hnb_gw->config.log_prefix_hnb_id = false;
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-07-31 11:13:24 +00:00
|
|
|
DEFUN(cfg_hnbgw_iucs_remote_addr,
|
|
|
|
cfg_hnbgw_iucs_remote_addr_cmd,
|
|
|
|
"remote-addr NAME",
|
|
|
|
"SCCP address to send IuCS to (MSC)\n"
|
|
|
|
"SCCP address book entry name (see 'cs7-instance')\n")
|
2016-10-13 13:12:18 +00:00
|
|
|
{
|
2017-07-31 11:13:24 +00:00
|
|
|
g_hnb_gw->config.iucs_remote_addr_name = talloc_strdup(g_hnb_gw, argv[0]);
|
2016-10-13 13:12:18 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-07-31 11:13:24 +00:00
|
|
|
DEFUN(cfg_hnbgw_iups_remote_addr,
|
|
|
|
cfg_hnbgw_iups_remote_addr_cmd,
|
|
|
|
"remote-addr NAME",
|
|
|
|
"SCCP address to send IuPS to (SGSN)\n"
|
|
|
|
"SCCP address book entry name (see 'cs7-instance')\n")
|
2016-10-13 13:12:18 +00:00
|
|
|
{
|
2017-07-31 11:13:24 +00:00
|
|
|
g_hnb_gw->config.iups_remote_addr_name = talloc_strdup(g_hnb_gw, argv[0]);
|
2016-10-13 13:12:18 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-08-18 00:15:56 +00:00
|
|
|
static int config_write_hnbgw(struct vty *vty)
|
|
|
|
{
|
|
|
|
vty_out(vty, "hnbgw%s", VTY_NEWLINE);
|
2020-12-30 12:36:20 +00:00
|
|
|
vty_out(vty, " log-prefix %s%s", g_hnb_gw->config.log_prefix_hnb_id ? "hnb-id" : "umts-cell-id",
|
|
|
|
VTY_NEWLINE);
|
2016-08-18 00:15:56 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int config_write_hnbgw_iuh(struct vty *vty)
|
|
|
|
{
|
2016-08-18 00:18:00 +00:00
|
|
|
const char *addr;
|
2016-10-13 13:11:07 +00:00
|
|
|
uint16_t port;
|
2016-08-18 00:18:00 +00:00
|
|
|
|
2016-08-18 00:15:56 +00:00
|
|
|
vty_out(vty, " iuh%s", VTY_NEWLINE);
|
2016-08-18 00:18:00 +00:00
|
|
|
|
2016-10-13 12:43:49 +00:00
|
|
|
addr = g_hnb_gw->config.iuh_local_ip;
|
|
|
|
if (addr && (strcmp(addr, HNBGW_LOCAL_IP_DEFAULT) != 0))
|
2016-09-25 23:07:19 +00:00
|
|
|
vty_out(vty, " local-ip %s%s", addr, VTY_NEWLINE);
|
2016-08-18 00:18:00 +00:00
|
|
|
|
2016-10-13 13:11:07 +00:00
|
|
|
port = g_hnb_gw->config.iuh_local_port;
|
|
|
|
if (port && port != IUH_DEFAULT_SCTP_PORT)
|
|
|
|
vty_out(vty, " local-port %u%s", port, VTY_NEWLINE);
|
|
|
|
|
hnbap: accept UE Register Requests with TMSI and pTMSI
Add the option to allow UE Register Requests with a TMSI identity.
Add VTY command to enable this option, 'hnbap-allow-tmsi'.
Add hnbgw_tx_ue_register_acc_tmsi().
HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
UE registers with only a TMSI, we obviously can't store an IMSI. However, since
we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
accept the TMSI registration and carry on as usual. All that is needed for
proper operation is a valid UE context.
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected. So far this caused failures and the need to
make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
different network), so that UE registration switched back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current code
state.
For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
upon first registration to the network.
Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
does include a page-to-all-HNBs in case the first HNB paging fails. But we must
be aware that UEs that register by TMSI will simply not have an IMSI recorded
in the list of UE contexts, so a lookup based on IMSI may fail.
Patch-by: Harald Welte <laforge@gnumonks.org>, me
Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589
2016-04-25 13:05:32 +00:00
|
|
|
if (g_hnb_gw->config.hnbap_allow_tmsi)
|
|
|
|
vty_out(vty, " hnbap-allow-tmsi 1%s", VTY_NEWLINE);
|
|
|
|
|
2016-08-18 00:15:56 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-10-13 13:12:18 +00:00
|
|
|
static int config_write_hnbgw_iucs(struct vty *vty)
|
|
|
|
{
|
2017-07-31 11:13:24 +00:00
|
|
|
if (!g_hnb_gw->config.iucs_remote_addr_name)
|
|
|
|
return CMD_SUCCESS;
|
2016-10-13 13:12:18 +00:00
|
|
|
|
2017-07-31 11:13:24 +00:00
|
|
|
vty_out(vty, " iucs%s", VTY_NEWLINE);
|
|
|
|
vty_out(vty, " remote-addr %s%s", g_hnb_gw->config.iucs_remote_addr_name,
|
|
|
|
VTY_NEWLINE);
|
2016-10-13 13:12:18 +00:00
|
|
|
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int config_write_hnbgw_iups(struct vty *vty)
|
|
|
|
{
|
2017-07-31 11:13:24 +00:00
|
|
|
if (!g_hnb_gw->config.iups_remote_addr_name)
|
|
|
|
return CMD_SUCCESS;
|
2016-10-13 13:12:18 +00:00
|
|
|
|
2017-07-31 11:13:24 +00:00
|
|
|
vty_out(vty, " iups%s", VTY_NEWLINE);
|
|
|
|
vty_out(vty, " remote-addr %s%s", g_hnb_gw->config.iups_remote_addr_name,
|
|
|
|
VTY_NEWLINE);
|
2016-10-13 13:12:18 +00:00
|
|
|
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2016-08-17 23:03:44 +00:00
|
|
|
void hnbgw_vty_init(struct hnb_gw *gw, void *tall_ctx)
|
|
|
|
{
|
|
|
|
g_hnb_gw = gw;
|
|
|
|
tall_hnb_ctx = tall_ctx;
|
2016-08-18 00:15:56 +00:00
|
|
|
|
|
|
|
install_element(CONFIG_NODE, &cfg_hnbgw_cmd);
|
|
|
|
install_node(&hnbgw_node, config_write_hnbgw);
|
|
|
|
|
2017-12-24 23:01:37 +00:00
|
|
|
install_element(HNBGW_NODE, &cfg_hnbgw_rnc_id_cmd);
|
2020-12-30 12:36:20 +00:00
|
|
|
install_element(HNBGW_NODE, &cfg_hnbgw_log_prefix_cmd);
|
2017-12-24 23:01:37 +00:00
|
|
|
|
2016-08-18 00:15:56 +00:00
|
|
|
install_element(HNBGW_NODE, &cfg_hnbgw_iuh_cmd);
|
|
|
|
install_node(&iuh_node, config_write_hnbgw_iuh);
|
hnbap: accept UE Register Requests with TMSI and pTMSI
Add the option to allow UE Register Requests with a TMSI identity.
Add VTY command to enable this option, 'hnbap-allow-tmsi'.
Add hnbgw_tx_ue_register_acc_tmsi().
HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
UE registers with only a TMSI, we obviously can't store an IMSI. However, since
we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
accept the TMSI registration and carry on as usual. All that is needed for
proper operation is a valid UE context.
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected. So far this caused failures and the need to
make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
different network), so that UE registration switched back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current code
state.
For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
upon first registration to the network.
Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
does include a page-to-all-HNBs in case the first HNB paging fails. But we must
be aware that UEs that register by TMSI will simply not have an IMSI recorded
in the list of UE contexts, so a lookup based on IMSI may fail.
Patch-by: Harald Welte <laforge@gnumonks.org>, me
Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589
2016-04-25 13:05:32 +00:00
|
|
|
|
2016-09-25 23:07:19 +00:00
|
|
|
install_element(IUH_NODE, &cfg_hnbgw_iuh_local_ip_cmd);
|
2016-10-13 13:11:07 +00:00
|
|
|
install_element(IUH_NODE, &cfg_hnbgw_iuh_local_port_cmd);
|
hnbap: accept UE Register Requests with TMSI and pTMSI
Add the option to allow UE Register Requests with a TMSI identity.
Add VTY command to enable this option, 'hnbap-allow-tmsi'.
Add hnbgw_tx_ue_register_acc_tmsi().
HNBGW so far keeps track of UEs that have registered, with their IMSI. When a
UE registers with only a TMSI, we obviously can't store an IMSI. However, since
we're so far never *using* the list of UEs in osmo-hnbgw, we might as well just
accept the TMSI registration and carry on as usual. All that is needed for
proper operation is a valid UE context.
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected. So far this caused failures and the need to
make the UE clear its TMSI (wait several minutes or attempt to subscribe to a
different network), so that UE registration switched back to IMSI. When simply
accepting the TMSI in osmo-hngw, no problems are apparent in our current code
state.
For example, a Samsung Galaxy S4 seems to send a UE_Identity_PR_tMSILAI (CS
identity), and a GT-I9100 seems to send a UE_Identity_PR_pTMSIRAI (PS identity)
upon first registration to the network.
Recording the IMSI in hnbgw: we could use the subscriber list during paging, to
page a UE on only its last seen HNB. On the other hand, it doesn't hurt to
anyway always page to all HNBs connected to osmo-hnbgw. The paging procedure
does include a page-to-all-HNBs in case the first HNB paging fails. But we must
be aware that UEs that register by TMSI will simply not have an IMSI recorded
in the list of UE contexts, so a lookup based on IMSI may fail.
Patch-by: Harald Welte <laforge@gnumonks.org>, me
Change-Id: I87bc1aa3e85815ded7ac1dbdca48f1680b468589
2016-04-25 13:05:32 +00:00
|
|
|
install_element(IUH_NODE, &cfg_hnbgw_iuh_hnbap_allow_tmsi_cmd);
|
2016-08-18 00:15:56 +00:00
|
|
|
|
2016-10-13 13:12:18 +00:00
|
|
|
install_element(HNBGW_NODE, &cfg_hnbgw_iucs_cmd);
|
|
|
|
install_node(&iucs_node, config_write_hnbgw_iucs);
|
|
|
|
|
2017-07-31 11:13:24 +00:00
|
|
|
install_element(IUCS_NODE, &cfg_hnbgw_iucs_remote_addr_cmd);
|
2016-10-13 13:12:18 +00:00
|
|
|
|
|
|
|
install_element(HNBGW_NODE, &cfg_hnbgw_iups_cmd);
|
|
|
|
install_node(&iups_node, config_write_hnbgw_iups);
|
|
|
|
|
2017-07-31 11:13:24 +00:00
|
|
|
install_element(IUPS_NODE, &cfg_hnbgw_iups_remote_addr_cmd);
|
2016-10-13 13:12:18 +00:00
|
|
|
|
vty: tweak / improve HNB and cnlink introspection
Add 'show cnlink' (uses new osmo_sccp_user_name(), see 'Depends' below).
Tweak 'show hnb all'.
The result looks something like:
OsmoHNBGW> show cnlink
IuCS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.1,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
IuPS: OsmoHNBGW:RI=SSN_PC,PC=0.23.5,SSN=RANAP <-> RI=SSN_PC,PC=0.23.4,SSN=RANAP
SS7 route: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoHNBGW proto=m3ua ASP asp-clnt-OsmoHNBGW (r=127.0.0.1:2905<->l=127.0.0.1:37699)
OsmoHNBGW> show hnb all
No HNB connected
OsmoHNBGW> show hnb all
HNB (r=192.168.0.124:29169<->l=192.168.0.9:29169) "000295-0000152614@ap.ipaccess.com"
MCC 901 MNC 70 LAC 14357 RAC 11 SAC 1 CID 8595638 SCCP-stream:HNBAP=0,RUA=0
IuCS 24->1002 (RUA->SUA) state=1
IuPS 24->1003 (RUA->SUA) state=1
HNB (r=192.168.0.15:29169<->l=192.168.0.9:29169) "000295-0000154153@ap.ipaccess.com"
MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 SCCP-stream:HNBAP=0,RUA=0
IuCS 23->1000 (RUA->SUA) state=1
IuPS 23->1001 (RUA->SUA) state=1
2 HNB connected
Related: OS#2772 OS#2773
Depends: Ib7abf69cfcf4c56273223054b280458451e6c2f6 (libosmo-sccp)
Ia0d15a2814b08bc3f052a1ed12dbb68bade55309 (libosmo-sccp)
Change-Id: I3c937306a011715e163a40bc8ef8ec7e8d4e5d08
2017-12-20 22:48:02 +00:00
|
|
|
install_element_ve(&show_cnlink_cmd);
|
2016-08-17 23:03:44 +00:00
|
|
|
install_element_ve(&show_hnb_cmd);
|
2018-10-29 17:19:14 +00:00
|
|
|
install_element_ve(&show_one_hnb_cmd);
|
2016-08-17 23:03:44 +00:00
|
|
|
install_element_ve(&show_ue_cmd);
|
|
|
|
install_element_ve(&show_talloc_cmd);
|
|
|
|
}
|