- OpenBSC - lists.osmocom.org

[patch 4/4] abis_rsl: Fix rsl_encryption_cmd L3 length computation
by Sylvain Munaut 24 Sep '09

24 Sep '09

commit c582a730570f96ea294d53f5261b6f4df35f256c Author: Sylvain Munaut <tnt(a)246tNt.com> Date: Thu Sep 24 01:54:40 2009 +0200 [abis_rsl] Fix rsl_encryption_cmd L3 length computation msg->l3h doesn't have any coherent value at that point, can't use that. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> openbsc/src/abis_rsl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

1 0

[patch 3/4] gsm_04_08: Fix gsm48_send_rr_ciph_mode algorithm ID
by Sylvain Munaut 24 Sep '09

24 Sep '09

commit 7aa86ed1e8669bcd06970ba23a1ff5abd5da81e6 Author: Sylvain Munaut <tnt(a)246tNt.com> Date: Thu Sep 24 01:44:24 2009 +0200 [gsm_04_08] Fix gsm48_send_rr_ciph_mode algorithm ID The algorithm ID used in the GSM 04.08 RR message is (x-1) for A5/x. In RSL it's (x+1) for A5/x so there is a difference of 2. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> openbsc/src/gsm_04_08.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

1 0

[patch 2/4] gsm_04_08: Fix gsm48_tx_mm_auth_req implementation
by Sylvain Munaut 24 Sep '09

24 Sep '09

commit ed85ac5d09fa892996a06170422430274e050124 Author: Sylvain Munaut <tnt(a)246tNt.com> Date: Thu Sep 24 01:40:55 2009 +0200 [gsm_04_08] Fix gsm48_tx_mm_auth_req implementation It was mainly missing the key_seq field, causing the command to just be rejected by the ME. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> openbsc/include/openbsc/gsm_04_08.h | 7 +++++++ openbsc/src/gsm_04_08.c | 8 +++++--- 2 files changed, 12 insertions(+), 3 deletions(-)

1 0

OpenBSC related job offer in Dresden / Germany
by Harald Welte 23 Sep '09

23 Sep '09

Hi all! I have recently been informed there is a job opening related to OpenBSC in Dresden / Germany. So if you're interested in working full time on issues such as * integrating OpenBSC into actual applications / products * testing OpenBSC with various handsets in various scenarios * sending bug reports and interacting with actual developers The job is not really about development of the OpenBSC stack itself, but related to system integration. So don't worry if you are neither a full-blown programmer, nor know the GSM protocol specs up to the last bit .. Please drop me a note, in case you're interested. Regards, -- - 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)

2 2

AW: new 1.6 debian packages for lcr and misdnuser
by Andreas Eversberg 14 Sep '09

14 Sep '09

hi joerg, i am not into debian. can you explain: - what files in your directory http://www.dorchain.net/~joerg/code/debian/ should be added to the git repository? - where should they be located? (inside lcr directory) - what files of original lcr or mISDN git are changed? thanx in advance, andreas

2 1

Ericsson RBS 2401 Status
by Caleb Pal 14 Sep '09

14 Sep '09

Hello all, Just thought I would give everyone an update on my progress with the Ericsson RBS. I got a T1 card, a Digium TE122P (http://www.digium.com/en/products/digital/te122.php) This card support E1/T1/J1. The 2401 I have only supports T1, otherwise I would have gotten a HFC based chipset that OpenBSC supports. The TE122P uses the DAHDI drivers, which used to be Zaptel. In reading through the list archives, I found a couple tidbits about Zaptel. The first was back in February from Harald: http://lists.gnumonks.org/pipermail/openbsc/2009-February/000023.html. I didn't see any updates after that. Were there updates made to make the integration with other drivers easier? The next I found was in March from Klaus-Peter Junghann: http://lists.gnumonks.org/pipermail/openbsc/2009-March/000064.html. It looks like he actually got the Zaptel driver to work. I'm not sure how much of Zaptel has changed when the driver set was renamed to DAHDI. I did not see a post from Mr. Junghann with the zaptel input module he spoke of. I'm not sure what the interest level is with getting OpenBSC to integrate with Ericsson RBS's? Like I previously mentioned, I am not much of a coder, so I can't help much in that department. That being said, I am willing to provide remote access to all the resources I have here (Debian Linux 5.0 Server, RBS 2401, Windows LMT). I can also provide access to a spec an (which would be accessed via software on the Windows LMT) if needed down the road. I am going to look into a STA to test on a couple ARFCN's in the GSM1900 band, and I am more than willing to help with handset debugging at that stage. I have quite a few different handsets lying around! Thanks much, Caleb

4 3

Motorola V3 Force ARFCN
by Caleb Pal 14 Sep '09

14 Sep '09

Hello, While experimenting with a Motorola V3 GSM branded for AT&T, I enabled the Engineering Menu with a SEEM edit. Not a terribly hard procedure once you know where to look. After performing this hack, I looked in the Engineering Menu, and there is an option to force the ARFCN the phone camps on. I think this would be a useful tool if you want to force a handset to camp on your Base Station. I'm not if it will help with the clock issues, but it might alleviate some frustration. The Original V3's (no 3G) can be found on ebay for a decent price. I'm not sure if any other phones include this functionality (I haven't come across any), so I thought I would share it with you all. If you need help performing the SEEM edit, let me know. Caleb

2 1

AW: new release of LCR (linux-call-router)
by Andreas.Eversberg 12 Sep '09

12 Sep '09

hi harald, >Of course this will mean that we need to develop the RTP-to-MNCC integration, since nanoBTS voice channels arrive on RTP. I am willing to look into this, but I presume you also have a big interest in that (and maybe more time?). i am interested having RTP audio available to MNCC interface as well. the audio stream (frames) should be equal for BS11 and nanoBTS, so both streams work for MNCC interface without different handling on the application side. for this i would like to cross-convert the frame coding of BS11 to the actual gsm format inside OpenBSC instead of just forwarding the TRAU frame format. if the TRAU frame is converted inside OpenBSC, calls from BS11 to nanoBTS would also be possible. >Since I now own more nanoBTS, I could send you one for 1-2 months of development of that code. Are you interested in this? yes, i am. this way it is easier to run some tests. regards, andreas

2 1

DTMF processing errors
by Sergey V. Efimoff 12 Sep '09

12 Sep '09

Hello All, While testing DTMF facilities of OpenBSС I've discovered a couple of bugs. The first bug is generic to GSM TS 04.08, minor and is connected with gsm0408_cc_msg_names variable (gsm_04_08_utils.c). I've found that message names order is wrong: in original source it is enumerated as ... "unknown 0x3b", "STATUS", "unknown 0x3c" "NOTIFY" ... while it should be ... "unknown 0x3b" "unknown 0x3c" "STATUS" "NOTIFY" ... thus faling to identify GSM 04.08 STATUS messages. The second problem is connected with DTMF message sequence. According to the GSM TS 04.08, DTMF message flow is the following: MS -----> START_DTMF MNCC_START_DTMF_IND ----> MNCC MNCC_START_DTMF_RSP <---- MNCC MS <---- START_DTMF_ACK MS ----> STOP_DTMF MNCC_STOP_DTMF_IND ----> MNCC MNCC_STOP_DTMF_RSP <---- MNCC MS <---- STOP_DTMF_ACK This is correct, but some mobile equipment (for example, my iPhone and Nokia 6150) do not reply with STOP_DTMF message; instead of this, they reply with STATUS message (type 0x3D). This type of messages is not processed within OpenBSC. Message is left unhandled in this state and further DTMF transactions become impossible because MNCC does not receive DTMF_STOP. GSM standard says that STATUS message reports about some errors occurred during transaction, but I did not explore the message still, though, I can do that if it is interesting for developers. I have no ideas why some of my mobile phones behave wrong, while others work correctly. I still don't know how to deal with STATUS messages properly, so I've simply added processing entry to the datastatelist[] variable in gsm_04_08.c which describes a call to gsm48_cc_rx_stop_dtmf when received a STATUS message. It is incorrect, I know, but, however, temporary helps to process DTMF messages with MS equipment which have wrong DTMF sequence flow. Now it looks like this: MS -----> START_DTMF MNCC_START_DTMF_IND ----> MNCC MNCC_START_DTMF_RSP <---- MNCC MS <---- START_DTMF_ACK MS ----> STATUS MNCC_STOP_DTMF_IND ----> MNCC MNCC_STOP_DTMF_RSP <---- MNCC MS <---- STOP_DTMF_ACK Sergey.

2 1

Siemens born nanoBTS
by WoMax 09 Sep '09

09 Sep '09

I got a few Siemens born nanoBTS, this is OEM from ip.access for project MOGIS. They are new in box. Details on http://umts.zerber.us

1 0