This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Marcel Holtmann marcel at holtmann.orgHi Johannes, >> 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. I think that viewpoint is too simplistic. And for sure we have no such system where the control path is done as IP packets for Ethernet packets. >> 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. Same thing, but different way of doing it. Mind you that Bluetooth support is older than tracing. > 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. I do not follow on why is that. Why would I care if wwan0 is self-sustained of just a VLAN device. Or for that matter any other kind of slave/child device. 3GPP and 3GPP2 are not Ethernet frame based. We only have raw IPv4 and IPv6 packets for the data path. > 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. And for 3GPP you have context identifiers that at least within the context of the control path make logical sense of the data streams and what they are assigned to. This goes back to my original point. You need to capture the control path to see what APN context is set up and how. Mind you that you also have the fun between primary context and secondary context (primarily for quality of service in VoLTE cases). > 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. As I said, as long as you do not get the QMI, AT command, MBIM etc. control path session recorded as well, you have nothing to really analyze. Regards Marcel