From laforge at gnumonks.org Wed Sep 5 06:50:02 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 Sep 2012 08:50:02 +0200 Subject: Sept 5, 8pm / Osmocom Berlin User Group meeting Message-ID: <20120905065002.GM12467@prithivi.gnumonks.org> Hi all! This is the announcement for the next Osmocom Berlin meeting. Sept 05, 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, Harald [p.s.: I myself will not be able to attend tonight, but I'm sure you will be able to do just fine (or even better?)] -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From GNUtoo at no-log.org Mon Sep 10 19:39:45 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Mon, 10 Sep 2012 21:39:45 +0200 Subject: [terminal profile] Additional informations. Message-ID: <20120910213945.75bec84b.GNUtoo_no-log.org@no-log.org> Hi, I'd like to add the baseband revision which is: '1.7.4.0 (Date: Jan 5 2011, Time: 11:14:34)' to that entry: https://terminal-profile.osmocom.org/decode.php?tp=1700e84211000000800000000000000000000000000000000000000000 In additionnal information(it wasn't clear at the execution of terminal profile that I could put the baseband version there...). By the way I'd like to test the impact of having free libraries/deamons(like fsogsmd, free android RILs like the samsung-ril+libsamsung-ipc) that resides on the Application processor, and which talk to the baseband(compared to the default non-free libraries), if I do that, should I leave a note in "additionnal information"? if so, what should I tell? Denis. From kevredon at mail.tsaitgaist.info Mon Sep 10 20:00:54 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 10 Sep 2012 22:00:54 +0200 Subject: [terminal profile] Additional informations. In-Reply-To: <20120910213945.75bec84b.GNUtoo_no-log.org@no-log.org> References: <20120910213945.75bec84b.GNUtoo_no-log.org@no-log.org> Message-ID: <1347306996-sup-4029@dennou> Excerpts from Denis 'GNUtoo' Carikli's message of Mon Sep 10 21:39:45 +0200 2012: > Hi, > > I'd like to add the baseband revision which is: > '1.7.4.0 (Date: Jan 5 2011, Time: 11:14:34)' > to that entry: > https://terminal-profile.osmocom.org/decode.php?tp=1700e84211000000800000000000000000000000000000000000000000 > In additionnal information(it wasn't clear at the execution of > terminal profile that I could put the baseband version there...). done. thanks for the entry > > By the way I'd like to test the impact of having free > libraries/deamons(like fsogsmd, free android RILs like > the samsung-ril+libsamsung-ipc) that resides on the Application > processor, and which talk to the baseband(compared to the default > non-free libraries), if I do that, should I leave a note in "additionnal > information"? if so, what should I tell? I think the baseband defines the terminal profile, and I am not sure the application processor can change it. If otherwise, just tell which software did that in the additionnal information (I can also change/delete the entries later on). kevin From laforge at gnumonks.org Mon Sep 10 21:33:50 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 10 Sep 2012 23:33:50 +0200 Subject: Introducing libosmosim Message-ID: <20120910213350.GT6618@prithivi.gnumonks.org> Hi! I've been hacking away a bit on a new library 'libosmosim' whihc is scheduled to become part of libosmocore. In fact, as the automake integration has been cleaned up, I'll probably merge it master any day now. The idea of this library is to * understand the EF/DF hierarchy if GSM SIM, ETSI UICC and 3GPP USIM * provide encoding and decoding routines for at least the most important EFs * decode the binary data into a generic data structure which can be used by some form of a GUI application * be able to re-encode from the generic parsed structure into the binary form, possibly after modification from the UI * be able to transact APDUs via T0 and T1 on PC/SC and other reader interfaces, e.g. the OsmocomBB SIM interface So the primary purpose of this is to be able to have a tool for meaningful (human-readable/writable) modification of all files on a programmable SIM card, such as the sysmoSIM-GR1 (and other cards where you have the ADM PIN that gives you write permission). Other useful purposes on the horizon of the library could be: * implementation of a generic SIM/UICC/USIM simulator based on user-created input, or based on 'ripped' SIM cards (well, you have to provide the key in some way). The current status is still quite experimental, but you can already see the major parts: * mapping of APDU and TPDU (only T=0 so far) on to 'struct msgb struct osim_file_ops encode and decode callbacks for a given file struct osim_file_desc node in the hierarchical description of filesystem tree struct osim_decoded_data the runtime representation of a decoded file: struct osim_decoded_element one decoded element in a decoded file struct osim_card_sw status + bitmask + human readable description struct osim_card_profile full description profile of card, including filesystem hierarchy, status words and card-specific commands struc osim_reader_hdl represents a card reader (currently a slot in a reader, not sure really how to represent multi-slot readers like sim-banks yet). primarily consist of osim_reader_ops struc osim_card_hdl representing a card inside a reader struc osim_chan_hdl currently just a dummy. intended for logical channel support most of the existing code is in src/sim/*.c, while some not-yet-cleaned-up example code is in utils/osmo-sim-test.c. There are gaps everywhere all over the place, and I think it will take quite some time to fill those gaps. Current roadmap: * properly integrate all parts, so with a single call you can read in the tree of all EFs of a card into their in-memory representation * verify that the APIs for encoding/decoding functions work the way they are before writing 'all' the EF decode/encode routines * add more decoded element types, such as location area codes and the like So if you survived this mail until this point, I think you are a prime candidate for contributing some code. Let me know if you're interested in helping out. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From chris at techworks.ie Tue Sep 11 15:18:24 2012 From: chris at techworks.ie (Christian Gagneraud) Date: Tue, 11 Sep 2012 16:18:24 +0100 Subject: Introducing libosmosim In-Reply-To: <20120910213350.GT6618@prithivi.gnumonks.org> References: <20120910213350.GT6618@prithivi.gnumonks.org> Message-ID: <504F5640.5070601@techworks.ie> On 10/09/12 22:33, Harald Welte wrote: > Hi! > > I've been hacking away a bit on a new library 'libosmosim' whihc is > scheduled to become part of libosmocore. In fact, as the automake > integration has been cleaned up, I'll probably merge it master any day > now. > > The idea of this library is to > * understand the EF/DF hierarchy if GSM SIM, ETSI UICC and 3GPP USIM > * provide encoding and decoding routines for at least the most important > EFs > * decode the binary data into a generic data structure which can be used > by some form of a GUI application > * be able to re-encode from the generic parsed structure into the > binary form, possibly after modification from the UI > * be able to transact APDUs via T0 and T1 on PC/SC and other reader > interfaces, e.g. the OsmocomBB SIM interface > > So the primary purpose of this is to be able to have a tool for > meaningful (human-readable/writable) modification of all files on a > programmable SIM card, such as the sysmoSIM-GR1 (and other cards where > you have the ADM PIN that gives you write permission). > > Other useful purposes on the horizon of the library could be: > * implementation of a generic SIM/UICC/USIM simulator based on > user-created input, or based on 'ripped' SIM cards (well, you have to > provide the key in some way). > > The current status is still quite experimental, but you can already see > the major parts: > > * mapping of APDU and TPDU (only T=0 so far) on to 'struct msgb > > struct osim_file_ops > encode and decode callbacks for a given file > > struct osim_file_desc > node in the hierarchical description of filesystem tree > > struct osim_decoded_data > the runtime representation of a decoded file: > > struct osim_decoded_element > one decoded element in a decoded file > > struct osim_card_sw > status + bitmask + human readable description > > struct osim_card_profile > full description profile of card, including filesystem > hierarchy, status words and card-specific commands > > struc osim_reader_hdl > represents a card reader (currently a slot in a reader, > not sure really how to represent multi-slot readers like > sim-banks yet). primarily consist of osim_reader_ops > > struc osim_card_hdl > representing a card inside a reader > > struc osim_chan_hdl > currently just a dummy. intended for logical channel support > > most of the existing code is in src/sim/*.c, while some > not-yet-cleaned-up example code is in utils/osmo-sim-test.c. There are > gaps everywhere all over the place, and I think it will take quite some > time to fill those gaps. Hi, In which branch can one find this code? Or maybe you have a separate tree somewhere? I couldn't find anything in simtrace git repo nor in openbsc one. Chris > > Current roadmap: > > * properly integrate all parts, so with a single call you can read in > the tree of all EFs of a card into their in-memory representation > > * verify that the APIs for encoding/decoding functions work the way > they are before writing 'all' the EF decode/encode routines > > * add more decoded element types, such as location area codes and the > like > > So if you survived this mail until this point, I think you are a prime > candidate for contributing some code. Let me know if you're interested > in helping out. > > Regards, > Harald > -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/ From 246tnt at gmail.com Tue Sep 11 15:25:45 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 11 Sep 2012 17:25:45 +0200 Subject: Introducing libosmosim In-Reply-To: <504F5640.5070601@techworks.ie> References: <20120910213350.GT6618@prithivi.gnumonks.org> <504F5640.5070601@techworks.ie> Message-ID: Hi, > In which branch can one find this code? Or maybe you have a separate tree > somewhere? I couldn't find anything in simtrace git repo nor in openbsc one. http://cgit.osmocom.org/cgit/libosmocore/log/?h=laforge/sim Cheers, Sylvain From chris at techworks.ie Tue Sep 11 15:31:29 2012 From: chris at techworks.ie (Christian Gagneraud) Date: Tue, 11 Sep 2012 16:31:29 +0100 Subject: Introducing libosmosim In-Reply-To: References: <20120910213350.GT6618@prithivi.gnumonks.org> <504F5640.5070601@techworks.ie> Message-ID: <504F5951.7010006@techworks.ie> On 11/09/12 16:25, Sylvain Munaut wrote: > Hi, > >> In which branch can one find this code? Or maybe you have a separate tree >> somewhere? I couldn't find anything in simtrace git repo nor in openbsc one. > > http://cgit.osmocom.org/cgit/libosmocore/log/?h=laforge/sim Thanks, Chris > > > Cheers, > > Sylvain > -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/ From chris at techworks.ie Tue Sep 11 17:04:59 2012 From: chris at techworks.ie (Christian Gagneraud) Date: Tue, 11 Sep 2012 18:04:59 +0100 Subject: Introducing libosmosim In-Reply-To: <20120910213350.GT6618@prithivi.gnumonks.org> References: <20120910213350.GT6618@prithivi.gnumonks.org> Message-ID: <504F6F3B.1050406@techworks.ie> On 10/09/12 22:33, Harald Welte wrote: > Hi! > [...] > > Current roadmap: > > * properly integrate all parts, so with a single call you can read in > the tree of all EFs of a card into their in-memory representation > > * verify that the APIs for encoding/decoding functions work the way > they are before writing 'all' the EF decode/encode routines Hi, I wouldn't mind to write a testsuite for that, I have no knowledge about ISO7816-5, and i never used simtrace and co. but I see that as an oportunity to dig into them. As i don't have a SIM reader, it would be nice if someone could provide me raw dump files. FWIU, I should be able to test the low-level stuff like osim_file_decode() and osim_file_encode() Regards, Chris > > * add more decoded element types, such as location area codes and the > like > > So if you survived this mail until this point, I think you are a prime > candidate for contributing some code. Let me know if you're interested > in helping out. > > Regards, > Harald > -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/ From chris at techworks.ie Tue Sep 11 18:06:11 2012 From: chris at techworks.ie (Christian Gagneraud) Date: Tue, 11 Sep 2012 19:06:11 +0100 Subject: Introducing libosmosim In-Reply-To: <20120910213350.GT6618@prithivi.gnumonks.org> References: <20120910213350.GT6618@prithivi.gnumonks.org> Message-ID: <504F7D93.5050107@techworks.ie> On 10/09/12 22:33, Harald Welte wrote: > Hi! > Hi, I've just build libosmocore and ran osmo-sim-test, but it crashes. There's a function signature mismatch between osim_reader_ops.reader_open() and pcsc_reader_open(), the later requires an extra parameter "void *ctx". Chris > I've been hacking away a bit on a new library 'libosmosim' whihc is > scheduled to become part of libosmocore. In fact, as the automake > integration has been cleaned up, I'll probably merge it master any day > now. > > The idea of this library is to > * understand the EF/DF hierarchy if GSM SIM, ETSI UICC and 3GPP USIM > * provide encoding and decoding routines for at least the most important > EFs > * decode the binary data into a generic data structure which can be used > by some form of a GUI application > * be able to re-encode from the generic parsed structure into the > binary form, possibly after modification from the UI > * be able to transact APDUs via T0 and T1 on PC/SC and other reader > interfaces, e.g. the OsmocomBB SIM interface > > So the primary purpose of this is to be able to have a tool for > meaningful (human-readable/writable) modification of all files on a > programmable SIM card, such as the sysmoSIM-GR1 (and other cards where > you have the ADM PIN that gives you write permission). > > Other useful purposes on the horizon of the library could be: > * implementation of a generic SIM/UICC/USIM simulator based on > user-created input, or based on 'ripped' SIM cards (well, you have to > provide the key in some way). > > The current status is still quite experimental, but you can already see > the major parts: > > * mapping of APDU and TPDU (only T=0 so far) on to 'struct msgb > > struct osim_file_ops > encode and decode callbacks for a given file > > struct osim_file_desc > node in the hierarchical description of filesystem tree > > struct osim_decoded_data > the runtime representation of a decoded file: > > struct osim_decoded_element > one decoded element in a decoded file > > struct osim_card_sw > status + bitmask + human readable description > > struct osim_card_profile > full description profile of card, including filesystem > hierarchy, status words and card-specific commands > > struc osim_reader_hdl > represents a card reader (currently a slot in a reader, > not sure really how to represent multi-slot readers like > sim-banks yet). primarily consist of osim_reader_ops > > struc osim_card_hdl > representing a card inside a reader > > struc osim_chan_hdl > currently just a dummy. intended for logical channel support > > most of the existing code is in src/sim/*.c, while some > not-yet-cleaned-up example code is in utils/osmo-sim-test.c. There are > gaps everywhere all over the place, and I think it will take quite some > time to fill those gaps. > > Current roadmap: > > * properly integrate all parts, so with a single call you can read in > the tree of all EFs of a card into their in-memory representation > > * verify that the APIs for encoding/decoding functions work the way > they are before writing 'all' the EF decode/encode routines > > * add more decoded element types, such as location area codes and the > like > > So if you survived this mail until this point, I think you are a prime > candidate for contributing some code. Let me know if you're interested > in helping out. > > Regards, > Harald > -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/ From kevredon at mail.tsaitgaist.info Fri Sep 14 15:10:24 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Fri, 14 Sep 2012 17:10:24 +0200 Subject: Introducing libosmosim In-Reply-To: <20120910213350.GT6618@prithivi.gnumonks.org> References: <20120910213350.GT6618@prithivi.gnumonks.org> Message-ID: <1347635118-sup-6553@dennou> Hi, here some additional comments for functions/structures, and one small renaming (to match ISO 7816-3). I would also like to rename Le/Lc into Ne/Nc, as Ne/Nc is the value for the length (which is also how it is used in libosmosim), and Le/Lc is it's encoded version for the APDU/TPDU. I will continue reading code (so to get an overview), and add comments for now kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: comments.diff Type: application/octet-stream Size: 80785 bytes Desc: not available URL: From laforge at gnumonks.org Sat Sep 15 12:24:54 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 15 Sep 2012 14:24:54 +0200 Subject: Introducing libosmosim In-Reply-To: <1347635118-sup-6553@dennou> References: <20120910213350.GT6618@prithivi.gnumonks.org> <1347635118-sup-6553@dennou> Message-ID: <20120915122454.GE31654@prithivi.gnumonks.org> hi Kevin, On Fri, Sep 14, 2012 at 05:10:24PM +0200, Kevin Redon wrote: > here some additional comments for functions/structures, and one small renaming (to match ISO 7816-3). I think you made some mistake while creating the diff. It contains lots of whole-file patches and changes bits in libosmogb. Please check again. The best way to create the patch is probably to commit your changes and then do 'git format-patch -1'. Thanks! > I would also like to rename Le/Lc into Ne/Nc, as Ne/Nc is the value > for the length (which is also how it is used in libosmosim), and Le/Lc > is it's encoded version for the APDU/TPDU. Makes a lot of sense, thanks for pointing this out. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kevredon at mail.tsaitgaist.info Sun Sep 16 11:41:59 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Sun, 16 Sep 2012 13:41:59 +0200 Subject: Introducing libosmosim In-Reply-To: <20120915122454.GE31654@prithivi.gnumonks.org> References: <20120910213350.GT6618@prithivi.gnumonks.org> <1347635118-sup-6553@dennou> <20120915122454.GE31654@prithivi.gnumonks.org> Message-ID: <1347795435-sup-5434@dennou> Hi, Excerpts from Harald Welte's message of Sat Sep 15 14:24:54 +0200 2012: > hi Kevin, > > On Fri, Sep 14, 2012 at 05:10:24PM +0200, Kevin Redon wrote: > > here some additional comments for functions/structures, and one small renaming (to match ISO 7816-3). > > I think you made some mistake while creating the diff. It contains lots > of whole-file patches and changes bits in libosmogb. Please check > again. The best way to create the patch is probably to commit your > changes and then do 'git format-patch -1'. sorry for the buggy patch. I tried to make a patch for the branch I made for my commits. Here are the individual commit patches. > > Thanks! > > > I would also like to rename Le/Lc into Ne/Nc, as Ne/Nc is the value > > for the length (which is also how it is used in libosmosim), and Le/Lc > > is it's encoded version for the APDU/TPDU. > > Makes a lot of sense, thanks for pointing this out. > I'll make the appropriate changes Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-add-comment-explaination-for-structure-osim_apdu_cas.patch Type: application/octet-stream Size: 1506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-comment-explain-signature-of-osim_new_apdumsg.patch Type: application/octet-stream Size: 1097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-add-comment-explaination-for-structure-osim_apdu_cmd.patch Type: application/octet-stream Size: 1082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-renamed-case-to-the-one-defined-in-ISO7816-3.patch Type: application/octet-stream Size: 5167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-added-utils-osmo-sim-test-to-.gitignore.patch Type: application/octet-stream Size: 522 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-add-comment-explaination-for-structure-osim_msgb_cb.patch Type: application/octet-stream Size: 1274 bytes Desc: not available URL: From laforge at gnumonks.org Sun Sep 16 12:22:27 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 16 Sep 2012 14:22:27 +0200 Subject: Introducing libosmosim In-Reply-To: <1347795435-sup-5434@dennou> References: <20120910213350.GT6618@prithivi.gnumonks.org> <1347635118-sup-6553@dennou> <20120915122454.GE31654@prithivi.gnumonks.org> <1347795435-sup-5434@dennou> Message-ID: <20120916122227.GU31654@prithivi.gnumonks.org> Hi Kevin, On Sun, Sep 16, 2012 at 01:41:59PM +0200, Kevin Redon wrote: > Here are the individual commit patches. thanks a lot. I will merge it, but I think it would be preferred if you can add comments that can be parsed by doxygen. While we don't yet use doxygen for libosmosim, we do use it for the other parts of libosmocore and I want to use it for libosmosim later. So if you have some time, feel free to submit an incremental patch adding the annotations for doxygen. You can look at the examples from libosmocore. Also, if you like, you can add the respective header/footer to each file and the actual doxyfile to actually build the reference documentation for libosmocore. 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 kevredon at mail.tsaitgaist.info Sun Sep 16 16:46:50 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Sun, 16 Sep 2012 18:46:50 +0200 Subject: Introducing libosmosim In-Reply-To: <20120916122227.GU31654@prithivi.gnumonks.org> References: <20120910213350.GT6618@prithivi.gnumonks.org> <1347635118-sup-6553@dennou> <20120915122454.GE31654@prithivi.gnumonks.org> <1347795435-sup-5434@dennou> <20120916122227.GU31654@prithivi.gnumonks.org> Message-ID: <1347813398-sup-1606@dennou> Hi Harald, Excerpts from Harald Welte's message of Sun Sep 16 14:22:27 +0200 2012: > Hi Kevin, > > On Sun, Sep 16, 2012 at 01:41:59PM +0200, Kevin Redon wrote: > > > Here are the individual commit patches. > > thanks a lot. I will merge it, but I think it would be preferred if you > can add comments that can be parsed by doxygen. While we don't yet use > doxygen for libosmosim, we do use it for the other parts of libosmocore > and I want to use it for libosmosim later. > I did not use doxygen yet. Feel free to correct/teach me if my doxygen comments are wrong/missing. > So if you have some time, feel free to submit an incremental patch > adding the annotations for doxygen. like so (see patch)? > You can look at the examples from > libosmocore. Also, if you like, you can add the respective > header/footer to each file and the actual doxyfile to actually build the > reference documentation for libosmocore. will do kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-replaced-function-structure-comments-with-doxygen-co.patch Type: application/octet-stream Size: 6455 bytes Desc: not available URL: From laforge at gnumonks.org Sun Sep 16 20:26:15 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 16 Sep 2012 22:26:15 +0200 Subject: Introducing libosmosim In-Reply-To: <1347813398-sup-1606@dennou> References: <20120910213350.GT6618@prithivi.gnumonks.org> <1347635118-sup-6553@dennou> <20120915122454.GE31654@prithivi.gnumonks.org> <1347795435-sup-5434@dennou> <20120916122227.GU31654@prithivi.gnumonks.org> <1347813398-sup-1606@dennou> Message-ID: <20120916202615.GE31654@prithivi.gnumonks.org> Hi Kevin, On Sun, Sep 16, 2012 at 06:46:50PM +0200, Kevin Redon wrote: > I did not use doxygen yet. Feel free to correct/teach me if my doxygen comments are wrong/missing. I'm a doxygen beginner myself. > > So if you have some time, feel free to submit an incremental patch > > adding the annotations for doxygen. > > like so (see patch)? yes, thanks. I've merged it. > > You can look at the examples from > > libosmocore. Also, if you like, you can add the respective > > header/footer to each file and the actual doxyfile to actually build the > > reference documentation for libosmocore. > > will do erm, I meant 'build it for libosmosim like we do for libosmocore'. 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 laforge at gnumonks.org Tue Sep 18 17:49:25 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 18 Sep 2012 19:49:25 +0200 Subject: Sept 19, 8pm / Osmocom Berlin User Group meeting Message-ID: <20120918174925.GL3968@prithivi.gnumonks.org> Hi all! This is the announcement for the next Osmocom Berlin meeting. Sept 19, 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, 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 Wed Sep 19 17:48:15 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 19 Sep 2012 19:48:15 +0200 Subject: Sept 19, 8pm / Osmocom Berlin User Group meeting In-Reply-To: <20120918174925.GL3968@prithivi.gnumonks.org> References: <20120918174925.GL3968@prithivi.gnumonks.org> Message-ID: <20120919174815.GG1258@localhost> On Tue, Sep 18, 2012 at 07:49:25PM +0200, Harald Welte wrote: > Hi all! Hi, I am not going to make it today, I hope some other Osmocom/CCC members will be present. sorry