Hi Johannes, On Wed, Apr 10, 2019 at 09:23:13AM +0200, Johannes Berg wrote: > > but unfortunately, nobody has invested time into this (yet?). > > 2012! Well, Osmocom is a very small community, with probably somewhere less than 25 active developers over the last few years (less than 15 full-time), with an *incredibly* large scope: Implement virtually any protocol layer of any protocol stack on any of the 3GPP interfaces and all their related network elements for 2G/3G as well as even other technologies like TETRA, GMR-1, ... And all that in a field of technology that has less free software than the Operating Systems world had in the mid-1990ies. It really feels a bit like the Linux community 20 years ago. So resources are always *extremely* tight, and given those limited resources, I'm actually very happy with the results by now, having automatied CI, build verifications, unit tests, functional test suites, end-to-end testing, and all the code we implemented on git.osmocom.org :) While current GSMTAPv2 is ugly, it works rather solid for all known existing use cases, so there was no urgency to introduce a new version of it. > Not sure I get this, but I also don't really care all that much. Well, with all respect, GSMTAP was created for a variety of use cases, see my other lengthy mail. It's fine if you don't care, but unless you could explain your use cases with a few paragraphs, neither you nor us are able to determine if there is common functionality and if it makes sense to use GSMTAP or not :) So far I have not seen any explanation about what kind of data you want to encapsulate at all. > just a pretty strange design if the kernel were to output this, I'm not > even sure how I'd do that properly. I don't want to be generating UDP > packets there... There are well-established APIs for having sockets in the kernel and for generating + receiving UDP packets from it. NFS has been doing this for decades, as do various kernel-side tunneling helpers including the GTP kernel module. I'm not saying it's the right approach for your problem, I'm just saying kernel-side code can for sure use UDP sockets. > Perhaps we can define something (GSMTAPv3) to not really care how it's > encapsulated, and for 'native' packet captures like what I want on Linux > when integrated with the driver, actually use an ARPHDR_GSMTAP, and > encapsulate in UDP when you create it in an application and want to send > it elsewhere, rather than just writing it to a pcap file? Sure, that works. But the real question is, to me: Are there common GSMTAP payload types that both the existing GSMTAP users carry, as well as what you would want to carry? If yes, then it makes sense to think about a common encapsulation like GSMTAP. If the payload types differ, then it seems rather like there are two distinct use cases that wouldn't benefit from standardizing on one format. Regards, Harald -- - Harald Welte <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
