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/.
Johannes Berg johannes at sipsolutions.netOn Fri, 2019-04-12 at 21:49 +0200, Marcel Holtmann wrote: > > > 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. That's true, but as far as I can tell in a lot of cases the pipe is actually still a virtual netdev (session, encoded in whatever way) using some sort of serial line format on top? But I agree that typically this will not be sufficient anyway. > > 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. Sure. Looking forward though, perhaps tracing *would* indeed be the simplest thing to do. > > 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. >From a driver perspective I think it makes a difference. For example, if you just have a single netdev from the driver, it gets harder to do multiple TX/RX queues properly. > 3GPP and 3GPP2 are not Ethernet frame based. We only have raw IPv4 and > IPv6 packets for the data path. Sure. Though some drivers/devices fake them anyway. > 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). Right. > > 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. But you do - afaict there are no ways other than the netdevs to communicate with the device, and people do things like "socat" to set up PTYs and pretend to have serial channels there, on top of the netdevs? johannes