So far three persons have indicated their interest to join
a meeting at my place.
Considering the time it takes to drive to my place, it
probably makes sense to have the meeting at the weekend
(either Saturday or Sunday) so that there is more time
for the meeting itself. I can suggest one of the following
dates for the first meeting, somewhere between 10:00 to
18:00 on each day:
25.8. (Sa) or 26.8. (Su)
1.9. (Sa) or 2.9. (Su)
8.9. (Sa) or 9.9. (Su)
So please let me know when you have time and also make
suggestions in which Osmocom topic you are interested
in so that we can have some sort of agenda for the
meeting to make best use of the time.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello everyone,
I've just finnished writing together a small web interface for the OpenBSC
HLR. It allows you to modify various parameters in the database and also
provides a set of functions to modify the HLR or sending SMSes in your own
scripts.
The project is still very alpha but it seems to work reasonably good. Feel
free to give any feedback!
Screenshots and source code is available on my website:
https://stormhub.org/simplehlr/
--
*Best regards,
Peter Caprioli*
Hello list,
First of all congratulation to developers of this project making such
wonderful project in an interesting subject. I am new to this project and
for past few days i managed to go through the documentation and get most of
it tested. Thanks for pretty good documentation in most of the areas as
well.
I have the osmo-nitb working very fine using a nano bts.
How ever when i try to install it with LCR to interconnect with external
switch, im facing some problems. Initially i thought i must use
LCR+Asterisk. But later i figured out there is a built in SIP interface on
LCR which there is no need to asterisk or chan_asterisk. I would prefer to
use this LCR SIP interface as i dont want to use asterisk and just want to
forward all calls to another SIP switch.
Now in this context there seems absolutely no documentation on both openbsc
and LCR/mISDN lists.
Can some one please shed me some light here on how to build a LCR with SIP
to be work with osmo-nitb.
All i want to test is
GSM phone > Osmo-nitb > LCR with SIP > SIP softswitch
Thank you very much for every one's effort in this project and would be
glad to see some response for this.
Best Regards
Nava.
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-antenn…
Best regards
Konrad Meier
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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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=2e…
[3] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&id=af…
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 <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Pablo,
getaddrinfo does not work for the combination of AF_INET, SOCK_RAW
and IPPROTO_GRE. I have attached an example application that can be
compiled with:
$ gcc -o fr fr.c `pkg-config --cflags --libs libosmocore libosmogb`
this prints:
getaddrinfo returned NULL: Success
FAILED
gettadrinfo returns -8 which should be this:
# define EAI_SERVICE -8 /* SERVICE not supported for `ai_socktype'. */
I am not sure what is the most clever way to resolve this. Make SOCK_RAW
branch out early and do the socket/bind(/listen) manually, use getaddrinfo
twice with some more unspefici options, just deal with SOCK_RAW differently
now? The attached code has the benefit of at least handling INET and INET6
inside the getaddrinfo result.
any ideas?
holger
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: Sylvain Munaut <tnt(a)246tNt.com>
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 <tnt(a)246tNt.com>
---
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
Hi guys,
i'm still testing the eap-sim authentication and lately i got acceptable results using
a simple flat file containing the triplets of specific SIM cards. Next step will be to
enable the external radius server to use the sysmoBTS database hlr.sqlite3, so the
OpenBSC users (Users using the OpenBSC-GSM Network) can automatically access
to the internet.
i just want to ask if there are any limitations with the sysmocom SIM cards?
In fact, i noticed that by using the sysmocom sim cards, the eap-sim authentication
failed when the RAND values strong randomly chosen were, e.g
046DBA898016454aB3920C58180DA2F5 or e177842fe16c47de84784be1b4141c27.
But when i chose a RAND like this 10101010101010101010101010101010,
0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F or 00000000000000000000000000000000,
the authentication succeeded.
By using an other sim (not from sysmocom) with the same strong and weak RAND
values the authentication always succeeded.
Why does the authentication succeed buy using sysmocom sim card with weak RAND
(10101010101010101010101010101010) and fail by using strong RAND values
(e177842fe16c47de84784be1b4141c27) ?
best regards
Yann
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.
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.
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 and the
hacking days
2) consider whether late march (like 2012) would be a good schedule
again
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
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.
Regards and happy new year,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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.