Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 13.06.2016 12:52, Martin Pieuchot wrote:

On 10/06/16(Fri) 21:09, Mark Kettenis wrote:

Date: Fri, 10 Jun 2016 17:20:18 +0100
From: Stuart Henderson 

On 2016/06/10 16:05, Mark Kettenis wrote:

In any case this is something we can figure out once the code hits the
tree.  Unless mpi@ is still unhappy with the way the driver performs
ioctls, I think we should get the driver bits into the tree such that
we can work on fixing the remaining issues with it.


Agreed.

Did people notice the uhub.c part? Any concerns with that?


Yes, that is a separate issue as well.  And should therefore be a
separate commit.  It doesn't seem unreasonable to me to retry once
before giving up.  But this is another area where mpi@ should have the
final say.

The printf doesn't trigger on my Sierra Wireless EM7345 (which really
is an Intel XMM 7160 in disguise).


I'm worried that this hack alone won't help us improve the currently
outdated code to initialize USB devices as it will work around other
bugs.

That said I think it's a good starting point to improve things,  so I
gave Gerhard my ok.



Thanks for the ok, the umb(4) driver has been committed now.

But because of the controversy, I did exclude the uhub.c part.
I would suggest to wait and see what other users of umb(4) experience.
If I'm the only one seeing this strange behavior, we might just forget
about it. But if others suffer from it, too, then I'll submit a separate
patch for it.

Gerhard

Re: MBIM Patch (Round 3)

[Bryan Vyhmeister]

On Tue, Jun 14, 2016 at 11:56:14PM +0100, Stuart Henderson wrote:
> As far as I can make out, the FCC auth is to enable the radio rather
> than anything else, the command has to be sent over (qmi-over-)MBIM.
> I haven't had time to get a linux install to see how it behaves there
> but I would assume that it could easily look like an rfkill until
> that command is sent.

Hopefully that's the problem.

> The patch I sent (I think it may have been offlist) is highly unlikely
> to work as-is, it looked like the device needs to be reset as well
> after sending the command..

Ah. That explains why I couldn't find the patch. I'm happy to test at
some point. Thanks again.

Bryan

Re: MBIM Patch (Round 3)

[Bryan Vyhmeister]

On Tue, Jun 14, 2016 at 11:17:56PM +0200, Gerhard Roth wrote:
> Well, the device still refuses to turn on the radio and without it,
> there's no chance to register with the provider.
> 
> That you see more information now is just due to the fact, that the
> state machine now continues beyond the "turn radio on" step.
> 
> You might try the FCC auth patch, but I'm not very confident about
> it in your situation. Your device already speaks MBIM, so why should
> we need to enable it.
> 
> I haven't got the slightest clue, why it refuses to turn on the radio.
> It might be related to the type of SIM card. But honestly, I don't know.

I tried to apply your most recently posted public patch again on a clean
tree and ran into some problems with patching. As soon as I figure out
what changed between your patch and -current src I will try again with a
Verizon Wireless SIM card. It does seem that different device firmware
is specific to specific carriers in some cases but it's not that clear.
If I can rule out the SIM card causing problems it is at least one step
further along. Thanks again! I hope that umb(4) can make it into OpenBSD
soon!

Bryan

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 10.06.2016 14:41, Bryan Vyhmeister wrote:

On Fri, Jun 10, 2016 at 09:43:36AM +0200, Gerhard Roth wrote:

Hmm, I don't see the missing break. It is still stuck in the same
state trying to turn on the radio and always getting non-confirmative
resonses.

If the break before "case UMB_S_RADIO:" is missing, I would expect
to see a debug printf "umb0: init: checking SIM state ...".
Could you please check once again?



From a previous email you said to comment out the break after "case

UMB_S_RADIO" which did not have any effect. Commenting out the break
after "case UMB_S_OPEN" as I believe you are saying above did have an
effect.


case UMB_S_OPEN:
DPRINTF("%s: init: turning radio on ...\n", DEVNAM(sc));
umb_radio(sc, 1);
// break;
case UMB_S_RADIO:
DPRINTF("%s: init: checking SIM state ...\n", DEVNAM(sc));
umb_cmd(sc, MBIM_CID_SUBSCRIBER_READY_STATUS, MBIM_CMDOP_QRY,
NULL, 0);
break;
case UMB_S_SIMREADY:
DPRINTF("%s: init: attaching ...\n", DEVNAM(sc));
umb_packet_service(sc, 1);
break;


The error code is rather generic and gives us no help to
determine why exactly the device refuses to turn on the
radio. But it reports that the hw-state is on, which means
we can at least exclude any rfkill switch ;)

So why does the firmware refuse to turn it on? Could still
be a problem of the PIN-less SIM card you're using.


With the break commented out above I now see this output from ifconfig
umb0 (sensitive info with XXX):

umb0: flags=8811 mtu 1500
index 5 priority 0
roaming disabled registration not registered
state SIM is ready cell-class none
SIM initialized PIN valid (3 attempts left)
subscriber-id  ICC-id XX
device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
phone# ++XX APN broadband
status: down

I have not seen the first ten digits of the SIM card's phone number, the
subscriber-id, or the ICC-id in ifconfig output before so that seems
promising. Could this be something like needing the FCC auth? The debug
output follows. Thank you!


Well, the device still refuses to turn on the radio and without it,
there's no chance to register with the provider.

That you see more information now is just due to the fact, that the
state machine now continues beyond the "turn radio on" step.

You might try the FCC auth patch, but I'm not very confident about
it in your situation. Your device already speaks MBIM, so why should
we need to enable it.

I haven't got the slightest clue, why it refuses to turn on the radio.
It might be related to the type of SIM card. But honestly, I don't know.




Bryan



OpenBSD 6.0-beta (GENERIC.MP) #1: Fri Jun 10 04:25:48 PDT 2016
r...@x.brycv.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17024274432 (16235MB)
avail mem = 16503758848 (15739MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries)
bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016
bios0: LENOVO 20F6CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 
BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) 
PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2485.32 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.21 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: 

Re: MBIM Patch (Round 3)

[Martin Pieuchot]

On 10/06/16(Fri) 21:09, Mark Kettenis wrote:
> > Date: Fri, 10 Jun 2016 17:20:18 +0100
> > From: Stuart Henderson 
> > 
> > On 2016/06/10 16:05, Mark Kettenis wrote:
> > > In any case this is something we can figure out once the code hits the
> > > tree.  Unless mpi@ is still unhappy with the way the driver performs
> > > ioctls, I think we should get the driver bits into the tree such that
> > > we can work on fixing the remaining issues with it.
> > 
> > Agreed.
> > 
> > Did people notice the uhub.c part? Any concerns with that?
> 
> Yes, that is a separate issue as well.  And should therefore be a
> separate commit.  It doesn't seem unreasonable to me to retry once
> before giving up.  But this is another area where mpi@ should have the
> final say.
> 
> The printf doesn't trigger on my Sierra Wireless EM7345 (which really
> is an Intel XMM 7160 in disguise).

I'm worried that this hack alone won't help us improve the currently
outdated code to initialize USB devices as it will work around other
bugs.

That said I think it's a good starting point to improve things,  so I
gave Gerhard my ok.

Re: MBIM Patch (Round 3)

[Mark Kettenis]

> Date: Fri, 10 Jun 2016 17:20:18 +0100
> From: Stuart Henderson 
> 
> On 2016/06/10 16:05, Mark Kettenis wrote:
> > In any case this is something we can figure out once the code hits the
> > tree.  Unless mpi@ is still unhappy with the way the driver performs
> > ioctls, I think we should get the driver bits into the tree such that
> > we can work on fixing the remaining issues with it.
> 
> Agreed.
> 
> Did people notice the uhub.c part? Any concerns with that?

Yes, that is a separate issue as well.  And should therefore be a
separate commit.  It doesn't seem unreasonable to me to retry once
before giving up.  But this is another area where mpi@ should have the
final say.

The printf doesn't trigger on my Sierra Wireless EM7345 (which really
is an Intel XMM 7160 in disguise).

Re: MBIM Patch (Round 3)

[Stuart Henderson]

On 2016/06/10 16:05, Mark Kettenis wrote:
> In any case this is something we can figure out once the code hits the
> tree.  Unless mpi@ is still unhappy with the way the driver performs
> ioctls, I think we should get the driver bits into the tree such that
> we can work on fixing the remaining issues with it.

Agreed.

Did people notice the uhub.c part? Any concerns with that?

> The ifconfig bits seem to be a bit more controversial.  And we
> defenitely need to test those in a RAMDISK context as well.

yes.

Re: MBIM Patch (Round 3)

[Stuart Henderson]

I found 
https://lists.freedesktop.org/archives/libmbim-devel/2016-April/000704.html
which suggests that the Lenovo firmware build of the 7455 is definitely one
that needs the fccauth command.

I don't think fccauth or device support are things that should stop the driver
going in though. It doesn't matter if it works everywhere.

Re: MBIM Patch (Round 3)

[Mark Kettenis]

> From: Gerhard Roth 
> Date: Fri, 10 Jun 2016 00:31:44 +0200
> 
> On 10.06.2016 00:22, Stuart Henderson wrote:
> > On 2016/06/10 00:10, Mark Kettenis wrote:
> >>> From: Gerhard Roth 
> >>> Date: Thu, 9 Jun 2016 23:48:23 +0200
> >>>
> >>> On 09.06.2016 23:42, Mark Kettenis wrote:
> > Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST)
> > From: Mark Kettenis 
> >
> >> Date: Wed, 8 Jun 2016 15:08:52 +0200
> >> From: Gerhard Roth 
> >>
> >> I would be glad to hear from some people trying this with a real MBIM
> >> device.
> >
> > Sierra Wireless EM7345 4G LTE here.  This devices currently attached
> > as umodem(4).  But I did add its vendor id and device id to umb_devs,
> > which makes it partially attach:
> >
> > umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G 
> > LTE" rev 2.00/17.29 addr 2
> > umb0: switching to config #1
> > umb0: ignoring invalid segment size 1500
> > umb0: ctrl_len=512, maxpktlen=8192, cap=0x4
> > umb0: no control interface found
> >
> > (this is with UMB_DEBUG enabled)
> >
> > It seems this device needs some additional poking to select alternate
> > interface settings.
> 
>  With the appropriate alternate settings for the communication
>  interface and data interface (1 and 2) hardcoded in the driver, this
>  works!
> >>>
> >>> Great!
> >>>
> >>> Although another example of a device violating the MBIM spec which
> >>> clearly states that alternate settings 0 and 1 have to be used.
> >>
> >> Which version of the spec are you looking at?  Because my copy
> >> (Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have
> >> to be used ;).
> >
> > There are different sections, 3.2 for dual-mode (NCM1.0 / MBIM)
> > devices talks about various alternate settings for NCM1.0 and
> > for MBIM, then 6.6 which is only dealing with MBIM just talks
> > about 0 and 1 ..
> >
> 
> That's how I looked at it, too. But it seems that some vendors look
> at it differently ;)
> 
> So we should find a solution where we don't need to use the
> currently hard-coded MBIM_INTERFACE_ALTSETTING (== 1) anymore.

I don't think that is too difficult.  The alternate settings are
encoded in the bAlternateSetting of the Interface Descriptor.  So we
just need to remmeber those when we iterate over the full set of
interface descriptors at the start of umb_attach().

In any case this is something we can figure out once the code hits the
tree.  Unless mpi@ is still unhappy with the way the driver performs
ioctls, I think we should get the driver bits into the tree such that
we can work on fixing the remaining issues with it.

The ifconfig bits seem to be a bit more controversial.  And we
defenitely need to test those in a RAMDISK context as well.

Re: MBIM Patch (Round 3)

[Bryan Vyhmeister]

On Fri, Jun 10, 2016 at 09:43:36AM +0200, Gerhard Roth wrote:
> Hmm, I don't see the missing break. It is still stuck in the same
> state trying to turn on the radio and always getting non-confirmative
> resonses.
> 
> If the break before "case UMB_S_RADIO:" is missing, I would expect
> to see a debug printf "umb0: init: checking SIM state ...".
> Could you please check once again?

>From a previous email you said to comment out the break after "case
UMB_S_RADIO" which did not have any effect. Commenting out the break
after "case UMB_S_OPEN" as I believe you are saying above did have an
effect.


case UMB_S_OPEN:
DPRINTF("%s: init: turning radio on ...\n", DEVNAM(sc));
umb_radio(sc, 1);
// break;
case UMB_S_RADIO:
DPRINTF("%s: init: checking SIM state ...\n", DEVNAM(sc));
umb_cmd(sc, MBIM_CID_SUBSCRIBER_READY_STATUS, MBIM_CMDOP_QRY,
NULL, 0);
break;
case UMB_S_SIMREADY:
DPRINTF("%s: init: attaching ...\n", DEVNAM(sc));
umb_packet_service(sc, 1);
break;

> The error code is rather generic and gives us no help to
> determine why exactly the device refuses to turn on the
> radio. But it reports that the hw-state is on, which means
> we can at least exclude any rfkill switch ;)
> 
> So why does the firmware refuse to turn it on? Could still
> be a problem of the PIN-less SIM card you're using.

With the break commented out above I now see this output from ifconfig
umb0 (sensitive info with XXX):

umb0: flags=8811 mtu 1500
index 5 priority 0
roaming disabled registration not registered
state SIM is ready cell-class none
SIM initialized PIN valid (3 attempts left)
subscriber-id  ICC-id XX
device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
phone# ++XX APN broadband
status: down

I have not seen the first ten digits of the SIM card's phone number, the
subscriber-id, or the ICC-id in ifconfig output before so that seems
promising. Could this be something like needing the FCC auth? The debug
output follows. Thank you!

Bryan



OpenBSD 6.0-beta (GENERIC.MP) #1: Fri Jun 10 04:25:48 PDT 2016
r...@x.brycv.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17024274432 (16235MB)
avail mem = 16503758848 (15739MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries)
bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016
bios0: LENOVO 20F6CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 
BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) 
PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2485.32 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.21 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.21 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 10.06.2016 05:09, Bryan Vyhmeister wrote:

On Thu, Jun 09, 2016 at 10:31:58PM +0200, Gerhard Roth wrote:

If that doesn't help, please set UMB_DEBUG and set umb_debug to 5.


I left that break commented out which perhaps I shouldn't have but below
is the output when I set an apn and bring umb0 up.


Hmm, I don't see the missing break. It is still stuck in the same
state trying to turn on the radio and always getting non-confirmative
resonses.

If the break before "case UMB_S_RADIO:" is missing, I would expect
to see a debug printf "umb0: init: checking SIM state ...".
Could you please check once again?



[...]

umb0: init: turning radio on ...
umb0: set radio on
umb0: -> set MBIM_CID_RADIO_STATE (tid 7)
umb0: sent MBIM_COMMAND_MSG (tid 7)
   0:   03 00 00 00 34 00 00 00 07 00 00 00 01 00 00 00
  16:   00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 13 3e
  32:   c2 aa e6 df 03 00 00 00 01 00 00 00 04 00 00 00
  48:   01 00 00 00
umb0: umb_intr: response available
umb0: got response: len 56
   0:   03 00 00 80 38 00 00 00 07 00 00 00 01 00 00 00
  16:   00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 13 3e
  32:   c2 aa e6 df 03 00 00 00 02 00 00 00 08 00 00 00

  ^^^
  status == MBIM_STATUS_FAILURE

  48:   01 00 00 00 00 00 00 00

  ^^^ 
  hw_state on sw_state off

umb0: <- rcv MBIM_COMMAND_DONE (tid 7)
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE



The error code is rather generic and gives us no help to
determine why exactly the device refuses to turn on the
radio. But it reports that the hw-state is on, which means
we can at least exclude any rfkill switch ;)

So why does the firmware refuse to turn it on? Could still
be a problem of the PIN-less SIM card you're using.

Re: MBIM Patch (Round 3)

[Bryan Vyhmeister]

On Thu, Jun 09, 2016 at 10:31:58PM +0200, Gerhard Roth wrote:
> If that doesn't help, please set UMB_DEBUG and set umb_debug to 5.

I left that break commented out which perhaps I shouldn't have but below
is the output when I set an apn and bring umb0 up.


OpenBSD 6.0-beta (GENERIC.MP) #0: Thu Jun  9 16:28:43 PDT 2016
r...@x.brycv.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17024274432 (16235MB)
avail mem = 16503758848 (15739MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries)
bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016
bios0: LENOVO 20F6CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 
BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) 
PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2485.30 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.16 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.16 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.16 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 2 (EXP1)
acpiprt5 at acpi0: bus 4 (EXP3)
acpiprt6 at acpi0: bus -1 (EXP4)
acpiprt7 at acpi0: bus -1 (EXP5)
acpiprt8 at acpi0: bus -1 (EXP8)
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI
acpipwrres1 at acpi0: PG00, resource for PEG0
acpipwrres2 at acpi0: PG01, resource for PEG1
acpipwrres3 at acpi0: PG02, resource for PEG2
acpipwrres4 at acpi0: WRST
acpipwrres5 at acpi0: WRST
acpitz0 at acpi0: critical temperature is 128 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"LEN0071" at acpi0 not configured
"LEN2014" at acpi0 not configured
"INT3F0D" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "45N1113" serial  4020 type LION oem "LGC"
acpibat1 at acpi0: BAT1 model "45N1738" serial  2903 type LION oem "LGC"

Re: MBIM Patch (Round 3)

[Bryan Vyhmeister]

On Thu, Jun 09, 2016 at 10:31:58PM +0200, Gerhard Roth wrote:
> If you're using the latest version of the driver, the 'ifconfig ubm0 inet
> ...' isn't required anymore.
> 
> But you probably have to set the default route after the interface is
> up.

Good to know. Thanks!

> Hmm, around here apart from some special company bulk contracts,
> almost all SIM cards require PINs. But since yours says "PIN valid"
> it clearly is content without one. But the "SIM not initialized"
> is a bit strange.

That seemed odd to me as well.

> No, I don't think that you have problems with the correct APN at this
> stage. The driver is trying to turn on the radio and doesn't get a
> response on the radio state.
> 
> Are you sure you haven't turned it off with the rfkill switch?

There is no physical switch on the X260 that I'm aware of and the WWAN
card is enabled in the BIOS.

> Or maybe this device refuses to accept radio commands and wants to
> auto-control the radio. You could try this by commenting out the
> "break" statement in umb_ub() in the UBM_S_RADIO case and see
> what happens:
> 
> case UMB_S_RADIO:
> umb_cmd(sc, MBIM_CID_SUBSCRIBER_READY_STATUS,
>   MBIM_CMDOP_QRY, NULL, 0);
> // break;
> case UMB_S_SIMREADY:
> umb_packet_service(sc, 1);
> break;
> 
> This way, it will send a command to turn the radio on, but also
> continue to send the next command (register packet service) which
> would otherwise be delayed until the device confirms that the radio
> is on.

I commented out break as above and that made no difference.

> If that doesn't help, please set UMB_DEBUG and set umb_debug to 5.

I'm compiling a new kernel new with UMB_DEBUG and will provide the
output.

Bryan

Re: MBIM Patch (Round 3)

[Bryan Vyhmeister]

On Thu, Jun 09, 2016 at 09:58:10PM +0100, Stuart Henderson wrote:
> You're getting further than me.
> 
> Though, looking at list posts, it does seem that Lenovo is another
> vendor which requires the command being referred to as "fcc auth"
> in order to connect, at least in some of their cards.

That would not be surprising at all. At this point this "fcc auth" would
have to be hardcoded into the driver as well it sounds like?

> There are several PINs and unlock codes (PIN1 PIN2 PUK1 PUK2)
> on a SIM card. A SIM can be setup so that a PIN1 is required to
> make calls etc, or not required. PIN2 is for configuration
> (setting call restrictions, editing the restricted numbers
> list, etc).
> 
> Too many bad attempts to enter a PIN1 will result in the SIM
> being locked and requiring the PUK1 to unlock. In most cases
> these are fairly easy to obtain from the operator.
> 
> Too many bad attempts to enter a PIN2 will result in the SIM
> being locked and requiring the PUK2 to unlock. These are
> usually harder to obtain from the operator and at least
> require more checks.
> 
> From a phone or older-type WWAN device with AT command set
> (or probably the vendor tools on Windows, and maybe libmbim
> on linux) you can control which PINs the card asks for.
> You'll need to know what a PIN is before you can lock it.
> Most operators have a default PIN that they use (different
> ones for different operators) though theoretically they
> could use a different one per SIM.
> 
> If PIN1 is unlocked (no matter whether PIN2 is locked or not),
> you shouldn't need to use a PIN to connect.
> 
> > umb0: SIM not initialized (PIN missing)
> > umb0: SIM not initialized (PIN missing)
> 
> The description in the spec for the state which triggers this
> message is,
> 
> "The operation failed because the device is
> in the process of initializing. Retry the
> operation after the ReadyState of the device
> changes to MBIMSubscriberReadyStateInitialized."
> 
> Spec may differ from real-world devices, but from my reading
> of the spec it doesn't seem to me that this indicates "PIN
> missing".
> 
> I think you should rebuild with UMB_DEBUG (one simple way
> is to just add "#define UMB_DEBUG" before #ifdef UMB_DEBUG
> in if_umb.c) and see if you get more information. It's
> probably worth changing the 'umb_debug = 0' to 2 or 4
> while debugging too (this can be done using DDB, but if
> you want to capture any possible messages starting at
> boot then you probably want to chagne it in the code).

Thanks for the explanation on how all the PIN codes work. I wasn't aware
it was so complex. I'm compiling a new kernel right now with UMB_DEBUG
so we will see what happens there.

Bryan

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 10.06.2016 00:22, Stuart Henderson wrote:

On 2016/06/10 00:10, Mark Kettenis wrote:

From: Gerhard Roth 
Date: Thu, 9 Jun 2016 23:48:23 +0200

On 09.06.2016 23:42, Mark Kettenis wrote:

Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST)
From: Mark Kettenis 


Date: Wed, 8 Jun 2016 15:08:52 +0200
From: Gerhard Roth 

I would be glad to hear from some people trying this with a real MBIM
device.


Sierra Wireless EM7345 4G LTE here.  This devices currently attached
as umodem(4).  But I did add its vendor id and device id to umb_devs,
which makes it partially attach:

umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 
2.00/17.29 addr 2
umb0: switching to config #1
umb0: ignoring invalid segment size 1500
umb0: ctrl_len=512, maxpktlen=8192, cap=0x4
umb0: no control interface found

(this is with UMB_DEBUG enabled)

It seems this device needs some additional poking to select alternate
interface settings.


With the appropriate alternate settings for the communication
interface and data interface (1 and 2) hardcoded in the driver, this
works!


Great!

Although another example of a device violating the MBIM spec which
clearly states that alternate settings 0 and 1 have to be used.


Which version of the spec are you looking at?  Because my copy
(Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have
to be used ;).


There are different sections, 3.2 for dual-mode (NCM1.0 / MBIM)
devices talks about various alternate settings for NCM1.0 and
for MBIM, then 6.6 which is only dealing with MBIM just talks
about 0 and 1 ..



That's how I looked at it, too. But it seems that some vendors look
at it differently ;)

So we should find a solution where we don't need to use the
currently hard-coded MBIM_INTERFACE_ALTSETTING (== 1) anymore.

Re: MBIM Patch (Round 3)

[Stuart Henderson]

On 2016/06/10 00:10, Mark Kettenis wrote:
> > From: Gerhard Roth 
> > Date: Thu, 9 Jun 2016 23:48:23 +0200
> > 
> > On 09.06.2016 23:42, Mark Kettenis wrote:
> > >> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST)
> > >> From: Mark Kettenis 
> > >>
> > >>> Date: Wed, 8 Jun 2016 15:08:52 +0200
> > >>> From: Gerhard Roth 
> > >>>
> > >>> I would be glad to hear from some people trying this with a real MBIM
> > >>> device.
> > >>
> > >> Sierra Wireless EM7345 4G LTE here.  This devices currently attached
> > >> as umodem(4).  But I did add its vendor id and device id to umb_devs,
> > >> which makes it partially attach:
> > >>
> > >> umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G 
> > >> LTE" rev 2.00/17.29 addr 2
> > >> umb0: switching to config #1
> > >> umb0: ignoring invalid segment size 1500
> > >> umb0: ctrl_len=512, maxpktlen=8192, cap=0x4
> > >> umb0: no control interface found
> > >>
> > >> (this is with UMB_DEBUG enabled)
> > >>
> > >> It seems this device needs some additional poking to select alternate
> > >> interface settings.
> > >
> > > With the appropriate alternate settings for the communication
> > > interface and data interface (1 and 2) hardcoded in the driver, this
> > > works!
> > 
> > Great!
> > 
> > Although another example of a device violating the MBIM spec which
> > clearly states that alternate settings 0 and 1 have to be used.
> 
> Which version of the spec are you looking at?  Because my copy
> (Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have
> to be used ;).

There are different sections, 3.2 for dual-mode (NCM1.0 / MBIM)
devices talks about various alternate settings for NCM1.0 and
for MBIM, then 6.6 which is only dealing with MBIM just talks
about 0 and 1 ..

Re: MBIM Patch (Round 3)

[Mark Kettenis]

> From: Gerhard Roth 
> Date: Thu, 9 Jun 2016 23:48:23 +0200
> 
> On 09.06.2016 23:42, Mark Kettenis wrote:
> >> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST)
> >> From: Mark Kettenis 
> >>
> >>> Date: Wed, 8 Jun 2016 15:08:52 +0200
> >>> From: Gerhard Roth 
> >>>
> >>> I would be glad to hear from some people trying this with a real MBIM
> >>> device.
> >>
> >> Sierra Wireless EM7345 4G LTE here.  This devices currently attached
> >> as umodem(4).  But I did add its vendor id and device id to umb_devs,
> >> which makes it partially attach:
> >>
> >> umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" 
> >> rev 2.00/17.29 addr 2
> >> umb0: switching to config #1
> >> umb0: ignoring invalid segment size 1500
> >> umb0: ctrl_len=512, maxpktlen=8192, cap=0x4
> >> umb0: no control interface found
> >>
> >> (this is with UMB_DEBUG enabled)
> >>
> >> It seems this device needs some additional poking to select alternate
> >> interface settings.
> >
> > With the appropriate alternate settings for the communication
> > interface and data interface (1 and 2) hardcoded in the driver, this
> > works!
> 
> Great!
> 
> Although another example of a device violating the MBIM spec which
> clearly states that alternate settings 0 and 1 have to be used.

Which version of the spec are you looking at?  Because my copy
(Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have
to be used ;).

It does violate the spec for the maximumsegment size though.

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 09.06.2016 23:42, Mark Kettenis wrote:

Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST)
From: Mark Kettenis 


Date: Wed, 8 Jun 2016 15:08:52 +0200
From: Gerhard Roth 

I would be glad to hear from some people trying this with a real MBIM
device.


Sierra Wireless EM7345 4G LTE here.  This devices currently attached
as umodem(4).  But I did add its vendor id and device id to umb_devs,
which makes it partially attach:

umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 
2.00/17.29 addr 2
umb0: switching to config #1
umb0: ignoring invalid segment size 1500
umb0: ctrl_len=512, maxpktlen=8192, cap=0x4
umb0: no control interface found

(this is with UMB_DEBUG enabled)

It seems this device needs some additional poking to select alternate
interface settings.


With the appropriate alternate settings for the communication
interface and data interface (1 and 2) hardcoded in the driver, this
works!


Great!

Although another example of a device violating the MBIM spec which
clearly states that alternate settings 0 and 1 have to be used.




umb0: flags=8851 mtu 1500
index 5 priority 0
roaming disabled registration home network
state up cell-class LTE rssi -79dBm speed 47.7Mps up 95.4Mps down
SIM initialized PIN valid (3 attempts left)
subscriber-id  ICC-id YY provider NL KPN
device XMM7160_V1.2_MB IMEI Z firmware FIH7160_V1.2_WW
APN umts.xs4all.nl
groups: egress
status: active
inet 83.161.163.248 --> 83.161.163.1 netmask 0xff00

Re: MBIM Patch (Round 3)

[Mark Kettenis]

> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST)
> From: Mark Kettenis 
> 
> > Date: Wed, 8 Jun 2016 15:08:52 +0200
> > From: Gerhard Roth 
> > 
> > I would be glad to hear from some people trying this with a real MBIM
> > device.
> 
> Sierra Wireless EM7345 4G LTE here.  This devices currently attached
> as umodem(4).  But I did add its vendor id and device id to umb_devs,
> which makes it partially attach:
> 
> umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 
> 2.00/17.29 addr 2
> umb0: switching to config #1
> umb0: ignoring invalid segment size 1500
> umb0: ctrl_len=512, maxpktlen=8192, cap=0x4
> umb0: no control interface found
> 
> (this is with UMB_DEBUG enabled)
> 
> It seems this device needs some additional poking to select alternate
> interface settings.

With the appropriate alternate settings for the communication
interface and data interface (1 and 2) hardcoded in the driver, this
works!

umb0: flags=8851 mtu 1500
index 5 priority 0
roaming disabled registration home network
state up cell-class LTE rssi -79dBm speed 47.7Mps up 95.4Mps down
SIM initialized PIN valid (3 attempts left)
subscriber-id  ICC-id YY provider NL KPN  
device XMM7160_V1.2_MB IMEI Z firmware FIH7160_V1.2_WW
APN umts.xs4all.nl
groups: egress
status: active
inet 83.161.163.248 --> 83.161.163.1 netmask 0xff00

Re: MBIM Patch (Round 3)

[Stuart Henderson]

On 2016/06/09 22:59, Mark Kettenis wrote:
> It seems this device needs some additional poking to select alternate
> interface settings.  Currently playing around with that.  But in case
> you're curious, the lsusb -v output for this device is:

Oh lsusb -v, that is a good idea, and interesting. With a kernel
containing umb:

Bus 001 Device 003: ID 413c:81a3 Dell Computer Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x413c Dell Computer Corp.
  idProduct  0x81a3
  bcdDevice0.06
  iManufacturer   1 (error)
  iProduct2 (error)
  iSerial 3 (error)
  bNumConfigurations  2
Device Status: 0x6544
  (Bus Powered)
  Test Mode
  Debug Mode

(By the way I have tried it on a netbook as well as the APU2, and
have similar results, though it's a bit fiddly to move it between them
so I won't fetch lsusb from there unless requested).

It's much longer without:

Bus 001 Device 003: ID 413c:81a3 Dell Computer Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x413c Dell Computer Corp.
  idProduct  0x81a3 
  bcdDevice0.06
  iManufacturer   1 Sierra Wireless, Incorporated
  iProduct2 Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband 
Card
  iSerial 3 
  bNumConfigurations  2
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  204
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000c  1x 12 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber3
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000c  1x 12 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7

Re: MBIM Patch (Round 3)

[Stuart Henderson]

On 2016/06/09 12:35, Bryan Vyhmeister wrote:
> On Wed, Jun 08, 2016 at 03:08:52PM +0200, Gerhard Roth wrote:
> > I would be glad to hear from some people trying this with a real MBIM
> > device.
> 
> I have a Sierra Wireless EM7455 MBIM device that I purchased with my
> ThinkPad X260. I am very excited for this driver to make it into
> OpenBSD. I am a little bit unclear as to how to connect to AT wireless
> in the United States thus far but I want to rule out an error in how I
> am using the driver. Perhaps I have a similar issue to what sthen@ has.
> I have been watching the driver discussion on the list and applied the
> most recent complete patch and then did the following sequence:

You're getting further than me.

Though, looking at list posts, it does seem that Lenovo is another
vendor which requires the command being referred to as "fcc auth"
in order to connect, at least in some of their cards.

> ifconfig umb0 pin 1234 apn broadband
> ifconfig umb0 inet 0.0.0.1 0.0.0.2
> route add -ifp umb0 default 0.0.0.2
> ifconfig umb0 up
> 
> I don't have a PIN set on this SIM card which seems to be needed? I'm
> not sure if it's different elsewhere but I've never had a SIM card with
> a PIN set before here. The output of ifconfig umb0:
> 
> umb0: flags=8811 mtu 1500
> index 4 priority 0
> roaming disabled registration not registered
> state open cell-class none
> SIM not initialized PIN valid (3 attempts left)
  ^
This suggests that you don't need to enter a PIN, otherwise
you would get "PIN required" instead of "PIN valid".

> device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
> APN broadband
> groups: egress
> status: down
> inet 0.0.0.1 --> 0.0.0.2 netmask 0xff00
> 
> From the console:
> 
> umb0: state going up from 'down' to 'open'
> umb0: PIN2 state locked (3 attempts left)

There are several PINs and unlock codes (PIN1 PIN2 PUK1 PUK2)
on a SIM card. A SIM can be setup so that a PIN1 is required to
make calls etc, or not required. PIN2 is for configuration
(setting call restrictions, editing the restricted numbers
list, etc).

Too many bad attempts to enter a PIN1 will result in the SIM
being locked and requiring the PUK1 to unlock. In most cases
these are fairly easy to obtain from the operator.

Too many bad attempts to enter a PIN2 will result in the SIM
being locked and requiring the PUK2 to unlock. These are
usually harder to obtain from the operator and at least
require more checks.

>From a phone or older-type WWAN device with AT command set
(or probably the vendor tools on Windows, and maybe libmbim
on linux) you can control which PINs the card asks for.
You'll need to know what a PIN is before you can lock it.
Most operators have a default PIN that they use (different
ones for different operators) though theoretically they
could use a different one per SIM.

If PIN1 is unlocked (no matter whether PIN2 is locked or not),
you shouldn't need to use a PIN to connect.

> umb0: SIM not initialized (PIN missing)
> umb0: SIM not initialized (PIN missing)

The description in the spec for the state which triggers this
message is,

"The operation failed because the device is
in the process of initializing. Retry the
operation after the ReadyState of the device
changes to MBIMSubscriberReadyStateInitialized."

Spec may differ from real-world devices, but from my reading
of the spec it doesn't seem to me that this indicates "PIN
missing".

I think you should rebuild with UMB_DEBUG (one simple way
is to just add "#define UMB_DEBUG" before #ifdef UMB_DEBUG
in if_umb.c) and see if you get more information. It's
probably worth changing the 'umb_debug = 0' to 2 or 4
while debugging too (this can be done using DDB, but if
you want to capture any possible messages starting at
boot then you probably want to chagne it in the code).

Re: MBIM Patch (Round 3)

[Mark Kettenis]

> Date: Wed, 8 Jun 2016 15:08:52 +0200
> From: Gerhard Roth 
> 
> Here comes the next version of the MBIM driver.
> 
> Changes since last version:
> 
> - incorporated suggestions from mpi@
> 
> - renamed to "umb"
>   Only file "mbim.h" which contains MBIM protocol related stuff
>   continues to use "mbim" as prefix.
> 
> - No longer takes fake addresses nor does it try to restore them
> 
> 
> I would be glad to hear from some people trying this with a real MBIM
> device.

Sierra Wireless EM7345 4G LTE here.  This devices currently attached
as umodem(4).  But I did add its vendor id and device id to umb_devs,
which makes it partially attach:

umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 
2.00/17.29 addr 2
umb0: switching to config #1
umb0: ignoring invalid segment size 1500
umb0: ctrl_len=512, maxpktlen=8192, cap=0x4
umb0: no control interface found

(this is with UMB_DEBUG enabled)

It seems this device needs some additional poking to select alternate
interface settings.  Currently playing around with that.  But in case
you're curious, the lsusb -v output for this device is:


Bus 000 Device 002: ID 1199:a001 Sierra Wireless, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x1199 Sierra Wireless, Inc.
  idProduct  0xa001 
  bcdDevice   17.29
  iManufacturer   1 Sierra Wireless Inc.
  iProduct2 Sierra Wireless EM7345 4G LTE
  iSerial 3 013937004372999
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  229
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass  2 Communications
  bFunctionSubClass  13 
  bFunctionProtocol   0 
  iFunction   4 Sierra Wireless EM7345 4G LTE
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass 13 
  bInterfaceProtocol  0 
  iInterface  5 Sierra Wireless EM7345 4G LTE (NCM)
  CDC Header:
bcdCDC   1.20
  CDC Union:
bMasterInterface0
bSlaveInterface 1 
  CDC NCM:
bcdNcmVersion1.00
bmNetworkCapabilities 0x00
  CDC Ethernet:
iMacAddress  6 11121314
bmEthernetStatistics0x
wMaxSegmentSize   2048
wNumberMCFilters0x
bNumberPowerFilters  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   4
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   1
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass 14 
  bInterfaceProtocol  0 
  iInterface  7 Sierra Wireless EM7345 4G LTE (MBIM)
  CDC Header:
bcdCDC   1.20
  CDC Union:
bMasterInterface0
bSlaveInterface 1 
  CDC MBIM:
bcdMBIMVersion   1.00
wMaxControlMessage   512
bNumberFilters   32
bMaxFilterSize   192
wMaxSegmentSize  1500
bmNetworkCapabilities 0x04
  UNRECOGNIZED CDC:  08 24 1c 00 01 01 94 05
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   4
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass10 CDC Data
  

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 09.06.2016 21:35, Bryan Vyhmeister wrote:

On Wed, Jun 08, 2016 at 03:08:52PM +0200, Gerhard Roth wrote:

I would be glad to hear from some people trying this with a real MBIM
device.


I have a Sierra Wireless EM7455 MBIM device that I purchased with my
ThinkPad X260. I am very excited for this driver to make it into
OpenBSD. I am a little bit unclear as to how to connect to AT wireless
in the United States thus far but I want to rule out an error in how I
am using the driver. Perhaps I have a similar issue to what sthen@ has.
I have been watching the driver discussion on the list and applied the
most recent complete patch and then did the following sequence:

ifconfig umb0 pin 1234 apn broadband
ifconfig umb0 inet 0.0.0.1 0.0.0.2
route add -ifp umb0 default 0.0.0.2
ifconfig umb0 up


If you're using the latest version of the driver, the 'ifconfig ubm0 
inet ...' isn't required anymore.


But you probably have to set the default route after the interface is
up.




I don't have a PIN set on this SIM card which seems to be needed? I'm
not sure if it's different elsewhere but I've never had a SIM card with
a PIN set before here. The output of ifconfig umb0:

umb0: flags=8811 mtu 1500
index 4 priority 0
roaming disabled registration not registered
state open cell-class none
SIM not initialized PIN valid (3 attempts left)
device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
APN broadband
groups: egress
status: down
inet 0.0.0.1 --> 0.0.0.2 netmask 0xff00


Hmm, around here apart from some special company bulk contracts,
almost all SIM cards require PINs. But since yours says "PIN valid"
it clearly is content without one. But the "SIM not initialized"
is a bit strange.





From the console:


umb0: state going up from 'down' to 'open'
umb0: PIN2 state locked (3 attempts left)
umb0: SIM not initialized (PIN missing)
umb0: SIM not initialized (PIN missing)
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE

I'm not totally clear as to whether I have the right firmware by default. I
haven't booted up Windows on this system at all and there is different firmware
for some carriers (AT, Verizon, Spring) listed from Sierra Wireless for this
model. Perhaps I need to try with Verizon and see what happens.

I also tried with several other apn values that work in some circumstances 
(wap.cingular, phone) with identical results. Any ideas? Thank you!


No, I don't think that you have problems with the correct APN at this
stage. The driver is trying to turn on the radio and doesn't get a
response on the radio state.

Are you sure you haven't turned it off with the rfkill switch?

Or maybe this device refuses to accept radio commands and wants to
auto-control the radio. You could try this by commenting out the
"break" statement in umb_ub() in the UBM_S_RADIO case and see
what happens:

case UMB_S_RADIO:
umb_cmd(sc, MBIM_CID_SUBSCRIBER_READY_STATUS,
MBIM_CMDOP_QRY, NULL, 0);
// break;
case UMB_S_SIMREADY:
umb_packet_service(sc, 1);
break;

This way, it will send a command to turn the radio on, but also
continue to send the next command (register packet service) which
would otherwise be delayed until the device confirms that the radio
is on.

If that doesn't help, please set UMB_DEBUG and set umb_debug to 5.



Bryan



OpenBSD 6.0-beta (GENERIC.MP) #1: Wed Jun  8 08:11:28 PDT 2016
r...@x.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17024274432 (16235MB)
avail mem = 16503767040 (15739MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries)
bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016
bios0: LENOVO 20F6CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 
BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) 
PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 1097.89 MHz
cpu0: 

Re: MBIM Patch (Round 3)

[Bryan Vyhmeister]

On Wed, Jun 08, 2016 at 03:08:52PM +0200, Gerhard Roth wrote:
> I would be glad to hear from some people trying this with a real MBIM
> device.

I have a Sierra Wireless EM7455 MBIM device that I purchased with my
ThinkPad X260. I am very excited for this driver to make it into
OpenBSD. I am a little bit unclear as to how to connect to AT wireless
in the United States thus far but I want to rule out an error in how I
am using the driver. Perhaps I have a similar issue to what sthen@ has.
I have been watching the driver discussion on the list and applied the
most recent complete patch and then did the following sequence:

ifconfig umb0 pin 1234 apn broadband
ifconfig umb0 inet 0.0.0.1 0.0.0.2
route add -ifp umb0 default 0.0.0.2
ifconfig umb0 up

I don't have a PIN set on this SIM card which seems to be needed? I'm
not sure if it's different elsewhere but I've never had a SIM card with
a PIN set before here. The output of ifconfig umb0:

umb0: flags=8811 mtu 1500
index 4 priority 0
roaming disabled registration not registered
state open cell-class none
SIM not initialized PIN valid (3 attempts left)
device EM7455 IMEI 014582000 firmware SWI9X30C_02.08.
APN broadband
groups: egress
status: down
inet 0.0.0.1 --> 0.0.0.2 netmask 0xff00

>From the console:

umb0: state going up from 'down' to 'open'
umb0: PIN2 state locked (3 attempts left)
umb0: SIM not initialized (PIN missing)
umb0: SIM not initialized (PIN missing)
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE
umb0: state change time out
umb0: set/qry MBIM_CID_RADIO_STATE failed: FAILURE

I'm not totally clear as to whether I have the right firmware by default. I
haven't booted up Windows on this system at all and there is different firmware
for some carriers (AT, Verizon, Spring) listed from Sierra Wireless for this
model. Perhaps I need to try with Verizon and see what happens.

I also tried with several other apn values that work in some circumstances 
(wap.cingular, phone) with identical results. Any ideas? Thank you!

Bryan



OpenBSD 6.0-beta (GENERIC.MP) #1: Wed Jun  8 08:11:28 PDT 2016
r...@x.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17024274432 (16235MB)
avail mem = 16503767040 (15739MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7c01000 (66 entries)
bios0: vendor LENOVO version "R02ET44W (1.17 )" date 01/25/2016
bios0: LENOVO 20F6CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 
BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) 
PXSX(S4) EXP8(S4) PXSX(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 1097.89 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 926.72 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PTcpu1:
 failed to identify
,SENSOR,ARATcpu2 at mainbus0
cpu1: 256KB 64b/line 8-way L2 cache
: apid 1 (application processor)
cpu1: smt 0, core 1, package 0
cpu2: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 897.90 MHz
cpu2: 

Re: MBIM Patch (Round 3)

[Ingo Schwarze]

Hi Joshua,

joshua stein wrote on Thu, Jun 09, 2016 at 12:21:26PM -0500:
> On Thu, 09 Jun 2016 at 19:04:27 +0200, Ingo Schwarze wrote:
>> Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200:

>>> +.\" Copyright (c) 2016 genua mbH
>>> + * Copyright (c) 2016 genua mbH

>> These kinds of Copyright notices without the name of the actual author
>> are misleading.  The purpose of a Copyright notice is to inform the
>> reader who enjoys rights with respect to the Works; while they are
>> not legally required to establish Copyright and purely of advisory
>> nature, it is hard in practice, often almost impossible, to find out
>> who holds rights without them.  So putting incorrect or incomplete
>> information in Copyright notices defeats the very purpose of these
>> notices.  Please never do that.

> Can we stop all this bullshit bikeshedding and just get this driver
> imported?

Just to be clear:  I didn't intend to say that the exact wording of
Copyright notices should prevent import (unless the license is
unacceptable of course, which is clearly not the case here).

Of course, i'm in no position to comment on kernel code.

> This is getting so ridiculous.

I do not consider making Copyright notices and licences as clear
and complete as possible "ridiculous".  The finer details are of
course not as important as the code itself, but even getting the
details right makes things better.

It is not all that difficult.  With the ISC license, the purpose
of the Copyright line is to name the author because he or she
retains the Moral Rights.  All other (economic) rights are freely
licensed to the public.  I consider it important that everybody
be aware of this one simple idea.  It is central to the way
OpenBSD attributes and licenses its software.

Yes, this fundamental idea is quite different from the way for
example NetBSD or the FSF do it.


Also note that failing to mention the author in a Copyright notice
is not a choice of "how to licence the code", but an omission in a
statement of fact.  The author is free to choose the license terms
(and to transfer economic rights, of course).  It is the redistibutor's
(the OpenBSD project's) responsibility to make it clear who owns
rights on the code it distributes.  Sometimes, you only get that
out of the CVS logs.  Again, that certainly doesn't hinder import,
but i consider it somewhat unfortunate when it happens.




My remaining answers concern details of less, mostly historical,
importance:

[...]
> There is tons of code in our tree that has a copyright line of a
> corporate entity.

Sure, but those are mostly historical leftovers, and some also
contain slight defects.

The most common case is probably this one:

  * Copyright (c) 1989, 1993
  * The Regents of the University of California.  All rights reserved.

Note that the UCB CSRG had very serious issues in U.S. courts,
so they definitely had to focus on U.S. law and were naturally
less concerned with the Berne Convention.

Besides, even those files usually say something like this:

  * This code is derived from software contributed to Berkeley by
  * Kevin Fall.

And yet besides, the original BSD licenses (four and even three
clauses) were not as free as the ISC license; they put some material
conditions on the redistributor, however easy to comply with.

  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
  * 3. Neither the name of the University nor the names of its contributors
  *may be used to endorse or promote products derived from this software
  *without specific prior written permission.

In that case, it does matter slightly who holds the economic rights.
For the ISC license, it matters much less.

> "The NetBSD Foundation, Inc.", "Carnegie-Mellon University", etc.

Both are U.S. legal entities, so maybe they do indeed intend to
violate international law and strip authors of inalienable rights.
Of course, internationally, that is null and void, and we should
add the author names when missing (outside the license, of course).
Obviously, it's not a high priority for existing code, but we can
at least make new files get it right.

> Your argument makes no sense

Do you mean to say that owning some ISC-licensed code may provide
some benefit to a company?  Which one, exactly?

> and you are in no position to tell Gerhard to force him

Of course i'm not trying to force anything.

> to go get the code re-licensed (which makes no sense anyway, as he
> probably wrote it on company time).

Even when working on company time, the Copyright originates in him.
In the working contract, the company may have reserved the right
to have the economic rights transferred, but exercising that right
makes no sense for code that is intended to be put under an ISC
license.

No re-licensing is involved here.  The question is only whether the

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 09.06.2016 19:04, Ingo Schwarze wrote:

Hi Gerhard,

Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200:


+.\" Copyright (c) 2016 genua mbH
+ * Copyright (c) 2016 genua mbH


These kinds of Copyright notices without the name of the actual author
are misleading.  The purpose of a Copyright notice is to inform the
reader who enjoys rights with respect to the Works; while they are
not legally required to establish Copyright and purely of advisory
nature, it is hard in practice, often almost impossible, to find out
who holds rights without them.  So putting incorrect or incomplete
information in Copyright notices defeats the very purpose of these
notices.  Please never do that.

According to international law, specifically Article 6bis of the
Berne Convention (1886, last amended 1979), even when transferring
all the economic rights, the original author of a Works always
retains the Moral Rights, including the following:

  "Independently of the author's economic rights, and even after
  the transfer of the said rights, the author shall have the right
  to claim authorship of the work and to object to any distortion,
  mutilation or other modification of, or other derogatory action
  in relation to, the said work, which would be prejudicial to his
  honor or reputation."

So not naming the author in the Copyright notice effectively
subverts the author's most fundamental inalienable right:
Being known as the author - without which the other moral rights
against derogatory action etc. lose most of their power.

At the very least, the name of the author must be included,
for example as follows:

  Copyright (c) 2016 genua mbH
  This software was written by Gerhard Roth.

But actually, company names on ISC software licences are silly.

The ISC license is specifically designed to grant all rights under
Copyright that can legally be granted except one:  To relicense.
But relicensing never has any effect since that ISC license already
grants all rights; relicensing under a different license could only
grant less rights, which would have no legal effect but might confuse
people unaware of the original grant of the ISC license.  The ISC
license only explicitly reserves one right:  To be known as the
author.  And that cannot ever be given away (see Article 6bis above).

So technically, if genua mbH insists on "(C) genua mbH", what they
are actually saying is this:  "Look, in the future, we might wish
to decide to attempt to deceive people into believing that this
software is less free than it actually is, so we reserve the right
to relicense under a less free license; or we mistrust the author
and fear that he himself might attempt this deception, so we legally
bar the author from re-releasing his own code."  In my book, both
would make them look somewhat silly.

So please get their OK for:

  Copyright (c) 2016 Gerhard Roth.

If they want acknowledgement for supporting the development, which
would only be fair if they did support it, that acknowledgement
does not belong inside, but after the license, for example:

  * Copyright (c) 2016 Gerhard Roth.
  *
  * Permission to use, copy, modify, and distribute this software for any
  * [...]
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  *
  * Development of this software was supported by genua mbH.

Of course, if you have a working contract with them, they may be
allowed to insist on the silly line "Copyright (c) 2016 genua mbH"
if they want to.  But even if they try to forbid you from adding

  This software was written by Gerhard Roth.

they cannot prevent that.  Even if your working contract would say
that you transfer all your rights including the Moral Rights, that
part of it would be null and void.


Note that the form you used might be considered legal in the U.S.
because the U.S. still doesn't fully implement the Berne Convention,
after all those 130 years.  Last time i checked, the U.S. still
allowed companies to strip authors of rights that are inalienable
by international law.  But in most other countries, in particular
those that respect international law, and specifically in Germany,
your version of the Copyright notice seriously misrepresents the
legal situation.  And none of my proposed versions is illegal in
the U.S., by the way.

Yours,
  Ingo




Please don't tell me how to licence the code. As you are not the author
and as you don't have any rights on it, this is none of your business.

Either OpenBSD accepts it this way or it rejects it. But the copyright
notice won't change. EOT

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On 09.06.2016 17:52, Gerhard Roth wrote:

But: this payload is only 13 bytes but the length field says 14 bytes (0x0d).


Studid me. Can't even read single digit hex values anymore :(

Re: MBIM Patch (Round 3)

[Marcus Glocker]

On Thu, Jun 09, 2016 at 12:21:26PM -0500, joshua stein wrote:

> On Thu, 09 Jun 2016 at 19:04:27 +0200, Ingo Schwarze wrote:
> > Hi Gerhard,
> > 
> > Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200:
> > 
> > > +.\" Copyright (c) 2016 genua mbH
> > > + * Copyright (c) 2016 genua mbH
> > 
> > These kinds of Copyright notices without the name of the actual author
> > are misleading.  The purpose of a Copyright notice is to inform the
> > reader who enjoys rights with respect to the Works; while they are
> > not legally required to establish Copyright and purely of advisory
> > nature, it is hard in practice, often almost impossible, to find out
> > who holds rights without them.  So putting incorrect or incomplete
> > information in Copyright notices defeats the very purpose of these
> > notices.  Please never do that.
> 
> Can we stop all this bullshit bikeshedding and just get this driver
> imported?  This is getting so ridiculous.  I'm amazed Gerhard has
> stuck with it this long.
> 
> There is tons of code in our tree that has a copyright line of a
> corporate entity.  "The NetBSD Foundation, Inc.", "Carnegie-Mellon
> University", etc.  Your argument makes no sense and you are in no
> position to tell Gerhard to force him to go get the code re-licensed
> (which makes no sense anyway, as he probably wrote it on company
> time).

One of the best e-mails i've seen recently on this thread ...

I think some initial code shaping is fine before importing, but i also
see no point to rewrite the whole driver in a mailing list.

Re: MBIM Patch (Round 3)

[joshua stein]

On Thu, 09 Jun 2016 at 19:04:27 +0200, Ingo Schwarze wrote:
> Hi Gerhard,
> 
> Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200:
> 
> > +.\" Copyright (c) 2016 genua mbH
> > + * Copyright (c) 2016 genua mbH
> 
> These kinds of Copyright notices without the name of the actual author
> are misleading.  The purpose of a Copyright notice is to inform the
> reader who enjoys rights with respect to the Works; while they are
> not legally required to establish Copyright and purely of advisory
> nature, it is hard in practice, often almost impossible, to find out
> who holds rights without them.  So putting incorrect or incomplete
> information in Copyright notices defeats the very purpose of these
> notices.  Please never do that.

Can we stop all this bullshit bikeshedding and just get this driver
imported?  This is getting so ridiculous.  I'm amazed Gerhard has
stuck with it this long.

There is tons of code in our tree that has a copyright line of a
corporate entity.  "The NetBSD Foundation, Inc.", "Carnegie-Mellon
University", etc.  Your argument makes no sense and you are in no
position to tell Gerhard to force him to go get the code re-licensed
(which makes no sense anyway, as he probably wrote it on company
time).

Re: MBIM Patch (Round 3)

[Ingo Schwarze]

Hi Gerhard,

Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200:

> +.\" Copyright (c) 2016 genua mbH
> + * Copyright (c) 2016 genua mbH

These kinds of Copyright notices without the name of the actual author
are misleading.  The purpose of a Copyright notice is to inform the
reader who enjoys rights with respect to the Works; while they are
not legally required to establish Copyright and purely of advisory
nature, it is hard in practice, often almost impossible, to find out
who holds rights without them.  So putting incorrect or incomplete
information in Copyright notices defeats the very purpose of these
notices.  Please never do that.

According to international law, specifically Article 6bis of the
Berne Convention (1886, last amended 1979), even when transferring
all the economic rights, the original author of a Works always
retains the Moral Rights, including the following:

  "Independently of the author's economic rights, and even after
  the transfer of the said rights, the author shall have the right
  to claim authorship of the work and to object to any distortion,
  mutilation or other modification of, or other derogatory action
  in relation to, the said work, which would be prejudicial to his
  honor or reputation."

So not naming the author in the Copyright notice effectively
subverts the author's most fundamental inalienable right:
Being known as the author - without which the other moral rights
against derogatory action etc. lose most of their power.

At the very least, the name of the author must be included,
for example as follows:

  Copyright (c) 2016 genua mbH
  This software was written by Gerhard Roth.

But actually, company names on ISC software licences are silly.

The ISC license is specifically designed to grant all rights under
Copyright that can legally be granted except one:  To relicense.
But relicensing never has any effect since that ISC license already
grants all rights; relicensing under a different license could only
grant less rights, which would have no legal effect but might confuse
people unaware of the original grant of the ISC license.  The ISC
license only explicitly reserves one right:  To be known as the
author.  And that cannot ever be given away (see Article 6bis above).

So technically, if genua mbH insists on "(C) genua mbH", what they
are actually saying is this:  "Look, in the future, we might wish
to decide to attempt to deceive people into believing that this
software is less free than it actually is, so we reserve the right
to relicense under a less free license; or we mistrust the author
and fear that he himself might attempt this deception, so we legally
bar the author from re-releasing his own code."  In my book, both
would make them look somewhat silly.

So please get their OK for:

  Copyright (c) 2016 Gerhard Roth.

If they want acknowledgement for supporting the development, which
would only be fair if they did support it, that acknowledgement
does not belong inside, but after the license, for example:

  * Copyright (c) 2016 Gerhard Roth.
  *
  * Permission to use, copy, modify, and distribute this software for any
  * [...]
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  *
  * Development of this software was supported by genua mbH.

Of course, if you have a working contract with them, they may be
allowed to insist on the silly line "Copyright (c) 2016 genua mbH"
if they want to.  But even if they try to forbid you from adding

  This software was written by Gerhard Roth.

they cannot prevent that.  Even if your working contract would say
that you transfer all your rights including the Moral Rights, that
part of it would be null and void.


Note that the form you used might be considered legal in the U.S.
because the U.S. still doesn't fully implement the Berne Convention,
after all those 130 years.  Last time i checked, the U.S. still
allowed companies to strip authors of rights that are inalienable
by international law.  But in most other countries, in particular
those that respect international law, and specifically in Germany,
your version of the Copyright notice seriously misrepresents the
legal situation.  And none of my proposed versions is illegal in
the U.S., by the way.

Yours,
  Ingo

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On Thu, 9 Jun 2016 17:37:54 +0200 Gerhard Roth  wrote:
> On Thu, 9 Jun 2016 16:19:14 +0100 Stuart Henderson  
> wrote:
> > On 2016/06/09 15:29, Stuart Henderson wrote:
> > > On 2016/06/08 15:08, Gerhard Roth wrote:
> > > > I would be glad to hear from some people trying this with a real MBIM
> > > > device.
> > > 
> > > So I have a Dell-branded Sierra MC8805, but I don't seem able to
> > > get it to recognise my SIM card (which I can see from my Huawei
> > > umsm).
> > 
> > aha, it needs a command (and same for some HP-branded ones)... 
> > https://sigquit.wordpress.com/2015/02/
> 
> Hmm, so you need somthing similar to umb_cmd() where you have to
> use UUID d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3 instead of
> 'umb_uuid_basic_connect'. It is clear that 'op' is MBIM_CMDOP_SET.
> 
> But what value to use for 'cid' (command-id)? Somewhere it says '1',
> but '1' is MBIM_CID_DEVICE_CAPS. Well, could be anyway.
> 
> And what's inside the payload ('data', 'len')? I'm not sure.


Decoding the bytes from 
https://lists.freedesktop.org/archives/libmbim-devel/2015-August/000626.html

03 00 00 00 3D 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 D1 A3 0B C2
^type   ^len^tid^nfrag  ^currfrag   ^UUID
F9 7A 6E 43 BF 65 C7 E2 4F B0 F0 D3 01 00 00 00 01 00 00 00 0D 00 00 00
^cid^op == SET  ^infolen
01 0C 00 00 02 14 00 01 00 5F 55 00 00
^info


So:

- CID is in fact 1
- payload is { 0x01, 0x0c, 0x00, 0x00, 0x02, 0x14, 0x00, 0x01, 0x00, 0x5f, 
0x55, 0x00, 0x00 }

But: this payload is only 13 bytes but the length field says 14 bytes (0x0d).
So maybe the guy missed to paste the last byte of the payload. Appending
another null byte would be a good start :)

Re: MBIM Patch (Round 3)

[Stuart Henderson]

On 2016/06/09 16:19, Stuart Henderson wrote:
> On 2016/06/09 15:29, Stuart Henderson wrote:
> > On 2016/06/08 15:08, Gerhard Roth wrote:
> > > I would be glad to hear from some people trying this with a real MBIM
> > > device.
> > 
> > So I have a Dell-branded Sierra MC8805, but I don't seem able to
> > get it to recognise my SIM card (which I can see from my Huawei
> > umsm).
> 
> aha, it needs a command (and same for some HP-branded ones)... 
> https://sigquit.wordpress.com/2015/02/
> 

By the way, for anyone interested, on the APU2 it's the middle
mPCIe connector (mPCIe 2, J13) that the SIM holder is routed to.

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On Thu, 9 Jun 2016 16:19:14 +0100 Stuart Henderson  wrote:
> On 2016/06/09 15:29, Stuart Henderson wrote:
> > On 2016/06/08 15:08, Gerhard Roth wrote:
> > > I would be glad to hear from some people trying this with a real MBIM
> > > device.
> > 
> > So I have a Dell-branded Sierra MC8805, but I don't seem able to
> > get it to recognise my SIM card (which I can see from my Huawei
> > umsm).
> 
> aha, it needs a command (and same for some HP-branded ones)... 
> https://sigquit.wordpress.com/2015/02/

Hmm, so you need somthing similar to umb_cmd() where you have to
use UUID d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3 instead of
'umb_uuid_basic_connect'. It is clear that 'op' is MBIM_CMDOP_SET.

But what value to use for 'cid' (command-id)? Somewhere it says '1',
but '1' is MBIM_CID_DEVICE_CAPS. Well, could be anyway.

And what's inside the payload ('data', 'len')? I'm not sure.

Re: MBIM Patch (Round 3)

[Stuart Henderson]

On 2016/06/09 15:29, Stuart Henderson wrote:
> On 2016/06/08 15:08, Gerhard Roth wrote:
> > I would be glad to hear from some people trying this with a real MBIM
> > device.
> 
> So I have a Dell-branded Sierra MC8805, but I don't seem able to
> get it to recognise my SIM card (which I can see from my Huawei
> umsm).

aha, it needs a command (and same for some HP-branded ones)... 
https://sigquit.wordpress.com/2015/02/

Re: MBIM Patch (Round 3)

[Gerhard Roth]

On Thu, 9 Jun 2016 15:29:34 +0100 Stuart Henderson  wrote:
> On 2016/06/08 15:08, Gerhard Roth wrote:
> > I would be glad to hear from some people trying this with a real MBIM
> > device.
> 
> So I have a Dell-branded Sierra MC8805, but I don't seem able to
> get it to recognise my SIM card (which I can see from my Huawei
> umsm).

You're not even getting anywhere near SIM card information. See below.


> 
> # ifconfig umb0 pin  apn x
> # ifconfig umb0  
> umb0: flags=8810 mtu 1500
>   index 19 priority 0
>   roaming disabled registration unknown
>   state down cell-class none
>   SIM not initialized PIN required
>   APN x
>   status: down
> 
> Any suggestions of where I can poke?
> 
> Jun  9 15:22:31 zoo apmd: system resumed from sleep
> Jun  9 15:22:31 zoo /bsd: uvideo0 at uhub4 port 5 configuration 1 interface 0 
> "Sonix Technology Co., Ltd. USB 2.0 Camera" rev 2.00/1.00 addr 2
> Jun  9 15:22:31 zoo /bsd: video0 at uvideo0
> Jun  9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size
> Jun  9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size
> Jun  9 15:22:32 zoo /bsd: ugen0 at uhub4 port 6 "Sierra Wireless, 
> Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card" rev 
> 2.00/0.00 addr 3
> Jun  9 15:22:32 zoo /bsd: ugen0: setting configuration index 0 failed
> Jun  9 15:22:32 zoo /bsd: ugen0 detached
> Jun  9 15:22:43 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 
> "Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile 
> Broadband Card" rev 2.00/0.06 addr 3
> Jun  9 15:22:43 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20
> Jun  9 15:22:43 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: 
> ep-rx=1, ep-tx=1
> Jun  9 15:22:43 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1)
> Jun  9 15:22:43 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1)
> Jun  9 15:22:43 zoo /bsd:0:   01 00 00 00 10 00 00 00 01 00 00 00 00 10 
> 00 00
> Jun  9 15:22:43 zoo /bsd: umb0: vers 1.0

This is the first MBIM message sent the the device.


> Jun  9 15:22:44 zoo /bsd: umb0: notification error: IOERROR
> Jun  9 15:22:51 zoo last message repeated 305 times

Normally, the device would reply with a MBIM_OPEN_DONE message on the
control pipe. And it should inform us that this reply is ready for
fetching by a UCDC_N_RESPONSE_AVAILABLE message on the interrupt pipe.

Apparently it tries to send something on the interrupt pipe, but
we fail to receive it (306 IOERRORs within 7 seconds).

I have no idea what makes the interrupt pipe fail.


> Jun  9 15:22:51 zoo /bsd: umb0: notification error: CANCELLED
> Jun  9 15:22:51 zoo /bsd: umb0 detached
> Jun  9 15:23:02 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 
> "Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile 
> Broadband Card" rev 2.00/0.06 addr 3
> Jun  9 15:23:02 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20
> Jun  9 15:23:02 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: 
> ep-rx=1, ep-tx=1
> Jun  9 15:23:02 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1)
> Jun  9 15:23:02 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1)
> Jun  9 15:23:02 zoo /bsd:0:   01 00 00 00 10 00 00 00 01 00 00 00 00 10 
> 00 00
> Jun  9 15:23:02 zoo /bsd: umb0: vers 1.0
> Jun  9 15:24:06 zoo /bsd: umb0: -> set MBIM_CID_PIN (tid 2)
> Jun  9 15:24:06 zoo /bsd: umb0: sent MBIM_COMMAND_MSG (tid 2)
> Jun  9 15:24:06 zoo /bsd:0:   03 00 00 00 50 00 00 00 02 00 00 00 01 00 
> 00 00
> Jun  9 15:24:06 zoo /bsd:   16:   00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 
> 13 3e
> Jun  9 15:24:06 zoo /bsd:   32:   c2 aa e6 df 04 00 00 00 01 00 00 00 20 00 
> 00 00
> Jun  9 15:24:06 zoo /bsd:   48:   02 00 00 00 00 00 00 00 18 00 00 00 08 00 
> 00 00
> Jun  9 15:24:06 zoo /bsd:   64:   00 00 00 00 00 00 00 00 30 00 30 00 30 00 
> 30 00

Re: MBIM Patch (Round 3)

[Stuart Henderson]

On 2016/06/08 15:08, Gerhard Roth wrote:
> I would be glad to hear from some people trying this with a real MBIM
> device.

So I have a Dell-branded Sierra MC8805, but I don't seem able to
get it to recognise my SIM card (which I can see from my Huawei
umsm).

# ifconfig umb0 pin  apn x
# ifconfig umb0  
umb0: flags=8810 mtu 1500
index 19 priority 0
roaming disabled registration unknown
state down cell-class none
SIM not initialized PIN required
APN x
status: down

Any suggestions of where I can poke?

Jun  9 15:22:31 zoo apmd: system resumed from sleep
Jun  9 15:22:31 zoo /bsd: uvideo0 at uhub4 port 5 configuration 1 interface 0 
"Sonix Technology Co., Ltd. USB 2.0 Camera" rev 2.00/1.00 addr 2
Jun  9 15:22:31 zoo /bsd: video0 at uvideo0
Jun  9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size
Jun  9 15:22:32 zoo /bsd: usbd_fill_iface_data: bad max packet size
Jun  9 15:22:32 zoo /bsd: ugen0 at uhub4 port 6 "Sierra Wireless, Incorporated 
Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card" rev 2.00/0.00 addr 3
Jun  9 15:22:32 zoo /bsd: ugen0: setting configuration index 0 failed
Jun  9 15:22:32 zoo /bsd: ugen0 detached
Jun  9 15:22:43 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 
"Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile 
Broadband Card" rev 2.00/0.06 addr 3
Jun  9 15:22:43 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20
Jun  9 15:22:43 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: ep-rx=1, 
ep-tx=1
Jun  9 15:22:43 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1)
Jun  9 15:22:43 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1)
Jun  9 15:22:43 zoo /bsd:0:   01 00 00 00 10 00 00 00 01 00 00 00 00 10 00 
00
Jun  9 15:22:43 zoo /bsd: umb0: vers 1.0
Jun  9 15:22:44 zoo /bsd: umb0: notification error: IOERROR
Jun  9 15:22:51 zoo last message repeated 305 times
Jun  9 15:22:51 zoo /bsd: umb0: notification error: CANCELLED
Jun  9 15:22:51 zoo /bsd: umb0 detached
Jun  9 15:23:02 zoo /bsd: umb0 at uhub4 port 6 configuration 2 interface 12 
"Sierra Wireless, Incorporated Dell Wireless 5570 HSPA+ (42Mbps) Mobile 
Broadband Card" rev 2.00/0.06 addr 3
Jun  9 15:23:02 zoo /bsd: umb0: ctrl_len=4096, maxpktlen=4064, cap=0x20
Jun  9 15:23:02 zoo /bsd: umb0: ctrl-ifno#12: ep-ctrl=2, data-ifno#13: ep-rx=1, 
ep-tx=1
Jun  9 15:23:02 zoo /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1)
Jun  9 15:23:02 zoo /bsd: umb0: sent MBIM_OPEN_MSG (tid 1)
Jun  9 15:23:02 zoo /bsd:0:   01 00 00 00 10 00 00 00 01 00 00 00 00 10 00 
00
Jun  9 15:23:02 zoo /bsd: umb0: vers 1.0
Jun  9 15:24:06 zoo /bsd: umb0: -> set MBIM_CID_PIN (tid 2)
Jun  9 15:24:06 zoo /bsd: umb0: sent MBIM_COMMAND_MSG (tid 2)
Jun  9 15:24:06 zoo /bsd:0:   03 00 00 00 50 00 00 00 02 00 00 00 01 00 00 
00
Jun  9 15:24:06 zoo /bsd:   16:   00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 13 
3e
Jun  9 15:24:06 zoo /bsd:   32:   c2 aa e6 df 04 00 00 00 01 00 00 00 20 00 00 
00
Jun  9 15:24:06 zoo /bsd:   48:   02 00 00 00 00 00 00 00 18 00 00 00 08 00 00 
00
Jun  9 15:24:06 zoo /bsd:   64:   00 00 00 00 00 00 00 00 30 00 30 00 30 00 30 
00