FYI, there
already was a discussion about GSMTAPv3:
https://www.youtube.com/watch?v=vum9jzavZi0&list=PL07C78AF831FFE8F9&…
but unfortunately, nobody has invested time into this (yet?).
2012! But, umm, I don't really have time for a whole video right now -
anyone have the slides? :-)
But yeah, the first slides look sensible :-)
1) Why
the design with encapsulating it in UDP?
This gives us a possibility to "demux" multiple GSMTAP streams on the
receiving side, e.g. if you are running multiple processes.
Not sure I get this, but I also don't really care all that much. It's
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...
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?
before you go all out and define this, it would suggest to understand what meta-data for
the connection contexts you actually need as well. The data path itself is just a pipe and
has not all the information attached with it. That goes via the control path and that is
normally in user space and carries the real important information to make useful analysis
of how the data path / context is setup.
From what I am seeing right now is that unless you have a method to also feed the control
path into your GSMTAPv3, then this is rather useless. The majority of the debugging is
really done for the control path. For oFono that is OFONO_DEBUG=1 environment variable and
while it works it is not the most elegant solution. I would love to feed that into a
generic debugging / tap that you can read out later.
As a side note, for Bluetooth we created a path where the bluetoothd can feed back its
control debugging data back into the Bluetooth monitor in the kernel to allow combined
userspace, mgmt and HCI tracing. Some really nasty issues could only be triaged by having
all the meta data with a common timestamp.
Regards
Marcel