On 31/05/16(Tue) 13:08, Gerhard Roth wrote:
> [...]
> I'm quite sure this is a firmware bug and the only workaround I have
> is the match by VID/PID. That still allows to match other MBIM devices
> not listed in the table to be matched by Class/SubClass.
I'd prefer if we could start like that, th
On 31/05/16(Tue) 15:52, Gerhard Roth wrote:
> On Mon, 23 May 2016 17:47:28 +0200 Martin Pieuchot wrote:
> > On 23/05/16(Mon) 16:51, Gerhard Roth wrote:
> > > On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot
> > > wrote:
> > > > On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> > > >
> > > > This
> But using SIOCAIFADDR/SIOCDIFADDR seems rather awkward since in_control()
> requires a 'struct socket *so' argument (even though it does nothing with
> it, except checking 'so->so_state & SS_PRIV'). Creating a socket inside
> the driver for this sole purpose seems just as weird as setting up a
>
On Mon, 23 May 2016 17:47:28 +0200 Martin Pieuchot wrote:
> On 23/05/16(Mon) 16:51, Gerhard Roth wrote:
> > On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot wrote:
> > > On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> > >
> > > This is crazy :) No driver should ever modify `ia' directly. This
On Mon, 23 May 2016 17:47:28 +0200 Martin Pieuchot wrote:
> On 23/05/16(Mon) 16:51, Gerhard Roth wrote:
> > On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot wrote:
> > > On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> > > > This is part 2 of the MBIM patch. It adds the mbim driver to i386
> > > >
On 23.05.2016 17:47, Martin Pieuchot wrote:
On 23/05/16(Mon) 16:51, Gerhard Roth wrote:
Why do you need to set a default route in the first place?
Just like PPP this was designed as a point-to-point interface. The idea
is that once you get an uplink, all traffic should be routed through it.
On 23/05/16(Mon) 16:40, Stuart Henderson wrote:
> What I don't understand is why routing to a point-to-point interface needs
> anything other than the interface name to be used for the destination.
It doesn't really need anything else. At least not from the network
stack point of view.
Well I'm
On 23/05/16(Mon) 16:51, Gerhard Roth wrote:
> On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot wrote:
> > On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> > > This is part 2 of the MBIM patch. It adds the mbim driver to i386
> > > +/*
> > > + * Some devices are picky about too frequent control mess
> > Just like PPP this was designed as a point-to-point interface. The idea
> > is that once you get an uplink, all traffic should be routed through it.
> >
> > What other sensible routing could there be? Only routing some selected IP
> > addresses through your mobile uplink doesn't seem like the
On 2016/05/23 16:51, Gerhard Roth wrote:
> > This is the kind of horrors I have been removing during the past years.
> >
> > Why do you need to set a default route in the first place?
>
> Just like PPP this was designed as a point-to-point interface. The idea
> is that once you get an uplink, all
> > Why is it better? This is just working around usb_probe_and_attach()
> > and require developer to add an entry for every device we need to
> > support.
>
> I just thought that some modules that are already in use say with a
> umsm config would otherwise change to mbim and break the setup. The
On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot wrote:
> On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> > This is part 2 of the MBIM patch. It adds the mbim driver to i386
>
> Comments inline.
Replies too.
>
> > Index: sys/dev/usb/if_mbim.c
> > ==
On 23/05/16(Mon) 15:38, Gerhard Roth wrote:
> This is part 2 of the MBIM patch. It adds the mbim driver to i386
Comments inline.
> Index: sys/dev/usb/if_mbim.c
> ===
> RCS file: sys/dev/usb/if_mbim.c
> diff -N sys/dev/usb/if_mbim.c
>
This is part 2 of the MBIM patch. It adds the mbim driver to i386
and amd64 kernels.
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.418
diff -u -p -u -p -r1.418 GENERIC
-
14 matches
Mail list logo