Hi Marcel, > 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. Yes, that's true, though the control path is actually going through one of the data pipes as well. > 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. So the control path *itself* would be there, I guess, but ... > 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. there's definitely room for more information than _just_ the control path "chat", also application state etc. would be useful, and logging etc. Typically on wifi we feed all of this together into kernel tracing (to record with trace-cmd) rather than trying to encapsulate it some other way. > 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. Right. This is something we'd typically use tracing for in wifi. I don't really know what the right model for WWAN would be, I guess. Right now - and I really should've said this before - really the only problem I was thinking of was how we can mux multiple "chat" sessions with a device into a single data stream. Currently, this is all vendor-specific. If you have a Qualcomm modem, you'd be able to see all the open sessions on the underlying netdev, and the QMI header tells you what session a given 'packet' belongs to, and if you follow along maybe you can figure out if this is a control or IP 'packet' (could be an AT command). cdc_mbim uses VLAN tags instead to achieve this, and decapsulates the VLAN tags to send them down to the hardware in a different way. There are a few reasons why I think that this model of having a single underlying netdev controlled by the modem driver, with additional netdevs layered on top in software will not work right in the future. I think drivers should and will need to migrate to creating "real" netdevs for the sessions instead of pure software ones. But if you do this, you lose the ability to listen to all the session streams at the same time, you can only do it for each netdev. Adding this ability back seems worthwhile, but then we probably shouldn't do it in a vendor-specific way, but rather in a generic way. So basically right now that's all I'm trying to solve. In WiFi we don't have the problem of "sessions" because we just use the addresses in the frames to disambiguate - on such 'monitor' netdevs we see the frames including full 802.11 headers. Now, here's maybe where I'm getting off the right path - in wifi we mostly couple that with PHY information as well, and so we have PHY information + full 802.11 headers + data for capturing what's going on. I figured that theoretically at least that would be possible/useful for the modem as well (obviously control packets have no PHY data), but there doesn't seem to be any hardware that would actually expose data in this way. Everyone I've spoken to says these things are only available as modem trace data. What I haven't figured out though is if that's by some other design trade-off, or just because no such infrastructure is/was available. It may well be that doing kernel-tracing instead of doing it via some kind of monitor netdev is perfectly sufficient, but I have a feeling that the relative simplicity of starting tcpdump/wireshark might be preferable. johannes
