DSS usage

[Bjørn Mork]

Bjørn Mork <bjorn at mork.no> writes:
> Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:
>
>> Of course as the long term solution a DSS channel should be visible as
>> a character device.
>
> A network device can easily be converted to a character device in
> userspace using a pty. socat is one userspace implementation.  There is
> nothing preventing the implementation of a similar proxying solution in
> software written for some specific DSS application.
>
> In any case, I see no reason to reimplement this proxying functionality
> as a kernel driver, having to add a driver specific API to manage the
> character devices.  The data manipulation would maybe be simpler, but
> the device management API most certainly would not.

Just to follow up on this, I had to test out my brave statements :-)

I spent a couple of hours trying to write such a proxy application from
scratch, deliberately choosing not to take advantage of any existing
packet capture helper library.  Just standard system libraries (it needs
'-lutil' though) and kernel APIs. Of course extremely Linux specific and
unportable, but that comes with the Linux cdc_mbim driver API anyway...

The result is attached. It's not beautiful and ready for production,
creating 256 DSS ptys whether they are needed or not. I would at least
add a relation to DSS connect and disconnect actions, proxying *only*
the actually open channels for a real implementation.  But it works.
Or...

Well, it *would* have worked if it weren't for something I have decided
to label a serious bug in the driver: The driver doesn't handle VLAN
tags added by any other means than through a sub-interface. There is a
bogus assumption that setting NETIF_F_HW_VLAN_CTAG_TX ensures
out-of-band tags, but this is not true for packet sockets (or for e.g.
bridged tap interfaces, I guess). Such packets are silently dropped
instead of being forwared to the appropriate MBIM session. IMHO, the
driver *must* cope with in-band tags as well.  This doesn't just affect
DSS, but also the IP VLANs.  The use cases are mabye odd, but the effect
is certainly unexpected and hard to debug. And also currently impossible
to work around, AFAICS.  At least I didn't find anything inside
af_packet that will allow VLAN tagging by any other means than in-band.

I will fix this ASAP.  I have a debug version locally, but the real fix
is not ready yet.

So this driver bugfix is required for the attached implementation.  If
you want to make proxying work with the current driver, then there is no
way around creating a subdev per DSS session and making the proxy at
least transmit on the subdev (it can still listen on the master to
reduce the number of fd's you have to select on).

I'm still attaching the application FYI.

> It's not like we can make the driver just create a character device and
> make it immediately available for any legacy application written for a
> serial port. MBIM DSS sessions are not just "there", like for example a
> USB serial function. Something has to manage the session, and this
> something should know what type of data the stream contains.  This
> "something" can then just as well set up the necessary data
> transformation for any legacy application it wants to support.
>
> For example, if you want to support NMEA over DSS using gpsd, then you
> will create a userspace application which
>  - starts the appropriate DSS session
>  - creates the matching VLAN
>  - proxies the VLAN to a pty, adding and stripping ethernet headers
>  - adds the pty to the list of gpsd devices
>
> I believe it would make sense for libmbim to provide utility functions
> taking care of the first three.

If I were more of a programmer, then I would of course have worked on a
real implementation for libmbim.  The truth is that I don't have a clue
where I would start doing that.  So therefore, this proof-of-concept is
all you get for now.


Bjørn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsschannel.c
Type: text/x-csrc
Size: 11901 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140509/bc2a676a/attachment.c>