From snehasish.cse at live.com Wed Feb 1 16:05:20 2017 From: snehasish.cse at live.com (Snehasish Kar) Date: Wed, 1 Feb 2017 16:05:20 +0000 Subject: Usrp with 3G Message-ID: Hi Can 3G be used with USRP? BR Snehasish From laforge at gnumonks.org Wed Feb 1 16:21:00 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Feb 2017 17:21:00 +0100 Subject: Usrp with 3G In-Reply-To: References: Message-ID: <20170201162100.7odzf6pcdcvsalvp@nataraja> On Wed, Feb 01, 2017 at 04:05:20PM +0000, Snehasish Kar wrote: > Hi > Can 3G be used with USRP? Osmocom so far implements only the core network down to IuCS and IuPS as well as a gateway to Iuh. It does not implement an RNC nor the NodeB. So *if* you find a PHY/RLC/MAC layer (NodeB) and the RRC layer (RNC) supporting a USRP device, then you can connect it to the Omsocom Iu or Iuh interface. In absence of that, it is not possible. I don't know any such implementation. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From snehasish.cse at LIVE.COM Wed Feb 1 20:54:12 2017 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Wed, 1 Feb 2017 20:54:12 +0000 Subject: Usrp with 3G In-Reply-To: <20170201162100.7odzf6pcdcvsalvp@nataraja> References: , <20170201162100.7odzf6pcdcvsalvp@nataraja> Message-ID: Thanks for the info. Sent from my iPhone > On 01-Feb-2017, at 9:51 PM, Harald Welte wrote: > >> On Wed, Feb 01, 2017 at 04:05:20PM +0000, Snehasish Kar wrote: >> Hi >> Can 3G be used with USRP? > > Osmocom so far implements only the core network down to IuCS and IuPS as > well as a gateway to Iuh. It does not implement an RNC nor the NodeB. > > So *if* you find a PHY/RLC/MAC layer (NodeB) and the RRC layer (RNC) > supporting a USRP device, then you can connect it to the Omsocom Iu or > Iuh interface. In absence of that, it is not possible. I don't know > any such implementation. > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From pablo at netfilter.org Thu Feb 2 13:56:56 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu, 2 Feb 2017 14:56:56 +0100 Subject: [PATCH net-next v2 5/6] gtp: add socket to pdp context In-Reply-To: <20170130163713.17524-6-aschultz@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-6-aschultz@tpip.net> Message-ID: <20170202135656.GA23901@salvia> On Mon, Jan 30, 2017 at 05:37:12PM +0100, Andreas Schultz wrote: > Having the socket present in context simplifies the sending logic. > It also fixes the invalid assumption that we have to use the same > sending socket for all client IP's on a specific gtp interface. > > Signed-off-by: Andreas Schultz > --- > drivers/net/gtp.c | 72 ++++++++++++++++++++++++++++++------------------------- > 1 file changed, 39 insertions(+), 33 deletions(-) > > diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > index 68c6c9b..ff00597 100644 > --- a/drivers/net/gtp.c > +++ b/drivers/net/gtp.c [...] > @@ -984,16 +966,26 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct genl_info *info) > return 0; > } > > +static void pdp_context_free(struct rcu_head *head) > +{ > + struct pdp_ctx *pctx = container_of(head, struct pdp_ctx, rcu_head); > + > + sock_put(pctx->sk); > + kfree(pctx); > +} > + > static void pdp_context_delete(struct pdp_ctx *pctx) > { > hlist_del_rcu(&pctx->hlist_tid); > hlist_del_rcu(&pctx->hlist_addr); > - kfree(pctx); > + call_rcu(&pctx->rcu_head, pdp_context_free); This is fixing incorrect rcu conversion in 4/6. Please, fix this there. From pablo at netfilter.org Thu Feb 2 14:10:11 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu, 2 Feb 2017 15:10:11 +0100 Subject: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional In-Reply-To: <20170130163713.17524-2-aschultz@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-2-aschultz@tpip.net> Message-ID: <20170202141011.GB23901@salvia> On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote: > Having both GTPv0-U and GTPv1-U is not always desirable. > Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP > Rel-8 onwards. Post Rel-8 implementation are discuraged > from listening on the v0 port (see 3GPP TS 29.281, Sect. 1). > > A future change will completely decouple the sockets from the > network device. Till then, at least one of the sockets needs to > be specified (either v0 or v1), the other is optional. > > Signed-off-by: Andreas Schultz > --- > drivers/net/gtp.c | 142 +++++++++++++++++++++++++++++------------------------- > 1 file changed, 76 insertions(+), 66 deletions(-) > > diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > index bda0c64..18944f4 100644 > --- a/drivers/net/gtp.c > +++ b/drivers/net/gtp.c > @@ -259,28 +259,30 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb, > return iptunnel_pull_header(skb, hdrlen, skb->protocol, xnet); > } > > -static void gtp_encap_disable(struct gtp_dev *gtp) > -{ > - if (gtp->sock0 && gtp->sock0->sk) { > - udp_sk(gtp->sock0->sk)->encap_type = 0; > - rcu_assign_sk_user_data(gtp->sock0->sk, NULL); > - } > - if (gtp->sock1u && gtp->sock1u->sk) { > - udp_sk(gtp->sock1u->sk)->encap_type = 0; > - rcu_assign_sk_user_data(gtp->sock1u->sk, NULL); > - } > - > - gtp->sock0 = NULL; > - gtp->sock1u = NULL; > -} > - > static void gtp_encap_destroy(struct sock *sk) > { > struct gtp_dev *gtp; > > gtp = rcu_dereference_sk_user_data(sk); > - if (gtp) > - gtp_encap_disable(gtp); > + if (gtp) { > + udp_sk(sk)->encap_type = 0; > + rcu_assign_sk_user_data(sk, NULL); > + } > +} > + > +static void gtp_encap_disable_sock(struct socket *sock) Nitpick: Please, use sk for consistency: static void gtp_encap_disable_sock(struct socket *sk) > +{ > + if (!sock || !sock->sk) > + return; > + > + gtp_encap_destroy(sock->sk); > + sockfd_put(sock); This socket is created by userspace. If we hold it and the userspace daemon stops without cleaning up configuration, we keep this socket around that we cannot remove. That's why we didn't hold any reference to this so far. I guess you need this because of your follow up patch that catches this in the gtp instance structure, that's why this slipped through. > +} > + > +static void gtp_encap_disable(struct gtp_dev *gtp) > +{ > + gtp_encap_disable_sock(gtp->sock0); > + gtp_encap_disable_sock(gtp->sock1u); > } > > /* UDP encapsulation receive handler. See net/ipv4/udp.c. > @@ -640,27 +642,24 @@ static void gtp_link_setup(struct net_device *dev) > > static int gtp_hashtable_new(struct gtp_dev *gtp, int hsize); > static void gtp_hashtable_free(struct gtp_dev *gtp); > -static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp, > - int fd_gtp0, int fd_gtp1); > +static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]); > +static void gtp_encap_disable(struct gtp_dev *gtp); > > static int gtp_newlink(struct net *src_net, struct net_device *dev, > struct nlattr *tb[], struct nlattr *data[]) > { > - int hashsize, err, fd0, fd1; > + int hashsize, err; > struct gtp_dev *gtp; > struct gtp_net *gn; Nitpick: We prefer declarations in this order: struct gtp_dev *gtp; struct gtp_net *gn; int hashsize, err; >From longest line to shorter. I know we break this rule in many spots, but it would be good if you keep this in mind. > - if (!data[IFLA_GTP_FD0] || !data[IFLA_GTP_FD1]) > + if (!data[IFLA_GTP_FD0] && !data[IFLA_GTP_FD1]) > return -EINVAL; > > gtp = netdev_priv(dev); > > - fd0 = nla_get_u32(data[IFLA_GTP_FD0]); > - fd1 = nla_get_u32(data[IFLA_GTP_FD1]); > - > - err = gtp_encap_enable(dev, gtp, fd0, fd1); > + err = gtp_encap_enable(gtp, data); > if (err < 0) > - goto out_err; > + return err; > > if (!data[IFLA_GTP_PDP_HASHSIZE]) > hashsize = 1024; > @@ -688,7 +687,6 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, > gtp_hashtable_free(gtp); > out_encap: > gtp_encap_disable(gtp); > -out_err: > return err; > } > > @@ -803,61 +801,73 @@ static void gtp_hashtable_free(struct gtp_dev *gtp) > kfree(gtp->tid_hash); > } > > -static int gtp_encap_enable(struct net_device *dev, struct gtp_dev *gtp, > - int fd_gtp0, int fd_gtp1) > +static struct socket *gtp_encap_enable_socket(int fd, int type, > + struct gtp_dev *gtp) > { > struct udp_tunnel_sock_cfg tuncfg = {NULL}; > - struct socket *sock0, *sock1u; > + struct socket *sock; > int err; > > - netdev_dbg(dev, "enable gtp on %d, %d\n", fd_gtp0, fd_gtp1); > + pr_debug("enable gtp on %d, %d\n", fd, type); > > - sock0 = sockfd_lookup(fd_gtp0, &err); > - if (sock0 == NULL) { > - netdev_dbg(dev, "socket fd=%d not found (gtp0)\n", fd_gtp0); > - return -ENOENT; > + sock = sockfd_lookup(fd, &err); > + if (!sock) { > + pr_debug("gtp socket fd=%d not found\n", fd); > + return NULL; > } > > - if (sock0->sk->sk_protocol != IPPROTO_UDP) { > - netdev_dbg(dev, "socket fd=%d not UDP\n", fd_gtp0); > + if (sock->sk->sk_protocol != IPPROTO_UDP) { > + pr_debug("socket fd=%d not UDP\n", fd); I would suggest you submit an initial patch to cover all this conversion from netdev_dbg() to pr_debug() in first place, so we don't do this here. > err = -EINVAL; > - goto err1; > + goto out_sock; > } > > - sock1u = sockfd_lookup(fd_gtp1, &err); > - if (sock1u == NULL) { > - netdev_dbg(dev, "socket fd=%d not found (gtp1u)\n", fd_gtp1); > - err = -ENOENT; > - goto err1; > + if (rcu_dereference_sk_user_data(sock->sk)) { > + err = -EBUSY; > + goto out_sock; > } > > - if (sock1u->sk->sk_protocol != IPPROTO_UDP) { > - netdev_dbg(dev, "socket fd=%d not UDP\n", fd_gtp1); > - err = -EINVAL; > - goto err2; > - } > - > - netdev_dbg(dev, "enable gtp on %p, %p\n", sock0, sock1u); > - > - gtp->sock0 = sock0; > - gtp->sock1u = sock1u; > - > tuncfg.sk_user_data = gtp; > + tuncfg.encap_type = type; > tuncfg.encap_rcv = gtp_encap_recv; > tuncfg.encap_destroy = gtp_encap_destroy; > > - tuncfg.encap_type = UDP_ENCAP_GTP0; > - setup_udp_tunnel_sock(sock_net(gtp->sock0->sk), gtp->sock0, &tuncfg); > - > - tuncfg.encap_type = UDP_ENCAP_GTP1U; > - setup_udp_tunnel_sock(sock_net(gtp->sock1u->sk), gtp->sock1u, &tuncfg); > - > - err = 0; > -err2: > - sockfd_put(sock1u); > -err1: > - sockfd_put(sock0); > - return err; > + setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg); > + return sock; > + > +out_sock: > + sockfd_put(sock); > + return ERR_PTR(err); > +} > + > +static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) > +{ > + struct socket *sock0 = NULL; > + struct socket *sock1u = NULL; Same thing here regarding socket declaration. > + if (data[IFLA_GTP_FD0]) { > + u32 fd0 = nla_get_u32(data[IFLA_GTP_FD0]); > + > + sock0 = gtp_encap_enable_socket(fd0, UDP_ENCAP_GTP0, gtp); > + if (IS_ERR(sock0)) > + return PTR_ERR(sock0); > + } > + > + if (data[IFLA_GTP_FD1]) { > + u32 fd1 = nla_get_u32(data[IFLA_GTP_FD1]); > + > + sock1u = gtp_encap_enable_socket(fd1, UDP_ENCAP_GTP1U, gtp); > + if (IS_ERR(sock1u)) { > + if (sock0) > + sockfd_put(sock0); > + return PTR_ERR(sock1u); > + } > + } > + > + gtp->sock0 = sock0; > + gtp->sock1u = sock1u; > + > + return 0; > } > > static struct net_device *gtp_find_dev(struct net *net, int ifindex) > -- > 2.10.2 > From aschultz at tpip.net Thu Feb 2 14:12:55 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Thu, 2 Feb 2017 15:12:55 +0100 (CET) Subject: [PATCH net-next v2 5/6] gtp: add socket to pdp context In-Reply-To: <20170202135656.GA23901@salvia> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-6-aschultz@tpip.net> <20170202135656.GA23901@salvia> Message-ID: <858150010.730228.1486044775198.JavaMail.zimbra@tpip.net> Hi, ----- On Feb 2, 2017, at 2:56 PM, pablo pablo at netfilter.org wrote: > On Mon, Jan 30, 2017 at 05:37:12PM +0100, Andreas Schultz wrote: >> Having the socket present in context simplifies the sending logic. >> It also fixes the invalid assumption that we have to use the same >> sending socket for all client IP's on a specific gtp interface. >> >> Signed-off-by: Andreas Schultz >> --- >> drivers/net/gtp.c | 72 ++++++++++++++++++++++++++++++------------------------- >> 1 file changed, 39 insertions(+), 33 deletions(-) >> >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c >> index 68c6c9b..ff00597 100644 >> --- a/drivers/net/gtp.c >> +++ b/drivers/net/gtp.c > [...] >> @@ -984,16 +966,26 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct >> genl_info *info) >> return 0; >> } >> >> +static void pdp_context_free(struct rcu_head *head) >> +{ >> + struct pdp_ctx *pctx = container_of(head, struct pdp_ctx, rcu_head); >> + >> + sock_put(pctx->sk); >> + kfree(pctx); >> +} >> + >> static void pdp_context_delete(struct pdp_ctx *pctx) >> { >> hlist_del_rcu(&pctx->hlist_tid); >> hlist_del_rcu(&pctx->hlist_addr); >> - kfree(pctx); >> + call_rcu(&pctx->rcu_head, pdp_context_free); > > This is fixing incorrect rcu conversion in 4/6. Please, fix this there. Ehm, right, but the kfree in 4/6 could have been a kfree_rcu instead without the call_rcu. Do you prefer to introduce the call_rcu in 4/6 and then just add the sock_put in this patch or should I change 4/6 to kfree_rcu and do the call_rcu conversion here? Andreas From pablo at netfilter.org Thu Feb 2 14:19:51 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu, 2 Feb 2017 15:19:51 +0100 Subject: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup In-Reply-To: <20170130163713.17524-4-aschultz@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-4-aschultz@tpip.net> Message-ID: <20170202141951.GA3883@salvia> On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote: > This unifies duplicate code into a helper. It also prepares the > groundwork to add a lookup version that uses the socket to find > attache pdp contexts. > > Signed-off-by: Andreas Schultz > --- > drivers/net/gtp.c | 120 +++++++++++++++++++++++------------------------------- > 1 file changed, 51 insertions(+), 69 deletions(-) > > diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > index c96c71f..6b7a3c2 100644 > --- a/drivers/net/gtp.c > +++ b/drivers/net/gtp.c [...] > +static struct pdp_ctx *gtp_genl_find_pdp(struct sk_buff *skb, > + struct genl_info *info) > +{ > + struct pdp_ctx *pctx; > + > + if (info->attrs[GTPA_LINK]) > + pctx = gtp_genl_find_pdp_by_link(skb, info); > + else > + pctx = ERR_PTR(-EINVAL); > + if (!pctx) > + pctx = ERR_PTR(-ENOENT); > + > + return pctx; > +} For gtp_genl_find_pdp(), I think this is easier to read: if (!info->attrs[GTPA_LINK]) return ERR_PTR(-EINVAL); pctx = gtp_genl_find_pdp_by_link(skb, info); if (!pctx) return ERR_PTR(-ENOENT); return pctx; From aschultz at tpip.net Thu Feb 2 14:27:17 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Thu, 2 Feb 2017 15:27:17 +0100 (CET) Subject: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup In-Reply-To: <20170202141951.GA3883@salvia> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-4-aschultz@tpip.net> <20170202141951.GA3883@salvia> Message-ID: <1732401345.730492.1486045637611.JavaMail.zimbra@tpip.net> ----- On Feb 2, 2017, at 3:19 PM, pablo pablo at netfilter.org wrote: > On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote: >> This unifies duplicate code into a helper. It also prepares the >> groundwork to add a lookup version that uses the socket to find >> attache pdp contexts. >> >> Signed-off-by: Andreas Schultz >> --- >> drivers/net/gtp.c | 120 +++++++++++++++++++++++------------------------------- >> 1 file changed, 51 insertions(+), 69 deletions(-) >> >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c >> index c96c71f..6b7a3c2 100644 >> --- a/drivers/net/gtp.c >> +++ b/drivers/net/gtp.c > [...] >> +static struct pdp_ctx *gtp_genl_find_pdp(struct sk_buff *skb, >> + struct genl_info *info) >> +{ >> + struct pdp_ctx *pctx; >> + >> + if (info->attrs[GTPA_LINK]) >> + pctx = gtp_genl_find_pdp_by_link(skb, info); >> + else >> + pctx = ERR_PTR(-EINVAL); >> + if (!pctx) >> + pctx = ERR_PTR(-ENOENT); >> + >> + return pctx; >> +} > > For gtp_genl_find_pdp(), I think this is easier to read: > > if (!info->attrs[GTPA_LINK]) > return ERR_PTR(-EINVAL); > > pctx = gtp_genl_find_pdp_by_link(skb, info); > if (!pctx) > return ERR_PTR(-ENOENT); > > return pctx; Yes, but a later patch (will be submitted after this series is accepted) will change that to: if (info->attrs[GTPA_LINK]) pctx = gtp_genl_find_pdp_by_link(skb, info); else if (info->attrs[GTPA_FD]) pctx = gtp_genl_find_pdp_by_socket(skb, info); else pctx = ERR_PTR(-EINVAL); if (!pctx) pctx = ERR_PTR(-ENOENT); return pctx; I can use your form for this change, but have a larger change later. Which way do you prefer it? Andreas From pablo at netfilter.org Thu Feb 2 14:28:42 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu, 2 Feb 2017 15:28:42 +0100 Subject: [PATCH net-next v2 5/6] gtp: add socket to pdp context In-Reply-To: <858150010.730228.1486044775198.JavaMail.zimbra@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-6-aschultz@tpip.net> <20170202135656.GA23901@salvia> <858150010.730228.1486044775198.JavaMail.zimbra@tpip.net> Message-ID: <20170202142842.GA19643@salvia> On Thu, Feb 02, 2017 at 03:12:55PM +0100, Andreas Schultz wrote: > Hi, > > ----- On Feb 2, 2017, at 2:56 PM, pablo pablo at netfilter.org wrote: > > > On Mon, Jan 30, 2017 at 05:37:12PM +0100, Andreas Schultz wrote: > >> Having the socket present in context simplifies the sending logic. > >> It also fixes the invalid assumption that we have to use the same > >> sending socket for all client IP's on a specific gtp interface. > >> > >> Signed-off-by: Andreas Schultz > >> --- > >> drivers/net/gtp.c | 72 ++++++++++++++++++++++++++++++------------------------- > >> 1 file changed, 39 insertions(+), 33 deletions(-) > >> > >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > >> index 68c6c9b..ff00597 100644 > >> --- a/drivers/net/gtp.c > >> +++ b/drivers/net/gtp.c > > [...] > >> @@ -984,16 +966,26 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct > >> genl_info *info) > >> return 0; > >> } > >> > >> +static void pdp_context_free(struct rcu_head *head) > >> +{ > >> + struct pdp_ctx *pctx = container_of(head, struct pdp_ctx, rcu_head); > >> + > >> + sock_put(pctx->sk); > >> + kfree(pctx); > >> +} > >> + > >> static void pdp_context_delete(struct pdp_ctx *pctx) > >> { > >> hlist_del_rcu(&pctx->hlist_tid); > >> hlist_del_rcu(&pctx->hlist_addr); > >> - kfree(pctx); > >> + call_rcu(&pctx->rcu_head, pdp_context_free); > > > > This is fixing incorrect rcu conversion in 4/6. Please, fix this there. > > Ehm, right, but the kfree in 4/6 could have been a kfree_rcu instead without > the call_rcu. > > Do you prefer to introduce the call_rcu in 4/6 and then just add the sock_put > in this patch or should I change 4/6 to kfree_rcu and do the call_rcu > conversion here? I suggest you just call kfree_rcu() from 4/6. Regarding holding socket reference, see my comment for patch 1/6. From aschultz at tpip.net Thu Feb 2 14:30:51 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Thu, 2 Feb 2017 15:30:51 +0100 (CET) Subject: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional In-Reply-To: <20170202141011.GB23901@salvia> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-2-aschultz@tpip.net> <20170202141011.GB23901@salvia> Message-ID: <1114368875.730626.1486045851291.JavaMail.zimbra@tpip.net> ----- On Feb 2, 2017, at 3:10 PM, pablo pablo at netfilter.org wrote: > On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote: >> Having both GTPv0-U and GTPv1-U is not always desirable. >> Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP >> Rel-8 onwards. Post Rel-8 implementation are discuraged >> from listening on the v0 port (see 3GPP TS 29.281, Sect. 1). >> >> A future change will completely decouple the sockets from the >> network device. Till then, at least one of the sockets needs to >> be specified (either v0 or v1), the other is optional. >> >> Signed-off-by: Andreas Schultz >> --- >> drivers/net/gtp.c | 142 +++++++++++++++++++++++++++++------------------------- >> 1 file changed, 76 insertions(+), 66 deletions(-) >> >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c >> index bda0c64..18944f4 100644 >> --- a/drivers/net/gtp.c >> +++ b/drivers/net/gtp.c >> @@ -259,28 +259,30 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, >> struct sk_buff *skb, >> return iptunnel_pull_header(skb, hdrlen, skb->protocol, xnet); >> } >> >> -static void gtp_encap_disable(struct gtp_dev *gtp) >> -{ >> - if (gtp->sock0 && gtp->sock0->sk) { >> - udp_sk(gtp->sock0->sk)->encap_type = 0; >> - rcu_assign_sk_user_data(gtp->sock0->sk, NULL); >> - } >> - if (gtp->sock1u && gtp->sock1u->sk) { >> - udp_sk(gtp->sock1u->sk)->encap_type = 0; >> - rcu_assign_sk_user_data(gtp->sock1u->sk, NULL); >> - } >> - >> - gtp->sock0 = NULL; >> - gtp->sock1u = NULL; >> -} >> - >> static void gtp_encap_destroy(struct sock *sk) >> { >> struct gtp_dev *gtp; >> >> gtp = rcu_dereference_sk_user_data(sk); >> - if (gtp) >> - gtp_encap_disable(gtp); >> + if (gtp) { >> + udp_sk(sk)->encap_type = 0; >> + rcu_assign_sk_user_data(sk, NULL); >> + } >> +} >> + >> +static void gtp_encap_disable_sock(struct socket *sock) > > Nitpick: Please, use sk for consistency: > > static void gtp_encap_disable_sock(struct socket *sk) > Throughout the net subsystem 'struct socket` is always using sock for variable names and 'struct sock' is using sk. I have been following that convention, but can change to sk if you really want. Andreas From pablo at netfilter.org Thu Feb 2 14:31:52 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu, 2 Feb 2017 15:31:52 +0100 Subject: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup In-Reply-To: <1732401345.730492.1486045637611.JavaMail.zimbra@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-4-aschultz@tpip.net> <20170202141951.GA3883@salvia> <1732401345.730492.1486045637611.JavaMail.zimbra@tpip.net> Message-ID: <20170202143152.GA19708@salvia> On Thu, Feb 02, 2017 at 03:27:17PM +0100, Andreas Schultz wrote: > > > ----- On Feb 2, 2017, at 3:19 PM, pablo pablo at netfilter.org wrote: > > > On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote: > >> This unifies duplicate code into a helper. It also prepares the > >> groundwork to add a lookup version that uses the socket to find > >> attache pdp contexts. > >> > >> Signed-off-by: Andreas Schultz > >> --- > >> drivers/net/gtp.c | 120 +++++++++++++++++++++++------------------------------- > >> 1 file changed, 51 insertions(+), 69 deletions(-) > >> > >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > >> index c96c71f..6b7a3c2 100644 > >> --- a/drivers/net/gtp.c > >> +++ b/drivers/net/gtp.c > > [...] > >> +static struct pdp_ctx *gtp_genl_find_pdp(struct sk_buff *skb, > >> + struct genl_info *info) > >> +{ > >> + struct pdp_ctx *pctx; > >> + > >> + if (info->attrs[GTPA_LINK]) > >> + pctx = gtp_genl_find_pdp_by_link(skb, info); > >> + else > >> + pctx = ERR_PTR(-EINVAL); > >> + if (!pctx) > >> + pctx = ERR_PTR(-ENOENT); > >> + > >> + return pctx; > >> +} > > > > For gtp_genl_find_pdp(), I think this is easier to read: > > > > if (!info->attrs[GTPA_LINK]) > > return ERR_PTR(-EINVAL); > > > > pctx = gtp_genl_find_pdp_by_link(skb, info); > > if (!pctx) > > return ERR_PTR(-ENOENT); > > > > return pctx; > > Yes, but a later patch (will be submitted after this series is > accepted) will change that to: > > if (info->attrs[GTPA_LINK]) > pctx = gtp_genl_find_pdp_by_link(skb, info); > else if (info->attrs[GTPA_FD]) > pctx = gtp_genl_find_pdp_by_socket(skb, info); > else > pctx = ERR_PTR(-EINVAL); > > if (!pctx) > pctx = ERR_PTR(-ENOENT); > > return pctx; > > I can use your form for this change, but have a larger change > later. Which way do you prefer it? I see, then leave this as it is. From pablo at netfilter.org Thu Feb 2 14:32:54 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu, 2 Feb 2017 15:32:54 +0100 Subject: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional In-Reply-To: <1114368875.730626.1486045851291.JavaMail.zimbra@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-2-aschultz@tpip.net> <20170202141011.GB23901@salvia> <1114368875.730626.1486045851291.JavaMail.zimbra@tpip.net> Message-ID: <20170202143254.GA19735@salvia> On Thu, Feb 02, 2017 at 03:30:51PM +0100, Andreas Schultz wrote: > > > ----- On Feb 2, 2017, at 3:10 PM, pablo pablo at netfilter.org wrote: > > > On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote: > >> Having both GTPv0-U and GTPv1-U is not always desirable. > >> Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP > >> Rel-8 onwards. Post Rel-8 implementation are discuraged > >> from listening on the v0 port (see 3GPP TS 29.281, Sect. 1). > >> > >> A future change will completely decouple the sockets from the > >> network device. Till then, at least one of the sockets needs to > >> be specified (either v0 or v1), the other is optional. > >> > >> Signed-off-by: Andreas Schultz > >> --- > >> drivers/net/gtp.c | 142 +++++++++++++++++++++++++++++------------------------- > >> 1 file changed, 76 insertions(+), 66 deletions(-) > >> > >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > >> index bda0c64..18944f4 100644 > >> --- a/drivers/net/gtp.c > >> +++ b/drivers/net/gtp.c > >> @@ -259,28 +259,30 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, > >> struct sk_buff *skb, > >> return iptunnel_pull_header(skb, hdrlen, skb->protocol, xnet); > >> } > >> > >> -static void gtp_encap_disable(struct gtp_dev *gtp) > >> -{ > >> - if (gtp->sock0 && gtp->sock0->sk) { > >> - udp_sk(gtp->sock0->sk)->encap_type = 0; > >> - rcu_assign_sk_user_data(gtp->sock0->sk, NULL); > >> - } > >> - if (gtp->sock1u && gtp->sock1u->sk) { > >> - udp_sk(gtp->sock1u->sk)->encap_type = 0; > >> - rcu_assign_sk_user_data(gtp->sock1u->sk, NULL); > >> - } > >> - > >> - gtp->sock0 = NULL; > >> - gtp->sock1u = NULL; > >> -} > >> - > >> static void gtp_encap_destroy(struct sock *sk) > >> { > >> struct gtp_dev *gtp; > >> > >> gtp = rcu_dereference_sk_user_data(sk); > >> - if (gtp) > >> - gtp_encap_disable(gtp); > >> + if (gtp) { > >> + udp_sk(sk)->encap_type = 0; > >> + rcu_assign_sk_user_data(sk, NULL); > >> + } > >> +} > >> + > >> +static void gtp_encap_disable_sock(struct socket *sock) > > > > Nitpick: Please, use sk for consistency: > > > > static void gtp_encap_disable_sock(struct socket *sk) > > > > Throughout the net subsystem 'struct socket` is always using sock > for variable names and 'struct sock' is using sk. I have been > following that convention, but can change to sk if you really want. Forget this, sorry. I think I read there 'struct sock'. I got confused by patch context. From aschultz at tpip.net Thu Feb 2 14:38:07 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Thu, 2 Feb 2017 15:38:07 +0100 (CET) Subject: [PATCH net-next v2 5/6] gtp: add socket to pdp context In-Reply-To: <20170202142842.GA19643@salvia> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-6-aschultz@tpip.net> <20170202135656.GA23901@salvia> <858150010.730228.1486044775198.JavaMail.zimbra@tpip.net> <20170202142842.GA19643@salvia> Message-ID: <249401941.730762.1486046287023.JavaMail.zimbra@tpip.net> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote: > On Thu, Feb 02, 2017 at 03:12:55PM +0100, Andreas Schultz wrote: >> Hi, >> >> ----- On Feb 2, 2017, at 2:56 PM, pablo pablo at netfilter.org wrote: >> >> > On Mon, Jan 30, 2017 at 05:37:12PM +0100, Andreas Schultz wrote: >> >> Having the socket present in context simplifies the sending logic. >> >> It also fixes the invalid assumption that we have to use the same >> >> sending socket for all client IP's on a specific gtp interface. >> >> >> >> Signed-off-by: Andreas Schultz >> >> --- >> >> drivers/net/gtp.c | 72 ++++++++++++++++++++++++++++++------------------------- >> >> 1 file changed, 39 insertions(+), 33 deletions(-) >> >> >> >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c >> >> index 68c6c9b..ff00597 100644 >> >> --- a/drivers/net/gtp.c >> >> +++ b/drivers/net/gtp.c >> > [...] >> >> @@ -984,16 +966,26 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct >> >> genl_info *info) >> >> return 0; >> >> } >> >> >> >> +static void pdp_context_free(struct rcu_head *head) >> >> +{ >> >> + struct pdp_ctx *pctx = container_of(head, struct pdp_ctx, rcu_head); >> >> + >> >> + sock_put(pctx->sk); >> >> + kfree(pctx); >> >> +} >> >> + >> >> static void pdp_context_delete(struct pdp_ctx *pctx) >> >> { >> >> hlist_del_rcu(&pctx->hlist_tid); >> >> hlist_del_rcu(&pctx->hlist_addr); >> >> - kfree(pctx); >> >> + call_rcu(&pctx->rcu_head, pdp_context_free); >> > >> > This is fixing incorrect rcu conversion in 4/6. Please, fix this there. >> >> Ehm, right, but the kfree in 4/6 could have been a kfree_rcu instead without >> the call_rcu. >> >> Do you prefer to introduce the call_rcu in 4/6 and then just add the sock_put >> in this patch or should I change 4/6 to kfree_rcu and do the call_rcu >> conversion here? > > I suggest you just call kfree_rcu() from 4/6. > > Regarding holding socket reference, see my comment for patch 1/6. This is going to be a problem at this stage of the changes. The final goal is to have a reference from the socket to the pdp context. Then, when the socket is closed, the pdp context can be destroyed. However, at this point, only the netdevice knows about the contexts. So when the socket is closed, the pdp context would have a dangling reference to the socket. I can integrate this change into the later one. But it will make that change larger and more difficult to review. I guess, I'm going to drop this change from this series and see if can reorder the next part so that it still makes and I easy to review.... Andreas From pablo at netfilter.org Thu Feb 2 14:46:06 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Thu, 2 Feb 2017 15:46:06 +0100 Subject: [PATCH net-next v2 5/6] gtp: add socket to pdp context In-Reply-To: <249401941.730762.1486046287023.JavaMail.zimbra@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-6-aschultz@tpip.net> <20170202135656.GA23901@salvia> <858150010.730228.1486044775198.JavaMail.zimbra@tpip.net> <20170202142842.GA19643@salvia> <249401941.730762.1486046287023.JavaMail.zimbra@tpip.net> Message-ID: <20170202144606.GA19992@salvia> On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote: > > > ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote: > > > On Thu, Feb 02, 2017 at 03:12:55PM +0100, Andreas Schultz wrote: > >> Hi, > >> > >> ----- On Feb 2, 2017, at 2:56 PM, pablo pablo at netfilter.org wrote: > >> > >> > On Mon, Jan 30, 2017 at 05:37:12PM +0100, Andreas Schultz wrote: > >> >> Having the socket present in context simplifies the sending logic. > >> >> It also fixes the invalid assumption that we have to use the same > >> >> sending socket for all client IP's on a specific gtp interface. > >> >> > >> >> Signed-off-by: Andreas Schultz > >> >> --- > >> >> drivers/net/gtp.c | 72 ++++++++++++++++++++++++++++++------------------------- > >> >> 1 file changed, 39 insertions(+), 33 deletions(-) > >> >> > >> >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c > >> >> index 68c6c9b..ff00597 100644 > >> >> --- a/drivers/net/gtp.c > >> >> +++ b/drivers/net/gtp.c > >> > [...] > >> >> @@ -984,16 +966,26 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct > >> >> genl_info *info) > >> >> return 0; > >> >> } > >> >> > >> >> +static void pdp_context_free(struct rcu_head *head) > >> >> +{ > >> >> + struct pdp_ctx *pctx = container_of(head, struct pdp_ctx, rcu_head); > >> >> + > >> >> + sock_put(pctx->sk); > >> >> + kfree(pctx); > >> >> +} > >> >> + > >> >> static void pdp_context_delete(struct pdp_ctx *pctx) > >> >> { > >> >> hlist_del_rcu(&pctx->hlist_tid); > >> >> hlist_del_rcu(&pctx->hlist_addr); > >> >> - kfree(pctx); > >> >> + call_rcu(&pctx->rcu_head, pdp_context_free); > >> > > >> > This is fixing incorrect rcu conversion in 4/6. Please, fix this there. > >> > >> Ehm, right, but the kfree in 4/6 could have been a kfree_rcu instead without > >> the call_rcu. > >> > >> Do you prefer to introduce the call_rcu in 4/6 and then just add the sock_put > >> in this patch or should I change 4/6 to kfree_rcu and do the call_rcu > >> conversion here? > > > > I suggest you just call kfree_rcu() from 4/6. > > > > Regarding holding socket reference, see my comment for patch 1/6. > > This is going to be a problem at this stage of the changes. > > The final goal is to have a reference from the socket to the pdp context. Is this just a cleanup? Or you need this sk caching for some follow up work? > Then, when the socket is closed, the pdp context can be destroyed. > > However, at this point, only the netdevice knows about the contexts. So > when the socket is closed, the pdp context would have a dangling reference > to the socket. > > I can integrate this change into the later one. But it will make that > change larger and more difficult to review. > > I guess, I'm going to drop this change from this series and see if can > reorder the next part so that it still makes and I easy to review.... Agreed. Thanks. From aschultz at tpip.net Thu Feb 2 15:07:23 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Thu, 2 Feb 2017 16:07:23 +0100 (CET) Subject: [PATCH net-next v2 5/6] gtp: add socket to pdp context In-Reply-To: <20170202144606.GA19992@salvia> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-6-aschultz@tpip.net> <20170202135656.GA23901@salvia> <858150010.730228.1486044775198.JavaMail.zimbra@tpip.net> <20170202142842.GA19643@salvia> <249401941.730762.1486046287023.JavaMail.zimbra@tpip.net> <20170202144606.GA19992@salvia> Message-ID: <2083605423.731432.1486048043458.JavaMail.zimbra@tpip.net> ----- On Feb 2, 2017, at 3:46 PM, pablo pablo at netfilter.org wrote: > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote: >> >> >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote: >> >> > On Thu, Feb 02, 2017 at 03:12:55PM +0100, Andreas Schultz wrote: >> >> Hi, >> >> >> >> ----- On Feb 2, 2017, at 2:56 PM, pablo pablo at netfilter.org wrote: >> >> >> >> > On Mon, Jan 30, 2017 at 05:37:12PM +0100, Andreas Schultz wrote: >> >> >> Having the socket present in context simplifies the sending logic. >> >> >> It also fixes the invalid assumption that we have to use the same >> >> >> sending socket for all client IP's on a specific gtp interface. >> >> >> >> >> >> Signed-off-by: Andreas Schultz >> >> >> --- >> >> >> drivers/net/gtp.c | 72 ++++++++++++++++++++++++++++++------------------------- >> >> >> 1 file changed, 39 insertions(+), 33 deletions(-) >> >> >> >> >> >> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c >> >> >> index 68c6c9b..ff00597 100644 >> >> >> --- a/drivers/net/gtp.c >> >> >> +++ b/drivers/net/gtp.c >> >> > [...] >> >> >> @@ -984,16 +966,26 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct >> >> >> genl_info *info) >> >> >> return 0; >> >> >> } >> >> >> >> >> >> +static void pdp_context_free(struct rcu_head *head) >> >> >> +{ >> >> >> + struct pdp_ctx *pctx = container_of(head, struct pdp_ctx, rcu_head); >> >> >> + >> >> >> + sock_put(pctx->sk); >> >> >> + kfree(pctx); >> >> >> +} >> >> >> + >> >> >> static void pdp_context_delete(struct pdp_ctx *pctx) >> >> >> { >> >> >> hlist_del_rcu(&pctx->hlist_tid); >> >> >> hlist_del_rcu(&pctx->hlist_addr); >> >> >> - kfree(pctx); >> >> >> + call_rcu(&pctx->rcu_head, pdp_context_free); >> >> > >> >> > This is fixing incorrect rcu conversion in 4/6. Please, fix this there. >> >> >> >> Ehm, right, but the kfree in 4/6 could have been a kfree_rcu instead without >> >> the call_rcu. >> >> >> >> Do you prefer to introduce the call_rcu in 4/6 and then just add the sock_put >> >> in this patch or should I change 4/6 to kfree_rcu and do the call_rcu >> >> conversion here? >> > >> > I suggest you just call kfree_rcu() from 4/6. >> > >> > Regarding holding socket reference, see my comment for patch 1/6. >> >> This is going to be a problem at this stage of the changes. >> >> The final goal is to have a reference from the socket to the pdp context. > > Is this just a cleanup? Or you need this sk caching for some follow up > work? It's not caching, the plan is to completely remove the socket from the GTP netdevice (as far as that is possible without breaking the existing API). A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's can have overlapping IP address ranges. The only sensible way to handle this, is to have a netdevice per APN. This breaks the current 1:1 relation between sockets and netdevices. Andreas > >> Then, when the socket is closed, the pdp context can be destroyed. >> >> However, at this point, only the netdevice knows about the contexts. So >> when the socket is closed, the pdp context would have a dangling reference >> to the socket. >> >> I can integrate this change into the later one. But it will make that >> change larger and more difficult to review. >> >> I guess, I'm going to drop this change from this series and see if can >> reorder the next part so that it still makes and I easy to review.... > > Agreed. Thanks. From nhofmeyr at sysmocom.de Fri Feb 3 01:30:23 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 3 Feb 2017 02:30:23 +0100 Subject: Channel release error when osmo-nitb want execute location update In-Reply-To: References: Message-ID: <20170203013023.GA22980@my.box> Running a test on my sysmoBTS just now (for completely unrelated reasons) gave me a similar log like below. But it only happened once and I am unable to reproduce it: osmo-nitb tried to allocate an SDCCH on various lchan of TS 0, each says Activating ARFCN(868) SS(0) lctype SDCCH r=LOCATION_UPDATE but each ended up in "RELEASE DUE ERROR", then "back in operation". This happened probably more than a dozen times over in close succession. Seconds after it seemed to have settled and I could do Location Updating again. I've never seen this before on any BTS and am actually unable to reproduce it now. Could it be due to some recent software change? (running all the master branches of right now.) Complete logs are here: http://kleinekatze.de/Roht9Sei/release_due_error (note: logs contain ANSI coloring, so best view with 'less -r' or 'cat') The dance starts e.g. in the nitb log at 20170203014131863 . The bts.log timestamps are one hour earlier plus nine seconds, so the dance starts in the bts.log below 20170203004140 . It is over at nitb: 20170203014245298 , bts: 20170203004254 . Hossein, is this what your logs look like? How long have you retried connecting? It is known that USRPs without a high quality external timing source are somewhat unreliable (but they still work mostly). Has anyone else seen this or knows what the reason could be? BTW, Hossein, this happened now completely by chance and was not related to your mailing me privately ;) ~N On Tue, Jan 31, 2017 at 01:36:08AM +0330, Hossein Amini wrote: > hi dear > I install openbsc, osmosgsn, ggsn, osmo-trx, osmo-bts-trx, osmo-pcu and > dependency from master branch step by step from this link. > > > but when run osmo-nitb, osmo-trx and osmo-bts-trx, mobile connect to > network but no access to network. > (I used USRP N210/B210, ubuntu 15.10/16.10 64x) > > osmo-nitb log: > > 20170130041914525 DRLL <0000> chan_alloc.c:352 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH > 20170130041914525 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) > Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x05 ta=0 > 20170130041914525 DRSL <0004> abis_rsl.c:580 > (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) > Tx RSL Channel Activate with act_type=INITIAL > 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state > NONE -> ACTIVATION REQUESTED > 20170130041914525 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) > CHANNEL ACTIVATE ACK > 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state > ACTIVATION REQUESTED -> ACTIVE > 20170130041924529 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF > Channel Release due to error: 1 > 20170130041924529 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) > DEACTivate SACCH CMD > 20170130041924529 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state > ACTIVE -> RELEASE DUE ERROR > 20170130041924530 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF > CHANNEL RELEASE ACK > 20170130041926530 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is > back in operation. > 20170130041926531 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state > RELEASE DUE ERROR -> NONE > [...] -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Fri Feb 3 02:37:47 2017 From: holger at freyther.de (Holger Freyther) Date: Fri, 3 Feb 2017 10:37:47 +0800 Subject: Downtime due FreeBSD upgrade. Message-ID: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> Hi, the machine hosting most of *.osmocom.org is running FreeBSD9.3 which EOLed end of december and I would like to upgrade to FreeBSD10.3. I do not expect many problems but I also don't want to interfere with other peoples work. Even if it is short notice, any objections for Saturday->Sunday night of a European timezone? Otherwise I would pick next Friday->Saturday. regards holger From nhofmeyr at sysmocom.de Fri Feb 3 14:40:51 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 3 Feb 2017 15:40:51 +0100 Subject: Downtime due FreeBSD upgrade. In-Reply-To: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> References: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> Message-ID: <20170203144051.GA1586@my.box> Anytime is fine with me. ~N On Fri, Feb 03, 2017 at 10:37:47AM +0800, Holger Freyther wrote: > Even if it is short notice, any objections for Saturday->Sunday night > of a European timezone? Otherwise I would pick next Friday->Saturday. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ikostov at sysmocom.de Fri Feb 3 16:00:03 2017 From: ikostov at sysmocom.de (Ivaylo Kostov) Date: Fri, 3 Feb 2017 17:00:03 +0100 Subject: weekly test report (w5 2017) Message-ID: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> Hi, Please find BTS test report, week5 2017. BTSes which has been tested with OsmoNITB are: - sysmoBTS1002 - octasic BTS3500 - ettus B200 - nanoBTS model:165G sysmoBTS1002 has been tested with the following 4 channel configurations: 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH 6 TCH/F_PDCH (ip.access style dynamic timeslots) All test cases passed. ---------------------------------------------------- octasic BTS3500 has been tested with the next 2 channel configurations: 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH All test cases passed. ----------------------------------------------------- ettus B200 has been tested with below channel configurations: 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH 6 TCH/F_PDCH (ip.access style dynamic timeslots) All test cases passed. ------------------------------------------------------ During a weekly test of nanoBTS model:165G, an issue has been discovered. It is reported in redmine: https://osmocom.org/issues/1933 Short description: It was found that the initiated voice call drops immediately after B subscriber accepts the call, when nanoBTS (model 165G) and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH. Default voice codec tch-h hr has been selected. Remaining test cases passed. regards, Ivaylo -- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ From laforge at gnumonks.org Fri Feb 3 19:14:25 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 3 Feb 2017 20:14:25 +0100 Subject: weekly test report (w5 2017) In-Reply-To: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> Message-ID: <20170203191425.iph3cinqrcvwy3lk@nataraja> Hi Ivaylo, thanks for your test report. On Fri, Feb 03, 2017 at 05:00:03PM +0100, Ivaylo Kostov wrote: > During a weekly test of nanoBTS model:165G, an issue has been discovered. It > is reported in redmine: https://osmocom.org/issues/1933 > > Short description: It was found that the initiated voice call drops > immediately after B subscriber accepts the call, when nanoBTS (model 165G) > and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH. Default > voice codec tch-h hr has been selected. Why is there again an attempt to use HR (v1) with the nanoBTS? It is a codec that this BTS hardware is known to never have supported. I am quite sure this has been discussed before. Was there some miscommunication / mis-definition of the test cases? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Fri Feb 3 20:42:45 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 3 Feb 2017 23:42:45 +0300 Subject: weekly test report (w5 2017) In-Reply-To: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> Message-ID: Hi Ivaylo, Please could you share the goal and scope of these tests? And is there a publicly available definition of the test cases? Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co On Feb 3, 2017 5:00 PM, "Ivaylo Kostov" wrote: > Hi, > > Please find BTS test report, week5 2017. > > BTSes which has been tested with OsmoNITB are: > > - sysmoBTS1002 > - octasic BTS3500 > - ettus B200 > - nanoBTS model:165G > > > sysmoBTS1002 has been tested with the following 4 channel configurations: > > 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) > 3 TCH/F, 3 PDCH > 3 TCH/H, 3 PDCH > 6 TCH/F_PDCH (ip.access style dynamic timeslots) > > All test cases passed. > > ---------------------------------------------------- > octasic BTS3500 has been tested with the next 2 channel configurations: > > 3 TCH/F, 3 PDCH > 3 TCH/H, 3 PDCH > > All test cases passed. > > ----------------------------------------------------- > > ettus B200 has been tested with below channel configurations: > > 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) > 3 TCH/F, 3 PDCH > 3 TCH/H, 3 PDCH > 6 TCH/F_PDCH (ip.access style dynamic timeslots) > > All test cases passed. > > ------------------------------------------------------ > > During a weekly test of nanoBTS model:165G, an issue has been discovered. > It is reported in redmine: https://osmocom.org/issues/1933 > > Short description: It was found that the initiated voice call drops > immediately after B subscriber accepts the call, when nanoBTS (model 165G) > and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH. Default > voice codec tch-h hr has been selected. > > Remaining test cases passed. > > regards, > Ivaylo > > -- > ------------------------------ > - Ivaylo Kostov > 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 Director: Harald Welte > ------------------------------ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Feb 5 00:52:51 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 5 Feb 2017 08:52:51 +0800 Subject: Downtime due FreeBSD upgrade. In-Reply-To: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> References: <4E2306F1-3FBD-4C30-94D6-2B085FFD374A@freyther.de> Message-ID: <20FF7514-838C-4CC0-B990-803787F38CB3@freyther.de> > On 3 Feb 2017, at 10:37, Holger Freyther wrote: > > Hi, Hi! > the machine hosting most of *.osmocom.org is running FreeBSD9.3 which > EOLed end of december and I would like to upgrade to FreeBSD10.3. I do > not expect many problems but I also don't want to interfere with other > peoples work. the base system has been upgraded, individual jails/containers are still based on 9.3 and will be handled one by one in the next days. If something seems to not work, please either create a ticket in our redmine and assign it to me or send an email to me. thank you holger From ikostov at sysmocom.de Mon Feb 6 09:09:23 2017 From: ikostov at sysmocom.de (Ivaylo Kostov) Date: Mon, 6 Feb 2017 10:09:23 +0100 Subject: weekly test report (w5 2017) In-Reply-To: <20170203191425.iph3cinqrcvwy3lk@nataraja> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> <20170203191425.iph3cinqrcvwy3lk@nataraja> Message-ID: <9fc45532-7baf-5569-06fa-a03292758c05@sysmocom.de> Hi Harald, I see. What was communicated to me was that NITB channel configuration TCH/F_TCH/H_PDCH is not supported with nanoBTS. I will have in mind that nanoBTS does not support HR (v1) codec. Thank you. Regards, Ivaylo On 03.02.2017 20:14, Harald Welte wrote: > Hi Ivaylo, > > thanks for your test report. > > On Fri, Feb 03, 2017 at 05:00:03PM +0100, Ivaylo Kostov wrote: > >> During a weekly test of nanoBTS model:165G, an issue has been discovered. It >> is reported in redmine: https://osmocom.org/issues/1933 >> >> Short description: It was found that the initiated voice call drops >> immediately after B subscriber accepts the call, when nanoBTS (model 165G) >> and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH. Default >> voice codec tch-h hr has been selected. > > Why is there again an attempt to use HR (v1) with the nanoBTS? It is a > codec that this BTS hardware is known to never have supported. I am > quite sure this has been discussed before. Was there some > miscommunication / mis-definition of the test cases? > > Regards, > Harald > -- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ From ikostov at sysmocom.de Mon Feb 6 10:19:07 2017 From: ikostov at sysmocom.de (Ivaylo Kostov) Date: Mon, 6 Feb 2017 11:19:07 +0100 Subject: weekly test report (w5 2017) In-Reply-To: References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> Message-ID: <259192ce-74be-e496-9aea-bd31e9f560fd@sysmocom.de> Hi Alexander, On 03.02.2017 21:42, Alexander Chemeris wrote: > Hi Ivaylo, > > Please could you share the goal and scope of these tests? And is there a > publicly available definition of the test cases? The main goal of these weekly tests is to verify whether our actual software works as intended. The basic (traffic) cases are given below. - Location Update - Voice call between two subscribers using supported voice codecs - Mobile originating / Mobile terminating SMS - Mobile terminating SMS during ongoing voice call - GPRS test: displaying web site and pinging MS from Core network - USSD request: *#100# Timeslots configurations are: 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH 6 TCH/F_PDCH (ip.access style dynamic timeslots) 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) I have sent the first week test report to OpenBSC mailing list. In case issue is found, then ticket will be open in osmocom.org redmine. We are in a process of tunning and finalizing of our weekly tests and related reports. Regards, Ivaylo > > Please excuse typos. Written with a touchscreen keyboard. > > -- > Regards, > Alexander Chemeris > CEO Fairwaves, Inc. > https://fairwaves.co > > On Feb 3, 2017 5:00 PM, "Ivaylo Kostov" > wrote: > > Hi, > > Please find BTS test report, week5 2017. > > BTSes which has been tested with OsmoNITB are: > > - sysmoBTS1002 > - octasic BTS3500 > - ettus B200 > - nanoBTS model:165G > > > sysmoBTS1002 has been tested with the following 4 channel > configurations: > > 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) > 3 TCH/F, 3 PDCH > 3 TCH/H, 3 PDCH > 6 TCH/F_PDCH (ip.access style dynamic timeslots) > > All test cases passed. > > ---------------------------------------------------- > octasic BTS3500 has been tested with the next 2 channel configurations: > > 3 TCH/F, 3 PDCH > 3 TCH/H, 3 PDCH > > All test cases passed. > > ----------------------------------------------------- > > ettus B200 has been tested with below channel configurations: > > 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) > 3 TCH/F, 3 PDCH > 3 TCH/H, 3 PDCH > 6 TCH/F_PDCH (ip.access style dynamic timeslots) > > All test cases passed. > > ------------------------------------------------------ > > During a weekly test of nanoBTS model:165G, an issue has been > discovered. It is reported in redmine: > https://osmocom.org/issues/1933 > > Short description: It was found that the initiated voice call drops > immediately after B subscriber accepts the call, when nanoBTS (model > 165G) and NITB is configured with dynamic channels: 3 TCH/H and 3 > PDCH. Default voice codec tch-h hr has been selected. > > Remaining test cases passed. > > regards, > Ivaylo > > -- > ------------------------------ > - Ivaylo Kostov > > > > 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 Director: Harald Welte > ------------------------------ > -- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ From nhofmeyr at sysmocom.de Mon Feb 6 12:05:53 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 6 Feb 2017 13:05:53 +0100 Subject: weekly test report (w5 2017) In-Reply-To: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> Message-ID: <20170206120553.GB10371@my.box> Thanks Ivaylo, A bit of feedback... On Fri, Feb 03, 2017 at 05:00:03PM +0100, Ivaylo Kostov wrote: > 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) > 3 TCH/F, 3 PDCH > 3 TCH/H, 3 PDCH > 6 TCH/F_PDCH (ip.access style dynamic timeslots) IMHO it would make sense to group dyn TS, i.e. 3 TCH/F, 3 PDCH 3 TCH/H, 3 PDCH 6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots) 6 TCH/F_PDCH (ip.access style dynamic timeslots) > All test cases passed. This reminds me, maybe we should have a list of "all test cases" on the Osmocom wiki? > immediately after B subscriber accepts the call, when nanoBTS (model 165G) > and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH. Default 3 TCH/H, 3 PDCH is not a dynamic channel configuration. In general I like the brevity and clarity of the report. Thanks! ~N -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From hosseinamini2578 at gmail.com Mon Feb 6 13:15:40 2017 From: hosseinamini2578 at gmail.com (Hossein Amini) Date: Mon, 6 Feb 2017 16:45:40 +0330 Subject: MS cannot connect; Location Update Request not received by BTS In-Reply-To: <20170202225831.GA1524@dub7> References: <20170202225831.GA1524@dub7> Message-ID: I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at netfilter.org Mon Feb 6 13:55:12 2017 From: laforge at netfilter.org (Harald Welte) Date: Mon, 6 Feb 2017 14:55:12 +0100 Subject: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev In-Reply-To: <20170130163713.17524-3-aschultz@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-3-aschultz@tpip.net> Message-ID: <20170206135512.sbxvkbe3hzgnwwjt@nataraja> Hi Andreas, On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote: > Both function are always used together with the final goal to > get the gtp_dev. This simplifies the code by merging them together. Ok, some code restructuring / unification, seems useful. However: > - netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n", > - pctx->u.v0.tid, pctx); > + pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n", > + pctx->u.v0.tid, pctx); (and other related changes) appear to be purely cosmetic and should thus be unrelated to the function merging described in the change log message. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie From laforge at netfilter.org Mon Feb 6 13:51:09 2017 From: laforge at netfilter.org (Harald Welte) Date: Mon, 6 Feb 2017 14:51:09 +0100 Subject: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional In-Reply-To: <20170130163713.17524-2-aschultz@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-2-aschultz@tpip.net> Message-ID: <20170206135109.sw5p2yb7cbsa3g37@nataraja> Hi Andreas, my kernel coding skills are getting a bit rusty (no pun intended), and I'll think others on this list are more capable to do so. But let me at least provide feedback from the "3GPP / GTP side": On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote: > Having both GTPv0-U and GTPv1-U is not always desirable. > Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP > Rel-8 onwards. Post Rel-8 implementation are discuraged > from listening on the v0 port (see 3GPP TS 29.281, Sect. 1). I confirm this and I think the related change should be applied. > A future change will completely decouple the sockets from the > network device. Till then, at least one of the sockets needs to > be specified (either v0 or v1), the other is optional. Makes sense. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie From laforge at gnumonks.org Mon Feb 6 13:58:59 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 6 Feb 2017 14:58:59 +0100 Subject: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper In-Reply-To: <20170130163713.17524-5-aschultz@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-5-aschultz@tpip.net> Message-ID: <20170206135859.mq6pidofidnps2q6@nataraja> Hi Andreas, On Mon, Jan 30, 2017 at 05:37:11PM +0100, Andreas Schultz wrote: > Consolidate duplicate code into helper. Makes complete sense. However: > +static void pdp_context_delete(struct pdp_ctx *pctx); > + why introduce the forward-declaration and then define the function further down in the file? I think in general, it is preferred to put helper functions on top, before their first use, so forward declarations can be avoided? Particularly if the helper function doesn't call any other functions that are not yet declared at this point. Please note the above might just be my personal taste, not sure if that's a general habit in the kernel networking code these days. So with or without the re-ordering: Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Feb 6 14:04:18 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 6 Feb 2017 15:04:18 +0100 Subject: [PATCH net-next v2 5/6] gtp: add socket to pdp context In-Reply-To: <2083605423.731432.1486048043458.JavaMail.zimbra@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-6-aschultz@tpip.net> <20170202135656.GA23901@salvia> <858150010.730228.1486044775198.JavaMail.zimbra@tpip.net> <20170202142842.GA19643@salvia> <249401941.730762.1486046287023.JavaMail.zimbra@tpip.net> <20170202144606.GA19992@salvia> <2083605423.731432.1486048043458.JavaMail.zimbra@tpip.net> Message-ID: <20170206140418.dwiofucns5eolgel@nataraja> Dear All, On Thu, Feb 02, 2017 at 04:07:23PM +0100, Andreas Schultz wrote: > ----- On Feb 2, 2017, at 3:46 PM, pablo pablo at netfilter.org wrote: > > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote: > >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote: > >> > I suggest you just call kfree_rcu() from 4/6. > >> > > >> > Regarding holding socket reference, see my comment for patch 1/6. > >> > >> This is going to be a problem at this stage of the changes. > >> > >> The final goal is to have a reference from the socket to the pdp context. > > > > Is this just a cleanup? Or you need this sk caching for some follow up > > work? > > It's not caching, the plan is to completely remove the socket from the > GTP netdevice (as far as that is possible without breaking the existing API). I agree this is the way to go. When I originally thought about the GTP kernel tunneling module early on, I was not aware of the fact that operators actually in practise run multiple "virtual GGSNs" on one IP address/port. From a pure technical point of view you would say "why bother"? They could just use separate IP addresses for each of them. However, the reailty is that each new IP address that an operator uses for a GGSN results in paper forms required to be exchanged between this operator and all his roming partners, followed-up by manual re-configuration of the policies on all of those roaming partners. This is time-consuming and error-prone, but hey, it's how the procedures between GSMA members seem to work ;) > A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's > can have overlapping IP address ranges. The only sensible way to handle > this, is to have a netdevice per APN. This breaks the current 1:1 relation > between sockets and netdevices. Indeed. So the question is how to do this best and how to keep backwards compatibility of the netlink interface. I don't claim to have answers to that, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Feb 6 13:56:13 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 6 Feb 2017 14:56:13 +0100 Subject: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup In-Reply-To: <20170130163713.17524-4-aschultz@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-4-aschultz@tpip.net> Message-ID: <20170206135613.x6ryxtrzktqx65n2@nataraja> On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote: > Signed-off-by: Andreas Schultz Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Feb 6 13:46:37 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 6 Feb 2017 14:46:37 +0100 Subject: [PATCH net-next v2 0/6] gtp: misc improvements In-Reply-To: <20170131.130543.246760553501896069.davem@davemloft.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170131.130543.246760553501896069.davem@davemloft.net> Message-ID: <20170206134637.bwiyfrtsmhycipxx@nataraja> Hi Dave and List, On Tue, Jan 31, 2017 at 01:05:43PM -0500, David Miller wrote: > Please someone with GTP knowledge properly review this series. I am happy to provide review, but I was travelling and my time to work on things outside my dayjob is typically quite limited. So I'd like to ask for a bit more patience for patch review from me. Thanks for your understanding. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Wed Feb 8 15:26:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 8 Feb 2017 16:26:11 +0100 Subject: weekly test report (w5 2017) In-Reply-To: <9fc45532-7baf-5569-06fa-a03292758c05@sysmocom.de> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> <20170203191425.iph3cinqrcvwy3lk@nataraja> <9fc45532-7baf-5569-06fa-a03292758c05@sysmocom.de> Message-ID: <20170208152611.GB1544@my.box> (found this mail stuck in my outbox, sending late) On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: > Hi Harald, > > I see. What was communicated to me was that NITB channel configuration > TCH/F_TCH/H_PDCH is not supported with nanoBTS. > > I will have in mind that nanoBTS does not support HR (v1) codec. Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised because from some discussion it appeared that the nanoBTS supports HR, and I was expecting TCH/F only. While talking about codecs, the ip.access nanoBTS *should* in fact support the TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of your testing procedure and add it if not? ~N -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ikostov at sysmocom.de Wed Feb 8 15:33:26 2017 From: ikostov at sysmocom.de (Ivaylo Kostov) Date: Wed, 8 Feb 2017 16:33:26 +0100 Subject: weekly test report (w5 2017) In-Reply-To: <20170208152611.GB1544@my.box> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> <20170203191425.iph3cinqrcvwy3lk@nataraja> <9fc45532-7baf-5569-06fa-a03292758c05@sysmocom.de> <20170208152611.GB1544@my.box> Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada@sysmocom.de> Hi Neels, Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure. regards, Ivaylo On 08.02.2017 16:26, Neels Hofmeyr wrote: > (found this mail stuck in my outbox, sending late) > > On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: >> Hi Harald, >> >> I see. What was communicated to me was that NITB channel configuration >> TCH/F_TCH/H_PDCH is not supported with nanoBTS. >> >> I will have in mind that nanoBTS does not support HR (v1) codec. > > Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised > because from some discussion it appeared that the nanoBTS supports HR, and I > was expecting TCH/F only. > > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? > > ~N > >-- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ From laforge at gnumonks.org Wed Feb 8 15:45:57 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 8 Feb 2017 16:45:57 +0100 Subject: weekly test report (w5 2017) In-Reply-To: <20170208152611.GB1544@my.box> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> <20170203191425.iph3cinqrcvwy3lk@nataraja> <9fc45532-7baf-5569-06fa-a03292758c05@sysmocom.de> <20170208152611.GB1544@my.box> Message-ID: <20170208154557.2rmslkrzuqlv7xc4@nataraja> Hi all, On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote: > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'. Similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR). In reality there are also older nanoBTSs that don't support AMR (as far as I remember), but that shouldn't prevent us from having at least the most basic checks in place. For osmo-bts, we need a more sophisticated hand-shaking mechanism, as there are many different hardware/PHYs (and associated versions) supported by it. This is left for further study ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Wed Feb 8 23:43:35 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 9 Feb 2017 00:43:35 +0100 Subject: weekly test report (w5 2017) In-Reply-To: <20170208154557.2rmslkrzuqlv7xc4@nataraja> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> <20170203191425.iph3cinqrcvwy3lk@nataraja> <9fc45532-7baf-5569-06fa-a03292758c05@sysmocom.de> <20170208152611.GB1544@my.box> <20170208154557.2rmslkrzuqlv7xc4@nataraja> Message-ID: <20170208234335.GB27422@my.box> On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote: > libbsc should be extended to handle those restrictions, i.e. reject a > configuration containing HR codec or a osmocom-style dynamic channel on > a bts model 'nanobts'. i.e. checks on the VTY level. Seems like we want an issue for that: https://osmocom.org/issues/1946 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From raji.oshin at hotmail.com Thu Feb 9 03:30:11 2017 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Thu, 9 Feb 2017 03:30:11 +0000 Subject: OpenBSC Digest, Vol 28, Issue 5 In-Reply-To: References: Message-ID: Hello all can anyone send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? .... thanks regards Rajitha Peiris Sri lanka ________________________________ From: OpenBSC on behalf of openbsc-request at lists.osmocom.org Sent: Wednesday, February 8, 2017 8:56:30 PM To: openbsc at lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 5 Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org You can reach the person managing the list at openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: MS cannot connect; Location Update Request not received by BTS (Hossein Amini) 2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev (Harald Welte) 3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional (Harald Welte) 4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper (Harald Welte) 5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context (Harald Welte) 6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup (Harald Welte) 7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte) 8. Re: weekly test report (w5 2017) (Neels Hofmeyr) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Feb 2017 16:45:40 +0330 From: Hossein Amini To: openbsc at lists.osmocom.org Subject: Re: MS cannot connect; Location Update Request not received by BTS Message-ID: Content-Type: text/plain; charset="utf-8" I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Mon, 6 Feb 2017 14:55:12 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev Message-ID: <20170206135512.sbxvkbe3hzgnwwjt at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote: > Both function are always used together with the final goal to > get the gtp_dev. This simplifies the code by merging them together. Ok, some code restructuring / unification, seems useful. However: > - netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n", > - pctx->u.v0.tid, pctx); > + pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n", > + pctx->u.v0.tid, pctx); (and other related changes) appear to be purely cosmetic and should thus be unrelated to the function merging described in the change log message. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie ------------------------------ Message: 3 Date: Mon, 6 Feb 2017 14:51:09 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional Message-ID: <20170206135109.sw5p2yb7cbsa3g37 at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, my kernel coding skills are getting a bit rusty (no pun intended), and I'll think others on this list are more capable to do so. But let me at least provide feedback from the "3GPP / GTP side": On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote: > Having both GTPv0-U and GTPv1-U is not always desirable. > Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP > Rel-8 onwards. Post Rel-8 implementation are discuraged > from listening on the v0 port (see 3GPP TS 29.281, Sect. 1). I confirm this and I think the related change should be applied. > A future change will completely decouple the sockets from the > network device. Till then, at least one of the sockets needs to > be specified (either v0 or v1), the other is optional. Makes sense. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie ------------------------------ Message: 4 Date: Mon, 6 Feb 2017 14:58:59 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper Message-ID: <20170206135859.mq6pidofidnps2q6 at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, On Mon, Jan 30, 2017 at 05:37:11PM +0100, Andreas Schultz wrote: > Consolidate duplicate code into helper. Makes complete sense. However: > +static void pdp_context_delete(struct pdp_ctx *pctx); > + why introduce the forward-declaration and then define the function further down in the file? I think in general, it is preferred to put helper functions on top, before their first use, so forward declarations can be avoided? Particularly if the helper function doesn't call any other functions that are not yet declared at this point. Please note the above might just be my personal taste, not sure if that's a general habit in the kernel networking code these days. So with or without the re-ordering: Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 5 Date: Mon, 6 Feb 2017 15:04:18 +0100 From: Harald Welte To: Andreas Schultz Cc: pablo , netdev , Lionel Gauthier , openbsc Subject: Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context Message-ID: <20170206140418.dwiofucns5eolgel at nataraja> Content-Type: text/plain; charset=us-ascii Dear All, On Thu, Feb 02, 2017 at 04:07:23PM +0100, Andreas Schultz wrote: > ----- On Feb 2, 2017, at 3:46 PM, pablo pablo at netfilter.org wrote: > > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote: > >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote: > >> > I suggest you just call kfree_rcu() from 4/6. > >> > > >> > Regarding holding socket reference, see my comment for patch 1/6. > >> > >> This is going to be a problem at this stage of the changes. > >> > >> The final goal is to have a reference from the socket to the pdp context. > > > > Is this just a cleanup? Or you need this sk caching for some follow up > > work? > > It's not caching, the plan is to completely remove the socket from the > GTP netdevice (as far as that is possible without breaking the existing API). I agree this is the way to go. When I originally thought about the GTP kernel tunneling module early on, I was not aware of the fact that operators actually in practise run multiple "virtual GGSNs" on one IP address/port. From a pure technical point of view you would say "why bother"? They could just use separate IP addresses for each of them. However, the reailty is that each new IP address that an operator uses for a GGSN results in paper forms required to be exchanged between this operator and all his roming partners, followed-up by manual re-configuration of the policies on all of those roaming partners. This is time-consuming and error-prone, but hey, it's how the procedures between GSMA members seem to work ;) > A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's > can have overlapping IP address ranges. The only sensible way to handle > this, is to have a netdevice per APN. This breaks the current 1:1 relation > between sockets and netdevices. Indeed. So the question is how to do this best and how to keep backwards compatibility of the netlink interface. I don't claim to have answers to that, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 6 Date: Mon, 6 Feb 2017 14:56:13 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup Message-ID: <20170206135613.x6ryxtrzktqx65n2 at nataraja> Content-Type: text/plain; charset=us-ascii On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote: > Signed-off-by: Andreas Schultz Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 7 Date: Mon, 6 Feb 2017 14:46:37 +0100 From: Harald Welte To: David Miller Cc: aschultz at tpip.net, pablo at netfilter.org, netdev at vger.kernel.org, Lionel.Gauthier at eurecom.fr, openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 0/6] gtp: misc improvements Message-ID: <20170206134637.bwiyfrtsmhycipxx at nataraja> Content-Type: text/plain; charset=us-ascii Hi Dave and List, On Tue, Jan 31, 2017 at 01:05:43PM -0500, David Miller wrote: > Please someone with GTP knowledge properly review this series. I am happy to provide review, but I was travelling and my time to work on things outside my dayjob is typically quite limited. So I'd like to ask for a bit more patience for patch review from me. Thanks for your understanding. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 8 Date: Wed, 8 Feb 2017 16:26:11 +0100 From: Neels Hofmeyr To: Ivaylo Kostov Cc: Harald Welte , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208152611.GB1544 at my.box> Content-Type: text/plain; charset="iso-8859-1" (found this mail stuck in my outbox, sending late) On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: > Hi Harald, > > I see. What was communicated to me was that NITB channel configuration > TCH/F_TCH/H_PDCH is not supported with nanoBTS. > > I will have in mind that nanoBTS does not support HR (v1) codec. Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised because from some discussion it appeared that the nanoBTS supports HR, and I was expecting TCH/F only. While talking about codecs, the ip.access nanoBTS *should* in fact support the TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of your testing procedure and add it if not? ~N -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 5 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From raji.oshin at hotmail.com Thu Feb 9 03:39:17 2017 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Thu, 9 Feb 2017 03:39:17 +0000 Subject: OpenBSC Digest, Vol 28, Issue 6 In-Reply-To: References: Message-ID: [cid:9b893015-fe6c-4d05-9933-7169f767fc97] ________________________________ From: OpenBSC on behalf of openbsc-request at lists.osmocom.org Sent: Thursday, February 9, 2017 9:00:47 AM To: openbsc at lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 6 Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org You can reach the person managing the list at openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: weekly test report (w5 2017) (Ivaylo Kostov) 2. Re: weekly test report (w5 2017) (Harald Welte) 3. Re: weekly test report (w5 2017) (Neels Hofmeyr) 4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Feb 2017 16:33:26 +0100 From: Ivaylo Kostov To: Neels Hofmeyr Cc: Harald Welte , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada at sysmocom.de> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Neels, Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure. regards, Ivaylo On 08.02.2017 16:26, Neels Hofmeyr wrote: > (found this mail stuck in my outbox, sending late) > > On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: >> Hi Harald, >> >> I see. What was communicated to me was that NITB channel configuration >> TCH/F_TCH/H_PDCH is not supported with nanoBTS. >> >> I will have in mind that nanoBTS does not support HR (v1) codec. > > Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised > because from some discussion it appeared that the nanoBTS supports HR, and I > was expecting TCH/F only. > > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? > > ~N > >-- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ ------------------------------ Message: 2 Date: Wed, 8 Feb 2017 16:45:57 +0100 From: Harald Welte To: Neels Hofmeyr Cc: Ivaylo Kostov , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208154557.2rmslkrzuqlv7xc4 at nataraja> Content-Type: text/plain; charset=us-ascii Hi all, On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote: > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'. Similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR). In reality there are also older nanoBTSs that don't support AMR (as far as I remember), but that shouldn't prevent us from having at least the most basic checks in place. For osmo-bts, we need a more sophisticated hand-shaking mechanism, as there are many different hardware/PHYs (and associated versions) supported by it. This is left for further study ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Thu, 9 Feb 2017 00:43:35 +0100 From: Neels Hofmeyr To: Harald Welte Cc: Ivaylo Kostov , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208234335.GB27422 at my.box> Content-Type: text/plain; charset="us-ascii" On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote: > libbsc should be extended to handle those restrictions, i.e. reject a > configuration containing HR codec or a osmocom-style dynamic channel on > a bts model 'nanobts'. i.e. checks on the VTY level. Seems like we want an issue for that: https://osmocom.org/issues/1946 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Message: 4 Date: Thu, 9 Feb 2017 03:30:11 +0000 From: Rajitha peiris To: "openbsc at lists.osmocom.org" Subject: Re: OpenBSC Digest, Vol 28, Issue 5 Message-ID: Content-Type: text/plain; charset="us-ascii" Hello all can anyone send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? .... thanks regards Rajitha Peiris Sri lanka ________________________________ From: OpenBSC on behalf of openbsc-request at lists.osmocom.org Sent: Wednesday, February 8, 2017 8:56:30 PM To: openbsc at lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 5 Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org You can reach the person managing the list at openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: MS cannot connect; Location Update Request not received by BTS (Hossein Amini) 2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev (Harald Welte) 3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional (Harald Welte) 4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper (Harald Welte) 5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context (Harald Welte) 6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup (Harald Welte) 7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte) 8. Re: weekly test report (w5 2017) (Neels Hofmeyr) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Feb 2017 16:45:40 +0330 From: Hossein Amini To: openbsc at lists.osmocom.org Subject: Re: MS cannot connect; Location Update Request not received by BTS Message-ID: Content-Type: text/plain; charset="utf-8" I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Mon, 6 Feb 2017 14:55:12 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev Message-ID: <20170206135512.sbxvkbe3hzgnwwjt at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote: > Both function are always used together with the final goal to > get the gtp_dev. This simplifies the code by merging them together. Ok, some code restructuring / unification, seems useful. However: > - netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n", > - pctx->u.v0.tid, pctx); > + pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n", > + pctx->u.v0.tid, pctx); (and other related changes) appear to be purely cosmetic and should thus be unrelated to the function merging described in the change log message. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie ------------------------------ Message: 3 Date: Mon, 6 Feb 2017 14:51:09 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional Message-ID: <20170206135109.sw5p2yb7cbsa3g37 at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, my kernel coding skills are getting a bit rusty (no pun intended), and I'll think others on this list are more capable to do so. But let me at least provide feedback from the "3GPP / GTP side": On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote: > Having both GTPv0-U and GTPv1-U is not always desirable. > Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP > Rel-8 onwards. Post Rel-8 implementation are discuraged > from listening on the v0 port (see 3GPP TS 29.281, Sect. 1). I confirm this and I think the related change should be applied. > A future change will completely decouple the sockets from the > network device. Till then, at least one of the sockets needs to > be specified (either v0 or v1), the other is optional. Makes sense. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie ------------------------------ Message: 4 Date: Mon, 6 Feb 2017 14:58:59 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper Message-ID: <20170206135859.mq6pidofidnps2q6 at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, On Mon, Jan 30, 2017 at 05:37:11PM +0100, Andreas Schultz wrote: > Consolidate duplicate code into helper. Makes complete sense. However: > +static void pdp_context_delete(struct pdp_ctx *pctx); > + why introduce the forward-declaration and then define the function further down in the file? I think in general, it is preferred to put helper functions on top, before their first use, so forward declarations can be avoided? Particularly if the helper function doesn't call any other functions that are not yet declared at this point. Please note the above might just be my personal taste, not sure if that's a general habit in the kernel networking code these days. So with or without the re-ordering: Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 5 Date: Mon, 6 Feb 2017 15:04:18 +0100 From: Harald Welte To: Andreas Schultz Cc: pablo , netdev , Lionel Gauthier , openbsc Subject: Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context Message-ID: <20170206140418.dwiofucns5eolgel at nataraja> Content-Type: text/plain; charset=us-ascii Dear All, On Thu, Feb 02, 2017 at 04:07:23PM +0100, Andreas Schultz wrote: > ----- On Feb 2, 2017, at 3:46 PM, pablo pablo at netfilter.org wrote: > > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote: > >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote: > >> > I suggest you just call kfree_rcu() from 4/6. > >> > > >> > Regarding holding socket reference, see my comment for patch 1/6. > >> > >> This is going to be a problem at this stage of the changes. > >> > >> The final goal is to have a reference from the socket to the pdp context. > > > > Is this just a cleanup? Or you need this sk caching for some follow up > > work? > > It's not caching, the plan is to completely remove the socket from the > GTP netdevice (as far as that is possible without breaking the existing API). I agree this is the way to go. When I originally thought about the GTP kernel tunneling module early on, I was not aware of the fact that operators actually in practise run multiple "virtual GGSNs" on one IP address/port. From a pure technical point of view you would say "why bother"? They could just use separate IP addresses for each of them. However, the reailty is that each new IP address that an operator uses for a GGSN results in paper forms required to be exchanged between this operator and all his roming partners, followed-up by manual re-configuration of the policies on all of those roaming partners. This is time-consuming and error-prone, but hey, it's how the procedures between GSMA members seem to work ;) > A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's > can have overlapping IP address ranges. The only sensible way to handle > this, is to have a netdevice per APN. This breaks the current 1:1 relation > between sockets and netdevices. Indeed. So the question is how to do this best and how to keep backwards compatibility of the netlink interface. I don't claim to have answers to that, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 6 Date: Mon, 6 Feb 2017 14:56:13 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup Message-ID: <20170206135613.x6ryxtrzktqx65n2 at nataraja> Content-Type: text/plain; charset=us-ascii On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote: > Signed-off-by: Andreas Schultz Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 7 Date: Mon, 6 Feb 2017 14:46:37 +0100 From: Harald Welte To: David Miller Cc: aschultz at tpip.net, pablo at netfilter.org, netdev at vger.kernel.org, Lionel.Gauthier at eurecom.fr, openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 0/6] gtp: misc improvements Message-ID: <20170206134637.bwiyfrtsmhycipxx at nataraja> Content-Type: text/plain; charset=us-ascii Hi Dave and List, On Tue, Jan 31, 2017 at 01:05:43PM -0500, David Miller wrote: > Please someone with GTP knowledge properly review this series. I am happy to provide review, but I was travelling and my time to work on things outside my dayjob is typically quite limited. So I'd like to ask for a bit more patience for patch review from me. Thanks for your understanding. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 8 Date: Wed, 8 Feb 2017 16:26:11 +0100 From: Neels Hofmeyr To: Ivaylo Kostov Cc: Harald Welte , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208152611.GB1544 at my.box> Content-Type: text/plain; charset="iso-8859-1" (found this mail stuck in my outbox, sending late) On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: > Hi Harald, > > I see. What was communicated to me was that NITB channel configuration > TCH/F_TCH/H_PDCH is not supported with nanoBTS. > > I will have in mind that nanoBTS does not support HR (v1) codec. Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised because from some discussion it appeared that the nanoBTS supports HR, and I was expecting TCH/F only. While talking about codecs, the ip.access nanoBTS *should* in fact support the TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of your testing procedure and add it if not? ~N -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 5 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 6 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-02-09 09-08-05.png Type: image/png Size: 135124 bytes Desc: Screenshot from 2017-02-09 09-08-05.png URL: From raji.oshin at hotmail.com Thu Feb 9 03:40:31 2017 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Thu, 9 Feb 2017 03:40:31 +0000 Subject: OpenBSC Digest, Vol 28, Issue 6 In-Reply-To: References: , Message-ID: here i have attached my openbsc.cfg file ________________________________ From: Rajitha peiris Sent: Thursday, February 9, 2017 9:09:17 AM To: openbsc at lists.osmocom.org Subject: Re: OpenBSC Digest, Vol 28, Issue 6 [cid:9b893015-fe6c-4d05-9933-7169f767fc97] ________________________________ From: OpenBSC on behalf of openbsc-request at lists.osmocom.org Sent: Thursday, February 9, 2017 9:00:47 AM To: openbsc at lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 6 Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org You can reach the person managing the list at openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: weekly test report (w5 2017) (Ivaylo Kostov) 2. Re: weekly test report (w5 2017) (Harald Welte) 3. Re: weekly test report (w5 2017) (Neels Hofmeyr) 4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Feb 2017 16:33:26 +0100 From: Ivaylo Kostov To: Neels Hofmeyr Cc: Harald Welte , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada at sysmocom.de> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Neels, Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure. regards, Ivaylo On 08.02.2017 16:26, Neels Hofmeyr wrote: > (found this mail stuck in my outbox, sending late) > > On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: >> Hi Harald, >> >> I see. What was communicated to me was that NITB channel configuration >> TCH/F_TCH/H_PDCH is not supported with nanoBTS. >> >> I will have in mind that nanoBTS does not support HR (v1) codec. > > Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised > because from some discussion it appeared that the nanoBTS supports HR, and I > was expecting TCH/F only. > > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? > > ~N > >-- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ ------------------------------ Message: 2 Date: Wed, 8 Feb 2017 16:45:57 +0100 From: Harald Welte To: Neels Hofmeyr Cc: Ivaylo Kostov , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208154557.2rmslkrzuqlv7xc4 at nataraja> Content-Type: text/plain; charset=us-ascii Hi all, On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote: > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'. Similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR). In reality there are also older nanoBTSs that don't support AMR (as far as I remember), but that shouldn't prevent us from having at least the most basic checks in place. For osmo-bts, we need a more sophisticated hand-shaking mechanism, as there are many different hardware/PHYs (and associated versions) supported by it. This is left for further study ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Thu, 9 Feb 2017 00:43:35 +0100 From: Neels Hofmeyr To: Harald Welte Cc: Ivaylo Kostov , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208234335.GB27422 at my.box> Content-Type: text/plain; charset="us-ascii" On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote: > libbsc should be extended to handle those restrictions, i.e. reject a > configuration containing HR codec or a osmocom-style dynamic channel on > a bts model 'nanobts'. i.e. checks on the VTY level. Seems like we want an issue for that: https://osmocom.org/issues/1946 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Message: 4 Date: Thu, 9 Feb 2017 03:30:11 +0000 From: Rajitha peiris To: "openbsc at lists.osmocom.org" Subject: Re: OpenBSC Digest, Vol 28, Issue 5 Message-ID: Content-Type: text/plain; charset="us-ascii" Hello all can anyone send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? .... thanks regards Rajitha Peiris Sri lanka ________________________________ From: OpenBSC on behalf of openbsc-request at lists.osmocom.org Sent: Wednesday, February 8, 2017 8:56:30 PM To: openbsc at lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 5 Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org You can reach the person managing the list at openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: MS cannot connect; Location Update Request not received by BTS (Hossein Amini) 2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev (Harald Welte) 3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional (Harald Welte) 4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper (Harald Welte) 5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context (Harald Welte) 6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup (Harald Welte) 7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte) 8. Re: weekly test report (w5 2017) (Neels Hofmeyr) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Feb 2017 16:45:40 +0330 From: Hossein Amini To: openbsc at lists.osmocom.org Subject: Re: MS cannot connect; Location Update Request not received by BTS Message-ID: Content-Type: text/plain; charset="utf-8" I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Mon, 6 Feb 2017 14:55:12 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev Message-ID: <20170206135512.sbxvkbe3hzgnwwjt at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote: > Both function are always used together with the final goal to > get the gtp_dev. This simplifies the code by merging them together. Ok, some code restructuring / unification, seems useful. However: > - netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n", > - pctx->u.v0.tid, pctx); > + pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n", > + pctx->u.v0.tid, pctx); (and other related changes) appear to be purely cosmetic and should thus be unrelated to the function merging described in the change log message. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie ------------------------------ Message: 3 Date: Mon, 6 Feb 2017 14:51:09 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional Message-ID: <20170206135109.sw5p2yb7cbsa3g37 at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, my kernel coding skills are getting a bit rusty (no pun intended), and I'll think others on this list are more capable to do so. But let me at least provide feedback from the "3GPP / GTP side": On Mon, Jan 30, 2017 at 05:37:08PM +0100, Andreas Schultz wrote: > Having both GTPv0-U and GTPv1-U is not always desirable. > Fallback from GTPv1-U to GTPv0-U was depreciated from 3GPP > Rel-8 onwards. Post Rel-8 implementation are discuraged > from listening on the v0 port (see 3GPP TS 29.281, Sect. 1). I confirm this and I think the related change should be applied. > A future change will completely decouple the sockets from the > network device. Till then, at least one of the sockets needs to > be specified (either v0 or v1), the other is optional. Makes sense. -- - Harald Welte http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie ------------------------------ Message: 4 Date: Mon, 6 Feb 2017 14:58:59 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper Message-ID: <20170206135859.mq6pidofidnps2q6 at nataraja> Content-Type: text/plain; charset=us-ascii Hi Andreas, On Mon, Jan 30, 2017 at 05:37:11PM +0100, Andreas Schultz wrote: > Consolidate duplicate code into helper. Makes complete sense. However: > +static void pdp_context_delete(struct pdp_ctx *pctx); > + why introduce the forward-declaration and then define the function further down in the file? I think in general, it is preferred to put helper functions on top, before their first use, so forward declarations can be avoided? Particularly if the helper function doesn't call any other functions that are not yet declared at this point. Please note the above might just be my personal taste, not sure if that's a general habit in the kernel networking code these days. So with or without the re-ordering: Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 5 Date: Mon, 6 Feb 2017 15:04:18 +0100 From: Harald Welte To: Andreas Schultz Cc: pablo , netdev , Lionel Gauthier , openbsc Subject: Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context Message-ID: <20170206140418.dwiofucns5eolgel at nataraja> Content-Type: text/plain; charset=us-ascii Dear All, On Thu, Feb 02, 2017 at 04:07:23PM +0100, Andreas Schultz wrote: > ----- On Feb 2, 2017, at 3:46 PM, pablo pablo at netfilter.org wrote: > > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote: > >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo at netfilter.org wrote: > >> > I suggest you just call kfree_rcu() from 4/6. > >> > > >> > Regarding holding socket reference, see my comment for patch 1/6. > >> > >> This is going to be a problem at this stage of the changes. > >> > >> The final goal is to have a reference from the socket to the pdp context. > > > > Is this just a cleanup? Or you need this sk caching for some follow up > > work? > > It's not caching, the plan is to completely remove the socket from the > GTP netdevice (as far as that is possible without breaking the existing API). I agree this is the way to go. When I originally thought about the GTP kernel tunneling module early on, I was not aware of the fact that operators actually in practise run multiple "virtual GGSNs" on one IP address/port. From a pure technical point of view you would say "why bother"? They could just use separate IP addresses for each of them. However, the reailty is that each new IP address that an operator uses for a GGSN results in paper forms required to be exchanged between this operator and all his roming partners, followed-up by manual re-configuration of the policies on all of those roaming partners. This is time-consuming and error-prone, but hey, it's how the procedures between GSMA members seem to work ;) > A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's > can have overlapping IP address ranges. The only sensible way to handle > this, is to have a netdevice per APN. This breaks the current 1:1 relation > between sockets and netdevices. Indeed. So the question is how to do this best and how to keep backwards compatibility of the netlink interface. I don't claim to have answers to that, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 6 Date: Mon, 6 Feb 2017 14:56:13 +0100 From: Harald Welte To: Andreas Schultz Cc: Pablo Neira , netdev at vger.kernel.org, Lionel Gauthier , openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup Message-ID: <20170206135613.x6ryxtrzktqx65n2 at nataraja> Content-Type: text/plain; charset=us-ascii On Mon, Jan 30, 2017 at 05:37:10PM +0100, Andreas Schultz wrote: > Signed-off-by: Andreas Schultz Acked-by: Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 7 Date: Mon, 6 Feb 2017 14:46:37 +0100 From: Harald Welte To: David Miller Cc: aschultz at tpip.net, pablo at netfilter.org, netdev at vger.kernel.org, Lionel.Gauthier at eurecom.fr, openbsc at lists.osmocom.org Subject: Re: [PATCH net-next v2 0/6] gtp: misc improvements Message-ID: <20170206134637.bwiyfrtsmhycipxx at nataraja> Content-Type: text/plain; charset=us-ascii Hi Dave and List, On Tue, Jan 31, 2017 at 01:05:43PM -0500, David Miller wrote: > Please someone with GTP knowledge properly review this series. I am happy to provide review, but I was travelling and my time to work on things outside my dayjob is typically quite limited. So I'd like to ask for a bit more patience for patch review from me. Thanks for your understanding. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 8 Date: Wed, 8 Feb 2017 16:26:11 +0100 From: Neels Hofmeyr To: Ivaylo Kostov Cc: Harald Welte , openbsc at lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208152611.GB1544 at my.box> Content-Type: text/plain; charset="iso-8859-1" (found this mail stuck in my outbox, sending late) On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: > Hi Harald, > > I see. What was communicated to me was that NITB channel configuration > TCH/F_TCH/H_PDCH is not supported with nanoBTS. > > I will have in mind that nanoBTS does not support HR (v1) codec. Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised because from some discussion it appeared that the nanoBTS supports HR, and I was expecting TCH/F only. While talking about codecs, the ip.access nanoBTS *should* in fact support the TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of your testing procedure and add it if not? ~N -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 5 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 6 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-02-09 09-08-05.png Type: image/png Size: 135124 bytes Desc: Screenshot from 2017-02-09 09-08-05.png URL: From nhofmeyr at sysmocom.de Thu Feb 9 12:27:06 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 9 Feb 2017 13:27:06 +0100 Subject: OpenBSC Digest, Vol 28, Issue 5 In-Reply-To: References: Message-ID: <20170209122706.GA28816@my.box> Dear Rajitha, please do not ever send digests of this mailing list back to the mailing list. If you wish to ask a question you are welcome, but please don't just hit reply and include a load of unrelated messages in your question! I hope someone else will address your question, since I'm not quite familiar with nanobts. My guess is you don't need LCR and maybe check that it's 'type nanobts' and try voice codecs... There are example configs in openbsc.git. ~N On Thu, Feb 09, 2017 at 03:30:11AM +0000, Rajitha peiris wrote: > Hello all > > can anyone send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? .... > > > thanks > > regards > > Rajitha Peiris > > Sri lanka > [snipped 423 lines of unrelated discussions] -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Feb 9 13:53:21 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 9 Feb 2017 14:53:21 +0100 Subject: vlr+hlr: Insert Data Message-ID: <20170209135321.GB28816@my.box> What should we do if the HLR sends no Insert Data? When a subscriber does a Location Updating, the VLR sends a Location Updating request to the HLR. The HLR typically responds with a Location Updating Result as success and, in a *separate* message, sends an Insert Data to the VLR to tell it the subscriber's MSISDN. So it is possible to do a successful Location Updating without being told the MSISDN (as my test verifies). What should the VLR do if it never receives the Insert Data from the HLR? In that case the subscriber is attached but cannot be reached by MSISDN. Should we actively wait for Inser Data and reject the subscriber if not successful? It would be fairly easy to just send the MSISDN along in the Location Updating Result. Why this separate message? Thx, ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Feb 9 14:11:27 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 9 Feb 2017 15:11:27 +0100 Subject: accelerate3g5 ML? Message-ID: <20170209141127.GC28816@my.box> Will there be a separate mailing list for the accelerate3g5 "winners"? Maybe we could just make it a general osmocom-3G@ mailing list. Alternatively, we could use this list for 3G as well. What's the plan? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ikostov at sysmocom.de Thu Feb 9 17:25:51 2017 From: ikostov at sysmocom.de (Ivaylo Kostov) Date: Thu, 9 Feb 2017 18:25:51 +0100 Subject: Error while building osmo-bts for sysmoBTS Message-ID: Hi, I was following the procedure "Compiling osmo-bts for sysmoBTS" and using poky/1.5.4/sysroots/armv5te-poky-linux-gnueabi During execution of libosmocore project it failed with: ... GEN gsm0503_conv.c Traceback (most recent call last): File "../../utils/conv_gen.py", line 26, in import sys, os, math, argparse ImportError: CC oap.lo No module named argparse Makefile:735: recipe for target 'gsm0503_conv.c' failed make[2]: *** [gsm0503_conv.c] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/home/ivaylo/net/osmo/libosmocore/src/gsm' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/ivaylo/net/osmo/libosmocore' Makefile:327: recipe for target 'all' failed make: *** [all] Error 2 ... I am using: Python 2.7.12+ (default, Sep 17 2016, 12:08:02) [GCC 6.2.0 20160914] on linux2 Type "help", "copyright", "credits" or "license" for more information. I think that something is broken. regards, Ivaylo -- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ From msuraev at sysmocom.de Thu Feb 9 17:36:37 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 9 Feb 2017 18:36:37 +0100 Subject: Error while building osmo-bts for sysmoBTS In-Reply-To: References: Message-ID: <85c84f39-e63d-225a-38af-9bda35af3db9@sysmocom.de> This seems to be caused by recent 2c717948d91540016067f87bb3e0913067d42647 although it shouldn't have: argparse is part of python2.7 (not sure about minor version though) and our poky toolchain 1.5.4 uses Python 2.7.3 Could it be that python is somehow misconfigured in the toolchain? Shall we add argparse to sysroots/i686-pokysdk-linux/usr/lib/python2.7 manually or try to update toolchain to newer version? Max. From msuraev at sysmocom.de Thu Feb 9 18:09:03 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 9 Feb 2017 19:09:03 +0100 Subject: osmo-bts-trx error with tch/h Message-ID: <22290c88-cf00-9c89-9ac7-82448e17f161@sysmocom.de> Hi. There seems to be peculiar coding error with osmo-bts-trx and usrp b210: ... <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550946 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550950 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550955 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550959 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] ... The error seems to: - happen only on 2nd subslot of TCH/H - does not prevent calls establishement - let voice to go through The visible effect though is extra delay for call establishment when BSC allocates next available subslot - see https://projects.osmocom.org/issues/1795 for details. Have anyone else seen this? It could be that tch_hr_decode() screw up bits somehow while trying to decode stolen FACCH bits but the code seems rather arcane. For instance, when calling unmap (it actually just attempts to get hu(B) and hl(B) flags from 3GPP TS 45.003 ?4.3.5 located in bits 58 and 57 correspondingly) potentially stolen bits in the beginning of function, why bursts 0..3 are treated as even and 2..4 as odd? -- Max Suraev 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 Director: Harald Welte From laforge at gnumonks.org Thu Feb 9 20:16:45 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 9 Feb 2017 21:16:45 +0100 Subject: Problems with nanoBTS 1900 In-Reply-To: References: Message-ID: <20170209201645.dbyoqhqdelc36uof@nataraja> Dear Rajitha, On Thu, Feb 09, 2017 at 03:40:31AM +0000, Rajitha peiris wrote: > here i have attached my openbsc.cfg file no, you have not attached the config file. What you have attached is a (partial) screenshot of your config file. Please actually attach the config file, thanks. Also, it is customary to collect all relevant information in one mail before sending message to this list. Otherwise you will have literally hundreds of people reading your mail. Some might be interested in helping out, but then they cannot due to lack of information. Getting back to your actual question: It is many years since I last used aa nanoBTS (and never one for 1900 MHz), but irrespective of that you definitely do not need lcr or mISDN for simple voice call connectivity. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Feb 9 20:18:03 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 9 Feb 2017 21:18:03 +0100 Subject: accelerate3g5 ML? In-Reply-To: <20170209141127.GC28816@my.box> References: <20170209141127.GC28816@my.box> Message-ID: <20170209201803.ppi22k42nxx744bp@nataraja> Hi Neels, On Thu, Feb 09, 2017 at 03:11:27PM +0100, Neels Hofmeyr wrote: > Will there be a separate mailing list for the accelerate3g5 "winners"? Maybe we > could just make it a general osmocom-3G@ mailing list. Alternatively, we could > use this list for 3G as well. What's the plan? I would simply add related discussion to this mailing list. We already have quite a number of almost unused lists, and the traffic here is quite low. Plus, some discussion about people getting osmo-iuh & co to work might help spark interest in some of the other lurkers here ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Feb 9 22:49:11 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 9 Feb 2017 23:49:11 +0100 Subject: Heads-Up on ongoing libosmo-sccp SIGTRAN work Message-ID: <20170209224911.h6g6acyqqfmaxxig@nataraja> Dear all, so far libosmo-sccp had some code with a partial SCCP implementation that date back to the earliest day of OsmoBSC in 2009, done by Holger. It also contained a SUA implementation which (mostly) I did last year in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support. The latter code is already more 'modern' and uses the osmocom primitives (osmo_prim) between the SCCP User (the application) and the SCCP Provider (the library). Those primitives are modelled after the related specifications. What I'm now wokring on is to get those last SUA related patches finally merged in master, and to * add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in a generic way that they can be shared by all SIGTRAN xUA variants * add M3UA while sharing more code between SUA and M3UA * introduce a MTP SAP based on osmo_prim that can be used on top of M3UA * wrap the existing sccp.c code to use the MTP SAP on the lower end and the SCCP User SAP on the upper edge In the above implementations, I am aiming for implementing SGW, ASP and IPSP roles. However, primary focus is on ASP. In the end, we will be able to stack M3UA and SCCP code using primitives, and interact with the SCCP using the exact same primitives and API as we interact with SUA currently. This will give us: * true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin of their code * a way towards 3GPP compliant AoIP, by using the SCCP User SAP from OsmoBSC. This means that we'll also have to add that SCCP User SAP to the SCCPlite/IPA code that OsmoBSC is using for now. While all of the above sounds great, it somehow hurts me that we have already some (partial?) implementations of M3UA in cellmgr-ng (particularly the osmo-stp application). It hurts me that I'm not able to use the code that Holger wrote in recent years, but I still think it's worth-while to do an implementation centered around osmo_prim for layer-boundaries and osmo_fsm for state machines. So my apologies to Holger on this. It's not "Not Invented Here" syndrome, but I think there are reasons to take a different route than the existing code. I'm of course also looking forward to hearing other opinions on that. [... and while I'm working on this, I also think about introducing some generic inter-layer primitive logging code, so we can enable logging of the primitives at a given SAP without the specific SAP implementation having to implement anything, like we do in terms of osmo_fsm logging] Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Fri Feb 10 05:35:44 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 10 Feb 2017 12:35:44 +0700 Subject: osmo-bts-trx error with tch/h Message-ID: Hi Max and others, It seems, I faced similar problem while working on the libosmocoding. Despite the bursts_test in OsmoBTS always pass without any errors, when I merely moved some parts of GSM 05.03 code into a separate library, this test sometimes passes and fails on different machines... Thanks to tnt, who suggested me to use valgrind. Using this great tool and some tricks with memset(), I found, that the gsm0503_tch_burst_map() uses one uninitialized bit from the iB within the tch_hr_encode(). The same things happens in the tch_hr_decode(). I don't know, is it gsm0503_tch_hr_(de)interleave's bug or gsm0503_tch_burst_(un)map's one, we need to check GSM 05.03 specifications. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Fri Feb 10 09:18:24 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 10 Feb 2017 10:18:24 +0100 Subject: osmo-bts-trx error with tch/h In-Reply-To: References: Message-ID: <458355d4-aa96-550c-d61a-006f980a1be8@sysmocom.de> Neat, could you please share some more details? Like valgrind logs, code references etc. Is this also covered in gerrit review for some of your patches like 933 or 1628? On 10.02.2017 06:35, Vadim Yanitskiy wrote: > > Thanks to tnt, who suggested me to use valgrind. Using this great tool > and some tricks with memset(), I found, that the gsm0503_tch_burst_map() > uses one uninitialized bit from the iB within the tch_hr_encode(). The > same > things happens in the tch_hr_decode(). -- Max Suraev 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 Director: Harald Welte From axilirator at gmail.com Fri Feb 10 11:00:03 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 10 Feb 2017 18:00:03 +0700 Subject: osmo-bts-trx error with tch/h Message-ID: > Is this also covered in gerrit review for some of your patches like 933 > or 1628? Yeah, it's covered by https://gerrit.osmocom.org/#/c/933/ , and this is exactly the reason, why the change isn't ready to merge yet :( Well, some more details: # valgrind --track-origins=yes tests/coding/.libs/lt-coding_test ==27652== Memcheck, a memory error detector ==27652== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==27652== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==27652== Command: tests/coding/.libs/lt-coding_test ==27652== xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02 tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x400F49: ubits2sbits (coding_test.c:48) ==27652== by 0x401416: test_hr (coding_test.c:290) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x400F4E: ubits2sbits (coding_test.c:54) ==27652== by 0x401416: test_hr (coding_test.c:290) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422CCE: osmo_conv_decode_scan (conv.c:394) ==27652== by 0x54231E8: osmo_conv_decode (conv.c:616) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422D08: osmo_conv_decode_scan (conv.c:403) ==27652== by 0x54231E8: osmo_conv_decode (conv.c:616) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422F91: osmo_conv_decode_flush (conv.c:509) ==27652== by 0x5423235: osmo_conv_decode (conv.c:619) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x4E3D72C: osmo_conv_decode_ber (gsm0503_coding.c:480) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== tch_hr_decode: n_errors=11 n_bits_total=211 ber=0.05 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00 pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22 pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33 pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00 pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00 pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22 pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33 pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00 Success ==27652== ==27652== HEAP SUMMARY: ==27652== in use at exit: 0 bytes in 0 blocks ==27652== total heap usage: 2,367 allocs, 2,367 frees, 397,488 bytes allocated ==27652== ==27652== All heap blocks were freed -- no leaks are possible ==27652== ==27652== For counts of detected and suppressed errors, rerun with: -v ==27652== ERROR SUMMARY: 7041 errors from 6 contexts (suppressed: 0 from 0) I paid my attention on the "Uninitialised value was created by a stack allocation" warning, and merely used memset() to fill some arrays by 0x00 in the gsm0503_tch_hr_decode(). And... it was the first time when I got successful build on Jenkins! This is the temporary solution: sbit_t iB[912], cB[456], h; ubit_t conv[98], b[112], d[112], p[3]; int i, rv, steal = 0; /** * Fix valgrind warnings: * "Uninitialised value was created by a stack allocation" * "Conditional jump or move depends on uninitialised value(s)" */ memset(iB, 0x00, sizeof(iB)); Then I started to dig deeper into the code, and used memset() one more time: http://pastebin.com/jBJT3q6R This dirty printf based debug led me closer to the problem. We are getting different results (successes and fails) because the gsm0503_tch_burst_map() refers to uninitialized value at iB[353]. Now we need to find out, where is the bug. There are two assumptions: 1) The gsm0503_tch_hr_interleave() doesn't initialize the iB[353]; 2) The gsm0503_tch_burst_map() refers to the value which it shouldn't refer to. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Fri Feb 10 12:19:15 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 10 Feb 2017 13:19:15 +0100 Subject: Error while building osmo-bts for sysmoBTS In-Reply-To: References: Message-ID: <20170210121915.GD28816@my.box> I can reproduce this. Just pulled the newest libosmocore and SDK https://downloads.sysmocom.de/generic/sysmobts/201310-nightly/sdk/poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.4-20170210020032.sh and got the same error. Ivaylo, for now you could locally revert this revision to be able to continue: cd libosmocore git revert 2c717948d91540016067f87bb3e0913067d42647 For general solutions: the SDK apparently provides optarg, so we could use that instead of argparse. We could also try to find out why there is no argparse, but it seems to be more effort; the potential reason being packaging choices further upstream that might cause continuous efforts to work around?? ~N On Thu, Feb 09, 2017 at 06:25:51PM +0100, Ivaylo Kostov wrote: > Hi, > I was following the procedure "Compiling osmo-bts for sysmoBTS" and using > poky/1.5.4/sysroots/armv5te-poky-linux-gnueabi > > During execution of libosmocore project it failed with: > ... > GEN gsm0503_conv.c > Traceback (most recent call last): > File "../../utils/conv_gen.py", line 26, in > import sys, os, math, argparse > ImportError: CC oap.lo > No module named argparse > Makefile:735: recipe for target 'gsm0503_conv.c' failed > make[2]: *** [gsm0503_conv.c] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[2]: Leaving directory '/home/ivaylo/net/osmo/libosmocore/src/gsm' > Makefile:460: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/home/ivaylo/net/osmo/libosmocore' > Makefile:327: recipe for target 'all' failed > make: *** [all] Error 2 > ... > > I am using: > > Python 2.7.12+ (default, Sep 17 2016, 12:08:02) > [GCC 6.2.0 20160914] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > > I think that something is broken. > > regards, > Ivaylo > > -- > ------------------------------ > - Ivaylo Kostov > 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 Director: Harald Welte > ------------------------------ > -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Fri Feb 10 12:24:24 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 10 Feb 2017 13:24:24 +0100 Subject: Error while building osmo-bts for sysmoBTS In-Reply-To: <20170210121915.GD28816@my.box> References: <20170210121915.GD28816@my.box> Message-ID: <20170210122424.GE28816@my.box> On Fri, Feb 10, 2017 at 01:19:15PM +0100, Neels Hofmeyr wrote: > For general solutions: the SDK apparently provides optarg, so we could use that > instead of argparse. make that: getopt ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Fri Feb 10 12:27:01 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 10 Feb 2017 13:27:01 +0100 Subject: Error while building osmo-bts for sysmoBTS In-Reply-To: <20170210122424.GE28816@my.box> References: <20170210121915.GD28816@my.box> <20170210122424.GE28816@my.box> Message-ID: <4297bb87-7e44-fa86-f426-7b3bb195853b@sysmocom.de> Ironically the previous version of this patch was using getopt but it was changed to argparse based on review comments. On 10.02.2017 13:24, Neels Hofmeyr wrote: > On Fri, Feb 10, 2017 at 01:19:15PM +0100, Neels Hofmeyr wrote: >> For general solutions: the SDK apparently provides optarg, so we could use that >> instead of argparse. > make that: getopt > > ~N -- Max Suraev 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 Director: Harald Welte From laforge at gnumonks.org Fri Feb 10 12:38:22 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 10 Feb 2017 13:38:22 +0100 Subject: Error while building osmo-bts for sysmoBTS In-Reply-To: <20170210121915.GD28816@my.box> References: <20170210121915.GD28816@my.box> Message-ID: <20170210123822.kb6nkjzlrmnvdzz7@nataraja> Hi Neels and Ivaylo, On Fri, Feb 10, 2017 at 01:19:15PM +0100, Neels Hofmeyr wrote: > Just pulled the newest libosmocore and SDK > https://downloads.sysmocom.de/generic/sysmobts/201310-nightly/sdk/poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.4-20170210020032.sh > and got the same error. > > For general solutions: the SDK apparently provides optarg, so we could use that > instead of argparse. No, let's not go back there. We've been through that discussion. > We could also try to find out why there is no argparse, but it seems to be more > effort; the potential reason being packaging choices further upstream that > might cause continuous efforts to work around?? I'd say it just needs the right package name added to packagegroup-sdk-osmo.inc in https://github.com/sysmocom/meta-telephony/blob/master/recipes-osmocom/packagegroup/packagegroup-sdk-osmo.inc Also, as this discussion relates to the sysmocom SDK for a specific type of sysmocom products, I don't think we should bother the Osmocom mailing list with this. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Fri Feb 10 13:11:08 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 10 Feb 2017 14:11:08 +0100 Subject: Error while building osmo-bts for sysmoBTS In-Reply-To: <20170210121915.GD28816@my.box> References: <20170210121915.GD28816@my.box> Message-ID: <20170210131108.GF28816@my.box> On Fri, Feb 10, 2017 at 01:19:15PM +0100, Neels Hofmeyr wrote: > For general solutions: the SDK apparently provides optarg, so we could use that > instead of argparse. Changed to getopt in https://gerrit.osmocom.org/1792 which works with the current nightly SDK. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Fri Feb 10 13:14:36 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 10 Feb 2017 14:14:36 +0100 Subject: Error while building osmo-bts for sysmoBTS In-Reply-To: <20170210123822.kb6nkjzlrmnvdzz7@nataraja> References: <20170210121915.GD28816@my.box> <20170210123822.kb6nkjzlrmnvdzz7@nataraja> Message-ID: <20170210131436.GG28816@my.box> On Fri, Feb 10, 2017 at 01:38:22PM +0100, Harald Welte wrote: > > For general solutions: the SDK apparently provides optarg, so we could use that > > instead of argparse. > > No, let's not go back there. We've been through that discussion. ignore my recent mail/patch then. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ikostov at sysmocom.de Fri Feb 10 14:25:35 2017 From: ikostov at sysmocom.de (Ivaylo Kostov) Date: Fri, 10 Feb 2017 15:25:35 +0100 Subject: weekly test report (w6 2017) In-Reply-To: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> Message-ID: Hi, BTS test report, week6 2017. BTSes which has been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus B200 - nanoBTS model:165G All test cases passed. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests regards, Ivaylo -- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ From msuraev at sysmocom.de Fri Feb 10 15:40:21 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 10 Feb 2017 16:40:21 +0100 Subject: osmo-bts-trx error with tch/h In-Reply-To: References: Message-ID: Indeed, there seems to be typo in interleaving table used for TCH/H - see gerrit # 1793 for a fix. It doesn't fix CRC and call issues though so either I misread the spec or there are more errors on top of it. On 10.02.2017 12:00, Vadim Yanitskiy wrote: > > > Now we need to find out, where is the bug. There are two assumptions: > > 1) The gsm0503_tch_hr_interleave() doesn't initialize the iB[353]; > 2) The gsm0503_tch_burst_map() refers to the value which it shouldn't > refer to. > > -- Max Suraev 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 Director: Harald Welte From axilirator at gmail.com Sun Feb 12 02:24:04 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 12 Feb 2017 09:24:04 +0700 Subject: osmo-bts-trx error with tch/h Message-ID: Great work Max! I just applied your patch to the libosmocoding, and the problem was solved. Valgrind now says, that everything is ok ;) BTW: did the osmo-bts-trx TCH/H problem solved? With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Feb 12 03:23:30 2017 From: holger at freyther.de (Holger Freyther) Date: Sun, 12 Feb 2017 10:23:30 +0700 Subject: osmo-sip-connector in bad state In-Reply-To: <26031043-CBF8-4602-BCDA-AB8C28C4F0E4@freyther.de> References: <4514C195-4509-416D-A3A2-97C17C682CED@freyther.de> <26031043-CBF8-4602-BCDA-AB8C28C4F0E4@freyther.de> Message-ID: > On 26 Jan 2017, at 21:18, Holger Freyther wrote: > Hi > that sucks. I intend to look at early media in the connector and try to reproduce the issue as well, I have seen it once when a NAT was involved too.. I am traveling in south east asia right now and my test setup is quite limited but I read a bit of sofia-sip code, the glib integration and our event loop integration and while I couldn't reproduce it, there are things to improve in our eventloop code. If you are building from source you could pull this[1] to give it a try. I intend to submit the changes on Tuesday morning (giving europe/us time to review on a business day). Nightly packages should be available soon. thank you holger [1] git pull https://gerrit.osmocom.org/osmo-sip-connector refs/changes/97/1797/1 From sebastian.stumpf87 at googlemail.com Sun Feb 12 13:29:05 2017 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Sun, 12 Feb 2017 14:29:05 +0100 Subject: Virtual layer 1 - Questions Message-ID: Hi, The virtual layer 1 is currently in a state where the l23 app can successfully connect to the bts and most of the signaling messages will be forwarded and handled. TCH is not yet implemented. I have some problems still, not knowing if these are caused by configuration problems or my coding :). - Trying to initiate a call via the mobile vty will result in VTY: call 1 123 OsmocomBB# % (MS 1) % Call has been rejected call 1 123 OsmocomBB# % (MS 1) % Call has been released And no actual call setup message is transfered over the Um interface. What could be reasons for that? I am using the test-sim option the mobile app offers. - Occasionaly the T3210 timer is fired, which causes a new registering within the network. LOG: gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired How can i prevent that? - I did not implement a tdma or multiframe scheduler in the mobile uplink as the logical channel is directly put to the gsmtap-header and thus known by the bts. As Harald used a multiframe based scheduling for the bts downlink, i wonder if this might be necessary, though. To submit msgs with the correct frame number for example. - In my wireshark capture files, the gsmtap messages sent over the multicast sockets are only recognized as UDP messages. I have to "cast" them with the wireshark context menu "Decode as...". Why? I would be super happy if someone of you could check out my project (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch stumpf/virt-phy) try to run it with the config files lying within the project folders and tell me the problems they see :). Here you can find a wireshark capture file of 2 mobiles connecting to a virt bts. I also tried to init calls from both of them but the call setup is not send. https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-nitb_171002%3Asubscribers-accepted-by-nitb.pcapng?dl=0 Kind Regards, Sebastian Stumpf From laforge at gnumonks.org Sun Feb 12 23:09:20 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 13 Feb 2017 00:09:20 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: References: Message-ID: <20170212230920.epvdsj7jwxzta23w@nataraja> Hi Sebastian, On Sun, Feb 12, 2017 at 02:29:05PM +0100, Sebastian Stumpf wrote: > The virtual layer 1 is currently in a state where the l23 app can > successfully connect to the bts and most of the signaling messages > will be forwarded and handled. TCH is not yet implemented. this is excellent news! Thanks for sticking with this and pushing it forward. > - Trying to initiate a call via the mobile vty will result in > VTY: > call 1 123 > OsmocomBB# > % (MS 1) > % Call has been rejected > call 1 123 > OsmocomBB# > % (MS 1) > % Call has been released > And no actual call setup message is transfered over the Um interface. > What could be reasons for that? I am using the test-sim option the > mobile app offers. I'm not sure if this is the root cause, but it seems there is some timeslot mis-matches in your traces. The Immediate Assignment contains TS 2 or TS 7, but I see Uplink frames for FACH on TS0, which is impossible (TS0 never has a channel combination with FACCH). Also, The uplink frames don't have the Uplink bit set in the GSMTAP header. This is a bit confusing, and I think it would be a good idea to introduce some consistency/invariant checking on both sides, i.e. the BTS should drop all non-uplink frames received, and the MS should drop all uplink frames received. I'm also surprised to see you're seeing an immediate assignment reject in downlink. This should only happen if all channels are allocated and the BTS is out of resources. Also, in your traces, there are typically several frames that are on the same timeslot in the same GSM frame number. This is not possible (probably related to the wrong TS above?). At maximum, there can be one L2 signalling message for a given TS + FN. Also, on the real radio interface a MAC block takes typically four frames on that channel, so the actual rate is lower. > - Occasionaly the T3210 timer is fired, which causes a new registering > within the network. well, it means that something got lost between MS and MSC for such a long time (between sending the LU REQ and receving a response) that the MS gives up. > LOG: > gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired > How can i prevent that? The underlying problem must be resolved. On the simulated L1 you shouldn't loose messages, so this shouldn't happen if all messages arrive as expected on both sides. > - I did not implement a tdma or multiframe scheduler in the mobile > uplink as the logical channel is directly put to the gsmtap-header and > thus known by the bts. As Harald used a multiframe based scheduling > for the bts downlink, i wonder if this might be necessary, though. To > submit msgs with the correct frame number for example. It is primarily a question of how real the simulation should be. By using a multiframe scheduler one can make sure that the actual bandwidth/speed of GSM is maintained even over a virtual L1. Also, on the BTS side it must be present to schedule the BCCH (system information, ...) without which a MS would never even see the cell. I think one can do without on the MS side, but then the BTS must basically queue the incoming frames until the respective frame number indicated in the frame matches the current frame number. > - In my wireshark capture files, the gsmtap messages sent over the > multicast sockets are only recognized as UDP messages. I have to > "cast" them with the wireshark context menu "Decode as...". Why? This seems because you're using a non-standard port for the messages: In the capture I see UDP port 6666 rather than the IANA-registered port for GSMTAP which is 4729. > I would be super happy if someone of you could check out my project > (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch > stumpf/virt-phy) try to run it with the config files lying within the > project folders and tell me the problems they see :). I'll have a look, but not straight away now, sorry. > Here you can find a wireshark capture file of 2 mobiles connecting to > a virt bts. I also tried to init calls from both of them but the call > setup is not send. Already the LU is not working stable, so I think the first step is to stabilize this. You can see in packet 740 that the MS is sneding a LU Req, which the BTS forwards in frame 741 as RSL message to the NITB. The NITB then responds with an IDENTITY REQUEST which can be seen on RSL but which seems to disappear in the BTS without being ever sent on the virtual Um interface. As a result, the MS never sends the identity response, and the NITB will give up. I also see that the RACH requesets all are sent with a bogus frame number: 42. This will not work. The RACH request needs to be sent with the current frame number at the time being. Also, RACH retransmissions are happening way too quick. See Packets 600...644 where there are 7 RACH requests all within soemething like 10ms. The BTS then allocates 7 channels rather than one, ... So I think those lower-layer issues should be addressed before moving on to voice calls. Keep up the good work! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jacob01 at gmx.net Mon Feb 13 07:13:06 2017 From: jacob01 at gmx.net (Jacob Erlbeck) Date: Mon, 13 Feb 2017 08:13:06 +0100 Subject: vlr+hlr: Insert Data In-Reply-To: <20170209135321.GB28816@my.box> References: <20170209135321.GB28816@my.box> Message-ID: <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> Hi, On 02/09/2017 02:53 PM, Neels Hofmeyr wrote: > What should we do if the HLR sends no Insert Data? > > When a subscriber does a Location Updating, the VLR sends a Location Updating > request to the HLR. The HLR typically responds with a Location Updating Result > as success and, in a *separate* message, sends an Insert Data to the VLR to > tell it the subscriber's MSISDN. So it is possible to do a successful Location > Updating without being told the MSISDN (as my test verifies). I did not find much in 29.002 that tells otherwise. There is only figure 19.1.1/3 which states that the insert messages are not optional by not using italics. The automatons in 19.1.1/6 and 19.1.1/13 do not impose such a restriction. > > What should the VLR do if it never receives the Insert Data from the HLR? In > that case the subscriber is attached but cannot be reached by MSISDN. Should > we actively wait for Inser Data and reject the subscriber if not successful? The MS can still be happy without an MSISDN: GPRS, USSD, MT-calls, MT-SMS shouldn't need it. Or the HLR may decide to send an update with an MSISDN later on (or change it). > > It would be fairly easy to just send the MSISDN along in the Location Updating > Result. Why this separate message? In my understanding, the MAP UpdateLocationArg and UpdateLocationRes messages rather contain information directly related to the location update. The subscriber infos are modified by the insertSubscriberData and deleteSubscriberData operations which can also appear in different application contexts (networkLocUpContext, subscriberDataMngtContext, ...). So it makes sense to separate that from the UpdateLocationRes message. In addition, you can send any amount of subscriber data items but the maximum size of each single MAP message may be limited. Nevertheless it's difficult to handle in cases where you just need some information about a certain IMSI. That is why it is done differently in GSUP where the complexity of MAP can be handled by a separate proxy, and there is no such a size restriction. Jacob > > Thx, > > ~N > From msuraev at sysmocom.de Mon Feb 13 09:41:05 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 13 Feb 2017 10:41:05 +0100 Subject: osmo-bts-trx error with tch/h In-Reply-To: References: Message-ID: <3e5038bf-c854-3592-ba44-39436213e0c1@sysmocom.de> Thanks. On 12.02.2017 03:24, Vadim Yanitskiy wrote: > Great work Max! > > I just applied your patch to the libosmocoding, and the problem was > solved. > Valgrind now says, that everything is ok ;) > > BTW: did the osmo-bts-trx TCH/H problem solved? > Unfortunately not - I still got CRC errors and call delay due to ts switch so there's smth else unrelated to interleaving. -- Max Suraev 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 Director: Harald Welte From nhofmeyr at sysmocom.de Mon Feb 13 11:40:38 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 13 Feb 2017 12:40:38 +0100 Subject: vlr+hlr: Insert Data In-Reply-To: <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> References: <20170209135321.GB28816@my.box> <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> Message-ID: <20170213114038.GA1988@my.box> Hi Jacob, many thanks for these explanations and pointers! On Mon, Feb 13, 2017 at 08:13:06AM +0100, Jacob Erlbeck wrote: > I did not find much in 29.002 that tells otherwise. There is only figure > 19.1.1/3 which states that the insert messages are not optional by not > using italics. The automatons in 19.1.1/6 and 19.1.1/13 do not impose > such a restriction. Hmm, I don't really see a difference there. To me it all looks like "in case an Insert Subscriber Data {Ind,Req} is received, handle it", and no consequence if it's missing. So the lack of italics itself says it's mandatory? :) > The MS can still be happy without an MSISDN: GPRS, USSD, MT-calls, > MT-SMS shouldn't need it. Or the HLR may decide to send an update with > an MSISDN later on (or change it). Yes, but I assume "I can call you but you can't call me" is an error state. Anyway, I don't really expect this to happen in practice. Would be nice though to at least detect it and print an error message or something. > > It would be fairly easy to just send the MSISDN along in the Location Updating > > Result. Why this separate message? > > In my understanding, the MAP UpdateLocationArg and UpdateLocationRes > messages rather contain information directly related to the location > update. The subscriber infos are modified by the insertSubscriberData > and deleteSubscriberData operations which can also appear in different > application contexts (networkLocUpContext, subscriberDataMngtContext, > ...). So it makes sense to separate that from the UpdateLocationRes > message. In addition, you can send any amount of subscriber data items > but the maximum size of each single MAP message may be limited. > > Nevertheless it's difficult to handle in cases where you just need some > information about a certain IMSI. That is why it is done differently in > GSUP where the complexity of MAP can be handled by a separate proxy, and > there is no such a size restriction. As far as our GSUP encoding+decoding is concerned, it's all done unconditionally. So if our HLR were to stick an MSISDN TLV in the LU Accept GSUP message, the GSUP client would decode it, and hey, what's this: /* Handle UpdateLocation Result from HLR */ static int vlr_sub_handle_lu_res(struct vlr_subscriber *vsub, const struct osmo_gsup_message *gsup) { if (!vsub->lu_fsm) { LOGVSUBP(LOGL_ERROR, vsub, "Rx GSUP LU Result " "without LU in progress\n"); return -ENODEV; } /* contrary to MAP, we allow piggy-backing subscriber data onto the * UPDATE LOCATION RESULT, and don't mandate the use of a separate * nested INSERT SUBSCRIBER DATA transaction */ vlr_sub_gsup_insert_data(vsub, gsup); osmo_fsm_inst_dispatch(vsub->lu_fsm, VLR_ULA_E_HLR_LU_RES, NULL); return 0; } So Harald's VLR code would indeed also handle the MS data glued to the LU Result. All we need is make the HLR send the MSISDN TLV along in the LU Result. Of course to allow that also means to not insist on the Insert Data message from the HLR. We should probably still print an error message when the LU completes without an MSISDN known in the VLR. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Mon Feb 13 13:09:15 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 13 Feb 2017 14:09:15 +0100 Subject: vlr+hlr: Insert Data In-Reply-To: <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> References: <20170209135321.GB28816@my.box> <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> Message-ID: <20170213130915.4ooruoprfctsyig7@nataraja> On Mon, Feb 13, 2017 at 08:13:06AM +0100, Jacob Erlbeck wrote: > Nevertheless it's difficult to handle in cases where you just need some > information about a certain IMSI. That is why it is done differently in > GSUP where the complexity of MAP can be handled by a separate proxy, and > there is no such a size restriction. Please note that I had extended GSUP to also handle the separate/nested LU + ISD transactions, at least in the SGSN as far as I remember. So the subscriber related data can either be inside the LU-response or in the seperate/nested ISD-request. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jacob01 at gmx.net Mon Feb 13 13:56:16 2017 From: jacob01 at gmx.net (Jacob Erlbeck) Date: Mon, 13 Feb 2017 14:56:16 +0100 Subject: vlr+hlr: Insert Data In-Reply-To: <20170213114038.GA1988@my.box> References: <20170209135321.GB28816@my.box> <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> <20170213114038.GA1988@my.box> Message-ID: <14fad5aa-6fbe-85f5-3a84-3a6779bf0ba1@gmx.net> Hi Neels, On 02/13/2017 12:40 PM, Neels Hofmeyr wrote: > > On Mon, Feb 13, 2017 at 08:13:06AM +0100, Jacob Erlbeck wrote: > >> The MS can still be happy without an MSISDN: GPRS, USSD, MT-calls, >> MT-SMS shouldn't need it. Or the HLR may decide to send an update with >> an MSISDN later on (or change it). > > Yes, but I assume "I can call you but you can't call me" is an error state. > Anyway, I don't really expect this to happen in practice. Would be nice though > to at least detect it and print an error message or something. What about a "data only" SIM card that does e.g. not have a fixed IMSI needing an MT-SMS after initial LU to get a temporary one to be able to do GPRS etc? Jacob From aschultz at tpip.net Mon Feb 13 14:13:37 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Mon, 13 Feb 2017 15:13:37 +0100 (CET) Subject: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev In-Reply-To: <20170206135512.sbxvkbe3hzgnwwjt@nataraja> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-3-aschultz@tpip.net> <20170206135512.sbxvkbe3hzgnwwjt@nataraja> Message-ID: <2072664575.96405.1486995217363.JavaMail.zimbra@tpip.net> ----- On Feb 6, 2017, at 2:55 PM, Harald Welte laforge at netfilter.org wrote: > Hi Andreas, > > On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote: >> Both function are always used together with the final goal to >> get the gtp_dev. This simplifies the code by merging them together. > > Ok, some code restructuring / unification, seems useful. > > However: > >> - netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n", >> - pctx->u.v0.tid, pctx); >> + pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n", >> + pctx->u.v0.tid, pctx); > > (and other related changes) appear to be purely cosmetic and should thus > be unrelated to the function merging described in the change log > message. The dev argument has been removed from the surrounding function. However, for those debug message having the network device information is use full. I've modified the code in v3 a bit to keep the debug message. Andreas > > -- > - Harald Welte http://netfilter.org/ > ============================================================================ > "Fragmentation is like classful addressing -- an interesting early > architectural error that shows how much experimentation was going > on while IP was being designed." -- Paul Vixie From aschultz at tpip.net Mon Feb 13 14:14:49 2017 From: aschultz at tpip.net (Andreas Schultz) Date: Mon, 13 Feb 2017 15:14:49 +0100 (CET) Subject: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper In-Reply-To: <20170206135859.mq6pidofidnps2q6@nataraja> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-5-aschultz@tpip.net> <20170206135859.mq6pidofidnps2q6@nataraja> Message-ID: <1516124800.96408.1486995289464.JavaMail.zimbra@tpip.net> ----- On Feb 6, 2017, at 2:58 PM, laforge laforge at gnumonks.org wrote: > Hi Andreas, > > On Mon, Jan 30, 2017 at 05:37:11PM +0100, Andreas Schultz wrote: >> Consolidate duplicate code into helper. > > Makes complete sense. > > However: > >> +static void pdp_context_delete(struct pdp_ctx *pctx); >> + > > why introduce the forward-declaration and then define the function > further down in the file? I think in general, it is preferred to put > helper functions on top, before their first use, so forward declarations > can be avoided? Particularly if the helper function doesn't call any > other functions that are not yet declared at this point. I wanted to keep functions that work on the data structure close together. I this case the function the initialized the pdp context and the delete function for it. Andreas > > Please note the above might just be my personal taste, not sure if > that's a general habit in the kernel networking code these days. > > So with or without the re-ordering: > > Acked-by: Harald Welte > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From pablo at netfilter.org Mon Feb 13 14:51:14 2017 From: pablo at netfilter.org (Pablo Neira Ayuso) Date: Mon, 13 Feb 2017 15:51:14 +0100 Subject: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev In-Reply-To: <2072664575.96405.1486995217363.JavaMail.zimbra@tpip.net> References: <20170130163713.17524-1-aschultz@tpip.net> <20170130163713.17524-3-aschultz@tpip.net> <20170206135512.sbxvkbe3hzgnwwjt@nataraja> <2072664575.96405.1486995217363.JavaMail.zimbra@tpip.net> Message-ID: <20170213145114.GA4368@salvia> On Mon, Feb 13, 2017 at 03:13:37PM +0100, Andreas Schultz wrote: > > > ----- On Feb 6, 2017, at 2:55 PM, Harald Welte laforge at netfilter.org wrote: > > > Hi Andreas, > > > > On Mon, Jan 30, 2017 at 05:37:09PM +0100, Andreas Schultz wrote: > >> Both function are always used together with the final goal to > >> get the gtp_dev. This simplifies the code by merging them together. > > > > Ok, some code restructuring / unification, seems useful. > > > > However: > > > >> - netdev_dbg(dev, "GTPv0-U: update tunnel id = %llx (pdp %p)\n", > >> - pctx->u.v0.tid, pctx); > >> + pr_debug("GTPv0-U: update tunnel id = %llx (pdp %p)\n", > >> + pctx->u.v0.tid, pctx); > > > > (and other related changes) appear to be purely cosmetic and should thus > > be unrelated to the function merging described in the change log > > message. > > The dev argument has been removed from the surrounding function. > However, for those debug message having the network device information > is use full. I've modified the code in v3 a bit to keep the debug message. There is no reason to replace netdev_dbg() by pr_debug(). With several gtp devices in place, this debugging will render completely useless since you cannot know what device has triggered the debugging mesage. A better solution would be to simply remove this debugging thing. This actually is only useful at early development stage IMO. From nhofmeyr at sysmocom.de Mon Feb 13 15:42:37 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 13 Feb 2017 16:42:37 +0100 Subject: vlr+hlr: Insert Data In-Reply-To: <14fad5aa-6fbe-85f5-3a84-3a6779bf0ba1@gmx.net> References: <20170209135321.GB28816@my.box> <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> <20170213114038.GA1988@my.box> <14fad5aa-6fbe-85f5-3a84-3a6779bf0ba1@gmx.net> Message-ID: <20170213154237.GE1988@my.box> On Mon, Feb 13, 2017 at 02:56:16PM +0100, Jacob Erlbeck wrote: > What about a "data only" SIM card that does e.g. not have a fixed IMSI > needing an MT-SMS after initial LU to get a temporary one to be able to > do GPRS etc? Interesting, is IMSI a typo or is this real? Anyway, no MSISDN does seem to be a valid use case, thanks :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From axilirator at gmail.com Mon Feb 13 17:16:30 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 14 Feb 2017 00:16:30 +0700 Subject: osmo-bts-trx error with tch/h Message-ID: Just let me know if I can help you somehow. I have SDR based board too. P.S. Please CC me in the further messages. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Feb 14 16:40:01 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 14 Feb 2017 17:40:01 +0100 Subject: the near and further future of osmo-nitb Message-ID: <20170214164001.GA1485@ass40.sysmocom.de> Hi all, I would like to direct your attention towards upcoming fairly fundamental changes that we would like to make in openbsc.git. The operation of osmo-nitb will need some adjustments that might stump some users at first. Hence, I would like to ask your feedback on this. While these changes open the road forward in exciting ways, to some degree they constitute a code bomb and a point-of-no-return. Let's discuss, to be prepared for it. (1) Near future: We are separating the HLR from OsmoNITB, aka libvlr + OsmoHLR. This gets us asynchronous HLR database access, 3G authentication and one central HLR for both OsmoNITB and OsmoSGSN (at some point also several OsmoNITBs). OsmoNITB will no longer manage its own SQlite subscriber database. OsmoHLR is a separate process that manages subscriber data, which the OsmoNITB as well as the OsmoSGSN will contact using the GSUP protocol. On the OsmoNITB side, libvlr implements a VLR with a brand new finite state machine implementation of handling attach, authentication and ciphering on a subscriber connection. libvlr stores subscriber data solely in RAM. (Note that at first, OsmoNITB will still have an SQlite database file, which will be used for storage of SMS data, only.) The main changes in operating OsmoNITB will be: - A separate osmo-hlr process with its own hlr.db database needs to be run. - The osmo-nitb VTY (telnet localhost 4242) and CTRL interface will no longer allow changing subscriber data; good old commands like 'subscriber create imsi 1234', 'subscriber imsi 1234 authorized 1' and so on will no longer be available. All subscriber management must be done on the OsmoHLR side. Since OsmoHLR so far has no VTY or CTRL API to manage subscribers, that needs to be done via sqlite3 on the hlr.db file (or re-implemented for OsmoHLR). Since this will constitute a profound change in operating an Osmocom CN, it makes sense to think about ways to transition. We're planning to make the VLR+HLR branch the new 'master' branch of openbsc, while keeping the current master on a legacy branch (named something like v1, which implies that the new flavor is Osmocom v2). We do not indend to spend much effort on maintaining the old flavor, though. Ongoing development and new features will happen in the new libvlr+OsmoHLR flavor, only. To take a peek, see the openbsc.git branch 'neels/vlr' and OsmoHLR at http://git.osmocom.org/osmo-hlr/ . (2) Further plans: For Iu and A interfaces (a standalone 3G+2G MSC implementation), we have also worked towards a complete separation of libmsc from libbsc. As a result, we will probably completely replace OsmoNITB with the new OsmoCSCN, meaning "Circuit Switched Core Network", which will be mainly MSC+VLR, talking to OsmoHLR for subscriber data, and to OsmoBSC and/or OsmoHNBGW to manage GERAN (2G) and/or UTRAN (3G) radio services. The main changes in operating an Osmocom CN will be: - Instead of running OsmoNITB, run separate OsmoBSC, OsmoCSCN and OsmoHLR instances. - VTY configuration of the BTS parameters needs to be done on the OsmoBSC level. - Logging on the MSC level will no longer have intimate access to BSC and BTS details. It is thinkable to still offer an OsmoNITB that integrates BSC and MSC+VLR, but the focus is elsewhere. - There will be Iuh (3G) support; IuCS in OsmoCSCN (sysmocom/iu branch), IuPS in OsmoSGSN (already merged to master, 3G Authentication pending). - It will be possible to operate a real A interface towards other standalone BSCs. This will at first stay on the sysmocom/iu branch, and cannot be merged to the master branch before we have a fully operational A interface. To take a peek, see http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G Your feedback and opinions on these plans are welcome! ~N -- - Neels Hofmeyr 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: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue Feb 14 17:40:04 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 14 Feb 2017 18:40:04 +0100 Subject: the near and further future of osmo-nitb In-Reply-To: <20170214164001.GA1485@ass40.sysmocom.de> References: <20170214164001.GA1485@ass40.sysmocom.de> Message-ID: <20170214174004.dfdgvhbi44dgowpo@nataraja> Hi Neels, thanks for outlining the roadmap. On Tue, Feb 14, 2017 at 05:40:01PM +0100, Neels Hofmeyr wrote: > For Iu and A interfaces (a standalone 3G+2G MSC implementation), we have > also worked towards a complete separation of libmsc from libbsc. As a > result, we will probably completely replace OsmoNITB with the new > OsmoCSCN, meaning "Circuit Switched Core Network" Originally when we started this 3G related work, CSCN was "NITB without BSC", i.e. it included SMSC and HLR/AUC functionalities. However, as the VLR/HLR split is also coming to a close now, I'm not sure if we shoul continue to call it CSCN, or if we should simply call it "MSC". The only thing "unusual" for a MSC that it still contains at this point (when both BSC and HLR/AUC have been moved out) is the SMSC. So we migh simply move to a NITB that is split up in BSC, MSC/VLR and HLR/AUC, and call the components OsmoBSC (exists already), OsmoHLR (exists already) and OsmoMSC (which is still called CSCN). Or we keep calling it CSCN until the SMS has moved out? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Tue Feb 14 21:51:14 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 14 Feb 2017 22:51:14 +0100 Subject: the near and further future of osmo-nitb In-Reply-To: <20170214174004.dfdgvhbi44dgowpo@nataraja> References: <20170214164001.GA1485@ass40.sysmocom.de> <20170214174004.dfdgvhbi44dgowpo@nataraja> Message-ID: <20170214215114.GA14929@my.box> On Tue, Feb 14, 2017 at 06:40:04PM +0100, Harald Welte wrote: > So we migh simply move to a NITB that is split up in BSC, MSC/VLR and > HLR/AUC, and call the components OsmoBSC (exists already), OsmoHLR > (exists already) and OsmoMSC (which is still called CSCN). Or we keep I like OsmoMSC because it's a name familiar to all GSM network operators, while every time I write CSCN I feel that I have to explain it because we invented it. The VLR is also officially a component of the MSC, right? I'd be ok with calling it MSC before the SMSC is separated, because then we won't have a rename in our main history besides the move from OsmoNITB to OsmoMSC. I can rename CSCN to MSC on the branch and then CSCN is poof, gone. We already have OsmoCSCN named in some blog posts / wiki and a project with this name on osmocom.org, I guess the sooner we converge to a long term name (OsmoMSC) the better, to minimize the spread and confusion. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Tue Feb 14 22:44:58 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 14 Feb 2017 23:44:58 +0100 Subject: the near and further future of osmo-nitb In-Reply-To: <20170214215114.GA14929@my.box> References: <20170214164001.GA1485@ass40.sysmocom.de> <20170214174004.dfdgvhbi44dgowpo@nataraja> <20170214215114.GA14929@my.box> Message-ID: <20170214224458.f7ssubtdvntudrpc@nataraja> Hi Neels, On Tue, Feb 14, 2017 at 10:51:14PM +0100, Neels Hofmeyr wrote: > I like OsmoMSC because it's a name familiar to all GSM network operators, while > every time I write CSCN I feel that I have to explain it because we invented > it. The VLR is also officially a component of the MSC, right? "officially" the VLR is co-located with the MSC, but a VLR may exist separately and the VLR coverage area can encompass multiple MSC coverage areas. Not sure if anyone ever implemented it that way, though. It's the same like the AUC which is co-located with the HLR but may actually be a separate box. Still, I think it's common-place in the 3GPP world to use MSC=MSC+VLR and HLR=HLR+AUC. > I'd be ok with calling it MSC before the SMSC is separated, because then we > won't have a rename in our main history besides the move from OsmoNITB to > OsmoMSC. I can rename CSCN to MSC on the branch and then CSCN is poof, gone. fine with me. You can add a symlink, if you'd like ;) Hell, we can even be funky and make a multi-call binary that will behave differently depending on argv[0] - but no, let's not go there. We're not busybox. > We already have OsmoCSCN named in some blog posts / wiki and a project with > this name on osmocom.org, I guess the sooner we converge to a long term name > (OsmoMSC) the better, to minimize the spread and confusion. ACK. Let's do it at the time when the Iu and the VLR branches merge, i.e. once the HLR is no longer included, and A and Iu interface are offered. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From snehasish.cse at LIVE.COM Wed Feb 15 13:02:23 2017 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Wed, 15 Feb 2017 13:02:23 +0000 Subject: the near and further future of osmo-nitb In-Reply-To: <20170215104838.w3qexbzwww7fmt4p@nataraja> References: <20170214164001.GA1485@ass40.sysmocom.de> <20170214174004.dfdgvhbi44dgowpo@nataraja> <20170214215114.GA14929@my.box> <20170214224458.f7ssubtdvntudrpc@nataraja> , <20170215104838.w3qexbzwww7fmt4p@nataraja> Message-ID: Hi ________________________________ On Wed, Feb 15, 2017 at 09:39:15AM +0000, Snehasish Kar wrote: > A query, can it be now used with an usrp. > Please kindly always post questions to the mailing list and not to individual developers. Thanks. Sorry for that. > It can be for many years ?!? That's what OsmoTRX, OsmoBTS (with osmo-bts-trx backend) are for. I meant the version of osmo-nitb supporting 3G be used with a USRP ? BR Snehasish -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Feb 15 13:06:29 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 15 Feb 2017 14:06:29 +0100 Subject: the near and further future of osmo-nitb In-Reply-To: References: <20170214164001.GA1485@ass40.sysmocom.de> <20170214174004.dfdgvhbi44dgowpo@nataraja> <20170214215114.GA14929@my.box> <20170214224458.f7ssubtdvntudrpc@nataraja> <20170215104838.w3qexbzwww7fmt4p@nataraja> Message-ID: <20170215130629.53eiwsyi56cs75jw@nataraja> On Wed, Feb 15, 2017 at 01:02:23PM +0000, Snehasish Kar wrote: > > It can be for many years ?!? That's what OsmoTRX, OsmoBTS (with osmo-bts-trx backend) are for. > > I meant the version of osmo-nitb supporting 3G be used with a USRP ? It is a community based project. It can only do things that people have spent weeks/months/years of their lifetime to implement. So unless somebody with an interest to do so implements the missing parts: no :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Wed Feb 15 13:19:08 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 15 Feb 2017 14:19:08 +0100 Subject: the near and further future of osmo-nitb In-Reply-To: <20170214164001.GA1485@ass40.sysmocom.de> References: <20170214164001.GA1485@ass40.sysmocom.de> Message-ID: <5eaad9e4-0ed5-72fc-6528-b7b086fe6997@sysmocom.de> Hi. I think we should also use this opportunity for bigger cleanup: remove deprecated vty/ctrl commands, API/ABI break which was postponed etc. Since we're going to lose backward compatibility anyway it might make sense to batch all the incompatible changes together. -- Max Suraev 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 Director: Harald Welte From snehasish.cse at LIVE.COM Wed Feb 15 13:20:20 2017 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Wed, 15 Feb 2017 13:20:20 +0000 Subject: the near and further future of osmo-nitb In-Reply-To: <20170215130629.53eiwsyi56cs75jw@nataraja> References: <20170214164001.GA1485@ass40.sysmocom.de> <20170214174004.dfdgvhbi44dgowpo@nataraja> <20170214215114.GA14929@my.box> <20170214224458.f7ssubtdvntudrpc@nataraja> <20170215104838.w3qexbzwww7fmt4p@nataraja> , <20170215130629.53eiwsyi56cs75jw@nataraja> Message-ID: Thanks for the info. One more help, for using this do I need to purchase programmable u-sim, for testing or I can test with my usim by manually selecting the network, I am asking these because of the mutual authentication that takes place between UE and enode b. BR Snehasish ________________________________ From: Harald Welte Sent: Wednesday, February 15, 2017 6:36:29 PM To: Snehasish Kar Cc: openbsc at lists.osmocom.org Subject: Re: the near and further future of osmo-nitb On Wed, Feb 15, 2017 at 01:02:23PM +0000, Snehasish Kar wrote: > > It can be for many years ?!? That's what OsmoTRX, OsmoBTS (with osmo-bts-trx backend) are for. > > I meant the version of osmo-nitb supporting 3G be used with a USRP ? It is a community based project. It can only do things that people have spent weeks/months/years of their lifetime to implement. So unless somebody with an interest to do so implements the missing parts: no :) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From choukoumoun at gmail.com Wed Feb 15 13:35:10 2017 From: choukoumoun at gmail.com (choukoumoun) Date: Wed, 15 Feb 2017 14:35:10 +0100 Subject: (OPENBSC) osmo-sip-connector and freepbx Message-ID: Hello, I want to connect osmo-sip-connector with and freepbx server installed into another machine. is it possible ? anybody have a file configuration exemple ? Thanks From laforge at gnumonks.org Wed Feb 15 13:36:03 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 15 Feb 2017 14:36:03 +0100 Subject: the near and further future of osmo-nitb In-Reply-To: <5eaad9e4-0ed5-72fc-6528-b7b086fe6997@sysmocom.de> References: <20170214164001.GA1485@ass40.sysmocom.de> <5eaad9e4-0ed5-72fc-6528-b7b086fe6997@sysmocom.de> Message-ID: <20170215133603.gzkcllcfjnyf2jvt@nataraja> On Wed, Feb 15, 2017 at 02:19:08PM +0100, Max wrote: > I think we should also use this opportunity for bigger cleanup: remove > deprecated vty/ctrl commands, API/ABI break which was postponed etc. Since > we're going to lose backward compatibility anyway it might make sense to > batch all the incompatible changes together. feel free to create a ticket where to collect the changes you have in mind. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Wed Feb 15 17:28:23 2017 From: keith at rhizomatica.org (Keith) Date: Wed, 15 Feb 2017 17:28:23 +0000 Subject: the near and further future of osmo-nitb In-Reply-To: <20170214164001.GA1485@ass40.sysmocom.de> References: <20170214164001.GA1485@ass40.sysmocom.de> Message-ID: On 14 February 2017 17:40:01 CET, Neels Hofmeyr wrote: > >(Note that at first, OsmoNITB will still have an SQlite database file, >which will be used for storage of SMS data, only.) It sounds great to be able to freely manipulate directly the sqlite subscribers now. So no more equipment, equipmentwatch, but I see an imei field in osmoHLR, so will the subscriber auto create mechanism work, 'logging' IMSIs and IMEIs as such? I'm interested in the future of the SMSC. I have a python script ( that i''ll push to contrib once I iron out something with multipart messages in different charsets ) - it is reading the sms queue in order to pull out sms that are for destinations that are no longer on that nitb. It's a problem with having the sms queue inside the nitb. I need to.consequently delete sms and I intend to do this via the VTY, so I began looking at implementing some kindbof 'show sms-queue' and 'delete sms ID x'. But maybe this is not worth doing now? It doesn't seem like a lot of work, even for me, to 'port' the subscriber manipulation commands to an osmo HLR vty. Is it desirable though, if there is now now problem writing the sqlite while osmoHLR has it open? From ikostov at sysmocom.de Fri Feb 17 11:41:00 2017 From: ikostov at sysmocom.de (Ivaylo Kostov) Date: Fri, 17 Feb 2017 12:41:00 +0100 Subject: weekly test report (w7 2017) In-Reply-To: References: <0a9411de-4fb1-46bf-29cf-dbef1c094293@sysmocom.de> Message-ID: <59e552f4-671d-2d82-a60b-7ff991075cd8@sysmocom.de> Hi, BTS test report, week7 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G All test cases passed except the one for USRP B200, where Location update procedure failed and the related ticket is created at: https://osmocom.org/issues/1951 For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests regards, Ivaylo -- ------------------------------ - Ivaylo Kostov 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 Director: Harald Welte ------------------------------ From nhofmeyr at sysmocom.de Fri Feb 17 15:00:10 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 17 Feb 2017 16:00:10 +0100 Subject: logging filters, RFC Message-ID: <20170217150010.GA2235@my.box> Summary: [1] some problems found in the current logging filter implementation. [2]..[7] a long discussion on where we could take Osmocom logging. [2] logging "lifter" instead of a filter [3] setting logging levels for flagged objects [4] multiple log targets and multiple flagged objects [5] FSM instance logging [6] setting the log context [7] VTY logging commands [1] In the VLR development, I'm going to split the gsm_subscriber to a bsc_subscriber and a vlr_subscriber. Hence I need to care about the logging filter code, that e.g. drops all logging except that for a given subscriber. At first I wanted to drop it altogether, but in fact filtering on a given subscriber is an important feature. See https://gerrit.osmocom.org/1685 Looking further into adapting this to two types of subscriber struct being used in the code, I found that in fact the logging filter code looks quite neglected and degraded. - One functional problem is that the constants for BSC_CTX_SUBSCR and GPRS_CTX_BVC actually have the same value: they both resolve to 1, and both thus access the same logging context pointer with conflicting types. openbsc debug.c's filter_fn appears to use both BSC_CTX_SUBSCR and GPRS_CTX_BVC, but GPRS_* are only set in libosmocore/src/gb/ code. Could be justified by osmo-nitb and osmo-sgsn not overlapping much, but I doubt that it's on purpose. - A log target's filter_data[] possibly holds a subscr_get() reference. If a log target is closed, like a VTY closing, the reference count may leak, because there is no filter data tear down that could subscr_put() it back. - log_set_nsvc_filter() and log_set_bvc_filter() are declared in openbsc/debug.h, but the only implementations I can find are *static* in libosmocore/src/gb/gprs_bssgp_vty.c and gprs_ns_vty.c, respectively. - The openbsc/debug.h enum defining LOG_FILTER_* is never used, because it is bascially duplicated in debug.c, where the values are called FLT_* instead. - The BSC_CTX_BTS and BSC_CTX_LCHAN are each set once by a call to log_set_context(), but no filter function ever reads them back out from the context array. So they are utterly unused. Hence in libbsc/libmsc, the *only* logging filter practically used is the IMSI filter. The filter code screams for attention and more safety. I would collect the various constants in a central place in libosmocore to avoid collisions (like ports.h does), and would use the same constant for both... the filter ctx array index: ctx[FLT_CONSTANT] and the bitmask: filter_map & (1 << FLT_CONSTANT) with a static assert to ensure that the filter category constants don't outgrow the filter_data[], ctx[], filter_map sizes. I'd drop unused definitions, add a tear down cb. [2] While talking about logging, I'm thinking back to 33c3 where we had a large active network and might want to highlight a few subscribers in the logging... Any comments on below bold plans to overhaul the logging semantics are welcome. Despite the long discussion, implementation of this should not be a lot of work really. Nevertheless, there are pressing topics in need of attention, and this mail doesn't mean that it will be implemented now. It's a unicorn's dream of where I would take Osmocom logging, and it _might_ be a good time to do it now... If you will, join me on an extensive journey through our logging: So far the logging checking goes like this: 1. If a msg's logging category is disabled, drop the msg. 2. If a msg's logging level surpasses the currently set log level of that category, drop it. otherwise: 3. If filter_all is set (= "don't filter"), log the message; otherwise: 4. If no filter function is set, log the message (in libbsc/libmsc operation, a filter function is always set). If a filter function is set: 5. Ask the filter function whether to log: 5.1 If no IMSI filter is set, drop the message. (!) 5.2 If an IMSI filter is set and the ctx has a different subscriber, drop the message. 5.3 If an IMSI filter is set and it *is* the subscriber, log the message. The result is that in essence, we don't ever see any logging unless we say 'logging filter all 1'. And then, if filter_all is set, the IMSI filter has no further effect. To see logging for a specific IMSI, we set 'logging filter all 0' and set the IMSI filter to the subscriber. In that situation, all logging will cease except for those matching the selected IMSI (assuming that the filter context is always set correctly). Any logging for this IMSI that would be more detailed than the given category's global logging level is still dropped, and parts of the code where the subscriber ctx is not set yet also shows no logging. One could call it a prohibitive logging paradigm. I had a hard time understanding the UI for it: makes sense only when reading the code. My logging vision would be the other way around, more of a logging "lifter". In a general logging landscape, I would like to flag certain subscribers (plural) to stand out from this landscape with a more detailed logging level. For example, I set all categories to level ERROR, but on top allow all MM, RSL and RR logging on INFO level; but for subscribers 1234 and 5678 I also want to see all DEBUG level logs across all (or specifically selected) categories. It would look like this: 1. If there is a logging_lifter function: 1.1 If any items are flagged for more detailed logging, ask the lifter: 1.2 If the logging context is set to a subscriber, and this subscriber is flagged for more detailed logging, log the message; see also [3]. 2. If a msg's logging level is within the currently set general log level of that category, log the message. 3. Otherwise, drop the message. This way the general logging landscape remains freely configurable while certain objects' logging can be made more verbose. [3] A problem with 1.2 is that we would always see all categories' logging in all detail for that subscriber. We could a) set a full category mask per subscriber for complete logging freedom; Instead I'd go for: b) define one global "raised logging" category mask to lift flagged subscribers to, and for each subscriber simply have a boolean flag set to true to make them log on the raised logging levels -- but what about several logging targets? see [4]. [4] So far so good, but there is still this clumsiness in my plan: there can be any number of logging targets. Even if I'd like to highlight subscriber 1234 on my VTY, I don't necessarily want stderr and other VTYs to raise logging for 1234 as well. So if we flagged raised logging in a subscriber struct, we'd basically make it affect all logging targets in the same way. In the current code, I can open N VTY telnets and on each of them show only logging for a selected IMSI, because all logging flags are saved for each logging target. But I *can't* lift more than one subscriber instance to raised logging on *the same* log output, because for each target there is only one IMSI; and I *can't* combine detailed logging of a given IMSI with a general background of normal logging on the same log output, because I have to filter all logging away before I can allow a specific IMSI ('logging filter all 0'). The easiest way to allow multiple subscribers with raised logging on the same log target is to store the "raise-logging" flag with the subscriber instance, but to keep the log targets separate, I would instead have in struct log_target an llist of void* for each filter_data where we can point to N instances we'd like to flag for raised logging. Then, if the current ctx[] matches any of those, use the raised logging levels. (Expecting the list to remain short) This can be filter_fn implementation specific: the filter_data can be used to point at the first llist_head instead of just one subscriber. [5] There's another interesting logging topic: FSM instances. We have the osmo_fsm_inst feature where we can set all logging emitted by an FSM instance to a certain logging level. One "problem" with this is that the entire FSM logs on the same level, and we can only raise or lower all of these messages as one. The implementation is: remember a logging category and a logging level with the FSM instance, and log all messages from the FSM on this category and level. The state transitions and events logged from fsm.c are logged on this logging level. Because I wanted to specifically mark some logging as LOGL_ERROR, I've already broken up that idea by adding the LOGPFSML() macro. It allows passing an explicit logging level instead of using the FSM instance's. I like to think of it like this: the FSM instance's logging level tells the fsm.c code on which level to log state transitions and events (like Debug). The logging I write in my FSM implementation that I want to stand out from the state transitions (read: logging that's more than Debug) should be given more specific logging levels, like any other code we write. We could actually make LOGPFSML() use MAX(fsm_inst.log_level, log_level_arg) so that changing an FSM instance's log level raises all log messaging. One could now think, if I want raised logging for a given subscriber, I could set its FSM instances' logging level so that it prints more logging. But, again this implies the clumsiness like in [4]: the raised logging would be global across all logging targets. In this case, there's no easy way to make the feature log target specific, and neither do we need to... FSM instance specific logging levels, while sounding very nice at first, are a non-feature when taking multiple logging targets into account. The simpler way to show FSM logging for a specific subscriber is to use above suggested features: flag the subscriber for raised logging on a speicific log target and set the raised logging level for DVLR to Debug, relying on the logging ctx to be set correctly when the subscriber's FSMs are active [6]. No need to adjust an FSM instance's logging level individually. So, the log level could also be stored in the osmo_fsm definition instead of each separate osmo_fsm_inst. [6] Setting the log context needs to generally happen in these situations: - message received (e.g. from the MS or HLR) - timer callback called (e.g. state timeout, SMS queue) Particularly for timeouts on FSM instances' states this is a bit tricky. If the fsm.c code triggers the timeout, there isn't a general hook to set the log context to the FSM's subscriber first. The FSM instances that have timeouts set need to also set a specific timer_cb to update the log context and repeat the timeout logging "Timeout of T123" that comes from fsm.c before timer_cb() is called. (That means the timeout logging may be issued twice in some situations, once by fsm.c and once by the FSM implementation's timer_cb after setting the log context to make sure raised logging includes it.) Maybe we can add a pre_timer_cb to osmo_fsm, or teach osmo_fsm to set a specific log context whenever it logs things? Probably not that important. [7] In the VTY, my plan would look like this: logging = e:RSL,RR,n:MM,CC ! replace all levels logging + n:PAG ! set some more logging raised = d:MM,i:CC ! applies to flagged logging contexts logging raised + d:PAG,NM logging raise subscriber (imsi|msisdn|...) 1234 ... logging raise subscriber (imsi|msisdn|...) 1234 not For setting the logging levels, I would like to introduce letters f, e, n, i, d for the log levels (Fatal, Error, Notice, Info, Debug) instead of the level numbers that are "hidden" in logging.h, plus o for Off to disable categories. I would prefer the format: [l:]CAT[,[l:]CAT[,...]] so that a level is followed by N categories to be on this level, possibly followed by another level and another categories list. (i.e. from the current format, swap meaning of ',' and ':', reverse the current [,] order to [:] and carry the level over to following categories.) I would also add the 'all' keyword in the logging category parsing: logging = n:all,i:MM,CC,PAG which would put all levels on Notice, except MM, CC and PAG on Info. To avoid confusion with the old 'logging categories' format, I would like to go for '=' and '+' commands (yes, the VTY can handle these). The old 'logging categories' might even co-exist. 'logging = ...' and 'logging + ...' should imply 'logging enable'. The 'logging raised *' sets the logging levels used for flagged subscribers; they should default to d:all, i.e. everything on debug level. 'logging raise *' flags a given subscriber (or what else we want to add later). To remove a raise flag from a subscriber, 'logging no raise *' makes sense, but it is often useful to just recall a previous VTY command and append a keyword, so I'd make it 'logging raise subscriber imsi 1234 not' for convenience. The current 'logging level ' can remain as-is; I would add a 'logging raised level' command. I would completely drop the 'logging filter' commands. But it would still be useful on a VTY to mute logging to get a usable prompt without the need to discard the log target: logging (mute|off) logging (unmute|on) These are shorter and more intuitive than 'logging filter all (0|1)'. The current 'logging filter all everything' command is ambiguous. It sounds like it would aggressively turn on every last logging message. But instead it does the opposite: it can only add a general *restriction* on the logging level for all categories of a log target. Any category that is not enabled will still not log anything. Also, even if a log target has a more detailed level set, the log target's global logging level potentially prevents the detailed logging. So the command should sound more like 'logging restrict all to LEVEL'. It needs a rename, but IMHO we could also just drop it. Turning on every last log message could be done by 'logging = d:all'. Restrictions can be imposed by 'logging + e:RSL,MM,...'. Going back to a previous complex logging setup can be achieved by recalling the previous 'logging = ' commandline. The VTY could print such a paste-back-able line showing the current logging levels, so that going back is just a copy-paste on the VTY. So much for the unicorn's dream. For now, I'll start off with tidying up the things under [1] above. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Fri Feb 17 15:11:56 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 17 Feb 2017 16:11:56 +0100 Subject: logging filters, RFC In-Reply-To: <20170217150010.GA2235@my.box> References: <20170217150010.GA2235@my.box> Message-ID: A little side note to that: https://projects.osmocom.org/issues/71 and corresponding discussion in https://gerrit.osmocom.org/#/c/1582/ -- Max Suraev 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 Director: Harald Welte From msuraev at sysmocom.de Fri Feb 17 17:50:40 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 17 Feb 2017 18:50:40 +0100 Subject: the near and further future of osmo-nitb In-Reply-To: <20170214215114.GA14929@my.box> References: <20170214164001.GA1485@ass40.sysmocom.de> <20170214174004.dfdgvhbi44dgowpo@nataraja> <20170214215114.GA14929@my.box> Message-ID: <7392d1b3-292c-0866-51cf-1e665301afe7@sysmocom.de> Technically it can be separated already. I mean we can use external SMSC like https://github.com/RestComm/smscgateway/ via SMPP and in this case it's pure MSC. On 14.02.2017 22:51, Neels Hofmeyr wrote: > I'd be ok with calling it MSC before the SMSC is separated -- Max Suraev 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 Director: Harald Welte From nhofmeyr at sysmocom.de Sun Feb 19 02:15:34 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 19 Feb 2017 03:15:34 +0100 Subject: sanitizer build successful Message-ID: <20170219021534.GA17274@my.box> In case you haven't noticed ... now that the osmo-pcu issue is finally resolved, we've got a successful sanitizer build on Jenkins! :D https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ Still no --enable-sanitize configure switches though, except in libosmocore. To reiterate, I'll gladly do the jenkins config if someone else takes on the --enable-sanitize in our builds, e.g. like in https://gerrit.osmocom.org/974 . ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From sebastian.stumpf87 at googlemail.com Sun Feb 19 17:16:01 2017 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Sun, 19 Feb 2017 18:16:01 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: <20170212230920.epvdsj7jwxzta23w@nataraja> References: <20170212230920.epvdsj7jwxzta23w@nataraja> Message-ID: Hi Harald, thanks for the detailed response. > I also see that the RACH requesets all are sent with a bogus frame > number: 42. This will not work. The RACH request needs to be sent with > the current frame number at the time being. I fixed that and calculate the proper rach fn like in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151 . > Also, RACH retransmissions > are happening way too quick. Calculating a proper frame number didn't fix the fast retransmissions. They are caused by sending the channel request over the virtual um immediately after getting the rach-request from layer23. Thus also the rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its already transmitted" and will generate the next rach-request for my layer 1. > I think one can do without on the MS side, but then the BTS must > basically queue the incoming frames until the respective frame number > indicated in the frame matches the current frame number. I think to fix the problem with the quick retransmission , I need some type of scheduling. Because if I queue the incoming uplink-msgs in the bts-virtual-layer1 instead, I don't know when they are processed on the ms side and thus don't know when to send the rach-confirm to layer23... My idea for a simple scheduler would be: -- no timing and timer interrupts on ms side, but just set the current fn in the ms state each time we receive a message on downlink to the fn of the received message, which is accessible in the gsmtap header. -- queue the outgoing uplink messages with their confirm callback to l2 and process all that with a smaller fn than the current fn in the scheduling function. -- calling the scheduling function each time we receive a msg on downlink (so I do not need to handle timer interrupts) I hope that will be sufficent and try it out tomorrow. I am a bit afraid of trouble caused by the frame number skipping values with the upper incrementation logic. With kind regards, Sebastian Stumpf -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Feb 20 13:01:01 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 20 Feb 2017 14:01:01 +0100 Subject: sysmo-usim-tool / pySim Message-ID: <20170220130101.iif72sgaotping6m@nataraja> Hi Sylvain + list, we have developed a sysmoUSIM-SJS1 specific python tool for sim card (re)configuration called sysmo-usim-tool. It is complementary of pySim-prog, in that it is *not* about IMSI/ICCID/MSISDN programming, but more about the features specific to sysmoUSIM-SJS1, such as enabling/disabling the USIM application (and getting a classic SIM), selecting the A3/A8 algorithm (XOR, COMP128vX, MILENAGE), etc. Philipp has committed his code to pmaier/sim branch of pysim-prog. The question is now whether you want this in the same repository or a separate one. The two code-bases share nothing in tems of their implementation. They are completely separate. So it would just be convenience feature for the user not to have to check out two repositories. I'm not quite sure whether to create a new repo or to have it in pySim-prog. Do you (Sylvain, but also generally people on the list) have any preference? The license currently states unintentionally AGPLv3, we'll change that to GPLv2-or-later before a possible merge. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Mon Feb 20 13:27:03 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 20 Feb 2017 14:27:03 +0100 Subject: sysmo-usim-tool / pySim In-Reply-To: <20170220130101.iif72sgaotping6m@nataraja> References: <20170220130101.iif72sgaotping6m@nataraja> Message-ID: Hi, > The question is now whether you want this in the same repository or a > separate one. The two code-bases share nothing in tems of their > implementation. They are completely separate. So it would just be > convenience feature for the user not to have to check out two > repositories. I'm not quite sure whether to create a new repo or to > have it in pySim-prog. Do you (Sylvain, but also generally people on > the list) have any preference? I don't really mind either way. It's a bit of a shame that they're completely separate TBH since some of the functionality is duplicated (if you look at Card and Simcard classes, those have close equivalen in the pySim code). Would have been better if the helper classes of pySim had been extended to support this IMHO (like different CLA and things like that). > The license currently states unintentionally AGPLv3, we'll change that > to GPLv2-or-later before a possible merge. Yeah, keeping to the one-repo-one-license is probably best. Cheers, Sylvain From laforge at gnumonks.org Mon Feb 20 13:58:38 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 20 Feb 2017 14:58:38 +0100 Subject: sysmo-usim-tool / pySim In-Reply-To: References: <20170220130101.iif72sgaotping6m@nataraja> Message-ID: <20170220135838.hentxvy67zidtn34@nataraja> Hi Sylvain, On Mon, Feb 20, 2017 at 02:27:03PM +0100, Sylvain Munaut wrote: > > The question is now whether you want this in the same repository or a > > separate one. The two code-bases share nothing in tems of their > > implementation. They are completely separate. So it would just be > > convenience feature for the user not to have to check out two > > repositories. I'm not quite sure whether to create a new repo or to > > have it in pySim-prog. Do you (Sylvain, but also generally people on > > the list) have any preference? > > I don't really mind either way. ok, thanks for your feedback. Given that they don't share anything in common, it might actually be better to use a separate repository after all. This way people are less confused about which part of the code is actually used in case they want to read/understand/improve the code. > It's a bit of a shame that they're completely separate TBH since some > of the functionality is duplicated (if you look at Card and Simcard > classes, those have close equivalen in the pySim code). Would have > been better if the helper classes of pySim had been extended to > support this IMHO (like different CLA and things like that). Well, I agree it is a shame, but to be honest I have struggled quite a lot with trying to use pySim provided base classes in the past and found it extremely difficult to use. One issue is the many different type convesions between binary / ascii-hex. Whenever I wanted to call some function, I was calling it with the wrong type, as they all seem to have different assumptions. It might just be me (I'm not a python guy!) but it took me many cycles of trial+error when I wrote the last set of patches for it. The other 'problem' is that due to the many different supported cards (and probably noone still having all of them available for testing) it is virtually impossible to touch the code without cretaing regressions. For the past few years we either have code that works for sysmoUSIM-SJS1, or code for older cards, but not for both (due to some assumption about the FCI/SW see 8c1b33c439fef423c3536e9243035722c52aba4c with nobody finding sufficient time and/or interest to resolve it and test it on all cards. So given that history, I asked Philipp to do something separate to avoid falling into those traps again. Yes, reinventing the wheel sucks, but then, we're not talking about months of work here.. The advantage of pySIm-prog is that it supports serial card readers just as well as PC/SC readers. However, the serial readers seem to have very little significance these days, so in new software I wouldn't bother anymore to support them. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Mon Feb 20 17:03:30 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 20 Feb 2017 09:03:30 -0800 Subject: sysmo-usim-tool / pySim In-Reply-To: <20170220135838.hentxvy67zidtn34@nataraja> References: <20170220130101.iif72sgaotping6m@nataraja> <20170220135838.hentxvy67zidtn34@nataraja> Message-ID: Hi Harald, On Feb 20, 2017 06:01, "Harald Welte" wrote: The advantage of pySIm-prog is that it supports serial card readers just as well as PC/SC readers. However, the serial readers seem to have very little significance these days, so in new software I wouldn't bother anymore to support them. Why do you think serial readers are not used these days? They are coming free of charge with many programmable SIM cards and eg we always use them and don't even have a PC/SC one since we never needed one. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Mon Feb 20 17:06:39 2017 From: keith at rhizomatica.org (Keith) Date: Mon, 20 Feb 2017 18:06:39 +0100 Subject: Handover and load balancing on SysmoBTS 2050 Message-ID: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> Hi list, Hi all. This is quite Rhizomatica, or at least litecel 2050 specific, please excuse me for that. I also don't know, maybe it applies to other use cases. Rhizomatica has one community where an attempt was made to increase coverage at the same time as capacity, by installing two 2050s with a somewhat overlapping coverage area. We have currently plans to do the same in other places. The goal of this email is to try to establish the work needed to be done in order to fix what I outline below, I may just be lacking knowledge in some cases, in other It seems we need to implement some things. I have grabbed fairwaves' meas_json and meas_web and modified a little to give me a visualisation of the neighbour meas reports. So my first doubt is about idle cell reselection on the part of the MS. It doesn't seem to be operating quite as I would imagine it should and I am wondering is there any parameter that might make a difference, such as cell_identity? Is cell reselection hysteresis/offset relevant when handover is disabled? These parameters are not described in the manual. If I understood them I could update that. In the meantime, we seem to be getting reports from users that "the signal is weak" near what I might call the secondary BTS. At the same time, user reports are not terribly reliable. However what seems to be happening is that the MS is camped on the primary BTS, subsequently they have moved away so their handset is showing less 'bars'. I'm sometimes seeing TCH in use on the primary BTS that are showing neighbour measurements from the secondary that are more favourable. Of course, I am often seeing messages such as: handover_decision.c:203 (bts=3,trx=0,ts=2): Cell on ARFCN 242 is better: Skipping, Handover disabled Obviously, this makes sense, and I am not sure why historically we have handover disabled, I presume it is issues with rtp, although we are using the rtp_proxy. I don't have two BTS so I can't test locally here. Could anybody comment on the state of that? I am assuming that there is no way we can do load balancing unless we first have handover enabled, at the same time it is unclear to me if it will even work with handover. I believe this is called "Traffic Handover" Is this already implemented in the BSC? As in, can the BSC assign a channel on another ARFCN to the MS if the current ARFCN (the one the MS makes the access request on) has no TCH available? I also have a doubt about operation with a Litecel/2050. Obviously you don't really want rescue handover operating between the two BTS that are present in the Litecel as it is the same antenna, and this shouldn't happen anyway as the signal levels should never be sufficiently different, but we do want load balancing handover. I do see "no resources available" log messages, (especially related to the BROKEN channels issue) when one BTS in a litecel has no more capacity but the other does, so it would seem that the BSC is not managing this. Is that correct? Would it be correct to assume that maybe some handover rules are required that would specify: Handover from BTS 0 to BTS 3 but not from BTS 0 to BTS 1? Finally, I have a doubt about the rtp proxy mode. Was it ever discussed to implement SIP Mobility aka re-Invite in order to be able to do BTS-MGW rtp and also handover? This would seem to me to be a good thing to have? k/ From keith at rhizomatica.org Mon Feb 20 17:34:03 2017 From: keith at rhizomatica.org (Keith) Date: Mon, 20 Feb 2017 18:34:03 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> Message-ID: On 20/02/2017 18:06, Keith wrote: > Is cell reselection hysteresis/offset relevant when > handover is disabled? > I should add I understand in GSM that cell reselection hysteresis apply when changing location area, and in this case, we are not changing. From laforge at gnumonks.org Mon Feb 20 17:50:43 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 20 Feb 2017 18:50:43 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> Message-ID: <20170220175043.oee3537taqyoves3@nataraja> Hi Keith, we have had hand-over between BTSs working back in 2009, it is for sure not a new feature at all. This was working long before Abis/IP was implemented, and yes, it is also working with Abis/IP. I don't know why Rhizomatica has it disabled. Maybe you were seeing a particular bug or incompatibility at the time? Regarding cell reselection offset / cell reselection hysteresis: We generally try to not document parameters which are taken 1:1 from the specifications, as there are plenty of textbooks on the subject of GSM network planning and optimization. From our point of view we just provide the operator a way to specify a parameter which is then broadcast to the mobile phones. It is nothing that OpenBSC/OsmoBTS act upon or treat in any way. You simply specify what you want and we pass it through. And yes, the "cell reselection" parameters effect excatly cell-reselection in idle mode. This is completely unrelated to hand-over which happens in dedicated mode. Whether you have hand-over enabled or how it is configured thus has no influence on cell reselection and its parameters. I don't understand your question regarding SIP or re-invite. If you're using the rtp_proxy, any hand-overs are completely transparent to MNCC. You don't even have a way to know a hand-over has happened behind the MNCC interface. The proper solution for the two BTSs inside a LiteCell or sysmoBTS 2050 is to run them as one BTS with two TRX. This way you gain one timeslot, and you avoid any discussion about unwanted hand-over betwen those two transceivers. At sysmocom we never implemented support for this, as there was and still is insufficient customer interest in the sysmoBTS 2050 to rectify spending any resources on developing this. What would be needed is roughly: * OsmoBTS which can run on a single TRX without assuming that that TRX is C0 and transmits a BCCH/CCCH. * An OML proxy that terminates the OML connection to the BSC and which routes messages based on their TRX number to either of the two (or "N") instances of OsmoBTS. At that point, one board in the 2050 runs OsmoBTS for C0, and the OML proxy. The other board runs OsmoBTS for C1. Both OsmoBTS connect to the OML proxy on C0, and the OML proxy establishes OML to the BSC. Each OsmoBTS establishes a separate RSL connection (each from its own IP address) towards the BSC. On the BSC side we handle this since 2010 or 2011, as this is also how a multi-trx setup with nanoBTSs looks like on the Abis side. All other OsmoBTS-supported Multi-TRX hardware runs all transceivers with a single OsmoBTS instance, so they don't need the kind of support required for the 2050. Hence, we are back to step one: Somebody would have to spend some time on the required code. I'd be more than happy to review and/or merge any related changes. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Tue Feb 21 14:40:54 2017 From: keith at rhizomatica.org (Keith) Date: Tue, 21 Feb 2017 15:40:54 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <20170220175043.oee3537taqyoves3@nataraja> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> Message-ID: <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> Hi Harald. I appreciate the clarification on things that are pure GSM spec, I know where to look now. :) I tried activating handover this morning very briefly on that site and it started a ping-pong game between the two bts/trx in the LiteCell. Increasing handover power budget hysteresis a lot, >=15dB of course tames that, but surprisingly does not eliminate it. I thought to increase then the neighbour averaging, but 10 is the maximum. It seems it would be difficult to tune that for permanent operation. Notwithstanding what you said about the solution for the LiteCell, which is noted, it still suggests to me some kind of simpler solution such as a ruleset about which BTSs to use for rescue HO. On the question about SIP re-invite, I am talking about operating without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP streams at the same time as handover. From what I've read, this is quite feasable, as part of the SIP spec. I think this is already considered as part of the development of the osmo-sip-connector, which is a project I really want to see moving forward and hope to find time to contribute to over the next few months. However, and again notwithstanding your suggesting for how to resolve the LiteCell issue of the two BTS/TRX, I understand that load balancing (aka traffic handover?) is not implemented in OpenBSC. I am certainly seeing this, for example in the case where all available TCH are in use, a call cannot be established, even though another BTS has resources available. Is this not something that is desirable to implement? Regardless of whether it were a LiteCell, or two or more other types of BTS such as SysmoBTS 1020? Or what is the intended strategy for increasing channel capacity at a site? From laforge at gnumonks.org Tue Feb 21 15:14:05 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Feb 2017 16:14:05 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> Message-ID: <20170221151405.rsmrcrmwdc4etjjg@nataraja> Hi Keith, On Tue, Feb 21, 2017 at 03:40:54PM +0100, Keith wrote: > I tried activating handover this morning very briefly on that site and > it started a ping-pong game between the two bts/trx in the LiteCell. this is expected, as per GSM architecture such as system should operate as two TRXs of one BTS and not as two BTSs. No "normal" operator would put two BTSs with same transmit power and same coverage in place. > Increasing handover power budget hysteresis a lot, >=15dB of course > tames that, but surprisingly does not eliminate it. This might relate to the fact that the power control loop algorithm is very simplistic and has a tendency to oscillate. It has been a long-time TODO item to avoid the algorithm in the PHY and use a more dampened algorithm with a PID or kalman filter in OsmoBTS. But then, there are so many open TODO items for so many years :/ > However, and again notwithstanding your suggesting for how to resolve > the LiteCell issue of the two BTS/TRX, I understand that load balancing > (aka traffic handover?) is not implemented in OpenBSC. > I am certainly seeing this, for example in the case where all available > TCH are in use, a call cannot be established, even though another BTS > has resources available. Is this not something that is desirable to > implement? > Regardless of whether it were a LiteCell, or two or more other types of > BTS such as SysmoBTS 1020? Just a quick response: jolly implemented "traffic handover" aka "load balancing" 3 years ago as part of a branch (I believe for a customer), but unfortunately this never was merged back to master. Meanwhile, we already have all the code for execution of hand-overs in place. We also have dynamic timeslots in place. So the "mechanics" should all be there to add the two missing features from those old branches: a) de-fragmenting of channels (i.e. merging two separate TCH/H into one timeslot, so the other timeslot can be switched to TCH/F or PDCH on demand b) load/traffic based hand-over see jolly/new_handover and jolly/dyn_pdch branches. > Or what is the intended strategy for increasing channel capacity at a site? The general strategy I would normally assume is to * switch to half-rate channels with AMR whenever possible * use dynamic channel switching to switch between TCH/H (default) and TCH/F (if neded) * use BTSs with more TRX. Even high-end Ericsson equipment supporting up to 3 sectors of 4 TRX each (12 TRX) is actaully available surprisingly inexpensive these days. We've recently done some improvements in Ericsson RBS2000 support. Even PCU integration for GRPS support is coming up. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sipos.csaba at kvk.uni-obuda.hu Tue Feb 21 21:08:17 2017 From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba) Date: Tue, 21 Feb 2017 22:08:17 +0100 (CET) Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <20170221151405.rsmrcrmwdc4etjjg@nataraja> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <20170221151405.rsmrcrmwdc4etjjg@nataraja> Message-ID: <611444110.1641814.1487711297711.JavaMail.zimbra@kvk.uni-obuda.hu> Dear Harald, I noticed this part: > Even PCU integration for GRPS support is coming up. Can I ask how specific will that part be to the RBS2000? I have Nokia Ultra and MetroSite sets (both with EDGE capability), the EDAP part is accessbile, but I was not able to find a lot of details about the Nokia Abis implementation, especially of the PCU part. Thanks! Csaba ----- Eredeti ?zenet ----- Felad?: "Harald Welte" C?mzett: "Keith" M?solatot kap: "OpenBSC Mailing List" Elk?ld?tt ?zenetek: Kedd, 2017. Febru?r 21. 16:14:05 T?rgy: Re: Handover and load balancing on SysmoBTS 2050 Hi Keith, On Tue, Feb 21, 2017 at 03:40:54PM +0100, Keith wrote: > I tried activating handover this morning very briefly on that site and > it started a ping-pong game between the two bts/trx in the LiteCell. this is expected, as per GSM architecture such as system should operate as two TRXs of one BTS and not as two BTSs. No "normal" operator would put two BTSs with same transmit power and same coverage in place. > Increasing handover power budget hysteresis a lot, >=15dB of course > tames that, but surprisingly does not eliminate it. This might relate to the fact that the power control loop algorithm is very simplistic and has a tendency to oscillate. It has been a long-time TODO item to avoid the algorithm in the PHY and use a more dampened algorithm with a PID or kalman filter in OsmoBTS. But then, there are so many open TODO items for so many years :/ > However, and again notwithstanding your suggesting for how to resolve > the LiteCell issue of the two BTS/TRX, I understand that load balancing > (aka traffic handover?) is not implemented in OpenBSC. > I am certainly seeing this, for example in the case where all available > TCH are in use, a call cannot be established, even though another BTS > has resources available. Is this not something that is desirable to > implement? > Regardless of whether it were a LiteCell, or two or more other types of > BTS such as SysmoBTS 1020? Just a quick response: jolly implemented "traffic handover" aka "load balancing" 3 years ago as part of a branch (I believe for a customer), but unfortunately this never was merged back to master. Meanwhile, we already have all the code for execution of hand-overs in place. We also have dynamic timeslots in place. So the "mechanics" should all be there to add the two missing features from those old branches: a) de-fragmenting of channels (i.e. merging two separate TCH/H into one timeslot, so the other timeslot can be switched to TCH/F or PDCH on demand b) load/traffic based hand-over see jolly/new_handover and jolly/dyn_pdch branches. > Or what is the intended strategy for increasing channel capacity at a site? The general strategy I would normally assume is to * switch to half-rate channels with AMR whenever possible * use dynamic channel switching to switch between TCH/H (default) and TCH/F (if neded) * use BTSs with more TRX. Even high-end Ericsson equipment supporting up to 3 sectors of 4 TRX each (12 TRX) is actaully available surprisingly inexpensive these days. We've recently done some improvements in Ericsson RBS2000 support. Even PCU integration for GRPS support is coming up. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Wed Feb 22 03:56:51 2017 From: holger at freyther.de (Holger Freyther) Date: Wed, 22 Feb 2017 10:56:51 +0700 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <20170220175043.oee3537taqyoves3@nataraja> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> Message-ID: <061976B0-E4BC-40FC-898E-CAAFBF128E5E@freyther.de> > On 21 Feb 2017, at 00:50, Harald Welte wrote: > > Hi Keith, Hi! > we have had hand-over between BTSs working back in 2009, it is for sure > not a new feature at all. This was working long before Abis/IP was > implemented, and yes, it is also working with Abis/IP. I don't know why > Rhizomatica has it disabled. Maybe you were seeing a particular bug or > incompatibility at the time? I don't remember the details but we had several issues with it: * Crashing or no audio (e.g. only used at XC3) * Delay increases by number of handovers Since then we probably fixed the crash, I had removed the timestamp adjustment code. I still need to study the 3gpp AoIP specification but these days I wonder what should be done with the audio stream of the new BTS and I think we should generate a new SSRC, seq and timestamp. This should trigger the start of a new probation period as of Annex A. But it is a theoretical question (or for E1->RTP systems) right now. holger From laforge at gnumonks.org Wed Feb 22 06:07:38 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 22 Feb 2017 07:07:38 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <611444110.1641814.1487711297711.JavaMail.zimbra@kvk.uni-obuda.hu> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <20170221151405.rsmrcrmwdc4etjjg@nataraja> <611444110.1641814.1487711297711.JavaMail.zimbra@kvk.uni-obuda.hu> Message-ID: <20170222060738.h4oednksvh3lriuv@nataraja> Hi Sipos, On Tue, Feb 21, 2017 at 10:08:17PM +0100, Sipos Csaba wrote: > > Even PCU integration for GRPS support is coming up. > > Can I ask how specific will that part be to the RBS2000? *very* specific, as all related protocols (Ericsson L2TP, P-GSL, TFP, ericsson modified RSL) are Ericsson specific. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Wed Feb 22 09:02:17 2017 From: holger at freyther.de (Holger Freyther) Date: Wed, 22 Feb 2017 16:02:17 +0700 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> Message-ID: <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> > On 21 Feb 2017, at 21:40, Keith wrote: Hi Keith, > On the question about SIP re-invite, I am talking about operating > without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP > streams at the same time as handover. From what I've read, this is quite > feasable, as part of the SIP spec. > I think this is already considered as part of the development of the > osmo-sip-connector, which is a project I really want to see moving > forward and hope to find time to contribute to over the next few months. yes for the osmo-sip-connector I have ignored the topic of handover. In general I try to see how long I get away with not having to touch the UDP/RTP streams. In case of hand-over the new BTS might send from a different src IP, src Port and will most likely have a new SSRC, timestamp seqno. It is a bit of a question of how "your" PBX will handle it. I can see a couple of outcomes. a.) It has some support for "NAT" handling and will just use the new stream and return packages to the new src IP/src port. It might go back and forth but at some point the old bts will stop sending things. b.) It will accept the new stream but will try to send to the old BTS. The we would have one-way audio. c.) It will reject it as it is a unknown src ip/port. I think for b.) and c.) we will require SIP re-invite but also need to look at the AoIP spec to see if they say how to handle this scenario. But that depends on how the PBX handles this as well. So it means for handover we always need to look at BSC/SIP+PBX and how it is handling SDP/RTP. cheers holger PS: Do you have a docker container for your FreeSWITCH setup and maybe two numbers one to play audio and another to record the audio? From giselle2207 at gmail.com Wed Feb 22 09:00:48 2017 From: giselle2207 at gmail.com (Giselle Gonzalez lopez) Date: Wed, 22 Feb 2017 10:00:48 +0100 Subject: Ki and OPC values change when programming MCC and MNC Message-ID: Hello, We have already contacted our SIM cards provider (sysmocom), and they have referred us towards this Mailing List. We have purchased sysmoUSIM-SJS1 cards and we are having the following problem when trying to program them: We want to change the MCC and MNC values to the ones of our OpenAirInterface LTE system, and Ki and OPC of the SIM card are changing despite we are not intending for that to happen. The main issue with this behavior is that as we have two sets of Ki and OPC values, when we are going to register the user in the LTE database, we don't know for sure which set of parameters we are supposed to introduce. Here on I'll describe the configuration we are using and the commands introduced when programming the SIM cards: As programming software we are using PySIM. The default parameters of the SIM we are programming are: ADM: 20168462 ICCID: 8988211000000099120 Ki: 5B868E2B30C61190ABEFBA1CA6F6D56F OPC: B3425076F23BA6054557FA359B4F9C0C The parameters we are meaning to program are: MCC: 001 MNC: 01 IMSI: 001010000009912 The command we are using to program in the SIM card is: ./pySim-prog.py -p 0 -a 20168462 -x 001 -y 01 -t sysmoUSIM-SJS1 -i 001010000009912 -s 8988211000000099120 And after programming the card, we are getting this: [image: Im?genes integradas 1] Do you what's the reason why this is happening? Thank you very much for your time Best regards, Giselle Glez -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cambio KI-OPC.png Type: image/png Size: 158383 bytes Desc: not available URL: From alexander.chemeris at gmail.com Wed Feb 22 09:32:31 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 22 Feb 2017 01:32:31 -0800 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> Message-ID: Hi Holger, On Feb 22, 2017 1:02 AM, "Holger Freyther" wrote: > On 21 Feb 2017, at 21:40, Keith wrote: Hi Keith, > On the question about SIP re-invite, I am talking about operating > without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP > streams at the same time as handover. From what I've read, this is quite > feasable, as part of the SIP spec. > I think this is already considered as part of the development of the > osmo-sip-connector, which is a project I really want to see moving > forward and hope to find time to contribute to over the next few months. yes for the osmo-sip-connector I have ignored the topic of handover. In general I try to see how long I get away with not having to touch the UDP/RTP streams. You don't really need to touch RTP stream if you do re-invite. In case of hand-over the new BTS might send from a different src IP, src Port and will most likely have a new SSRC, timestamp seqno. It is a bit of a question of how "your" PBX will handle it. I can see a couple of outcomes. a.) It has some support for "NAT" handling and will just use the new stream and return packages to the new src IP/src port. It might go back and forth but at some point the old bts will stop sending things. b.) It will accept the new stream but will try to send to the old BTS. The we would have one-way audio. c.) It will reject it as it is a unknown src ip/port. I think for b.) and c.) we will require SIP re-invite but also need to look at the AoIP spec to see if they say how to handle this scenario. But that depends on how the PBX handles this as well. So it means for handover we always need to look at BSC/SIP+PBX and how it is handling SDP/RTP. If I remember correctly, (b) is what's going to happen if a client is following vanilla SIP spec, because changing RTP IP/port requires updating SDP which is done with a re-invite. (a) is a hack supported by many SIP clients, but it may depend not only on PBX, but also on its configuration parameters, on SBCs used on a network, etc So if you want to be nice to the other party and follow the spec, it's better to do re-invite :) Btw, re-invite will need to be implemented anyway if you want to support call hold. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Feb 22 09:19:26 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 22 Feb 2017 10:19:26 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> Message-ID: <20170222091926.cobz5dtquewlghjv@nataraja> Hi Holger, On Wed, Feb 22, 2017 at 04:02:17PM +0700, Holger Freyther wrote: > I think for b.) and c.) we will require SIP re-invite but also need > to look at the AoIP spec to see if they say how to handle this > scenario. I "think" the assumption in AoIP is that the RTP "originates" from the BSC and not from the BTS. As such, there is no change to the RTP stream parameters in any intra-BSC hand-over. The reasoning/rationale would be simple: There are still virtually no Abis/IP based BTS in the field so far, and most commercial systems (even RBS6000 from Ericsson e.g.) still uses E1/T1 for the Abis. That Abis might be adapted over some propriatary L2TP-over-IP stacking for the back-haul. So basically except the Osmocom implementations, and ip.access, I still don't think there are many native IP based Abis systems out there, and hence this is considered an implementation detail of the vendor. The A interface orignates at the BSC, and everything "below" the BSC is opaque. But feel free to check yourself, I might remember it wrong. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Feb 22 13:30:01 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 22 Feb 2017 14:30:01 +0100 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: References: Message-ID: Hi, > Do you what's the reason why this is happening? Because it's programmed like that ... Most cards you have to reprogram all the parameters at once, you can't change just one. Not sure about the sysmoUSIM-SJS1 in particulat but since pysim has to support different models, it has this restriction. So if you don't specify a Ki / OPC on the command line, they get picked randomly. Cheers, Sylvain From nhofmeyr at sysmocom.de Wed Feb 22 14:21:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 22 Feb 2017 15:21:11 +0100 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: References: Message-ID: <20170222142111.GA1653@my.box> Dear Giselle Glez, I hope that someone else will be able to help you soon; so far I would like to ask you to adhere to basic netiquette and *never* post image screenshots of text to this mailing list. Next time, paste the actual text into the email. Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Feb 22 14:58:53 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 22 Feb 2017 15:58:53 +0100 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: References: Message-ID: <20170222145853.GB3433@my.box> On Wed, Feb 22, 2017 at 02:30:01PM +0100, Sylvain Munaut wrote: > Hi, > > > > Do you what's the reason why this is happening? > > Because it's programmed like that ... > > Most cards you have to reprogram all the parameters at once, you can't > change just one. Not sure about the sysmoUSIM-SJS1 in particulat but > since pysim has to support different models, it has this restriction. BTW, this restriction only really came to my awareness once I took a look at the pysim source code. I think that it could be made clearer by the command line help, and it could print an according warning like "setting random OPC". I know what you'll say, right? "Patches welcome" :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From 246tnt at gmail.com Wed Feb 22 16:06:20 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 22 Feb 2017 17:06:20 +0100 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: <20170222145853.GB3433@my.box> References: <20170222145853.GB3433@my.box> Message-ID: > BTW, this restriction only really came to my awareness once I took a look at > the pysim source code. I think that it could be made clearer by the command > line help, and it could print an according warning like "setting random OPC". > > I know what you'll say, right? "Patches welcome" :) --help will tell you defaults for Ki and OPC is to randomize ... Cheers, Sylvain From nhofmeyr at sysmocom.de Thu Feb 23 02:53:36 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 23 Feb 2017 03:53:36 +0100 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: References: <20170222145853.GB3433@my.box> Message-ID: <20170223025336.GC20493@my.box> On Wed, Feb 22, 2017 at 05:06:20PM +0100, Sylvain Munaut wrote: > --help will tell you defaults for Ki and OPC is to randomize ... Ah, indeed, I never saw that. Could also be misunderstood. IMHO it should say right at the top that you normally want to pass -k and -o when calling pysim. After all, none of the other options do that. anyway... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Thu Feb 23 08:25:56 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 23 Feb 2017 15:25:56 +0700 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: <20170223025336.GC20493@my.box> References: <20170222145853.GB3433@my.box> <20170223025336.GC20493@my.box> Message-ID: <31579AC7-F837-49F1-9EDC-C0B8D2CCC85C@freyther.de> > On 23 Feb 2017, at 09:53, Neels Hofmeyr wrote: > > On Wed, Feb 22, 2017 at 05:06:20PM +0100, Sylvain Munaut wrote: >> --help will tell you defaults for Ki and OPC is to randomize ... > > Ah, indeed, I never saw that. Could also be misunderstood. IMHO it should say > right at the top that you normally want to pass -k and -o when calling pysim. > After all, none of the other options do that. anyway... "normally".. for the batch mode as used at XC3 events the "normal" is to generate a random KI, you wouldn't want to do that by hand 4k times. :) holger From laforge at gnumonks.org Thu Feb 23 14:41:24 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 Feb 2017 15:41:24 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: References: <20170212230920.epvdsj7jwxzta23w@nataraja> Message-ID: <20170223144124.mdba7w7avdujy23g@nataraja> Hi Sebastian, On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote: > > I also see that the RACH requesets all are sent with a bogus frame > > number: 42. This will not work. The RACH request needs to be sent with > > the current frame number at the time being. > > I fixed that and calculate the proper rach fn like in > https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151 good. > > Also, RACH retransmissions are happening way too quick. > > Calculating a proper frame number didn't fix the fast retransmissions. > They are caused by sending the channel request over the virtual um > immediately after getting the rach-request from layer23. Thus also the > rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its > already transmitted" and will generate the next rach-request for my > layer 1. i see. the confirmation should probably be delayed somehow. As a quick intermediate hack you might simply add a timer. > > I think one can do without on the MS side, but then the BTS must > > basically queue the incoming frames until the respective frame number > > indicated in the frame matches the current frame number. > > I think to fix the problem with the quick retransmission , I need some type > of scheduling. Because if I queue the incoming uplink-msgs in the > bts-virtual-layer1 instead, I don't know when they are processed on the ms > side and thus don't know when to send the rach-confirm to layer23... > > My idea for a simple scheduler would be: > -- no timing and timer interrupts on ms side, but just set the current fn in > the ms state each time we receive a message on downlink to the fn of > the received message, which is accessible in the gsmtap header. yes, that makes sense. > -- queue the outgoing uplink messages with their confirm callback to l2 > and process all that with a smaller fn than the current fn in the > scheduling function. yes, but please keep in mind that the frame number is wrapping every so often, so "smaller" must consider that modulo-arithmetic, or you will (after fn wrap) have pending downlink messages for much higher fn which are not sent as the wrapped fn is now very small. > -- calling the scheduling function each time we receive a msg on downlink > (so I do not need to handle timer interrupts) yes. I think it is reasonable to not have any actual timers on the ms side and always depend on the frame numbers in the downlink messages from the BTS. After all, in the worst case you have periodic messages like the BCCH messages that can be used to update the fn. > I hope that will be sufficent and try it out tomorrow. I am a bit > afraid of trouble caused by the frame number skipping values with the > upper incrementation logic. I don't think skips are that problematic. But then, I haven't tried it ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Fri Feb 24 05:43:26 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 24 Feb 2017 06:43:26 +0100 Subject: OsmoHLR and IPA unit id Message-ID: <20170224054326.GB1368@my.box> I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. Which way shall we resolve this? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-RFC-add-the-osmo_gsup_conn-directly-to-the-lu_operat.patch Type: text/x-diff Size: 2550 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From keith at rhizomatica.org Fri Feb 24 15:42:35 2017 From: keith at rhizomatica.org (Keith) Date: Fri, 24 Feb 2017 16:42:35 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> Message-ID: <39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org> Hi Alexander, seeing as how you came in on the thread, as a side topic, you may have noticed I mentioned meas_json and meas_web in the OP. I fixed up a small thing with meas_json that was producing unparseable json in the neighbours array. I also did some stuff server side to filter for either SDCCH or TCH, although I think I would make this a clientside javascript filter option, rather than running multiple websocketd I added the neighbour levels to the displayed data. I hardcoded the ARFCNs for the site in question, but I would make that happen dynamically. I found this quite useful for monitoring in relation to analysis on this site and the would-be handover scenario. I'm wondering what to do with this work. Should I make a commit of meas_json to master? In that case I would appreciate some minor help getting the Makefile right. Maybe meas_json is not a candidate for the master branch, as it doesn't currently do anything particularly useful without the external dependencies, ie meas_web and websocketd or alternative. I can publish my work on meas_web to github. Keith. From laforge at gnumonks.org Fri Feb 24 15:53:03 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Feb 2017 16:53:03 +0100 Subject: OsmoHLR and IPA unit id In-Reply-To: <20170224054326.GB1368@my.box> References: <20170224054326.GB1368@my.box> Message-ID: <20170224155303.tuidxovd4qbzp5go@nataraja> Hi Neels, IPA CCM made sense on the Abis interface, where each BTS reports with its unit_id and MAC address. I'm not quite sure how much sense that makes in the core network. I also don't know if existing implementations of e.g. A interface over IPA multiplex actually use it. In terms of future outlook, the MSC/VLR/SGSN should register at the HLR with some kind of identity. In MAP, it is the SCCP Address that is used for this purpose. In absence of SCCP on GSUP, I used the CCM identity as a replacement. However, it is used as an opaque string, so that any GSUP/MAP gateway might simply translate the SCCP address into a string of its choosing, and then talk to OsmoHLR. OsmoHLR would then simply do a strcmp() on the string to match the identity. Sooner or later, OsmoHLR will have to store this identity in the database, e.g. for imlpementing message-waiting-lists of SMSCs in case of MT-SMS from real SMSCs. All-in-all, I think the string approach is not too bad in terms of keeping GSUP simple while having a clan approach to interworkng with MAP. On Fri, Feb 24, 2017 at 06:43:26AM +0100, Neels Hofmeyr wrote: > I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. > It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM > means) to route GSUP replies back to its sender. > > It looks like "NAME-00-00-00-00-00-00". > > However, all of our GSUP client code simply sets the unit id to: > "SGSN-00-00-00-00-00-00". > > The result is that the VLR never receives an UPDATE LOCATION RESULT, because it > is sent to the SGSN instead, since that was the first one to say that it is > "SGSN-00...". this is of course not good. > I would extend the GSUP clients to allow setting an ID from VTY, or maybe a > random ID. At this point it would suffice to make the MSC side say it is > "MSC-00-00-00-00-00-00" but that's beside the point. A random ID would not be permissible, as it has to be persistent accross MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms working. I would say, why not simply use the same approach as in OsmoBTS, i.e. use the MAC address (together with the MSC or SGSN prefix). The MAC address is unlikely to change frequently or on short notice. For people who know what they're doing, we can have a VTY command to override the identity with a manually-specified string. If that option is not set, the default "(SGSN|MSC)-MAC" is used. > Do we really want to do that? Any peer could come along and say it is someone > else, very easy to misconfigure (and not very security sensitive when thinking > of OAP -- which we're not using but maybe we will one day). I don't think we are aiming for anyone to use those protocols on public[ly accessible] networks. There's no message authentication or other cryptographic protection anyway. OAP seems like a funny but futile minor obstacle, but nothing that can provide any reasonable level of security. > For some messages, OsmoHLR uses the conn pointer from msg rx to route the > response back -- that works. This should be done in all request-response style procedures, I think. > AFAICT it just receives messages and replies to them right away (but > haven't seen / understood all of it). For the case of the UPDATE > LOCATION RESULT, it would also be possible to use the same conn > pointer, but the code chooses to resolve by id and then sends to the > wrong peer. If it used the peer's IP address and port instead, things > would work out. Looking up by ID would also work in case meanwhile the old connection has died and a new connection has been established > With the attached and possibly very stupid patch, OsmoHLR works for me with > both MSC and SGSN talking to it even though they have identical IPA IDs: I > bluntly store the conn in struct lu_operation and re-use it later. For synchronous responses (i.e. no asynchronous activity in between) this will work. So I think it's an optimization for those cases, and we shouldn't rely on this to always work for all transactions at all time in the future. Rather, we should make sure it works even without that optimization? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Fri Feb 24 16:12:02 2017 From: keith at rhizomatica.org (Keith) Date: Fri, 24 Feb 2017 17:12:02 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <20170221151405.rsmrcrmwdc4etjjg@nataraja> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <20170221151405.rsmrcrmwdc4etjjg@nataraja> Message-ID: On 21/02/2017 16:14, Harald Welte wrote: > Just a quick response: jolly implemented "traffic handover" aka "load > balancing" 3 years ago as part of a branch (I believe for a customer), > but unfortunately this never was merged back to master. Reading the commit log, this looks terrific... > Meanwhile, we already have all the code for execution of hand-overs in > place. We also have dynamic timeslots in place. So the "mechanics" > should all be there to add the two missing features from those old > branches: > a) de-fragmenting of channels (i.e. merging two separate TCH/H into one > timeslot, so the other timeslot can be switched to TCH/F or PDCH on > demand > b) load/traffic based hand-over So essentially everything I was talking about is already implemented! My question then would be, and I understand maybe the answer is not so easily available without a full code review, but Was it unfortunately never merged back to master because Simply no one ever made the effort to do so. OR There were problems with the code, disagreement on the implementation or incompatibilities with other developments etc.. If it's the former, I'll have a go at this. If it is the latter, it's probably beyond my skills. > The general strategy I would normally assume is to > * switch to half-rate channels with AMR whenever possible > * use dynamic channel switching to switch between TCH/H (default) and > TCH/F (if neded) Absolutely, I must revisit this one. It was shelved for us due to my understanding a few months ago that if we implemented AMR, then we couldn't also use FR. As that's all now resolved, I can implement, test and report. :-) From laforge at gnumonks.org Fri Feb 24 16:26:28 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Feb 2017 17:26:28 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <20170221151405.rsmrcrmwdc4etjjg@nataraja> Message-ID: <20170224162628.ypnxnkeffirs36ab@nataraja> Hi Keith, On Fri, Feb 24, 2017 at 05:12:02PM +0100, Keith wrote: > Was it unfortunately never merged back to master because > Simply no one ever made the effort to do so. correct. I really love all the work jolly did, and I'm thankful for that. However, in order to really work productively in a collaborative FOSS project, it is part of the contributors task to submit the code in chunks digestible, go through the review process, address the review that might occur. Yes, that's annoying and much less exciting than writing the code in the first place. But it's necessary, as it ensures the code has been reviewed by other experts in the codebase, is understood by more than one person (in case of later issues), and also ensures a common architecture of the overall code. It's what set's a one-man-show apart from a collaborative effort. So the code that is present in some of the many branches that developers created might work perfectly fine and might even be used in production by some users. But the code in there has never been submitted for review or merge. And of course it bit-rots over time, which would have been avoidable had it gone through review + merge at the time it was completed. > There were problems with the code, disagreement on the implementation or > incompatibilities with other developments etc.. That may or may not be the case. As it was never presented for review/merge, we simply don't know. I think what needs to be done is it has to be re-based, understood, tested (both in terms of manual testing and in terms of adding unit tests where missing), split up in digestible patch sets and submitted for review in gerrit. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Fri Feb 24 16:46:37 2017 From: keith at rhizomatica.org (Keith) Date: Fri, 24 Feb 2017 17:46:37 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> Message-ID: <3819446c-fede-94f3-1177-23f84181b2da@rhizomatica.org> On 22/02/2017 10:02, Holger Freyther wrote: > PS: Do you have a docker container for your FreeSWITCH setup and maybe > two numbers one to play audio and another to record the audio? > The short answer is no. Docker is far too much in /vogue/ for me to be seen using it :-) Joking aside, we have a docker fan currently lending a hand at the office and willing to put together whatever you need. What else do you need in the container? We are still (somewhat ashamedly) using a rather old FreeSWITCH version in production, so the best might be to use the latest stable for this setup, rather than replicate ours exactly. All call numbers and setup are handled by our python dialplan, which is probably unneeded complexity for testing RTP streams. I can look at something for FreeSWITCH where you call a number that will playback audio and also trigger recording, if that's what you need. k/ From nhofmeyr at sysmocom.de Fri Feb 24 17:02:12 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 24 Feb 2017 18:02:12 +0100 Subject: borken pipe on jenkins Message-ID: <20170224170212.GB2045@my.box> Now I've actually added some monitoring on all opened and closed sockets in the python tests, and it turns out the recent patch had no effect because the tearDown() is overloaded in TestVTYBase. With every running test, another socket is opened and they aren't closed until presumably the test py program exits. "40 sockets open", "41 sockets open", "42 sockets open", ... Found two places where we need to close sockets, and now the number of open sockets stays between 0 and 1. Patches are https://gerrit.osmocom.org/1903 https://gerrit.osmocom.org/1905 Will update the docker for openbsc tests when it's merged, and hopefully we can remove the extra monitoring of tcp sockets soon. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Fri Feb 24 19:05:59 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Feb 2017 20:05:59 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> <39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org> Message-ID: <3CE11B84-B950-4149-8EBD-B159DE9E3A85@gnumonks.org> We could include and maintain all related code to a subdirectory of contributed in openbsc.git, if you'd like. -- Sent from a mobile device. Please excuse my brevity. From alexander.chemeris at gmail.com Fri Feb 24 20:05:13 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 24 Feb 2017 12:05:13 -0800 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> <39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org> Message-ID: Hi Keith, On Fri, Feb 24, 2017 at 7:42 AM, Keith wrote: > Hi Alexander, seeing as how you came in on the thread, as a side topic, > you may have noticed I mentioned meas_json and meas_web in the OP. I > fixed up a small thing with meas_json that was producing unparseable > json in the neighbours array. Thank you. Please submit a patch when main meas_json lands into the master. It looks like the patch was lost during the patchworks->Gerrit transition, so I re-submitted it to Gerrit here: https://gerrit.osmocom.org/#/c/1915/ > I also did some stuff server side to > filter for either SDCCH or TCH, although I think I would make this a > clientside javascript filter option, rather than running multiple websocketd Yes, this should rather be client side I believe. > I added the neighbour levels to the displayed data. I hardcoded the > ARFCNs for the site in question, but I would make that happen dynamically. > I found this quite useful for monitoring in relation to analysis on this > site and the would-be handover scenario. Sounds very useful indeed! And yes, ARFCN clearly should be dynamic before such a change oculd be merged. But this doesn't mean you should not commit your change in a WIP branch - commit early, commit often. :) > I'm wondering what to do with this work. I'm glad the code is useful and happy to review your changes. > Should I make a commit of meas_json to master? In that case I would > appreciate some minor help getting the Makefile right. If the commit is ready in general - please submit it to Gerrit and add me as a reviewer. > Maybe meas_json is not a candidate for the master branch, as it doesn't > currently do anything particularly useful without the external > dependencies, ie meas_web and websocketd or alternative. Well, it's a kind of an external API, so it's as useful as any other API. > I can publish my work on meas_web to github. That would be great. Please submit a pull request when you feel ready. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From alexander.chemeris at gmail.com Fri Feb 24 20:05:56 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 24 Feb 2017 12:05:56 -0800 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <3CE11B84-B950-4149-8EBD-B159DE9E3A85@gnumonks.org> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> <39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org> <3CE11B84-B950-4149-8EBD-B159DE9E3A85@gnumonks.org> Message-ID: Hi Harald, On Fri, Feb 24, 2017 at 11:05 AM, Harald Welte wrote: > We could include and maintain all related code to a subdirectory of contributed in openbsc.git, if you'd like. Are you talking about meas_web or something else. Your e-mail didn't include any context :( -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From raji.oshin at hotmail.com Sat Feb 25 03:16:36 2017 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Sat, 25 Feb 2017 03:16:36 +0000 Subject: OpenBSC Digest, Vol 28, Issue 20 In-Reply-To: References: Message-ID: Hi all I have got trough the pcs 1900 nano bts if you have any doubts pls let me ... and these days I am trying to resolves OML issues with RBS 2308 ericson bts Thank you very much Regards Rajitha peiris Sent from my iPhone On Feb 24, 2017, at 9:42 PM, "openbsc-request at lists.osmocom.org" > wrote: Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org You can reach the person managing the list at openbsc-owner at lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: Ki and OPC values change when programming MCC and MNC (Holger Freyther) 2. Re: Virtual layer 1 - Questions (Harald Welte) 3. OsmoHLR and IPA unit id (Neels Hofmeyr) 4. Re: Handover and load balancing on SysmoBTS 2050 (Keith) 5. Re: OsmoHLR and IPA unit id (Harald Welte) 6. Re: Handover and load balancing on SysmoBTS 2050 (Keith) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Feb 2017 15:25:56 +0700 From: Holger Freyther > To: Neels Hofmeyr > Cc: "openbsc at lists.osmocom.org" > Subject: Re: Ki and OPC values change when programming MCC and MNC Message-ID: <31579AC7-F837-49F1-9EDC-C0B8D2CCC85C at freyther.de> Content-Type: text/plain; charset=us-ascii On 23 Feb 2017, at 09:53, Neels Hofmeyr > wrote: On Wed, Feb 22, 2017 at 05:06:20PM +0100, Sylvain Munaut wrote: --help will tell you defaults for Ki and OPC is to randomize ... Ah, indeed, I never saw that. Could also be misunderstood. IMHO it should say right at the top that you normally want to pass -k and -o when calling pysim. After all, none of the other options do that. anyway... "normally".. for the batch mode as used at XC3 events the "normal" is to generate a random KI, you wouldn't want to do that by hand 4k times. :) holger ------------------------------ Message: 2 Date: Thu, 23 Feb 2017 15:41:24 +0100 From: Harald Welte > To: Sebastian Stumpf > Cc: openbsc at lists.osmocom.org, baseband-devel at lists.osmocom.org Subject: Re: Virtual layer 1 - Questions Message-ID: <20170223144124.mdba7w7avdujy23g at nataraja> Content-Type: text/plain; charset=us-ascii Hi Sebastian, On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote: I also see that the RACH requesets all are sent with a bogus frame number: 42. This will not work. The RACH request needs to be sent with the current frame number at the time being. I fixed that and calculate the proper rach fn like in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151 good. Also, RACH retransmissions are happening way too quick. Calculating a proper frame number didn't fix the fast retransmissions. They are caused by sending the channel request over the virtual um immediately after getting the rach-request from layer23. Thus also the rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its already transmitted" and will generate the next rach-request for my layer 1. i see. the confirmation should probably be delayed somehow. As a quick intermediate hack you might simply add a timer. I think one can do without on the MS side, but then the BTS must basically queue the incoming frames until the respective frame number indicated in the frame matches the current frame number. I think to fix the problem with the quick retransmission , I need some type of scheduling. Because if I queue the incoming uplink-msgs in the bts-virtual-layer1 instead, I don't know when they are processed on the ms side and thus don't know when to send the rach-confirm to layer23... My idea for a simple scheduler would be: -- no timing and timer interrupts on ms side, but just set the current fn in the ms state each time we receive a message on downlink to the fn of the received message, which is accessible in the gsmtap header. yes, that makes sense. -- queue the outgoing uplink messages with their confirm callback to l2 and process all that with a smaller fn than the current fn in the scheduling function. yes, but please keep in mind that the frame number is wrapping every so often, so "smaller" must consider that modulo-arithmetic, or you will (after fn wrap) have pending downlink messages for much higher fn which are not sent as the wrapped fn is now very small. -- calling the scheduling function each time we receive a msg on downlink (so I do not need to handle timer interrupts) yes. I think it is reasonable to not have any actual timers on the ms side and always depend on the frame numbers in the downlink messages from the BTS. After all, in the worst case you have periodic messages like the BCCH messages that can be used to update the fn. I hope that will be sufficent and try it out tomorrow. I am a bit afraid of trouble caused by the frame number skipping values with the upper incrementation logic. I don't think skips are that problematic. But then, I haven't tried it ;) -- - Harald Welte > http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Fri, 24 Feb 2017 06:43:26 +0100 From: Neels Hofmeyr > To: openbsc at lists.osmocom.org Subject: OsmoHLR and IPA unit id Message-ID: <20170224054326.GB1368 at my.box> Content-Type: text/plain; charset="us-ascii" I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. Which way shall we resolve this? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-RFC-add-the-osmo_gsup_conn-directly-to-the-lu_operat.patch Type: text/x-diff Size: 2550 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: ------------------------------ Message: 4 Date: Fri, 24 Feb 2017 16:42:35 +0100 From: Keith > To: Alexander Chemeris > Cc: OpenBSC Mailing List > Subject: Re: Handover and load balancing on SysmoBTS 2050 Message-ID: <39e245c4-ba1a-600b-8e38-cb300c10133f at rhizomatica.org> Content-Type: text/plain; charset=utf-8 Hi Alexander, seeing as how you came in on the thread, as a side topic, you may have noticed I mentioned meas_json and meas_web in the OP. I fixed up a small thing with meas_json that was producing unparseable json in the neighbours array. I also did some stuff server side to filter for either SDCCH or TCH, although I think I would make this a clientside javascript filter option, rather than running multiple websocketd I added the neighbour levels to the displayed data. I hardcoded the ARFCNs for the site in question, but I would make that happen dynamically. I found this quite useful for monitoring in relation to analysis on this site and the would-be handover scenario. I'm wondering what to do with this work. Should I make a commit of meas_json to master? In that case I would appreciate some minor help getting the Makefile right. Maybe meas_json is not a candidate for the master branch, as it doesn't currently do anything particularly useful without the external dependencies, ie meas_web and websocketd or alternative. I can publish my work on meas_web to github. Keith. ------------------------------ Message: 5 Date: Fri, 24 Feb 2017 16:53:03 +0100 From: Harald Welte > To: Neels Hofmeyr > Cc: openbsc at lists.osmocom.org Subject: Re: OsmoHLR and IPA unit id Message-ID: <20170224155303.tuidxovd4qbzp5go at nataraja> Content-Type: text/plain; charset=us-ascii Hi Neels, IPA CCM made sense on the Abis interface, where each BTS reports with its unit_id and MAC address. I'm not quite sure how much sense that makes in the core network. I also don't know if existing implementations of e.g. A interface over IPA multiplex actually use it. In terms of future outlook, the MSC/VLR/SGSN should register at the HLR with some kind of identity. In MAP, it is the SCCP Address that is used for this purpose. In absence of SCCP on GSUP, I used the CCM identity as a replacement. However, it is used as an opaque string, so that any GSUP/MAP gateway might simply translate the SCCP address into a string of its choosing, and then talk to OsmoHLR. OsmoHLR would then simply do a strcmp() on the string to match the identity. Sooner or later, OsmoHLR will have to store this identity in the database, e.g. for imlpementing message-waiting-lists of SMSCs in case of MT-SMS from real SMSCs. All-in-all, I think the string approach is not too bad in terms of keeping GSUP simple while having a clan approach to interworkng with MAP. On Fri, Feb 24, 2017 at 06:43:26AM +0100, Neels Hofmeyr wrote: I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". this is of course not good. I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. A random ID would not be permissible, as it has to be persistent accross MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms working. I would say, why not simply use the same approach as in OsmoBTS, i.e. use the MAC address (together with the MSC or SGSN prefix). The MAC address is unlikely to change frequently or on short notice. For people who know what they're doing, we can have a VTY command to override the identity with a manually-specified string. If that option is not set, the default "(SGSN|MSC)-MAC" is used. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). I don't think we are aiming for anyone to use those protocols on public[ly accessible] networks. There's no message authentication or other cryptographic protection anyway. OAP seems like a funny but futile minor obstacle, but nothing that can provide any reasonable level of security. For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. This should be done in all request-response style procedures, I think. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. Looking up by ID would also work in case meanwhile the old connection has died and a new connection has been established With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. For synchronous responses (i.e. no asynchronous activity in between) this will work. So I think it's an optimization for those cases, and we shouldn't rely on this to always work for all transactions at all time in the future. Rather, we should make sure it works even without that optimization? -- - Harald Welte > http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 6 Date: Fri, 24 Feb 2017 17:12:02 +0100 From: Keith > To: Harald Welte > Cc: OpenBSC Mailing List > Subject: Re: Handover and load balancing on SysmoBTS 2050 Message-ID: > Content-Type: text/plain; charset=windows-1252 On 21/02/2017 16:14, Harald Welte wrote: Just a quick response: jolly implemented "traffic handover" aka "load balancing" 3 years ago as part of a branch (I believe for a customer), but unfortunately this never was merged back to master. Reading the commit log, this looks terrific... Meanwhile, we already have all the code for execution of hand-overs in place. We also have dynamic timeslots in place. So the "mechanics" should all be there to add the two missing features from those old branches: a) de-fragmenting of channels (i.e. merging two separate TCH/H into one timeslot, so the other timeslot can be switched to TCH/F or PDCH on demand b) load/traffic based hand-over So essentially everything I was talking about is already implemented! My question then would be, and I understand maybe the answer is not so easily available without a full code review, but Was it unfortunately never merged back to master because Simply no one ever made the effort to do so. OR There were problems with the code, disagreement on the implementation or incompatibilities with other developments etc.. If it's the former, I'll have a go at this. If it is the latter, it's probably beyond my skills. The general strategy I would normally assume is to * switch to half-rate channels with AMR whenever possible * use dynamic channel switching to switch between TCH/H (default) and TCH/F (if neded) Absolutely, I must revisit this one. It was shelved for us due to my understanding a few months ago that if we implemented AMR, then we couldn't also use FR. As that's all now resolved, I can implement, test and report. :-) ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 20 *************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Feb 25 04:20:52 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 24 Feb 2017 20:20:52 -0800 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <81016EDC-986E-483F-80EC-6F7796ECF0AC@freyther.de> <39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org> <3CE11B84-B950-4149-8EBD-B159DE9E3A85@gnumonks.org> Message-ID: On Fri, Feb 24, 2017 at 12:05 PM, Alexander Chemeris wrote: > Hi Harald, > > On Fri, Feb 24, 2017 at 11:05 AM, Harald Welte wrote: >> We could include and maintain all related code to a subdirectory of contributed in openbsc.git, if you'd like. > > Are you talking about meas_web or something else. Your e-mail didn't > include any context :( I frankly don't know what's the best way here. Putting a web app into OpenBSC feels awkward, but it may make sense, given it's tightly coupled and is pretty small. OTOH it has its own installation requirements and debian packaging, which might make it a bit tricky when it's inside OpenBSC repo - I would appreciate thoughts on this. May be we can create two deb packages from the OpenBSC repo with one dedicated to meas_web? -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co From nhofmeyr at sysmocom.de Sat Feb 25 15:11:35 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 25 Feb 2017 16:11:35 +0100 Subject: OpenBSC Digest, Vol 28, Issue 20 In-Reply-To: References: Message-ID: <20170225151135.GA2458@my.box> Dear Rajitha, I have asked you before not to bounce an entire mail digest back to this mailing list. It's highly inappropriate. If you have a question, open a new empty mail, give it an intelligible subject line and ask your question. On Sat, Feb 25, 2017 at 03:16:36AM +0000, Rajitha peiris wrote: > Hi all > I have got trough the pcs 1900 nano bts if you have any doubts pls let me ... and these days I am trying to resolves OML issues with RBS 2308 ericson bts > > Thank you very much > Regards > Rajitha peiris > [...] snipped 460-odd lines of bloat ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sat Feb 25 16:22:02 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 25 Feb 2017 17:22:02 +0100 Subject: OsmoHLR and IPA unit id In-Reply-To: <20170224155303.tuidxovd4qbzp5go@nataraja> References: <20170224054326.GB1368@my.box> <20170224155303.tuidxovd4qbzp5go@nataraja> Message-ID: <20170225162202.GB2458@my.box> On Fri, Feb 24, 2017 at 04:53:03PM +0100, Harald Welte wrote: > All-in-all, I think the string approach is not too bad in terms of > keeping GSUP simple while having a clan approach to interworkng with > MAP. Yes, no objections there. > > I would extend the GSUP clients to allow setting an ID from VTY, or maybe a > > random ID. At this point it would suffice to make the MSC side say it is > > "MSC-00-00-00-00-00-00" but that's beside the point. > > A random ID would not be permissible, as it has to be persistent accross > MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms > working. > > I would say, why not simply use the same approach as in OsmoBTS, i.e. use > the MAC address (together with the MSC or SGSN prefix). The MAC address > is unlikely to change frequently or on short notice. For people who > know what they're doing, we can have a VTY command to override the > identity with a manually-specified string. If that option is not set, > the default "(SGSN|MSC)-MAC" is used. MAC will work when we have exactly one MSC|SGSN per machine: on loopback, MACs are 0* and if two of the same run on the same ethernet device we will get collisions (i.e. it doesn't help to create new IP addresses). But having two of the same on the very same box is very unusual, right? For those cases, like test setups, the VTY command solves it. So yes, sounds like a plan. Next question, *which* MAC? We have osmo_get_mac_addr(), yes, but it naturally needs a device name. In osmo-bts, I find: osmo-bts/src/common/abis.c:251: osmo_get_macaddr(bts_dev_info.mac_addr, "eth0"); o_O that looks really bad! Hardcoded "eth0"? Ok for sysmobts, but otherwise, seems like pure coincidence that it has worked out for everyone before. (I'll open up an issue for that, but first awaiting your responses.) I'm on unfamiliar turf ... is it possible to find the MAC for a given bind instead? At first glance I thought: nice, there's and fd in osmo_get_macaddr(), so I could just plug an fd sort of like: int osmo_get_macaddr_from_fd(uint8_t *mac_out, int fd) { int rc; struct ifreq ifr = {}; memcpy(&ifr.ifr_name, dev_name, sizeof(ifr.ifr_name)); /* but */ rc = ioctl(fd, SIOCGIFHWADDR, &ifr); if (rc < 0) return rc; memcpy(mac_out, ifr.ifr_hwaddr.sa_data, 6); return 0; } But shucks, there's still a dev_name involved. Can't I get the SIOCGIFHWADDR of the device that socket will use? Wait a minute, that won't work because the kernel decides on the device to use based on the routing table... Go through the list of interfaces and pick the first non-NULL MAC? But that would be vulnerable to server reconfig of possibly completely unrelated interfaces. At the moment it seems to me picking a MAC isn't all that simple or portable (also need a separate FreeBSD impl), and requiring a unique ID in the config file is so much simpler. Does anyone have better insights and ideas than me? > OAP seems like a funny but futile minor obstacle, but nothing that can > provide any reasonable level of security. heh "funny but futile" Seems to me OAP was basically my initiation ritual at Osmocom ;) > > For some messages, OsmoHLR uses the conn pointer from msg rx to route the > > response back -- that works. > > This should be done in all request-response style procedures, I think. > [...] > Looking up by ID would also work in case meanwhile the old connection > has died and a new connection has been established > > > With the attached and possibly very stupid patch, OsmoHLR works for me with > > both MSC and SGSN talking to it even though they have identical IPA IDs: I > > bluntly store the conn in struct lu_operation and re-use it later. > > For synchronous responses (i.e. no asynchronous activity in between) > this will work. So I think it's an optimization for those cases, and we > shouldn't rely on this to always work for all transactions at all time > in the future. Rather, we should make sure it works even without that > optimization? Fine with me. That patch of mine, if we apply it for optimization, needs to cleanup lu_operation instances in case a conn is closed. OsmoHLR should probably warn on the error log in case two conns are open simultaneously for the same peer ID; even reject a second conn for the same ID to help users do less foot shooting. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sat Feb 25 16:55:37 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 25 Feb 2017 17:55:37 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <20170224162628.ypnxnkeffirs36ab@nataraja> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <20170221151405.rsmrcrmwdc4etjjg@nataraja> <20170224162628.ypnxnkeffirs36ab@nataraja> Message-ID: <20170225165537.GC2458@my.box> On Fri, Feb 24, 2017 at 05:26:28PM +0100, Harald Welte wrote: > Hi Keith, > > On Fri, Feb 24, 2017 at 05:12:02PM +0100, Keith wrote: > > Was it unfortunately never merged back to master because > > Simply no one ever made the effort to do so. > > correct. And let me add that it would also need an effort to duly test it. I've touched the lchan defrag patch (while peeling the dynamic timeslot code from it) and it looked like it works, but I assume we'll still find some problems in tests. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From giselle2207 at gmail.com Mon Feb 27 09:07:52 2017 From: giselle2207 at gmail.com (Giselle Gonzalez lopez) Date: Mon, 27 Feb 2017 10:07:52 +0100 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: References: Message-ID: Hello again, I have tried to program the card setting Ki and OPC as recommended so they are not picked randomly by PySIM, and I'm getting this error message: root at click:/opt/pysim-zecke-tmp2# ./pySim-prog.py -p 0 -a 86416194 -x 214 -y 91 -t sysmoUSIM-SJS 1 -i 214910000009911 -s 8988211000000099112 -n openair4G.eur -o 9319ed3ee808bd467d42d3957c597cda -k 11111111111111111111111111111111 Usage: pySim-prog.py [options] pySim-prog.py: error: Extraneous arguments Does it have to do with Ki being set to all ones ("1x32")? Thank you! Regards, Giselle 2017-02-22 14:30 GMT+01:00 Sylvain Munaut <246tnt at gmail.com>: > Hi, > > > > Do you what's the reason why this is happening? > > Because it's programmed like that ... > > Most cards you have to reprogram all the parameters at once, you can't > change just one. Not sure about the sysmoUSIM-SJS1 in particulat but > since pysim has to support different models, it has this restriction. > So if you don't specify a Ki / OPC on the command line, they get > picked randomly. > > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giselle2207 at gmail.com Mon Feb 27 09:10:30 2017 From: giselle2207 at gmail.com (Giselle Gonzalez lopez) Date: Mon, 27 Feb 2017 10:10:30 +0100 Subject: Ki and OPC values change when programming MCC and MNC In-Reply-To: References: Message-ID: Just discovered my error, missing space! Sorry! 2017-02-27 10:07 GMT+01:00 Giselle Gonzalez lopez : > Hello again, > > I have tried to program the card setting Ki and OPC as recommended so they > are not picked randomly by PySIM, and I'm getting > this error message: > > root at click:/opt/pysim-zecke-tmp2# ./pySim-prog.py -p 0 -a 86416194 -x 214 > -y 91 -t sysmoUSIM-SJS > 1 -i 214910000009911 -s 8988211000000099112 -n openair4G.eur -o > 9319ed3ee808bd467d42d3957c597cda > -k 11111111111111111111111111111111 > Usage: pySim-prog.py [options] > > pySim-prog.py: error: Extraneous arguments > > > Does it have to do with Ki being set to all ones ("1x32")? > > Thank you! > > Regards, > > Giselle > > > 2017-02-22 14:30 GMT+01:00 Sylvain Munaut <246tnt at gmail.com>: > >> Hi, >> >> >> > Do you what's the reason why this is happening? >> >> Because it's programmed like that ... >> >> Most cards you have to reprogram all the parameters at once, you can't >> change just one. Not sure about the sysmoUSIM-SJS1 in particulat but >> since pysim has to support different models, it has this restriction. >> So if you don't specify a Ki / OPC on the command line, they get >> picked randomly. >> >> >> Cheers, >> >> Sylvain >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t-openbsc at tobias.org Mon Feb 27 09:47:43 2017 From: t-openbsc at tobias.org (Tobias Engel) Date: Mon, 27 Feb 2017 10:47:43 +0100 Subject: vlr+hlr: Insert Data In-Reply-To: <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> References: <20170209135321.GB28816@my.box> <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> Message-ID: <3a93aa6b-34bd-e523-ceda-f92991a81105@tobias.org> On 13.02.17 08:13, Jacob Erlbeck wrote: > On 02/09/2017 02:53 PM, Neels Hofmeyr wrote: >> >> What should we do if the HLR sends no Insert Data? > > I did not find much in 29.002 that tells otherwise. There is only figure > 19.1.1/3 which states that the insert messages are not optional by not > using italics. The automatons in 19.1.1/6 and 19.1.1/13 do not impose > such a restriction. By the way: Both updateLocation and updateGprsLocation have a skipSubscriberDataUpdate flag, which tells the HLR to skip the insertSubscriberData procedure. >From 29.002 8.1.2.3: Skip Subscriber Data Update The presence of the parameter is optional and if present it indicates that subscriber data download during the updateGprsLocation procedure may be skipped by the HLR e.g. because the service is solely used to inform the HLR about change of IMEISV. The parameter is used to optimise signalling load during Location Update procedure. -Tobias From nhofmeyr at sysmocom.de Mon Feb 27 12:56:57 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 27 Feb 2017 13:56:57 +0100 Subject: vlr+hlr: Insert Data In-Reply-To: <3a93aa6b-34bd-e523-ceda-f92991a81105@tobias.org> References: <20170209135321.GB28816@my.box> <35b22d03-b0be-fdc0-3dc1-74c9567d0a4f@gmx.net> <3a93aa6b-34bd-e523-ceda-f92991a81105@tobias.org> Message-ID: <20170227125657.GC1675@my.box> On Mon, Feb 27, 2017 at 10:47:43AM +0100, Tobias Engel wrote: > On 13.02.17 08:13, Jacob Erlbeck wrote: > > On 02/09/2017 02:53 PM, Neels Hofmeyr wrote: > >> > >> What should we do if the HLR sends no Insert Data? > > > > I did not find much in 29.002 that tells otherwise. There is only figure > > 19.1.1/3 which states that the insert messages are not optional by not > > using italics. The automatons in 19.1.1/6 and 19.1.1/13 do not impose > > such a restriction. > > By the way: Both updateLocation and updateGprsLocation have a > skipSubscriberDataUpdate flag, which tells the HLR to skip the > insertSubscriberData procedure. > > From 29.002 8.1.2.3: > > Skip Subscriber Data Update > The presence of the parameter is optional and if present it indicates > that subscriber data download during the updateGprsLocation procedure > may be skipped by the HLR e.g. because the service is solely used to > inform the HLR about change of IMEISV. The parameter is used to optimise > signalling load during Location Update procedure. Interesting, thanks! It seems the VLR should have an intention of whether it wants to receive subscriber data or not. I guess for now our VLR's intention is to always receive subscriber data, i.e. so far we can reject LU if missing. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From keith at rhizomatica.org Mon Feb 27 15:00:55 2017 From: keith at rhizomatica.org (Keith) Date: Mon, 27 Feb 2017 16:00:55 +0100 Subject: Handover and load balancing on SysmoBTS 2050 In-Reply-To: <20170225165537.GC2458@my.box> References: <6c2c2847-035b-2436-7c4b-d046969ce6cc@rhizomatica.org> <20170220175043.oee3537taqyoves3@nataraja> <7599d67e-ecd1-535a-9000-1f211bd5e512@rhizomatica.org> <20170221151405.rsmrcrmwdc4etjjg@nataraja> <20170224162628.ypnxnkeffirs36ab@nataraja> <20170225165537.GC2458@my.box> Message-ID: <98b1fa0c-0992-7f60-d07c-2472d0d59021@rhizomatica.org> On 25/02/2017 17:55, Neels Hofmeyr wrote: > On Fri, Feb 24, 2017 at 05:26:28PM +0100, Harald Welte wrote: >> Hi Keith, >> >> On Fri, Feb 24, 2017 at 05:12:02PM +0100, Keith wrote: >>> Was it unfortunately never merged back to master because >>> Simply no one ever made the effort to do so. >> correct. > And let me add that it would also need an effort to duly test it. I'm very happy to put that effort in. The effort required for me to test (using test BTSs and phones in the lab as well as coordinated real world deployment tests) is minimal compared to moving the code into the master branch and writing tests as in "make test" for it. :-) From nhofmeyr at sysmocom.de Tue Feb 28 11:27:13 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 28 Feb 2017 12:27:13 +0100 Subject: libosmo-netif failed on both jenkins FreeBSD and xUbuntu_16.04/i586 Message-ID: <20170228112713.GB1908@ass40.sysmocom.de> It seems to be a sporadic failure due to timing. Kicking off the same build on jenkins resulted in success. Can anyone relaunch the OBS build? I'm not too familiar with it... http://jenkins.osmocom.org/jenkins/job/libosmo-netif/ https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/libosmo-netif/xUbuntu_16.04/i586 Also, it would actually be nice if the opensuse builds also printed all test logs as in osmo-ci/scripts/cat-testlogs.sh -- if anyone knows how and has the time to insert such, that would be great. (git clone https://gerrit.osmocom.org/osmo-ci) Thanks, ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Tue Feb 28 11:47:54 2017 From: holger at freyther.de (Holger Freyther) Date: Tue, 28 Feb 2017 19:47:54 +0800 Subject: libosmo-netif failed on both jenkins FreeBSD and xUbuntu_16.04/i586 In-Reply-To: <20170228112713.GB1908@ass40.sysmocom.de> References: <20170228112713.GB1908@ass40.sysmocom.de> Message-ID: > On 28 Feb 2017, at 19:27, Neels Hofmeyr wrote: > > It seems to be a sporadic failure due to timing. > Kicking off the same build on jenkins resulted in success. > Can anyone relaunch the OBS build? I'm not too familiar with it... > > http://jenkins.osmocom.org/jenkins/job/libosmo-netif/ > https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/libosmo-netif/xUbuntu_16.04/i586 done. If you are logged in and open the above page you can see "Start refresh", "Download logfile" and "Rebuild" > Also, it would actually be nice if the opensuse builds also printed all > test logs as in osmo-ci/scripts/cat-testlogs.sh -- if anyone knows how and > has the time to insert such, that would be great. > > (git clone https://gerrit.osmocom.org/osmo-ci) @ruben: Is there something to do that easily? Is there a dedicated make rule that is called after (test) failure? Would you know of a snippet for dh_override_auto_test to use? dh_autotest || dump_logs and let it fail? holger From sebastian.stumpf87 at googlemail.com Tue Feb 28 17:29:20 2017 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Tue, 28 Feb 2017 18:29:20 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: <20170223144124.mdba7w7avdujy23g@nataraja> References: <20170212230920.epvdsj7jwxzta23w@nataraja> <20170223144124.mdba7w7avdujy23g@nataraja> Message-ID: Hi Harald, here is an update on the virt-phy (and some more problems ;)). I implemented the simple scheduler and it seems to work fine. I was happy to find the assignment of channels to their respective frame in the mframe in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/mframe_sched.c#L67-L292 and used that to calculate the fn the messages should be scheduled in. Thanks to your suggestions I could also fix some errors and produced a new capture file. https://www.dropbox.com/s/145w5c5kqwlk5ey/mobile--ms-virt--bts-virt--bsc-nitb_170228%3Ahyperframe_fast_repeat_test.pcapng?dl=0 I come some steps further but are still having trouble to: Send an sms to myself using the extension assigned to my ms from osmo-nitb (see 2341 in cap-file). VTY: sms 1 12 "Hallo zusammen" OsmocomBB# % (MS 1) % SMS to 12 failed: Semantically Incorrect Message Call myself (11851 in cap file) VTY: OsmocomBB# call 1 12 OsmocomBB# % (MS 1) % Call has been released Losing RR connection after some time. LOG-mobile: Tue Feb 28 17:16:35 2017 DRR <0001> gsm48_rr.c:662 MON: no cell info LOG-virt-phy: Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 0d 00 00 00 01 00 00 00 Tue Feb 28 17:16:34 2017 DL1C Received and handled from l23 - L1CTL_RESET_REQ (type=FULL) Tue Feb 28 17:16:34 2017 DL1C Sending to l23 - L1CTL_RESET_CONF (reset_type: 1) Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 00 00 00 7c Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=0, TO=124 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 00 80 00 fb Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=128, TO=251 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 02 00 02 99 Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=512, TO=665 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 02 9b 03 75 Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=667, TO=885 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 03 bb 03 ff Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=955, TO=1023 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 08 00 00 00 01 00 00 00 82 00 83 2a Tue Feb 28 17:16:34 2017 DL1C Received from l23 - L1CTL_PM_REQ TYPE=1, FROM=33280, TO=33578 Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 0d 00 00 00 01 00 00 00 Tue Feb 28 17:16:34 2017 DL1C Received and handled from l23 - L1CTL_RESET_REQ (type=FULL) Tue Feb 28 17:16:34 2017 DL1C Sending to l23 - L1CTL_RESET_CONF (reset_type: 1) Tue Feb 28 17:16:34 2017 DL1C Message incoming from layer 2: 01 00 00 00 83 2a 00 64 27 10 03 20 03 07 00 00 3f Tue Feb 28 17:16:34 2017 DL1C Received and handled from l23 - L1CTL_FBSB_REQ (arfcn=33578, flags=0x7) What I do not understand here is why I get a full power measurement request from mobile although I did set a fixed arfcn in the config. And of course a fbsb req for arfcn 33578 seems simply wrong... Next step after fixing the false fbsb request from l23 would be to add a second mobile and then try to get the mobile originated call to work. Of course i would be happy about other suggestions :). With kind regards, Sebastian Stumpf -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Feb 28 21:31:56 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 28 Feb 2017 22:31:56 +0100 Subject: Virtual layer 1 - Questions In-Reply-To: References: <20170212230920.epvdsj7jwxzta23w@nataraja> <20170223144124.mdba7w7avdujy23g@nataraja> Message-ID: <20170228213156.q72chdhhjxtyazy4@nataraja> Hi Sebastian, On Tue, Feb 28, 2017 at 06:29:20PM +0100, Sebastian Stumpf wrote: > I implemented the simple scheduler and it seems to work fine. I was happy > to find the assignment of channels to their respective frame in the mframe > in > https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/mframe_sched.c#L67-L292 > and used that to calculate the fn the messages should be scheduled in. good to hear. > I come some steps further but are still having trouble to: > > Send an sms to myself using the extension assigned to my ms from osmo-nitb > (see 2341 in cap-file). > VTY: > sms 1 12 "Hallo zusammen" > OsmocomBB# > % (MS 1) > % SMS to 12 failed: Semantically Incorrect Message The establishment from 2341 looks fine: * we first establish SAPI0 (signalling) on the SDCCH * we then establish SAPI3 (SMS) on the same SDCCH (SABM/UA) * we see The CP-DATA RP-DATA with the SMS-SUBMIT * we get an CP-ACK from the network Then the network tells us the SMS was semantically incorrect. This is a problem at a much higher level. I would expect this to also be the case if you used a real layer1 between an OsmocomBB phone and a BTS on the network side. from looking at the wireshark trace I cannot immediately identify an issue. I guess you need to 'logging enable sms debug' on the NITB and see if it tells you where/why it fails. > Call myself (11851 in cap file) > VTY: > OsmocomBB# call 1 12 > OsmocomBB# > % (MS 1) > % Call has been released Ok, in 11445-11449 we see the RACH/CHAN_RQD/IMM.ASS, which assigns Timeslot 7 to the MS. In 11466 we see the CM SERV REQ on the Um inteface, in 11470 on the Abis interface. In 11470 we see the BSC responding with CM SERV ACC, in 11475 this is forwaded over the Um inteface. However, the MS never reacts to it. Also, what's noteworthy (but likely unrelated) is that the BTS is sending empty idle/padding frames on the TS7 all the time (those containing 0x2b2b2b2b) but the MS is not doing that in uplink. In 11546 the CM SERV REQ is re-transmitted in a SABM frame, which is again acknowledged in the UA frame in 11548. So the BTS is doing everything correctly (it seems) but the MS somehow doesn't receive the UA (on LAPDm layer) nor the CM SERVICE ACCEPT (on layer 3 MM) As you can see there is no RSL communication this time, as it is just simply re-transmission on the LAPDm layer between BTS and MS. > Losing RR connection after some time. This is likely a result of the MS somehow not receiving/processing the downlink signalling messages. you could start a cell without any SDCCH to test if pure signalling works on TCH/FACCH at all. If you cannot even do a location update anymore, the problem is in the TCH/FACCH receiving code. If you can perform LU over TCH, the problem becomes more mysterious ;) > What I do not understand here is why I get a full power measurement request > from mobile although I did set a fixed arfcn in the config. maybe neighbor cell measurement reporting? > And of course a fbsb req for arfcn 33578 seems simply wrong... This is 0x832A which translates to ARFCN 810 decimal, with the highest bit set for (if I remember correctly) PCS? or Uplink/Downlink bit? In any case, the highest bit of the 16bit value is used for something else, check the code :P > Next step after fixing the false fbsb request from l23 would be to add a > second mobile and then try to get the mobile originated call to work. I think there's a problem with TCH/FACCH that needs to be resolved first, see above. But anyway, there's good progress and I'm happy you're pushing forward with this! I think a virtual L1 is a very useful foundation for all kinds of automatic testing of the higher protocol layers, in a way that everyone can execute, even without a real-world setup of BTSs and MSs. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)