baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

Fw: Re: mobile - making a call
by eisencah eisenach 16 May '11

16 May '11

So any ideea where to look for the answer to the UPDATE_BINARY message? Can I have a buffer overflow on UART RX? Is the buffer size selectable somewhere? --- On Wed, 5/4/11, eisencah eisenach <wbg_1000(a)yahoo.com> wrote: From: eisencah eisenach <wbg_1000(a)yahoo.com> Subject: Re: mobile - making a call To: baseband-devel(a)lists.osmocom.org Date: Wednesday, May 4, 2011, 4:58 PM Done some more digging in the logs and it seems the sim state machine has locked earlier (when attaching to the network) while waiting for some response on UPDATE BINARY. Does this sounds familiar to anyone? :) GOOD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:151 sending result to callback function (type=0) [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) BAD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated --- On Wed, 5/4/11, Harald Welte <laforge(a)gnumonks.org> wrote: From: Harald Welte <laforge(a)gnumonks.org> Subject: Re: mobile - making a call To: "eisencah eisenach" <wbg_1000(a)yahoo.com> Date: Wednesday, May 4, 2011, 11:59 AM On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote: > So is as if the message for the sim job doesn't get pulled from the > queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears. Must say > the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz > celeron with ubuntu 6.10) , and It gets slowed down when running the > hole thing. Can that be the cause? Mihai. The L1CTL protocol goes through a unix domain socket, and you can trace it in either osmocon or in the mobile program itself. It should be relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile, or if it is lost, where it is lost. -- - 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)

3 3

[PATCH] src: use namespace prefix osmo_* for crc16 functions
by Pablo Neira Ayuso 15 May '11

15 May '11

Summary of changes: s/crc16_table/osmo_crc16_table/g s/crc16/osmo_crc16/g s/crc16_byte/osmo_crc16_byte/g --- src/host/osmocon/osmoload.c | 8 ++++---- src/target/firmware/apps/loader/main.c | 6 +++--- src/target/firmware/apps/loader_mtk/main.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 5848e56..8a0b21c 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -575,7 +575,7 @@ loader_start_memput(uint8_t length, uint32_t address, void *data) { struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); msgb_put_u8(msg, LOADER_MEM_WRITE); msgb_put_u8(msg, length); - msgb_put_u16(msg, crc16(0, data, length)); + msgb_put_u16(msg, osmo_crc16(0, data, length)); msgb_put_u32(msg, address); memcpy(msgb_put(msg, length), data, length); loader_send_request(msg); @@ -603,7 +603,7 @@ loader_do_memdump(uint16_t crc, void *data, size_t length) { int rc; if(data && length) { - osmoload.memcrc = crc16(0, data, length); + osmoload.memcrc = osmo_crc16(0, data, length); if(osmoload.memcrc != crc) { osmoload.memoff -= osmoload.memreq; printf("\nbad crc %4.4x (not %4.4x) at offset 0x%8.8x", crc, osmoload.memcrc, osmoload.memoff); @@ -665,7 +665,7 @@ loader_do_memload() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); @@ -705,7 +705,7 @@ loader_do_fprogram() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index a948934..2ff6f9c 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -253,7 +253,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -274,7 +274,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -392,7 +392,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 899d765..9bfaa7e 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -194,7 +194,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -215,7 +215,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -333,7 +333,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); -- 1.7.2.5 --------------090200050301070809080105--

1 0

[PATCH] src: use namespace prefix osmo_wqueue*
by Pablo Neira Ayuso 15 May '11

15 May '11

Summary of changes: s/struct write_queue/struct osmo_wqueue/g s/write_queue_init/osmo_wqueue_init/g s/write_queue_clear/osmo_wqueue_clear/g s/write_queue_enqueue/osmo_wqueue_enqueue/g s/write_queue_bfd_cb/osmo_wqueue_bfd_cb/g --- .../include/osmocom/bb/common/osmocom_data.h | 2 +- src/host/layer23/src/common/l1l2_interface.c | 4 ++-- src/host/layer23/src/common/sap_interface.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h index 9d8a030..9ca4114 100644 --- a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h +++ b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h @@ -50,7 +50,7 @@ struct rx_meas_stat { struct osmocom_ms { struct llist_head entity; char name[32]; - struct write_queue l2_wq, sap_wq; + struct osmo_wqueue l2_wq, sap_wq; uint16_t test_arfcn; uint8_t deleting, shutdown, started; diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index 3272359..2abb660 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -126,7 +126,7 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->l2_wq, 100); + osmo_wqueue_init(&ms->l2_wq, 100); ms->l2_wq.bfd.data = ms; ms->l2_wq.bfd.when = BSC_FD_READ; ms->l2_wq.read_cb = layer2_read; @@ -167,7 +167,7 @@ int osmo_send_l1(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->l2_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->l2_wq, msg) != 0) { LOGP(DL1C, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; diff --git a/src/host/layer23/src/common/sap_interface.c b/src/host/layer23/src/common/sap_interface.c index 4d465f0..5d92840 100644 --- a/src/host/layer23/src/common/sap_interface.c +++ b/src/host/layer23/src/common/sap_interface.c @@ -127,7 +127,7 @@ int sap_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->sap_wq, 100); + osmo_wqueue_init(&ms->sap_wq, 100); ms->sap_wq.bfd.data = ms; ms->sap_wq.bfd.when = BSC_FD_READ; ms->sap_wq.read_cb = sap_read; @@ -170,7 +170,7 @@ int osmosap_send(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->sap_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->sap_wq, msg) != 0) { LOGP(DSAP, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; -- 1.7.2.5 --------------080404070907070702060601--

1 0

problem with Pirelli DP-L10 and upload the firmware
by Marco Schwan 15 May '11

15 May '11

Hi, I have a problem with the DP-L10. The upload the firmware in the phone is not succesfull. I have made following steps: - change the UART number in the two header files - compile the source - connected the phone with laptop - run the command "./host/osmocon/osmocon -p /dev/ttyUSB0 -m romload ./target/firmware/board/pirelli_dpl10/layer1.highram.bin" - put the accu in the mobile phone the upload the firmware start and the last message from osmocon is: handle_write_block(): 64 bytes (1024/1024) handle_write_block(): Block 51 finished Finished, sent 51 blocks in total Received block ack from phone Sending checksum: 0x55 I have follow message expected: Received block ack from phone Sending checksum: 0xaa Checksum on phone side matches, let's branch to your code Branching to 0x00820000 Received branch ack, your code is running now! I see not the error. Can you please a idea give. Marco

1 0

arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata)
by Jens Hoffmann 15 May '11

15 May '11

Hi, when compiling the firmware I get the following error: make[2]: Entering directory `/home/hoffmaje/proseminar/install/osmocom-bb/src/target/firmware' LD board/mt62xx/loader_mtk.mtkram.elf arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) I used a tool-chain mentioned in a post from 18. January 2011: ftp://ftp.pengutronix.de/pub/oselas/oselas.toolchain-1.99.3.6-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18_i386.tar.bz2 I read the PreliminaryRequirements <http://www.osmocom.org/trac/wiki/PreliminaryRequirements>, the archives and I did a google search; I would be even glad just to understand what this error is about. Thanks for your help, Jens

2 1

Re: Anybody using a BTS for debugging?
by Dieter Spaar 14 May '11

14 May '11

Hello Gianni, On Fri, 13 May 2011 11:41:35 +0100, "Gianni Tedesco" <gianni(a)scaramanga.co.uk> wrote: > > Any idea of model numbers? The ones I've looked at have been > $1,000 > and only do calls, not SMS for example. The Racal 6103E can do SMS and sometimes is available for less than $US 500 (a few cheap ones were sold in the UK a while ago). Be aware of the 6103G or the "Anite" variant, they cannot be used "standalone". Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

L1 corruption?
by suraev＠stud.ntnu.no 14 May '11

14 May '11

Hi. I'm trying to follow the logic described in app_ccch_scan to send RACH bursts to my openbts. First 2-2 goes fine but after that I got constant errors - see below. It looks like after I've sent couple of packets something got corrupted in L1. How can I debug this and understand what causing all the errors? LOG: <0001> app_rach_send.c:227 registering signal handler... <0001> app_rach_send.c:229 resetting L1... <0001> app_rach_send.c:231 L3 init... <0001> app_rach_send.c:190 requesting FBSB from L1... <0001> app_rach_send.c:200 unhandled callback 1 <S_L1CTL_FBSB_RESP> fired... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:73 SI2 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:75 SI3 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:75 SI3 on the wrong TC: 0 <0001> app_rach_send.c:200 unhandled callback 5 <S_L1CTL_CCCH_MODE_CONF> fired... <0001> app_rach_send.c:200 unhandled callback 5 <S_L1CTL_CCCH_MODE_CONF> fired... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 ... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:70 SI1 received. <0001> app_rach_send.c:127 sending RACH #0 on ARFCN 21... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:127 sending RACH #1 on ARFCN 21... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:127 sending RACH #2 on ARFCN 21... <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 62 bit errors <000b> l1ctl.c:210 Dropping frame with 60 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors

1 0

Osmocom project vs. sysmocom GmbH
by Harald Welte 14 May '11

14 May '11

Hi all! As some of you already know, Holger and I have recently started a new company called "sysmocom - systems for mobile communications GmbH". The process of establishing the new company has now formally concluded. Before some rumours start to spread, we would like to clarify some points and make sure there is mutual understanding between the Osmocom community and the sysmocom company. sysmocom is intended to provide commercial offerings related to the Osmocom projects. This is not entirely new. Especially on the network side, people like Holger and I have been doing quite a lot of paid development to bring those projects forward. We would not have many of the features we have today, if it wasn't for customers who actually pay us for development of OpenBSC, OsmoBSC, OsmoSGSN and the various side projects more targetted at a real network operator like cellmgr-ng, bsc-nat, gb_proxy - just to name a few. However, this has always only been freelancing development of Software. With sysmocom, we want to go one step further and work on hardware products related to the various Free Software projects. Right now I don't want to talk too much about unfinished products, but we are working towards an inexpensive BTS product, we are funding the prototypes for Osmocom SIMtrace, and we will likely also see stuff like OpenBSC appliances. Given our past involvement and exposure into other projects that share a split Free Software / business set-up, we think we understand very well where potential issues of conflict between the two sides may be. Let me make some more clarification what this is not about: * sysmocom is not about creating proprietary derivates of Osmocom software. We work on Free Software which is publicly available under OSI approved and FSF endorsed licenses. We may offer proprietary hardware and sometimes software - but those are independent projects from existing Osmocom software. * we specifically will not have a public and a non-public version of the same program with differences in features. * sysmocom is not a VC-funded startup. It's a very small company run out of personal funds with no intention to take external funding or grow rapidly. Nobody but Holger and I determine where it goes and what it does. * sysmocom does not hold any copyright on the Free Software projects. The copyrights stay distributed with the major authors such as Holger, Onwaves, Sylvain, Dieter, Andreas and myself. None of the others have any affiliation with sysmocom. I have (personally, unrelated to sysmocom) asked some of the smaller contributors for a copyright transfer to make sure we could do the AGPLv3 transition, or future re-licensing decisions without having to ask dozens and dozens of people. sysmocom does not seek to control the Free Software projects. * we will maintain a strict separation between the community side of things and the business side. Unlike some other popular projects, we will not end up in a situation where the osmocom.org websites will be full of advertisements and hidden links that lure you on the company website. * we will keep a strict separation of naming. Osmocom is for the FOSS projects, sysmocom for the business. The company will use the term "Osmocom" only in descriptive context, not as a product name, brand or for advertisement. If you do have any concerns, please feel free to share them. However, I'd like to avoid cross-posting them throguh different mailing lists. Please follow-up-to openbsc(a)lists.osmocom.org Regards, Harald -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

1 0

Anybody using a BTS for debugging?
by Gianni Tedesco 13 May '11

13 May '11

Hi, It seems like a BTS is required in order to really debug anything one develops with osmocombb. I'm still looking at implementing SMS. However the only off-the-shelf option seems to be USRP which is about $1,000 right? Is this going to become a very expensive hobby or are there cheaper options here? Is there a way to bypass L1CTL on the phone and feed the data in to, say, openBTS? If not, it would seem useful to hack such a thing up... Gianni

2 2

Planning for Radio Village at 2011 CCC Camp
by Harald Welte 13 May '11

13 May '11

Hi all! [This message is cross-posted to many lists, please be careful when replying to it! Think twice if your respones really matters to all those projects...] In order to do some better planning for our Camp activities this summer, I would like to request all people who intend to participate in the radio village to add themselves to the wiki: https://events.ccc.de/camp/2011/wiki/index.php/RadioVillage The list of citizens is auto-generated if you use Person template like I have done in my user page at https://events.ccc.de/camp/2011/wiki/index.php/User:LaForge The large main tent is not really intended as a place to sleep, but more like a place where we set up our gear and work on the various projects, similar to what happened at HAR. Thanks in advance! -- - 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)

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel