From jjuergens at seemoo.tu-darmstadt.de Fri Jan 13 11:37:54 2017 From: jjuergens at seemoo.tu-darmstadt.de (=?UTF-8?Q?Jannik_J=c3=bcrgens?=) Date: Fri, 13 Jan 2017 12:37:54 +0100 Subject: osmo-tetra: Add DMO Code Message-ID: <42d602cd-dbb9-7377-a136-2c3b9d8a15f0@seemoo.tu-darmstadt.de> Dear Osmocom Community, I currently writing my masterthesis about TETRA. For this, I am currently writing my master thesis on TETRA. For this the support of DMO is necessary. Another student had already implemented a rudimentary DMO receiver (based on the Osmocom code) in his thesis, which I now develop further. I would like to add this code to the Osmocom project as a new branch so that other people can participate. I was unsure, based on which branch I should develop the code, but I decide for the laforge / sq5bpf-rebase-20161218 branch, because this is most useful for my purpose. I hope this is okay and doesn't lead to chaos. When trying to create a new branch and commit this, however I get an error message: $ Git push origin jj / dmo Error: no DAV locking support at https://git.osmocom.org/osmo-tetra/ Fatal: git-http-push failed Error: Error sending some references to 'https://git.osmocom.org/osmo-tetra' Unfortunately, I have not found instructions, who is at Osmocom allowed to commit code or how the process works. Can you help me with this or send me a link, where I find the appropriate information? Best regards, Jannik From lbernal at gmail.com Fri Jan 13 12:51:55 2017 From: lbernal at gmail.com (n0p [Luis Bernal]) Date: Fri, 13 Jan 2017 13:51:55 +0100 Subject: osmo-tetra: Add DMO Code In-Reply-To: <42d602cd-dbb9-7377-a136-2c3b9d8a15f0@seemoo.tu-darmstadt.de> References: <42d602cd-dbb9-7377-a136-2c3b9d8a15f0@seemoo.tu-darmstadt.de> Message-ID: I think you'll have to send a patch to this list to have it reviewed. 2017-01-13 12:37 GMT+01:00 Jannik J?rgens : > Dear Osmocom Community, > > I currently writing my masterthesis about TETRA. For this, I am > currently writing my master thesis on TETRA. For this the support of DMO > is necessary. Another student had already implemented a rudimentary DMO > receiver (based on the Osmocom code) in his thesis, which I now develop > further. I would like to add this code to the Osmocom project as a new > branch so that other people can participate. > > I was unsure, based on which branch I should develop the code, but I > decide for the laforge / sq5bpf-rebase-20161218 branch, because this is > most useful for my purpose. I hope this is okay and doesn't lead to > chaos. When trying to create a new branch and commit this, however I get > an error message: > > $ Git push origin jj / dmo > Error: no DAV locking support at https://git.osmocom.org/osmo-tetra/ > Fatal: git-http-push failed Error: Error sending some references to > 'https://git.osmocom.org/osmo-tetra' > > Unfortunately, I have not found instructions, who is at Osmocom allowed > to commit code or how the process works. Can you help me with this or > send me a link, where I find the appropriate information? > > Best regards, > Jannik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sq5bpf at lipkowski.org Fri Jan 13 13:37:52 2017 From: sq5bpf at lipkowski.org (Jacek Lipkowski) Date: Fri, 13 Jan 2017 14:37:52 +0100 (CET) Subject: Revamping osmo-tetra Message-ID: On Mon, 19 Dec 2016, Harald Welte wrote: > thanks for your quick answer. now sorry for my late answer :) >> The problem with my code is that it was written for a particular purpose >> (which was running telive), and is really really ugly. It would be better to >> agree on a nice standardised way to get data from osmo-tetra to external >> programs (not gsmtap, i want cooked data, not raw). > > The question is what kind of information you're relly looking for. information that can be used by an external program without having to implement that which is already in osmo-tetra. this would be: - signalling data (d-setup, d-sds etc) with the fields (SSI etc) in some easy to interpret format (xml is fine) - binary data (voice frames, data frames etc), maybe along with a little bit of metadata - "housekeeping data" that is internally generated, but is useful for the application (telive version, frame count, information if the decoder is currently picking up frames, error rates etc) > Parsing all the data in hand-crafted C code and then re-encoding it into > some other intermediary format doesn't really seem like a great idea, > unless you have an army of developers at hand who like to do that :) you're right. on the other hand there is not that much pdu types which are interesting to me (d-setup, d-release etc), and if someone needs to implement yet another pdu, then he can easily do it. > The wireshark tetra dissector solved that problem by transcribing the > TETRA messages as ASN.1 with UPER encoding rules. We could do something > similar and use asn1c to do an automatic "transcoding" to XER (XML > Encoding Rules) or simply pass the parsed C structures generated by > asn1c around. this looks like a *LOT* of work (at least to me). i'd start with what is already implemented. btw i was also thinking about xml. unfortunately there will be overhead. currently you can run the code (gnuradio, qpsk decoder, my fork of osmo-tetra and telive) on a raspberry pi 3, and this can work for 2-3 channels simultaneously. i'm not sure this will still be possible with a full blown xml implementation, but we'll see. any thoughts aout the interface to other applications? my fork just sends everything in udp packets (which can get lots/reordered etc). there must be a better way (tcp is not one of them). any ideas? jacek From laforge at gnumonks.org Fri Jan 13 20:20:14 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 13 Jan 2017 21:20:14 +0100 Subject: osmo-tetra: Add DMO Code In-Reply-To: <3d75d67b-2f79-d058-e1b3-b722c15de697@seemoo.tu-darmstadt.de> References: <3d75d67b-2f79-d058-e1b3-b722c15de697@seemoo.tu-darmstadt.de> Message-ID: <20170113202014.jhfgcwiogjsmlutb@nataraja> Hi Jannik, On Fri, Jan 13, 2017 at 12:10:57PM +0100, Jannik J?rgens wrote: > I currently writing my masterthesis about TETRA. For this, I am > currently writing my master thesis on TETRA. For this the support of DMO > is necessary. Another student had already implemented a rudimentary DMO > receiver (based on the Osmocom code) in his thesis, which I now develop > further. I would like to add this code to the Osmocom project as a new > branch so that other people can participate. Thanks for reaching out, and I'm looking forward to see DMO support in the project! Unrelated to your work, Sylvain has recently published some DMO related wokr in the users/tnt/dmo branch. We had a quick conversation about DMO at 33C3 and he started right away to modify the demodulator/decoder from the osmo-gmr project. Have you seen that yet? Did you play with it yet? In general, the goal should be to not only have yet another branch, but to actually take it all the way to actually get it merged. I understand of course that as a student your primary goal is your thesis, but I have seen a lot of "fire and forget" style "contributions" of students before. Please take the extra effort and go through review cycles until your code is merged. Having it somewhere in a branch is nice, but in the end there will be dozens of diverging branches, with different featureset, unable to reconcile. This is clearly not the collaborative Free Software development process :) > I was unsure, based on which branch I should develop the code, but I > decide for the laforge / sq5bpf-rebase-20161218 branch, because this is > most useful for my purpose. I hope this is okay and doesn't lead to > chaos. When trying to create a new branch and commit this, however I get > an error message: It would be preferable to develop related changes based on master. The sq5bpf code (as you can see by recent mails on the list) is more experimental and (as can be seen from only looking at coding style) unfortuntely needs some more clean up before it can be merged. Please don't get me wrong. I love it if people work one features and I want to encourage all kinds of contributions. But at the same time, we have to maintain some degree of architecture and code quality. Even 'sq5bpf' himself has stated that he didn't officially submit his code as he doesn't think his code is ready for getting merged. So if you base your code on that, you introduce a dependency that might make it harder to get your code merged eventually - or at least a dependency on something outside your control. But it's of course your choice. > $ Git push origin jj / dmo > Error: no DAV locking support at https://git.osmocom.org/osmo-tetra/ > Fatal: git-http-push failed Error: Error sending some references to > 'https://git.osmocom.org/osmo-tetra' the http and git protocol is for check-out only. In order to commit, you need to use a ssh+git URL and have your ssh public key resgistered. To do so, please send it to me. you can then push your code into a branch. > Unfortunately, I have not found instructions, who is at Osmocom allowed > to commit code or how the process works. Can you help me with this or > send me a link, where I find the appropriate information? This depends on project by project basis. In the cellular infrastructure projects we have recently started to use Gerrit (see http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit) but this has not been adopted by all projects, particularly not those that haven't seen much activity in past years like osmo-tetra. However, I'm tempted to migrate osmo-tetra over to gerrit. What do you think? Have you worked with gerrit before? Unless we introduce gerrit, you can push code to a user-branch to the repo, but from there you will have to use git send-email to send patch series for submission here to this list, where changes will be reviewed and then hopefully merged. 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 sq5bpf at lipkowski.org Fri Jan 13 20:54:42 2017 From: sq5bpf at lipkowski.org (Jacek Lipkowski) Date: Fri, 13 Jan 2017 21:54:42 +0100 (CET) Subject: osmo-tetra: Add DMO Code In-Reply-To: <20170113202014.jhfgcwiogjsmlutb@nataraja> References: <3d75d67b-2f79-d058-e1b3-b722c15de697@seemoo.tu-darmstadt.de> <20170113202014.jhfgcwiogjsmlutb@nataraja> Message-ID: On Fri, 13 Jan 2017, Harald Welte wrote: > It would be preferable to develop related changes based on master. The > sq5bpf code (as you can see by recent mails on the list) is more > experimental and (as can be seen from only looking at coding style) > unfortuntely needs some more clean up before it can be merged. i don't know the quality of the code, but maybe merge it into https://github.com/sq5bpf/osmo-tetra-sq5bpf ? i doubt you're able to write uglier code than i did, so that's not an issue. this code gets regular use by hundreds of people (or rather thousands, many people that use it would like to stay under the radar so you won't hear from them), so you will hear about any bugs quick. also i will add support for it in telive (frontend application to listen/record/log/whatever) you will also find interesting things not currently present in stock osmo-tetra, like fragment reassembly (useful to put long sds messages together), or a simple (and ugly) interface for other programs to get data from it. and eventually i will try to merge all of this code into osmo-tetra (and clean it up beforehand). so even if you loose interest after your thesis is over there will be someone working on it. jacek From jjuergens at seemoo.tu-darmstadt.de Sat Jan 14 11:10:23 2017 From: jjuergens at seemoo.tu-darmstadt.de (=?UTF-8?Q?Jannik_J=c3=bcrgens?=) Date: Sat, 14 Jan 2017 12:10:23 +0100 Subject: osmo-tetra: Add DMO Code In-Reply-To: References: <3d75d67b-2f79-d058-e1b3-b722c15de697@seemoo.tu-darmstadt.de> <20170113202014.jhfgcwiogjsmlutb@nataraja> Message-ID: Thanks for your reply. On Fri, 13 Jan 2017, Harald Welte wrote: > Unrelated to your work, Sylvain has recently published some DMO related > wokr in the users/tnt/dmo branch. We had a quick conversation about DMO > at 33C3 and he started right away to modify the demodulator/decoder from > the osmo-gmr project. Have you seen that yet? Did you play with it yet? I looked at it briefly. To be honest, I did not really understand the code or its intention at the first glance. > It would be preferable to develop related changes based on master. The > sq5bpf code (as you can see by recent mails on the list) is more > experimental and (as can be seen from only looking at coding style) > unfortuntely needs some more clean up before it can be merged. Maybe we create a feature branch for DMO based on master and I will create patch for the sq5bpf code because I already have written some code for this branch. My intention is not to write quick and dirty code which is not usable for further development. I personally will develop my code first for the sq5bpf branch, but an integration into the master branch afterwards should not be so much overhead. > However, I'm tempted to migrate osmo-tetra over to gerrit. What do you > think? Have you worked with gerrit before? I have not worked with it yet. On Fri, 13.01.2017, Jacek Lipkowski wrote: > i don't know the quality of the code, but maybe merge it into > https://github.com/sq5bpf/osmo-tetra-sq5bpf ? > > i doubt you're able to write uglier code than i did, so that's not an > issue. > > this code gets regular use by hundreds of people (or rather thousands, > many people that use it would like to stay under the radar so you > won't hear from them), so you will hear about any bugs quick. also i > will add support for it in telive (frontend application to > listen/record/log/whatever) Sounds nice, but we should avoid parallel development in two different repositories. Because my changes for DMO only affects the osmocom part of telive, I would prefer to develop the code in the osmocom project. However, I already developed the DMO support for your code, so I will send you a patch. But if someone finds a bug, we should be alert to update the osmocom branch. I will clean up my code and optimize the DMO support. Probably next week I will send you a patch or create a feature branch. Regards, Jannik > On Fri, 13 Jan 2017, Harald Welte wrote: > >> It would be preferable to develop related changes based on master. The >> sq5bpf code (as you can see by recent mails on the list) is more >> experimental and (as can be seen from only looking at coding style) >> unfortuntely needs some more clean up before it can be merged. > > i don't know the quality of the code, but maybe merge it into > https://github.com/sq5bpf/osmo-tetra-sq5bpf ? > > i doubt you're able to write uglier code than i did, so that's not an > issue. > > this code gets regular use by hundreds of people (or rather thousands, > many people that use it would like to stay under the radar so you > won't hear from them), so you will hear about any bugs quick. also i > will add support for it in telive (frontend application to > listen/record/log/whatever) > > you will also find interesting things not currently present in stock > osmo-tetra, like fragment reassembly (useful to put long sds messages > together), or a simple (and ugly) interface for other programs to get > data from it. > > and eventually i will try to merge all of this code into osmo-tetra > (and clean it up beforehand). so even if you loose interest after your > thesis is over there will be someone working on it. > > jacek From jjuergens at seemoo.tu-darmstadt.de Mon Jan 23 11:25:40 2017 From: jjuergens at seemoo.tu-darmstadt.de (=?UTF-8?Q?Jannik_J=c3=bcrgens?=) Date: Mon, 23 Jan 2017 12:25:40 +0100 Subject: DMO Patch for sq5bpf rebase branch Message-ID: <1049d5d9-a66d-0230-81cf-080f80a58fd1@seemoo.tu-darmstadt.de> Hello, as already announced here is a first DMO patch for the sq5bpf rebase branch. I currently only modified the physical and lower mac layer. I added a new SAP: dp_sap_udata_ind but decided to forward the data to the TMO SAP because otherwise there would be a lot duplicate code. Best regards Jannik -------------- next part -------------- A non-text attachment was scrubbed... Name: dmo-for-sq5bpf-rebase.patch Type: text/x-patch Size: 55458 bytes Desc: not available URL: