DSS usage

[Dmytro Milinevskyy]

Hello Bjørn,

----- Original Message -----
> 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.

This approach still requires the network interface to be always "UP".
Will it be managed by libmbim?

thanks,
~ dmytro

> 
> 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
> 


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.