From zero-kelvin at gmx.de Mon Jan 7 13:14:16 2013 From: zero-kelvin at gmx.de (dexter) Date: Mon, 07 Jan 2013 14:14:16 +0100 Subject: Osmocom Berlin User Group meeting In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> Message-ID: <50EACA28.9040200@gmx.de> Hi folks. This is the announcement for the next Osmocom Berlin meeting. Jan 09, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Philipp Maier From kelum.nava at gmail.com Wed Jan 23 04:24:13 2013 From: kelum.nava at gmail.com (Kelum Navaratne) Date: Wed, 23 Jan 2013 09:54:13 +0530 Subject: OpenBSC with LCR/SIP In-Reply-To: References: <507D1926.8070504@eversberg.eu> Message-ID: Hi Every one, Would the IP.Access nanoBTS works behind a NAT with OpenBSC ? i.e. two BTSs in two different locations behind NAT connecting to NITB. im trying to make a call, but it seems rtp has some problem. rgds Nava On Tue, Oct 16, 2012 at 6:49 PM, Kelum Navaratne wrote: > Hi Andreas, > > Thank you very much. This is a good start for me. I also need to work with > freeswitch. Not asterisk. And simple point to point sip is more than enough > and rtp bridge would be fantastic. > > Would it work with amr codec as well ? Or only gsm full rate/ h. Rate? > > Im trying to find the lcr git location of jolly/new. Can you please give > me the url. I cant find it on openbsc git. > > Thanks again. > > Nava. > > > On Tuesday, October 16, 2012, Andreas Eversberg wrote: > >> hi kelum, >> >> in order to use sip, you need jolly/new branch of lcr and jolly/rtpmux of >> openbsc. the sip implementation of LCR is quite simple, so no >> authentication or oder features - just simple point-to-point SIP. if you >> run confiure of LCR, check if sip is enabled. in order to add a SIP >> interface, do the following at interface.conf: >> >> [sip] >> sip [:] [:] >> earlyb yes >> tones no >> >> you need to define local IP that will be used to connect to remote SIP >> endpoint. don't use localhost, if the endpoint is on a different machine, >> because this IP is also used for RTP. if you use same machine, you need to >> have different ports. you may change local port, by adding a local port or >> you may change port of SIP endpoint and then add remote port. >> >> i have tested it with freeswitch, but asterisk should work also. >> >> you may then also try at interface.conf below "[sip]" definition: >> >> rtp-brige >> >> then the codec (full rate or enhanced full rate) is negotiated between >> mobile and the remote SIP endpoint. the SIP endpoint must support at least >> one of it. >> >> regards, >> >> andreas >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kelum.nava at gmail.com Wed Jan 23 04:24:13 2013 From: kelum.nava at gmail.com (Kelum Navaratne) Date: Wed, 23 Jan 2013 09:54:13 +0530 Subject: OpenBSC with LCR/SIP In-Reply-To: References: <507D1926.8070504@eversberg.eu> Message-ID: Hi Every one, Would the IP.Access nanoBTS works behind a NAT with OpenBSC ? i.e. two BTSs in two different locations behind NAT connecting to NITB. im trying to make a call, but it seems rtp has some problem. rgds Nava On Tue, Oct 16, 2012 at 6:49 PM, Kelum Navaratne wrote: > Hi Andreas, > > Thank you very much. This is a good start for me. I also need to work with > freeswitch. Not asterisk. And simple point to point sip is more than enough > and rtp bridge would be fantastic. > > Would it work with amr codec as well ? Or only gsm full rate/ h. Rate? > > Im trying to find the lcr git location of jolly/new. Can you please give > me the url. I cant find it on openbsc git. > > Thanks again. > > Nava. > > > On Tuesday, October 16, 2012, Andreas Eversberg wrote: > >> hi kelum, >> >> in order to use sip, you need jolly/new branch of lcr and jolly/rtpmux of >> openbsc. the sip implementation of LCR is quite simple, so no >> authentication or oder features - just simple point-to-point SIP. if you >> run confiure of LCR, check if sip is enabled. in order to add a SIP >> interface, do the following at interface.conf: >> >> [sip] >> sip [:] [:] >> earlyb yes >> tones no >> >> you need to define local IP that will be used to connect to remote SIP >> endpoint. don't use localhost, if the endpoint is on a different machine, >> because this IP is also used for RTP. if you use same machine, you need to >> have different ports. you may change local port, by adding a local port or >> you may change port of SIP endpoint and then add remote port. >> >> i have tested it with freeswitch, but asterisk should work also. >> >> you may then also try at interface.conf below "[sip]" definition: >> >> rtp-brige >> >> then the codec (full rate or enhanced full rate) is negotiated between >> mobile and the remote SIP endpoint. the SIP endpoint must support at least >> one of it. >> >> regards, >> >> andreas >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Wed Jan 23 07:41:03 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 23 Jan 2013 08:41:03 +0100 Subject: OpenBSC with LCR/SIP In-Reply-To: References: <507D1926.8070504@eversberg.eu> Message-ID: <50FF940F.7040803@eversberg.eu> Kelum Navaratne wrote: > Would the IP.Access nanoBTS works behind a NAT with OpenBSC ? > > i.e. two BTSs in two different locations behind NAT connecting to > NITB. im trying to make a call, but it seems rtp has some problem. hi kelum, the NAT firewall should track the RTP frames from BTS behind NAT, so that frames from BSC outside NAT can find their way to the BTS. i suggest to sniff (tcpdump/wireshark) behind and before NAT, in order to localize the problem. regards, andreas From nikpakar at gmail.com Sat Jan 26 15:47:34 2013 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 26 Jan 2013 21:17:34 +0530 Subject: OpenBSC with LCR/SIP In-Reply-To: <50FF940F.7040803@eversberg.eu> References: <507D1926.8070504@eversberg.eu> <50FF940F.7040803@eversberg.eu> Message-ID: Hi Andreas, this is this mean a BTS behind NAT and a OpenBSC +LCR/freeswitch + sip phone on freeswitch will be able to communicate with good RTP ? Rgds Nik On Wed, Jan 23, 2013 at 1:11 PM, Andreas Eversberg wrote: > Kelum Navaratne wrote: > >> Would the IP.Access nanoBTS works behind a NAT with OpenBSC ? >> >> i.e. two BTSs in two different locations behind NAT connecting to NITB. >> im trying to make a call, but it seems rtp has some problem. >> > hi kelum, > > the NAT firewall should track the RTP frames from BTS behind NAT, so that > frames from BSC outside NAT can find their way to the BTS. i suggest to > sniff (tcpdump/wireshark) behind and before NAT, in order to localize the > problem. > > regards, > > andreas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Sat Jan 26 17:24:32 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 26 Jan 2013 18:24:32 +0100 Subject: OpenBSC with LCR/SIP In-Reply-To: <50FF940F.7040803@eversberg.eu> References: <50FF940F.7040803@eversberg.eu> <507D1926.8070504@eversberg.eu> <50FF940F.7040803@eversberg.eu> Message-ID: <20130126172432.18766.qmail@stuge.se> Andreas Eversberg wrote: > the NAT firewall should track the RTP frames Nik Pakar wrote: > this is this mean a BTS behind NAT and a OpenBSC > +LCR/freeswitch + sip phone on freeswitch will be able to > communicate with good RTP ? I think Andreas wrote pretty clearly that it depends on if the NAT firewall can and will track RTP or not; it has nothing to do with the software on either side. Follow Andreas' advice and experiment with different configurations while studying the packets on both sides of the firewall. //Peter From kelum.nava at gmail.com Sat Jan 26 16:20:24 2013 From: kelum.nava at gmail.com (Kelum Navaratne) Date: Sat, 26 Jan 2013 21:50:24 +0530 Subject: OpenBSC with LCR/SIP In-Reply-To: <507D1926.8070504@eversberg.eu> References: <507D1926.8070504@eversberg.eu> Message-ID: Hello andreas, Im trying to get the jolly/new branch of lcr, but there is no such branch on the tree. below is my output. can you please let me know whether im checking out from the right repo. root at debian:/software/lcr# git clone git://git.misdn.eu/lcr.git/ Cloning into lcr... remote: Counting objects: 3695, done. remote: Compressing objects: 100% (1328/1328), done. remote: Total 3695 (delta 2716), reused 3226 (delta 2353) Receiving objects: 100% (3695/3695), 5.76 MiB | 8.27 MiB/s, done. Resolving deltas: 100% (2716/2716), done. root at debian:/software/lcr/lcr# git branch -a * master remotes/origin/1.10 remotes/origin/1.11 remotes/origin/1.13 remotes/origin/1.8 remotes/origin/1.9 remotes/origin/HEAD -> origin/master remotes/origin/holger/cleaning remotes/origin/holger/cleaning-rebased remotes/origin/jolly/vootp remotes/origin/master remotes/origin/pending root at debian:/software/lcr/lcr# On Tue, Oct 16, 2012 at 1:51 PM, Andreas Eversberg wrote: > hi kelum, > > in order to use sip, you need jolly/new branch of lcr and jolly/rtpmux of > openbsc. the sip implementation of LCR is quite simple, so no > authentication or oder features - just simple point-to-point SIP. if you > run confiure of LCR, check if sip is enabled. in order to add a SIP > interface, do the following at interface.conf: > > [sip] > sip [:] [:] > earlyb yes > tones no > > you need to define local IP that will be used to connect to remote SIP > endpoint. don't use localhost, if the endpoint is on a different machine, > because this IP is also used for RTP. if you use same machine, you need to > have different ports. you may change local port, by adding a local port or > you may change port of SIP endpoint and then add remote port. > > i have tested it with freeswitch, but asterisk should work also. > > you may then also try at interface.conf below "[sip]" definition: > > rtp-brige > > then the codec (full rate or enhanced full rate) is negotiated between > mobile and the remote SIP endpoint. the SIP endpoint must support at least > one of it. > > regards, > > andreas > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Sat Jan 26 17:47:52 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 26 Jan 2013 18:47:52 +0100 Subject: OpenBSC with LCR/SIP In-Reply-To: References: <507D1926.8070504@eversberg.eu> Message-ID: <20130126174752.23738.qmail@stuge.se> Kelum Navaratne wrote: > Im trying to get the jolly/new branch of lcr Seriously? Come on.. > On Tue, Oct 16, 2012 at 1:51 PM, Andreas Eversberg wrote: > > in order to use sip, you need jolly/new branch of lcr Guess if there was some activity in the repository in the last three months? Oh wait - this is open source, so actually you don't have to guess. You can use the git log command to study the commit history and IMMEDIATELY see what development has happened in the repository. I suggest that you try that now. If you are more ambitious then you will of course additionally read the git-log manual, where you will find that you can use various methods to search the repository history. You might come up with a command like: git log --all -i --grep=rtp ..which you can follow up with a command like: git branch --contains insert_commit_id_here ..to learn which branches contain the most interesting commits. I advise you to study git, so that you will be able to use source code managed in git repositories. If you don't know the tools then you're very limited, and the OpenBSC community is obviously the wrong place for git training. There are plenty of resources online. I recommend studying the free-as-in-beer book called Pro Git. Ask google.com about it. //Peter From andreas at eversberg.eu Sat Jan 26 18:31:05 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Sat, 26 Jan 2013 19:31:05 +0100 Subject: OpenBSC with LCR/SIP In-Reply-To: References: <507D1926.8070504@eversberg.eu> Message-ID: <510420E9.7020604@eversberg.eu> Kelum Navaratne wrote: > Im trying to get the jolly/new branch of lcr, but there is no such > branch on the tree. below is my output. can you please let me know > whether im checking out from the right repo. hi kelum, it's gone - deleted. because it's already merged with master. regards, andreas From holger at freyther.de Tue Jan 8 18:40:46 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 8 Jan 2013 19:40:46 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20121123100656.GB11815@xiaoyu.lan> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> Message-ID: <20130108184046.GD20797@xiaoyu.lan> On Fri, Nov 23, 2012 at 11:06:56AM +0100, Holger Hans Peter Freyther wrote: > On Thu, Nov 22, 2012 at 10:36:34PM +0100, Pablo Neira Ayuso wrote: > > Hi Holger! Hi Pablo, this is still an issue for running the SGSN/GBproxy. Do you have an uptime in regard to the proper fix? I am going to land the workaround soon but I am interested in getting the real fix into glibc. Can you help? holger From pablo at gnumonks.org Sat Jan 12 23:30:33 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Jan 2013 00:30:33 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20130108184046.GD20797@xiaoyu.lan> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> <20130108184046.GD20797@xiaoyu.lan> Message-ID: <20130112233033.GA32099@1984> On Tue, Jan 08, 2013 at 07:40:46PM +0100, Holger Hans Peter Freyther wrote: > On Fri, Nov 23, 2012 at 11:06:56AM +0100, Holger Hans Peter Freyther wrote: > > On Thu, Nov 22, 2012 at 10:36:34PM +0100, Pablo Neira Ayuso wrote: > > > Hi Holger! > > Hi Pablo, > > this is still an issue for running the SGSN/GBproxy. Do you have an > uptime in regard to the proper fix? I am going to land the workaround > soon but I am interested in getting the real fix into glibc. Can you > help? Just filed the bug to glibc, you can track it here: http://sourceware.org/bugzilla/show_bug.cgi?id=15015 Sorry for lagging with this. From holger at freyther.de Sun Jan 13 00:24:13 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 13 Jan 2013 01:24:13 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20130112233033.GA32099@1984> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> <20130108184046.GD20797@xiaoyu.lan> <20130112233033.GA32099@1984> Message-ID: <20130113002412.GF13351@xiaoyu.lan> On Sun, Jan 13, 2013 at 12:30:33AM +0100, Pablo Neira Ayuso wrote: > Just filed the bug to glibc, you can track it here: > > http://sourceware.org/bugzilla/show_bug.cgi?id=15015 > > Sorry for lagging with this. thanks! any idea of a non ugly work-around. Even if it is glibc bug, and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it. holger From peter at stuge.se Sun Jan 13 08:06:32 2013 From: peter at stuge.se (Peter Stuge) Date: Sun, 13 Jan 2013 09:06:32 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20130113002412.GF13351@xiaoyu.lan> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> <20130108184046.GD20797@xiaoyu.lan> <20130112233033.GA32099@1984> <20130113002412.GF13351@xiaoyu.lan> Message-ID: <20130113080633.18842.qmail@stuge.se> Holger Hans Peter Freyther wrote: > > http://sourceware.org/bugzilla/show_bug.cgi?id=15015 > > thanks! any idea of a non ugly work-around. Even if it is glibc bug, > and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it. I would fall back to the same solution as for the other things that RHEL, Debian & co don't do the way I prefer: Build a replacement. But at least for Ubuntu I would expect them to be happy to apply a patch onto of their glibc package to fix this, as long as there is a launchpad bug demonstrating some concrete need - ideally backed by some paying canonical customers. :) I believe you can get any change you want into Red Hat as long as you have support and sponsorship from one of their employees. For minimum effort make friends with their glibc package maintainer. I have unsuccessfully been trying to communicate with the debian glibc package maintainer for some 8 months by now and he hasn't replied, so I think you are right that debian will "never" add a patch for fixing this, and even if they do I guess it takes some five years before that arrives to users. //Peter From pablo at gnumonks.org Sun Jan 13 23:25:37 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 14 Jan 2013 00:25:37 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20130113002412.GF13351@xiaoyu.lan> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> <20130108184046.GD20797@xiaoyu.lan> <20130112233033.GA32099@1984> <20130113002412.GF13351@xiaoyu.lan> Message-ID: <20130113232537.GA1123@1984> On Sun, Jan 13, 2013 at 01:24:13AM +0100, Holger Hans Peter Freyther wrote: > On Sun, Jan 13, 2013 at 12:30:33AM +0100, Pablo Neira Ayuso wrote: > > > Just filed the bug to glibc, you can track it here: > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=15015 > > > > Sorry for lagging with this. > > thanks! any idea of a non ugly work-around. Even if it is glibc bug, > and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it. Attached a workaround patch. It's a bit of cheating, but it allows us to obtain the address information from the kernel, which is what you need. As Peter mentioned, let's find a fast path to resolve this until some fix lands on glibc. Let me know! Regards. From pablo at gnumonks.org Sun Jan 13 23:12:28 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 14 Jan 2013 00:12:28 +0100 Subject: [PATCH] socket: fix osmo_sock_init with SOCK_RAW and IPPROTO_RAW Message-ID: getaddrinfo returns EAI_SERVICE (-8) if that combination is used. More information available in here: http://sourceware.org/bugzilla/show_bug.cgi?id=15015 Reported by Holger Hans Peter Freyther. While at it, this patch also removes hints.ai_flags = 0 as memset to zero already happened just a bit before that. --- src/socket.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/src/socket.c b/src/socket.c index 53205cd..0f41275 100644 --- a/src/socket.c +++ b/src/socket.c @@ -54,9 +54,16 @@ int osmo_sock_init(uint16_t family, uint16_t type, uint8_t proto, sprintf(portbuf, "%u", port); memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_family = family; - hints.ai_socktype = type; - hints.ai_flags = 0; - hints.ai_protocol = proto; + if (type == SOCK_RAW) { + /* Workaround for glibc, that returns EAI_SERVICE (-8) if + * SOCK_RAW and IPPROTO_GRE is used. + */ + hints.ai_socktype = SOCK_DGRAM; + hints.ai_protocol = IPPROTO_UDP; + } else { + hints.ai_socktype = type; + hints.ai_protocol = proto; + } if (flags & OSMO_SOCK_F_BIND) hints.ai_flags |= AI_PASSIVE; -- 1.7.10.4 --IS0zKkzwUGydFO0o-- From pablo at gnumonks.org Mon Jan 14 07:12:16 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 14 Jan 2013 08:12:16 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20130113232537.GA1123@1984> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> <20130108184046.GD20797@xiaoyu.lan> <20130112233033.GA32099@1984> <20130113002412.GF13351@xiaoyu.lan> <20130113232537.GA1123@1984> Message-ID: <20130114071216.GA32685@1984> On Mon, Jan 14, 2013 at 12:25:37AM +0100, Pablo Neira Ayuso wrote: > On Sun, Jan 13, 2013 at 01:24:13AM +0100, Holger Hans Peter Freyther wrote: > > On Sun, Jan 13, 2013 at 12:30:33AM +0100, Pablo Neira Ayuso wrote: > > > > > Just filed the bug to glibc, you can track it here: > > > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=15015 > > > > > > Sorry for lagging with this. > > > > thanks! any idea of a non ugly work-around. Even if it is glibc bug, > > and it will be fixed.. RHEL, Debian 6.0 will unlikely patch it. > > Attached a workaround patch. It's a bit of cheating, but it allows us > to obtain the address information from the kernel, which is what you > need. As Peter mentioned, let's find a fast path to resolve this until > some fix lands on glibc. > > Let me know! Patch was incomplete, sorry. New version attached. From pablo at gnumonks.org Sun Jan 13 23:12:28 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 14 Jan 2013 00:12:28 +0100 Subject: [PATCH] socket: fix osmo_sock_init with SOCK_RAW and IPPROTO_RAW Message-ID: getaddrinfo returns EAI_SERVICE (-8) if that combination is used. More information available in here: http://sourceware.org/bugzilla/show_bug.cgi?id=15015 Reported by Holger Hans Peter Freyther. While at it, this patch also removes hints.ai_flags = 0 as memset to zero already happened just a bit before that. --- src/socket.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/src/socket.c b/src/socket.c index 53205cd..a5530d0 100644 --- a/src/socket.c +++ b/src/socket.c @@ -54,9 +54,16 @@ int osmo_sock_init(uint16_t family, uint16_t type, uint8_t proto, sprintf(portbuf, "%u", port); memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_family = family; - hints.ai_socktype = type; - hints.ai_flags = 0; - hints.ai_protocol = proto; + if (type == SOCK_RAW) { + /* Workaround for glibc, that returns EAI_SERVICE (-8) if + * SOCK_RAW and IPPROTO_GRE is used. + */ + hints.ai_socktype = SOCK_DGRAM; + hints.ai_protocol = IPPROTO_UDP; + } else { + hints.ai_socktype = type; + hints.ai_protocol = proto; + } if (flags & OSMO_SOCK_F_BIND) hints.ai_flags |= AI_PASSIVE; @@ -68,6 +75,12 @@ int osmo_sock_init(uint16_t family, uint16_t type, uint8_t proto, } for (rp = result; rp != NULL; rp = rp->ai_next) { + /* Workaround for glibc again */ + if (type == SOCK_RAW) { + rp->ai_socktype = SOCK_RAW; + rp->ai_protocol = proto; + } + sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol); if (sfd == -1) continue; -- 1.7.10.4 --EeQfGwPcQSOJBaQU-- From holger at freyther.de Mon Jan 14 07:37:17 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 14 Jan 2013 08:37:17 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20130113232537.GA1123@1984> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> <20130108184046.GD20797@xiaoyu.lan> <20130112233033.GA32099@1984> <20130113002412.GF13351@xiaoyu.lan> <20130113232537.GA1123@1984> Message-ID: <20130114073717.GR13351@xiaoyu.lan> On Mon, Jan 14, 2013 at 12:25:37AM +0100, Pablo Neira Ayuso wrote: Hi, this appears to be only half of the fix. > - hints.ai_socktype = type; > - hints.ai_flags = 0; > - hints.ai_protocol = proto; > + if (type == SOCK_RAW) { > + /* Workaround for glibc, that returns EAI_SERVICE (-8) if > + * SOCK_RAW and IPPROTO_GRE is used. > + */ > + hints.ai_socktype = SOCK_DGRAM; > + hints.ai_protocol = IPPROTO_UDP; > + } else { > + hints.ai_socktype = type; > + hints.ai_protocol = proto; > + } now rp->ai_socktype will be SOCK_DGRAM and rp->ai_protocol UDP. So the 'raw' socket for GRE will be a datagram socket for UDP. E.g. you need the second hunk from my workaround[1]. I just wondered if you could think about a better way (one that can be easily dumped or ifdefed without putting the special case in the middle). holger [1] https://build.opensuse.org/package/view_file?expand=1&file=raw-socket.patch&package=libosmocore&project=home%3Azecke23 From pablo at gnumonks.org Mon Jan 14 11:05:10 2013 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Mon, 14 Jan 2013 12:05:10 +0100 Subject: osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW In-Reply-To: <20130114073717.GR13351@xiaoyu.lan> References: <20121107142114.GA15242@xiaoyu.lan> <20121122213634.GA14200@1984> <20121123100656.GB11815@xiaoyu.lan> <20130108184046.GD20797@xiaoyu.lan> <20130112233033.GA32099@1984> <20130113002412.GF13351@xiaoyu.lan> <20130113232537.GA1123@1984> <20130114073717.GR13351@xiaoyu.lan> Message-ID: <20130114110510.GA16463@1984> On Mon, Jan 14, 2013 at 08:37:17AM +0100, Holger Hans Peter Freyther wrote: > On Mon, Jan 14, 2013 at 12:25:37AM +0100, Pablo Neira Ayuso wrote: > > Hi, > > this appears to be only half of the fix. > > > - hints.ai_socktype = type; > > - hints.ai_flags = 0; > > - hints.ai_protocol = proto; > > + if (type == SOCK_RAW) { > > + /* Workaround for glibc, that returns EAI_SERVICE (-8) if > > + * SOCK_RAW and IPPROTO_GRE is used. > > + */ > > + hints.ai_socktype = SOCK_DGRAM; > > + hints.ai_protocol = IPPROTO_UDP; > > + } else { > > + hints.ai_socktype = type; > > + hints.ai_protocol = proto; > > + } > > > now rp->ai_socktype will be SOCK_DGRAM and rp->ai_protocol UDP. So the 'raw' > socket for GRE will be a datagram socket for UDP. > > E.g. you need the second hunk from my workaround[1]. I just wondered if you > could think about a better way (one that can be easily dumped or ifdefed > without putting the special case in the middle). Indeed. I noticed just after waking up in the morning while having breakfast. Please, check the new patch I sent you. Thanks. From yannm1 at hotmail.com Fri Jan 4 11:48:44 2013 From: yannm1 at hotmail.com (Yann R. Moupinda) Date: Fri, 4 Jan 2013 12:48:44 +0100 Subject: sysmoBTS doesn't start In-Reply-To: <20121127154809.GF30675@xiaoyu.lan> References: , <20121122181323.GE25233@xiaoyu.lan>, , , <20121127154809.GF30675@xiaoyu.lan> Message-ID: Hi guys, I have a sysmoBTS from sysmocom and last time i used it (for 3 weeks) everything was working well. Yesterday i wanted to do some tests and the device didn't start up. I think there are some problems by the booting process, here are the logging data: Board revision: C.3 Initializing NAND flash: Bypassing ECC checks ID:0xA1, 8-bit bus Blocks: 0x00400, Pages/block: 0x040, Bytes per page: 0x0800 BootMode = NAND I_ME UART_TIMEOUT Image infos: Magic = 0xA1ACED77, Entry = 0x84000000, Pages = 0x000000B9, Load = 0x84000000 Starting app at: 0x84000000 U-Boot 2011.12-g5ee9b97 (Aug 15 2012 - 21:35:37) Cores: ARM 405 MHz, DSP 810 MHz DDR: 189 MHz I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: 128 MiB Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x000000880000 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: DaVinci-EMAC Creating 1 MTD partitions on "nand0": 0x000000100000-0x000008000000 : "mtd=3" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=3" UBI: MTD device size: 127 MiB UBI: number of good PEBs: 1011 UBI: number of bad PEBs: 5 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 1011 UBI: number of PEBs reserved for bad PEB handling: 10 UBI: max/mean erase counter: 71/16 has anybody an idea how i can overcome this problem ? best regards Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Jan 1 21:16:52 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 1 Jan 2013 22:16:52 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20121231173736.GD21955@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: Hi, > I personally percevied OsmoDevCon 2012 as a big success, and it was fun > to bring everyone together. Same here and definitely looking forward to the 2013 edition ! > Generally, I prefer to keep the spirit of an invitation-only > developer+contributor-only event of those involved in Osmocom. +1 > At the same time, I would consider it a good idea to add a one day > user-conference to the schedule, where we try to get interested users up > to speed with the various projects, possibly including some workshops > and the like. Sure, could be nice. This might have some impact on logistics though since that means we may require significantly more space for the 'public' side that for the contributors only part, (and even possibly several rooms for workshops ?) > The concept of "hacking days" has proven to be quite useful for the > netfilter project in the past (Pablo and I can acknowledge to that > fact). I'm not sure how many people would be able to spend even more > days of their schedule, but even if it's a much smaller group it would > still be useful, IMHO. Yes, that's something we actually brought up during 29C3 that doing some hacking would definitely be a great idea. Last year we kinda planned of doing that in the evening but with day packed full of talk and then just general social interaction, we pretty much never got around to it. Now what I'm not yet sure is if it's best to have dedicated presentation / hacking days or to have hacking sessions on specific topic during the general schedule. > 2) consider whether late march (like 2012) would be a good schedule > again For me late march is fine. > 3) what we can improve from the last event The only thing that comes to mind was the "hacking" part and that's covered above. A south-east non-shielded window with visibility down to 20deg elevation maybe ... > Venue-wise, I would again suggest to hold it in Berlin, as it's > reasonbly well connected, has lots of low-cost flights to it, > accomodation is not too expensive and holger/me/sysmocom can take care > of local organization related activities. Hoewver, if somebody has a > strong opinion against berlin _and_ is willing to organize it, I'm not > completely against another venue. Damn, I was so looking forward to holding it in Dubai :p Cheers, Sylvain From laforge at gnumonks.org Wed Jan 2 15:46:55 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 Jan 2013 16:46:55 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: <20130102154655.GC21354@prithivi.gnumonks.org> On Tue, Jan 01, 2013 at 10:16:52PM +0100, Sylvain Munaut wrote: > This might have some impact on logistics though since that means we > may require significantly more space for the 'public' side that for > the contributors only part, (and even possibly several rooms for > workshops ?) I don't think that's much of a problem. Sure, it will have to be different rooms, maybe even at a different location in Berlin. In case of lack of better ideas, we could consider using the large c-base main hall for the user day, I'm quite sure it would be sufficient, size-wise. Also, one might be able to get some room at a university. In fact, given that some folks at TU Berlin are using OsmocomBB and even OpenBSC + sysmoBTS, it might be an option to consider. > Now what I'm not yet sure is if it's best to have dedicated > presentation / hacking days or to have hacking sessions on specific > topic during the general schedule. i think splitting them from the main part of the OsmoDevCon has the advantage that not everyone has to be there during all the days. > > 2) consider whether late march (like 2012) would be a good schedule > > again > > For me late march is fine. ok, then I'll start to look for a venue that's available during that timeframe. > A south-east non-shielded window with visibility down to 20deg > elevation maybe ... heh. well, I think considering that would make the search quite more difficult... 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 dburgess at jcis.net Wed Jan 2 03:23:35 2013 From: dburgess at jcis.net (David A. Burgess) Date: Tue, 1 Jan 2013 19:23:35 -0800 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20121231173736.GD21955@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> Harald - Am 31.12.2012 um 09:37 schrieb Harald Welte : > Hi all, > > as the year 2012 has already ended or will soon end depending on your > timezone, it might be a good occasion to start thinking of an OsmoDevCon > 2013. > > I personally percevied OsmoDevCon 2012 as a big success, and it was fun > to bring everyone together. I agree. And while I am not a direct participant in Osmocom, I would like participate in this event again and contribute in some way that others find useful. > > Generally, I prefer to keep the spirit of an invitation-only > developer+contributor-only event of those involved in Osmocom. At the > same time, I would consider it a good idea to add a one day > user-conference to the schedule, where we try to get interested users up > to speed with the various projects, possibly including some workshops > and the like. I would be interested in attending an user-oriented OsmocomBB event. > > So schedule-wise, I would suggest something like: > > * one day user conference > * two day developer/contributor event > * optionally: 1-2 "hacking days". > > The concept of "hacking days" has proven to be quite useful for the > netfilter project in the past (Pablo and I can acknowledge to that > fact). I'm not sure how many people would be able to spend even more > days of their schedule, but even if it's a much smaller group it would > still be useful, IMHO. To go to Berlin from San Francisco, I spend about 16 hours in transit each way. So once I am there, I might as well stay a few days. :) I would hope to find others interested in working on project that overlaps with OpenBTS, like Sylvain's recent handset-cum-femtocell project, or an SMSCB that both projects can use. > > I'd like you to > > 1) provide feedback on the ideas about the one-day user event and the > hacking days These sound like good additions. > 2) consider whether late march (like 2012) would be a good schedule > against My own preference would be either early March, immediately after the GSM World Congress (so anyone attending both from outside Europe can combine travel) or as late in March as possible or even in April to give some turn-around time between trips. > 3) what we can improve from the last event This may sound odd coming from me, but unless this is explicitly intended to be a broad "FOSS cellular" event, broader than Osmocom, I would prefer to discuss OpenBTS only to the degree that the projects overlap or might interoperate. I think more discussion of topics like SIM acquisition, SIM applications, SS7-MAP and core network integration would be great. I think the public-vs-commercial discussion of OpenBTS was weird and inappropriate for the audience. More discussion of analog radio topics, like antenna selection and propagation, including specific case studies, might be a good addition if there is interest. > > In terms of improvements, I so far have noted down: > * larger venue needs to be found > * complaints about the venue not having sufficient heating C-Base has its charms, but I agree with these. > > Venue-wise, I would again suggest to hold it in Berlin, as it's > reasonbly well connected, has lots of low-cost flights to it, > accomodation is not too expensive and holger/me/sysmocom can take care > of local organization related activities. Hoewver, if somebody has a > strong opinion against berlin _and_ is willing to organize it, I'm not > completely against another venue. I welcome any excuse to visit Berlin. I would personally prefer a venue in or near Mitte, and certainly near an U-Banhhof. > > Regards and happy new year, > 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 Wed Jan 2 16:15:06 2013 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 Jan 2013 17:15:06 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> References: <20121231173736.GD21955@prithivi.gnumonks.org> <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> Message-ID: <20130102161506.GD21354@prithivi.gnumonks.org> Hi David, On Tue, Jan 01, 2013 at 07:23:35PM -0800, David A. Burgess wrote: > I agree. And while I am not a direct participant in Osmocom, I would > like participate in this event again and contribute in some way that > others find useful. great, your presence is appreciated. > > 2) consider whether late march (like 2012) would be a good schedule > > against > > My own preference would be either early March, immediately after the > GSM World Congress (so anyone attending both from outside Europe can > combine travel) or as late in March as possible or even in April to > give some turn-around time between trips. I think very early march after MWC might be a bit challenging to organize given the limited lead-time. Late in march might be overlapping with Easter holidays, where people might have holiday plans, or attend other events like EasterHegg. So personally, I think early April might be a better choice then. Question to the list at large: Would you prefer or avoid overlap with Easter? > This may sound odd coming from me, but unless this is explicitly > intended to be a broad "FOSS cellular" event, broader than Osmocom, I > would prefer to discuss OpenBTS only to the degree that the projects > overlap or might interoperate. I understand that position and don't mind it at all. 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 Thu Jan 3 23:13:16 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 4 Jan 2013 00:13:16 +0100 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20130102161506.GD21354@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> <20130102161506.GD21354@prithivi.gnumonks.org> Message-ID: > Question to the list at large: Would you prefer or avoid overlap with > Easter? Maybe a slight preference since it means taking less days off work ... but really it doesn't change much to me. Cheers, Sylvain From dburgess at jcis.net Thu Jan 3 23:21:19 2013 From: dburgess at jcis.net (David A. Burgess) Date: Thu, 3 Jan 2013 15:21:19 -0800 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: References: <20121231173736.GD21955@prithivi.gnumonks.org> <85A5FA0C-E870-4A62-B66C-AE32C52112C7@jcis.net> <20130102161506.GD21354@prithivi.gnumonks.org> Message-ID: <39AB0CE8-535D-4052-B37C-AAB27E7CA85F@jcis.net> I would prefer not to overlap, since for me this actually counts as "work". I guess I'm lucky that way. And I will probably try to schedule other business in Europe around this event, so keeping it away from Easter gives me more flexibility. On Jan 3, 2013, at 3:13 PM, Sylvain Munaut wrote: >> Question to the list at large: Would you prefer or avoid overlap with >> Easter? > > Maybe a slight preference since it means taking less days off work ... > but really it doesn't change much to me. > > > Cheers, > > Sylvain From alexander.chemeris at gmail.com Fri Jan 4 11:04:55 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 4 Jan 2013 15:04:55 +0400 Subject: OsmoDevCon 2013 brainstorming In-Reply-To: <20121231173736.GD21955@prithivi.gnumonks.org> References: <20121231173736.GD21955@prithivi.gnumonks.org> Message-ID: Hi Harald, On Mon, Dec 31, 2012 at 9:37 PM, Harald Welte wrote: > as the year 2012 has already ended or will soon end depending on your > timezone, it might be a good occasion to start thinking of an OsmoDevCon > 2013. > > I personally percevied OsmoDevCon 2012 as a big success, and it was fun > to bring everyone together. +1 > Generally, I prefer to keep the spirit of an invitation-only > developer+contributor-only event of those involved in Osmocom. At the > same time, I would consider it a good idea to add a one day > user-conference to the schedule, where we try to get interested users up > to speed with the various projects, possibly including some workshops > and the like. I second this. > So schedule-wise, I would suggest something like: > > * one day user conference > * two day developer/contributor event > * optionally: 1-2 "hacking days". > > The concept of "hacking days" has proven to be quite useful for the > netfilter project in the past (Pablo and I can acknowledge to that > fact). I'm not sure how many people would be able to spend even more > days of their schedule, but even if it's a much smaller group it would > still be useful, IMHO. > > I'd like you to > > 1) provide feedback on the ideas about the one-day user event Tutorials and status updates? > and the hacking days Bug hunting&fixing (e.g. in osmosgsn), writing unit tests, architecture changes discussions? > 2) consider whether late march (like 2012) would be a good schedule > again I'm very much willing to attend and the lest week of March is very inconvenient for me due to other activities I participate in. April is much better (and warmer). > 3) what we can improve from the last event > > In terms of improvements, I so far have noted down: > * larger venue needs to be found > * complaints about the venue not having sufficient heating Yes, being at a warm place helps a lot. From noselasd at fiane.dyndns.org Wed Jan 2 23:58:01 2013 From: noselasd at fiane.dyndns.org (noselasd at fiane.dyndns.org) Date: Thu, 03 Jan 2013 00:58:01 +0100 Subject: [PATCH] libosmocore osmo_revbytebits_buf stack trashing Message-ID: <50E4C989.6030405@fiane.dyndns.org> Hi, The second loop in osmo_revbytebits_buf() in src/bits.c grabs 4 bytes each iteration, which can easily go past the supplied input in some cases. Compiled with -fstack-protector , I get a "stack smashing detected" in the bits test. Attached patch should deal with that. -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo_revbytebits_buf-check.patch Type: text/x-patch Size: 382 bytes Desc: not available URL: From 246tnt at gmail.com Thu Jan 3 08:36:57 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 3 Jan 2013 09:36:57 +0100 Subject: [PATCH] libosmocore osmo_revbytebits_buf stack trashing In-Reply-To: <50E4C989.6030405@fiane.dyndns.org> References: <50E4C989.6030405@fiane.dyndns.org> Message-ID: Hi, > The second loop in osmo_revbytebits_buf() in src/bits.c grabs 4 bytes > each iteration, which can easily go past the supplied input in some > cases. Compiled with -fstack-protector , I get a "stack smashing detected" > in the bits test. nice catch. Applied. Cheers, Sylvain From 246tnt at gmail.com Sat Jan 5 14:52:03 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 5 Jan 2013 15:52:03 +0100 Subject: [PATCH] core/msgb: Change return value of msgb_pull to the start of pulled header Message-ID: <1357397523-29643-1-git-send-email-246tnt@gmail.com> From: Sylvain Munaut Currently msgb_pull returns a pointer to the new start of msgb, which is pretty counter intuitive and when using msgb_pull is often annoying. For eg, the msgb_pull_u{8,16,32} were previously "fixed" for this quirk in a previous commit. The msgb_pull_l2h in lapdm is also wrong because of this, same for code in osmocom-bb loader. AFAICT, the current users of msgb_pull either don't care about the return value, or expect it to be a pointer to the pulled header and not the new start of msgb (and so are currently buggy). Without this patch, you have things like: struct foo *bar = msgb_pull(msg, sizeof(struct foo)) - sizeof(struct foo) With the patch, you have: struct foo *bar = msgb_pull(msg, sizeof(struct foo)); which is IMHO a much better style. Signed-off-by: Sylvain Munaut --- include/osmocom/core/msgb.h | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index a1939ab..4a72f2d 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -287,16 +287,18 @@ static inline unsigned char *msgb_push(struct msgb *msgb, unsigned int len) /*! \brief remove (pull) a header from the front of the message buffer * \param[in] msgb message buffer * \param[in] len number of octets to be pulled - * \returns pointer to new start of msgb + * \returns pointer to header that's been pulled (i.e. previous start of msgb) * * This function moves the \a data pointer of the \ref msgb further back * in the message, thereby shrinking the size of the message by \a len * bytes. */ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) -{ +{ + unsigned char *tmp = msgb->data; msgb->len -= len; - return msgb->data += len; + msgb->data += len; + return tmp; } /*! \brief remove uint8 from front of message @@ -305,7 +307,7 @@ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) */ static inline uint8_t msgb_pull_u8(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 1) - 1; + uint8_t *space = msgb_pull(msgb, 1); return space[0]; } /*! \brief remove uint16 from front of message @@ -314,7 +316,7 @@ static inline uint8_t msgb_pull_u8(struct msgb *msgb) */ static inline uint16_t msgb_pull_u16(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 2) - 2; + uint8_t *space = msgb_pull(msgb, 2); return space[0] << 8 | space[1]; } /*! \brief remove uint32 from front of message @@ -323,7 +325,7 @@ static inline uint16_t msgb_pull_u16(struct msgb *msgb) */ static inline uint32_t msgb_pull_u32(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 4) - 4; + uint8_t *space = msgb_pull(msgb, 4); return space[0] << 24 | space[1] << 16 | space[2] << 8 | space[3]; } -- 1.7.8.6 From hwit at a-domani.nl Sat Jan 5 16:56:50 2013 From: hwit at a-domani.nl (Hans Witvliet) Date: Sat, 05 Jan 2013 17:56:50 +0100 Subject: fosdem? Message-ID: <1357405010.19268.17.camel@t43.lan0.a-domani.nl> hi all, Any chance of giving presentation/demo at fosdem (1+2 feb)? Hans From 246tnt at gmail.com Sun Jan 6 17:35:57 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 6 Jan 2013 18:35:57 +0100 Subject: fosdem? In-Reply-To: <1357405010.19268.17.camel@t43.lan0.a-domani.nl> References: <1357405010.19268.17.camel@t43.lan0.a-domani.nl> Message-ID: Hi, > Any chance of giving presentation/demo at fosdem (1+2 feb)? I'll be there but I didn't submit anything to the cfp ... Cheers, Sylvain From laforge at gnumonks.org Mon Jan 7 08:19:34 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 7 Jan 2013 09:19:34 +0100 Subject: fosdem? In-Reply-To: References: <1357405010.19268.17.camel@t43.lan0.a-domani.nl> Message-ID: <20130107081934.GG11773@prithivi.gnumonks.org> Hi all, On Sun, Jan 06, 2013 at 06:35:57PM +0100, Sylvain Munaut wrote: > > Any chance of giving presentation/demo at fosdem (1+2 feb)? OpenBSC is so old these days, it doesn't make sense to present in 2013 something that exists since 2009. > I'll be there but I didn't submit anything to the cfp ... Same for me, and traditionally for a number of people involved with Osmocom. At least at past FOSDEMs, there were Stefan Schmidt, Daniel Willmann, Holger Freyther, to name a few. I'll be spending some time at a panel in the Legal DevRoom. 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 Jan 17 10:39:45 2013 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Jan 2013 11:39:45 +0100 Subject: Documentation for Control interface in wiki? Message-ID: <20130117103945.GG8380@prithivi.gnumonks.org> Hi Daniel, today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers and realised that there is no wiki page describing what the control protocol is (which I would ahve linked from PortNumbers). I know at the time you first posted the control interface patches to the list, there was some README/Documentation. Could you please add that to a wiki page, possibly reviewing/updating it to reflect today's control interface? Thanks in advance, Harald -- - 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 Thu Jan 17 16:39:31 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 17 Jan 2013 17:39:31 +0100 Subject: Documentation for Control interface in wiki? In-Reply-To: <20130117103945.GG8380@prithivi.gnumonks.org> References: <20130117103945.GG8380@prithivi.gnumonks.org> Message-ID: <20130117163931.GB11906@xiaoyu.lan> On Thu, Jan 17, 2013 at 11:39:45AM +0100, Harald Welte wrote: > Hi Daniel, Hi, > > today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers > and realised that there is no wiki page describing what the control > protocol is (which I would ahve linked from PortNumbers). the protocol is described in doc/control-interface.txt the commands are not documented. holger From holger at freyther.de Thu Jan 17 16:45:35 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 17 Jan 2013 17:45:35 +0100 Subject: Documentation for Control interface in wiki? In-Reply-To: <20130117103945.GG8380@prithivi.gnumonks.org> References: <20130117103945.GG8380@prithivi.gnumonks.org> Message-ID: <20130117164535.GC11906@xiaoyu.lan> On Thu, Jan 17, 2013 at 11:39:45AM +0100, Harald Welte wrote: > Hi Daniel, > > today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers > and realised that there is no wiki page describing what the control > protocol is (which I would ahve linked from PortNumbers). how to sort? TCP first, then UDP or interlevaed? holger From laforge at gnumonks.org Thu Jan 17 16:51:31 2013 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Jan 2013 17:51:31 +0100 Subject: Documentation for Control interface in wiki? In-Reply-To: <20130117164535.GC11906@xiaoyu.lan> References: <20130117103945.GG8380@prithivi.gnumonks.org> <20130117164535.GC11906@xiaoyu.lan> Message-ID: <20130117165131.GA10957@prithivi.gnumonks.org> Hi Holger, On Thu, Jan 17, 2013 at 05:45:35PM +0100, Holger Hans Peter Freyther wrote: > > today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers > > and realised that there is no wiki page describing what the control > > protocol is (which I would ahve linked from PortNumbers). > > how to sort? TCP first, then UDP or interlevaed? do we care about such details? as long as there is some order (currently TCP first, then by port number ascending, then UDP by port number ascending) it doesn't matter. -- - 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 Thu Jan 17 17:22:29 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 17 Jan 2013 18:22:29 +0100 Subject: Documentation for Control interface in wiki? In-Reply-To: <20130117165131.GA10957@prithivi.gnumonks.org> References: <20130117103945.GG8380@prithivi.gnumonks.org> <20130117164535.GC11906@xiaoyu.lan> <20130117165131.GA10957@prithivi.gnumonks.org> Message-ID: <20130117172229.GB12965@xiaoyu.lan> On Thu, Jan 17, 2013 at 05:51:31PM +0100, Harald Welte wrote: > do we care about such details? as long as there is some order (currently > TCP first, then by port number ascending, then UDP by port number > ascending) it doesn't matter. I just added the content but it might have been you had something specific in mind and there is no reason to cause additional re-sort work. :) holger From andreas at eversberg.eu Thu Jan 17 17:26:53 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 17 Jan 2013 18:26:53 +0100 Subject: Documentation for Control interface in wiki? In-Reply-To: <20130117164535.GC11906@xiaoyu.lan> References: <20130117103945.GG8380@prithivi.gnumonks.org> <20130117164535.GC11906@xiaoyu.lan> Message-ID: <50F8345D.6000306@eversberg.eu> Holger Hans Peter Freyther wrote: > On Thu, Jan 17, 2013 at 11:39:45AM +0100, Harald Welte wrote: >> Hi Daniel, >> >> today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers >> and realised that there is no wiki page describing what the control >> protocol is (which I would ahve linked from PortNumbers). > how to sort? TCP first, then UDP or interlevaed? > > holger sort by purpose. From peter at stuge.se Thu Jan 17 17:29:57 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 17 Jan 2013 18:29:57 +0100 Subject: Documentation for Control interface in wiki? In-Reply-To: <20130117164535.GC11906@xiaoyu.lan> References: <20130117103945.GG8380@prithivi.gnumonks.org> <20130117164535.GC11906@xiaoyu.lan> Message-ID: <20130117172957.28659.qmail@stuge.se> Holger Hans Peter Freyther wrote: > > today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers > > and realised that there is no wiki page describing what the control > > protocol is (which I would ahve linked from PortNumbers). > > how to sort? TCP first, then UDP or interlevaed? Maybe /etc/services style; ie. interleaved? //Peter From holger at freyther.de Thu Jan 17 17:35:43 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 17 Jan 2013 18:35:43 +0100 Subject: Review request for osmo-bts changes for my zecke/channel-release branch Message-ID: <20130117173543.GC12965@xiaoyu.lan> Hi, the branch is not done yet but I am confident about the first couple of commits and would like to have some extra eyes to take a look. The branch is here[1] and the general goal is to improve the reliability of the code. Under heavy use it is possible that the nitb will mark all lchans as broken. While doing the tests I noticed the following issues: 1.) On Call-Control with fast hangups (during channel modify) I can see empty FACCH messages from the DSP gsm queue. 2.) The wlc/prim request handling has the known and documented limitation that for a given confirm we do not know who sent the request. This can lead to call the 'wrong' callback with the wrong data/closure. I addressed this the following way: 1.) Add a u8Size == 0 check. For the SACCH we added a < 2 check. Should we check if a LAPDm header could fit? What would be the best limit? I have only seen u8Size == 0, so this is what I addressed.[2] 2.) I address it by passing the gsm_bts_trx as the data pointer and saving the lchan identifier in the hLayer3 pointer and then resolve the lchan from the TS. In follow up commits I introduced a new function to enter the Gsm primitive into the queue and I plan to change the callback signature for them to always include the TRX anyway. The main change is here[3]. There is still a clash between the Ciphering and the TxPower... 3.) The next commits should fix the reliability issue. I do this by keeping a queue of outstanding SAPI operations. And ACK ABIS requests when the queue becomes empty. This is mostly working right now but I have one issue with the ChannelReleaseMarker. When sending a SACCH DEACTIVATE and before the two SACCHs are deactivated send a RF Channel Release the queue appears to be stuck. cheers holger [1] http://cgit.osmocom.org/cgit/osmo-bts/log/?h=zecke/channel-release [2] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&id=2efcb791e4c7fa3da30e3c2389634c9bd1546d89 [3] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&id=af649e41b605d411c34e901fbd91ed65c0152008 From laforge at gnumonks.org Mon Jan 21 12:33:00 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 21 Jan 2013 13:33:00 +0100 Subject: Jan 23, 8pm / Osmocom Berlin User Group meeting Message-ID: <20130121123300.GY13197@prithivi.gnumonks.org> Hi all! This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting. January 23, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu. If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;) 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 meierk at informatik.uni-freiburg.de Wed Jan 23 14:55:26 2013 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Wed, 23 Jan 2013 15:55:26 +0100 Subject: nanoBTS Booster for sale Message-ID: <50FFF9DE.5010702@informatik.uni-freiburg.de> Hi all, At the University of Freiburg (Germany) we have a nanoBTS booster 1800 for sale. Details for the booster are given here: http://www.proximus.com.ua/Nano_BTS_high_power_GSM_booster.html The package includes everything required: - Booster - Power supply - 2x cable to connect to the nanoBTS (0,5 meter) - 1x cable to the antenna (5 meter) - 1x omnidirectional antenna. 3 dBd gain / 1800 MHz The antenna is a high quality omnidirectional antenna from Procom: http://www.procom.dk/products/base-station-antennas/1.3-2.0-ghz/gain-antennas-omnidirectional/cxl-1800-3 Best regards Konrad Meier From smith_fabian at yahoo.com Fri Jan 25 14:07:53 2013 From: smith_fabian at yahoo.com (FABIAN SMITH) Date: Fri, 25 Jan 2013 06:07:53 -0800 (PST) Subject: No subject Message-ID: <1359122873.32611.YahooMailNeo@web164002.mail.gq1.yahoo.com> http://www.arts-gallery.de/tmp/likemn.html FABIAN SMITH -------------- next part -------------- An HTML attachment was scrubbed... URL: