# Sierra Wireless HSPA+ USB modem



## PseudoCylon (Jun 28, 2011)

Hello

-- Update Mar 22, 2012 --
The driver is included in 9.0-RELEASE. No need to download the driver separately or modify the code.

Here is a new driver for Sierra Wireless HSPA+ USB modem. Please test it. My subscription will expire on June 29, 2011. (Yes, it sounds silly.) Try it before too late.

The driver should work on 9.0 and 8.2 RELEASE.
Supports only Direct IP supported models with device ID of *0x68A3*
which include following devices.
USB 306
USB 308/309
AT&T Shockwave
USB 305 (AT&T Lightning )
AirPrime MC8700 minicard
AirPrime MC8790 minicard
AirPrime MC870x
AirPrime SL501x
AirPrime SL808x
AirPrime SL80xx
Compass 888/889
USB 301/302
AirCard 501/502
AirCard 503 ( Telstra Elite)
AirCard 504( AT&T AirCard 890)
USB 310U modem
AirCard 312U /Telstra Ultimate

*How to use 9.0-RELEASE and up*
`# ifconfig usie0 up`
IP and DNS addr will be printed on the console. Using those addr,
`# ifconfig usie0 inet N.N.N.N`
`# ifconfig usie0 defaultif`
`# echo "nameserver N.N.N.N" > /etc/resolv.conf`
One nemaserve is sufficient.
`# echo "nameserver N.N.N.N" >> /etc/resolv.conf`

*How to use 8.x-RELEASE*
download the code.
source tree
tarball
add
	
	



```
product AIRPRIME USB308                0x68A3  USB308 HSPA+ USB Modem
```
somewhere in /usr/src/sys/dev/usb/usbdevs

`% cd driver_pakage_root/src/sys/modules/usb/usie`
`# make install`
`# kldload usie`
plug in the modem (Make sure load the driver before plugging in.)
wait while the modem is going though power up cycle
`# dhclient usie0`


*To disconnect* (same for all releases)
`# ifconfig usie0 down`or`# kldunload usie`


Following steps are needed *only if* your carrier needs username/password to get connected. Most of the time and if your carrire hasn't supplied them, you don't need to.
*To set up user profile*
`# cu -l cuaU0.2`
Now you are in cu session
`AT+CGDCONT=1,"IP","[i]supplied_APN.com[/i]"``AT$QCPDPP=1,1,"[i]password[/i]","[i]username[/i]"`
to view the setting`AT+CGDCONT?``AT$QCPDPP?`
to exit cu session`~.`(You won't see those 2 characters. Just hit 2 keys.)
You only need to set up the user profile once. The modem will remember it.


----------



## mrezny (Mar 22, 2012)

*Test Report*

First, thank you very much for helping the community by writing and sharing your driver.

Based on this post, and a quick glance to see that I already had usie.ko on my fresh 9.0-RELEASE box, I bought an AirCard 308 / AT&T Shockwave in hopes the Direct IP mode would be less troublesome. Not that it's terrible to setup ppp, but the Hauwei modem I have hard locks every few hours, requiring an unplug/replug of the modem and restart of ppp.

Today I tried to setup the new modem, but so far have not had any luck getting a connection running. I started by setting the APN and leaving the username blank, then again with username and password set. I know both work on my provider from using other hardware with the same SIM. Regardless how I have it set, when I start dhclient the data light goes solid blue (indicating it made a 3G connection) but dhclient never gets an address.

I am currently using the new AirCard on a Mac with the driver from Sierra Wireless installed and the settings as i put them when it was connected to the FreeBSD box. So, I know the APN and user/pass settings are correct and that the hardware is compatible with my SIM and carrier's network.

I followed your instructions step by step for setting it up. As it has been some time since the original post, and the driver has made it into the tree in the meantime, I figure that perhaps some minor change has been made and so maybe I am missing an obvious step, but I see no manpage and have found nothing else searching Google.

Any help you could provide would be greatly appreciated. I have no problem with compiling a modified driver to test out on this machine and I will collect whatever debug output you desire.Thank you in advance for any and all assistance on this.


----------



## PseudoCylon (Mar 23, 2012)

Mock DHCP server was stripped off when it made to the HEAD, as expected. (No device driver should do that kind of stuff.)

Please follow updated instruction.
http://lists.freebsd.org/pipermail/freebsd-current/2011-July/025828.html
IP addresses may be printed on ttyv0.

If it doesn't work, first please confirm that device ID is 0x68a3 with`# usbconfig -d [i]N.N[/i] dump_device_desc`_N.N_ is the same number as
	
	



```
ugen[I]N.N[/I]: <Sierra Wireless ...>
```


----------



## mrezny (Mar 30, 2012)

Ahhh, well now, after reading the mailing list thread I have a much clearer picture of how this should work. I had not looked at the code previously to see the DHCP responses were from the driver, but had assumed dhclient was going to negotiate an address with the ISP. The modem has already done that so it*'*s just a matter of exposing the address. Is there any reason the driver cannot simply set the address of the interface itself?

Beyond just the address, there is the gateway and DNS values that maybe should be dealt with. I need some automated solution, so I tossed together a script to harvest everything from dmesg and configure the system appropriately. I was planning to have that run from devd, but I never see a LINK_UP event from usie0. I see the initial ATTACH of usie0 from devd, which I use to trigger the *ifconfig up* of the interface, but nothing after that. Any idea why usie never generates a LINK_UP when the interface is clearly transitioned into running state?

I did some basic use testing while I was fiddling with scripts and noticed some strange behavior. After all else was done, I went digging with the help of tcpdump. What I found is that any packet with a size over 1496 bytes (MTU - 4bytes) is not properly transmitted (unsure if its truncated, mangled or not sent at all). The easiest way to reproduce is *ping -s NUM* where NUM up to 1472 should work (1500MTU - 28bytes ethernet header) but any NUM over 1468 fails in my testing.

My first thought on it is that this is a matter of alignment or packing of the packet data. I am running on amd64 and so native word size is then 8 bytes and while 1500 divides evenly into 4 it does not do so for 8. To complicate matters, I have compiled my whole system with clang rather than gcc, so that may make a difference in how structures are packed and aligned. I will do some more testing on an i386 box and with gcc to see if I can narrow the cause.

I thought of hacking the MTU to mask the issue, but have put that off for the moment in case there is a good reason it*'*s set static in the driver right now. Also, having a real fix is better.


----------



## PseudoCylon (Mar 31, 2012)

mrezny said:
			
		

> The modem has already done that so it*'*s just a matter of exposing the address.


Yes, it is. The problem is IEEE802.16 hasn't been supported, yet. The driver receive all necessarily information from the hardware, but there is no mechanism to expose, until someone writes code for it.



			
				mrezny said:
			
		

> Any idea why usie never generates a LINK_UP when the interface is clearly transitioned into running state?


The same as above, there is no mechanism to do it for IEEE802.16 device. One time I tried making the device pretend as an ethernet device (so that it would generate LINK_UP), but I had to allocate irrelevant structures just to prevent page faults, and uninitialized members generated errors irrelevant to IEEE802.16 devices. It wasn't pretty.

When addresses are printed on console, the device is ready. You could use it for your script.



			
				mrezny said:
			
		

> What I found is that any packet with a size over 1496 bytes (MTU - 4bytes) is not properly transmitted (unsure if its truncated, mangled or not sent at all). The easiest way to reproduce is *ping -s NUM* where NUM up to 1472 should work (1500MTU - 28bytes ethernet header) but any NUM over 1468 fails in my testing.


Most likely, your network carrier has set MTU to 1468. My carrier set it to 1420.


----------



## mrezny (Apr 4, 2012)

Interesting. It was my understanding that 802.16 is WiMAX and that is different than what the carriers are using for the WWAN Internet services. So I suppose that these SW sticks are presenting themselves as an 802.16 device for convenience although the radio technology in use is different than that spec. It is unfortunate to hear that this driver is currently hampered by lack of an appropriate network stack with which to interface.

I seriously doubt that my ISP is using an MTU lower than 1500. The size specified in the ping is the ICMP payload, not including IP and ICMP headers. So it would be MTU 1496 for the payload of 1468, and I can't think of any reasonable encapsulation that would be causing drop of mere 4 bytes to MTU. An ICMP payload of 1472 should be the goal as that corresponds to MTU of 1500. As a reference, when I am using the same hardware plugged into a Mac with the driver provided by Sierra Wireless, I can *ping -D -s 1472* successfully both from the Mac and from a FreeBSD box behind the Mac's natd. When I plug the same stick into a FreeBSD box, then I can't get anything over 1468 to work, which is just 4 bytes different but enough to wreck havoc when something tries to push TCP packets of the maximum size. For example, I can load this forum in a browser but not make a post when using it directly from a FreeBSD box. That is rather clear evidence the carrier is running 1500 MTU as even without the DF bit set the behavior is the same (many ISP silently drop rather than fragment oversize packets regardless of DF bit).

I had suspected the compiler or architecture could play a role, so I installed on another box that is plain i386 rather than amd64, and it is running stock kernel and userland compiled with gcc by re@ rather than my own build with clang and optimized cflags. Turns out it makes no difference, the behavior is exactly the same on both FreeBSD 9.0 boxes.

So now I have to wonder about your setup. How are you controlling the apparent MTU for applications since the driver will not allow directly changing the MTU of the interface itself? I can only guess something like using the firewall to change the mss value to fix TCP and just hope for the best on UDP, but that's a little uglier solution than I'd prefer. Now that I know you are using a provider which operates with MTU 1420, I have to wonder, has anyone else tested the driver yet with a prover that uses MTU 1500 or am I the first hitting this and perhaps the first to hit the edge case triggering the behavior?


----------



## PseudoCylon (Apr 5, 2012)

mrezny said:
			
		

> Interesting. It was my understanding that 802.16 is WiMAX and that is different than what the carriers are using for the WWAN Internet services. So I suppose that these SW sticks are presenting themselves as an 802.16 device for convenience although the radio technology in use is different than that spec.


Do you want me to waste time by saying _list_all_of_would_be_supported_protocol_name stuck_? 



			
				mrezny said:
			
		

> It is unfortunate to hear that this driver is currently hampered by lack of an appropriate network stack with which to interface.


Then, you add the support by yourself, since you are such an expert. Even you can name it whatever you like.



			
				mrezny said:
			
		

> For example, I can load this forum in a browser but not make a post when using it directly from a FreeBSD box. That is rather clear evidence the carrier is running 1500 MTU as even without the DF bit set the behavior is the same (many ISP silently drop rather than fragment oversize packets regardless of DF bit).


Well, oversized packets get dropped, that is rather clear evidence MTU is less than 1500. But, if you insist, set MTU to 1500 and don't post again.



			
				mrezny said:
			
		

> So now I have to wonder about your setup. How are you controlling the apparent MTU for applications since the driver will not allow directly changing the MTU of the interface itself?


See how FreeBSD kernel handles ifp->if_mtu.


----------



## mrezny (Apr 15, 2012)

> Do you want me to waste time by saying list_all_of_would_be_supported_protocol_name stuck?



I haven't a clue what you even mean with this, but it's clear the tone is becoming hostile. I expected a rough driver, but I did not expect the associated personality to the the roughest spot I hit. What I want is stuff that works and is documented, but both of those appear to be asking too much.



> See how FreeBSD kernel handles ifp->if_mtu.



Oh, I have seen how the driver handles that, or rather mishandles. The driver sets that to 1500 and then provides no way to change it. In the handling of ioctls, the MTU change is not handled and falls to the default case, resulting in an error when attempting to use ifconfig to set the MTU lower. That is of course the first thing I tried when I saw the problem.



> Well, oversized packets get dropped, that is rather clear evidence MTU is less than 1500. But, if you insist, set MTU to 1500 and don't post again.



Actually, as noted above, I'm NOT setting the MTU to 1500, the problem is I CAN'T CHANGE IT WITHOUT RECOMPILING! Now, seeing as how I installed a vanilla 9.0-RELEASE box on i386 so I could test with totally stock binaries on simplest hardware, and it STILL doesn't work correctly, I have to declare it a bug. Changing the code in the driver and recompiling to set the proper MTU is simply not an acceptable solution to anyone I can consider sane.

I did a further test to check against another source. I installed Linux onto another drive with a 3.0 kernel from last year and proceeded to install the open source driver from Sierra Wireless on that. What a surprise, it works perfectly with a 1500 (default) MTU just as it does on Mac OS X. So, that's two other operating systems which work just fine, and  can see there's no magic fragmenting going on in the driver to do it either.

Looking through the source of the Linux driver, I notice the encapsulation of the IP packet into a HIP structure is done rather differently. I also can't help but notice the size of HIP header is declared as 4 bytes, the exact amount by which the functional MTU is incorrect. So, I must suspect the bug is an error in the accounting for the header bytes and thus that's where I'll be looking to fix it. But first, I will make the MTU properly adjustable as the current state is absurd.

It's clear that you basically don't give damn because it works for you. So, I'm now really posting for the sake of others that may otherwise experience my misfortune. I don't care if you like or dislike any patch I may come up with it, they are for everyone else anyway. My personal feeling is an attitude like yours does a disservice to the project. It is a challenge to remain civil in such a presence so I hope you choose to to be the one to cease posting.


----------



## DutchDaemon (Apr 15, 2012)

Let's focus on the actual problem from now on, shall we?


----------



## mrezny (Apr 16, 2012)

*Patch 1*

Here is a patch to allow setting the MTU of the interface. It passes my quick tests and is of immediate utility.

Now that I can set the MTU, using a value of 1496 clears up the problems I was seeing with TCP traffic. Using a sftp upload as a test case; with MTU at 1500 it immediately stalls and zero bytes are transferred, whereas with MTU at 1496 the transfer begins immediately and completes quickly. The behavior with ping is of course the same.

So, there is a problem, but this patch allows the issue to be effectively masked. The interface is usable in an almost ideal state (less than 0.3% potential throughput decrease). The root problem remains and I shall try to solve it, but at least with this simple first step we make a huge improvement in usability.


----------



## state_terror (Feb 1, 2013)

Hi, 

Thanks for your work on this. It works great for me with the MC8705 card, but I'm having problems with the 4G MC7710 card, It has the same device ID 0x68A3, it sees the card fine, I can talk to it with cu, it picks up DHCP, IP address, DNS, etc. but it won't transfer data after that. Tried different SIM's, setting the modem to 3G only, card works under Windows using identical AT commands, so near, yet so far. Any ideas how I can troubleshoot this further? TIA.


----------



## PseudoCylon (Feb 2, 2013)

`# usbconfig -d [i]your.ugen_num[/i] dump_device_desc`and after trying to use the network (It is O.K. you cannot surf. I want to know if the packets are directed to the correct device.)`# netstat -r`please.

As far as I know, LTE devices have device ID of 0x68aa.

Did you follow the steps on the very first post?
`# dhclient usie0`
will not work at this moment.


----------



## state_terror (Feb 3, 2013)

Hi, 

Thanks for your reply.

I think there are two sets of firmware for the MC7710, QMI and DirectIP.

I believe that the device ID 0x68aa is the default for the QMI version.

I'm using *F*reeBSD 9.0. I'm not using dhclient. I have a script that gets the DHCP settings from syslog, although I can equally get them using AT commands. 

Then the script configures the IP address of the usie0 interface. Note: the one issue here is that I cannot set the subnet mask to 255.255.255.255 for some unknown reason. I have to use 255.255.255.254 [/31], but this works with the MC8705.

It then sets that as the default route, deletes existing arp entries, and sets up the nameservers.


```
$ usbconfig -d 1.2 dump_device_desc
ugen1.2: <MC7710 Sierra Wireless, Incorporated> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000 
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x1199 
  idProduct = 0x68a3 
  bcdDevice = 0x0006 
  iManufacturer = 0x0003  <Sierra Wireless, Incorporated>
  iProduct = 0x0002  <MC7710>
  iSerialNumber = 0x0004  <358178040511182>
  bNumConfigurations = 0x0001
```

I had to use *netstat -rn* as the configured DNS servers were on the WAN and it was hanging.


```
$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.5.74.224        US          0      301  usie0
10.5.74.224        link#9             UHS         0        0    lo0 =>
10.5.74.224/31     link#9             U           0        0  usie0
127.0.0.1          link#7             UH          0        0    lo0
192.168.1.0/24     link#1             U           0     3135    vr0
192.168.1.1        link#1             UHS         0        0    lo0
192.168.7.100      link#8             UHS         0        0    lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::1                               ::1                           UH          lo0
fe80::%vr0/64                     link#1                        U           vr0
fe80::20d:b9ff:fe26:5af8%vr0      link#1                        UHS         lo0
fe80::%lo0/64                     link#7                        U           lo0
fe80::1%lo0                       link#7                        UHS         lo0
fe80::%wlan0/64                   link#8                        U         wlan0
fe80::215:6dff:fe56:cbef%wlan0    link#8                        UHS         lo0
ff01::%vr0/32                     fe80::20d:b9ff:fe26:5af8%vr0  U           vr0
ff01::%lo0/32                     ::1                           U           lo0
ff01::%wlan0/32                   fe80::215:6dff:fe56:cbef%wlan0 U         wlan0
ff02::%vr0/32                     fe80::20d:b9ff:fe26:5af8%vr0  U           vr0
ff02::%lo0/32                     ::1                           U           lo0
ff02::%wlan0/32                   fe80::215:6dff:fe56:cbef%wlan0 U         wlan0
```


----------



## PseudoCylon (Feb 4, 2013)

To clarify, MC8705 works on the same box you are talking of. Packet forwarding stuff hasn't been tested. Bridging shouldn't work; routing theoretically work.

For testing, please try to ping from 10.5.74.224 rather than from 192.168.1.N.

[CMD=""]AT!MAPUART?[/CMD]and
`# usbconfig -d [i]N.N[/i] dump_all_config_desc`please.

Hopefully, this gives some useful info.
load the module, `# sysctl hw.usb.usie.debug=20`plug-in the device (want to know how it attaches too), connect, ping a few packets.


----------



## state_terror (Feb 4, 2013)

> To clarify, MC8705 works on the same box you are talking of.



Yes.



> Packet forwarding stuff hasn't been tested.



This box works as a router, packets are forwarded from the LAN [Ethernet],
to the WAN, either WiFi or MC8705. I work behind both everyday with no device related issues.

It's NATed between the LAN and WAN, and runs ipf.



> Bridging shouldn't work;





> routing theoretically work.





> For testing, please try to ping from 10.5.74.224 rather than from 192.168.1.N.



Using the MC7710 card I get


```
$ /sbin/ping -S31.121.107.6 -c4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 31.121.107.6: 56 data bytes

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
```

You can ping from the device as well using AT!PING=8.8.8.8 but this doesn't work with the MC7710 either on Windows [connection working] or *F*reeBSD, but on Windows where I can make a connection I can ping from the OS, which shows ping [ICMP] isn't blocked on the WAN.

Using the MC8705 card I get


```
AT!PING=8.8.8.8
!PING: Reply from 8.8.8.8 time=90 ms
OK
```

and 

```
$ /sbin/ping -S31.122.217.17 -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 31.122.217.17: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=80.140 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 80.140/80.140/80.140/0.000 ms
```

and I can ping from Windows.



> AT!MAPUART?



MC7710 has MDM9200 chipset which supports AT!MAPUART? according to the Sierra manual, but it just returns ERROR whatever I do.

I tested it under Windows and it doesn't work connected/disconnected either.

AT!MAPUART? doesn't work with the MC8705 card either on *F*reeBSD or Windows.



> and # usbconfig -d N.N dump_all_config_desc please.




```
$ usbconfig -d 1.2 dump_all_config_desc
ugen1.2: <MC7710 Sierra Wireless, Incorporated> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE


 Configuration index 0

    bLength = 0x0009 
    bDescriptorType = 0x0002 
    wTotalLength = 0x00a8 
    bNumInterfaces = 0x0006 
    bConfigurationValue = 0x0001 
    iConfiguration = 0x0001  <Sierra Configuration>
    bmAttributes = 0x00e0 
    bMaxPower = 0x0000 

    Interface 0
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0002 
      bInterfaceClass = 0x00ff 
      bInterfaceSubClass = 0x00ff 
      bInterfaceProtocol = 0x00ff 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0001  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 


    Interface 1
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0001 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0002 
      bInterfaceClass = 0x00ff 
      bInterfaceSubClass = 0x00ff 
      bInterfaceProtocol = 0x00ff 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0082  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0002  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 


    Interface 2
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0002 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0002 
      bInterfaceClass = 0x00ff 
      bInterfaceSubClass = 0x00ff 
      bInterfaceProtocol = 0x00ff 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0083  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0003  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 


    Interface 3
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0003 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0003 
      bInterfaceClass = 0x00ff 
      bInterfaceSubClass = 0x00ff 
      bInterfaceProtocol = 0x00ff 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0084  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040 
        bInterval = 0x0005 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0085  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 2
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0004  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 


    Interface 4
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0004 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0003 
      bInterfaceClass = 0x00ff 
      bInterfaceSubClass = 0x00ff 
      bInterfaceProtocol = 0x00ff 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0086  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040 
        bInterval = 0x0005 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0087  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 2
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0005  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 


    Interface 5
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0005 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0003 
      bInterfaceClass = 0x00ff 
      bInterfaceSubClass = 0x00ff 
      bInterfaceProtocol = 0x00ff 
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0088  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040 
        bInterval = 0x0005 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 1
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0089  <IN>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

     Endpoint 2
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0006  <OUT>
        bmAttributes = 0x0002  <BULK>
        wMaxPacketSize = 0x0200 
        bInterval = 0x0020 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000
```



> Hopefully, this gives some useful info. load the module, # sysctl hw.usb.usie.debug=20



This oid doesn't exist.

I built this on *F*reeBSD 9.0

```
__FBSDID("$FreeBSD: release/9.0.0/sys/dev/usb/net/if_usie.c 223896 2011-07-09 20:16:52Z hselasky $");
```

CURRENT has


```
__FBSDID("$FreeBSD: src/sys/dev/usb/net/if_usie.c,v 1.8 2012/12/04 11:18:53 svnexp Exp $");
```

There are some changes, including something to do with the oid on line 80, or maybe I did something. I vaguely remember trying to sup*p*ress output from usie for some reason lost in time.



> plug-in the device (want to know how it attaches too)



The MC7710 miniPCIe card is attached to the motherboard on *F*reeBSD, so I can only reset it using

`#usbconfig -u 1 -a 2 reset`

which produces this in syslog


```
192.168.1.1 kern.crit Feb 4 16:11:02 kernel: usieO: < Sierra Wireless, Incorporated MC7710,
 class 0/0, rev 2.00/0.06, addr 2> on usbusl
192.168.1.1 kern.crit Feb 4 16:11:02 kernel: usieO: at uhubl, port 2, addr 2 (disconnected)
```
I get an identical result except for the model number with the MC8705



> connect, ping a few packets.



See above.


----------



## PseudoCylon (Feb 5, 2013)

state_terror said:
			
		

> This oid doesn't exist.


That's because the driver wasn't build with USB_DEBUG flag. Since you need to re-compile the driver anyway, try this patch. I preset everything I need. All you have to do is to load the patched driver.
	
	



```
[B]diff --git a/src/sys/dev/usb/net/if_usie.c b/src/sys/dev/usb/net/if_usie.c
index cda1d3d..6032350 100644
--- a/src/sys/dev/usb/net/if_usie.c
+++ b/src/sys/dev/usb/net/if_usie.c[/B]
[color="Blue"]@@ -65,6 +65,7 @@[/color] __FBSDID("$FreeBSD$");
 #include <dev/usb/usb_cdc.h>
 #include "usbdevs.h"
 
[color="Green"]+#define        USB_DEBUG[/color]
 #define        USB_DEBUG_VAR usie_debug
 #include <dev/usb/usb_debug.h>
 #include <dev/usb/usb_process.h>
[color="Blue"]@@ -75,7 +76,7 @@[/color] __FBSDID("$FreeBSD$");
 #include <dev/usb/net/if_usievar.h>
 
 #ifdef USB_DEBUG
[color="Red"]-static int usie_debug = 0;[/color]
[color="Green"]+static int usie_debug = 1;[/color]
 
 SYSCTL_NODE(_hw_usb, OID_AUTO, usie, CTLFLAG_RW, 0, "sierra USB modem");
 SYSCTL_INT(_hw_usb_usie, OID_AUTO, debug, CTLFLAG_RW, &usie_debug, 0,
[color="Blue"]@@ -347,7 +348,8 @@[/color] usie_attach(device_t self)
                        continue;
 
                /* setup Direct IP transfer */
[color="Red"]-               if (id->bInterfaceNumber >= 7 && id->bNumEndpoints == 3) {[/color]
[color="Green"]+               if ((id->bInterfaceNumber == 7 || id->bInterfaceNumber == 10 ||[/color]
[color="Green"]+                   id->bInterfaceNumber == 11) && id->bNumEndpoints == 3) {[/color]
                        sc->sc_if_ifnum = id->bInterfaceNumber;
                        iface_index = ifidx;
```
MC7710 has port config different from mine. Hopefully, the patch works.

If not, let me know what kind of debug message`# sysctl hw.usb.usie.debug=20`produces. (Set it to '0' to turn the debug message off.)

The modem seem to be properly connected, but to eliminate the possibility of routing problem please do`$ /sbin/ping`


----------



## state_terror (Feb 5, 2013)

Hi, I think our source must be a little different. I hand patched it. See attachment. I've included output from syslog during a connection attempt, and my patched if_usie.c

I still couldn't ping or browse.


----------



## PseudoCylon (Feb 6, 2013)

Actually, there should be more debug messages earlier than you have attached here.

They should be right after
	
	



```
usieO: < Sierra Wireless, Incorporated MC7710, ...
```
and look like
	
	



```
usie_attach: ifnum=N, ifidx=N
usie_attach: NumEndpoints=N bInterfaceNumber=N
```
I set debug level to 1, so boot or reset with usbconfig(8) should print out the messages.

Because MC8705 works fine and MC7710 has different port config, I'm suspecting setting direct IP on wrong port.


----------



## state_terror (Feb 6, 2013)

Here you go

`$  usbconfig -u 1 -a 2 reset`


```
Feb 06 07:36:04 192.168.1.1 Feb  6 07:36:04 kernel: usie0: at uhub1, port 2, addr 2 (disconnected)
Feb 06 07:36:04 192.168.1.1 Feb  6 07:36:04 kernel: usie_cns_req: param: 01:00:7e:68:50:db:83:91:99:27:07:07:00:00:64:00
Feb 06 07:36:04 192.168.1.1 Feb  6 07:36:04 kernel: usie_if_cmd: cmd=26
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie0: <Sierra Wireless, Incorporated MC7710, class 0/0, rev 2.00/0.06, addr 2> on usbus1
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: fwattr=f
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=0
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=1
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=2
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=3
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=4
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: ifnum=7, ifidx=5
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: Found 5 interfaces.
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: enabling automatic suspend and resume
Feb 06 07:36:05 192.168.1.1 Feb  6 07:36:05 kernel: usie_attach: device attached
```

AT!RESET produces


```
Feb 06 07:38:34 192.168.1.1 Feb  6 07:38:34 php: /test_AT_command.php: $_POST variable: at : AT!RESET
Feb 06 07:38:34 192.168.1.1 Feb  6 07:38:34 php: /test_AT_command.php: $_POST variable: sleep : 2
Feb 06 07:38:34 192.168.1.1 Feb  6 07:38:34 php: /test_AT_command.php: $_POST variable: test : Test AT Command
Feb 06 07:38:35 192.168.1.1 Feb  6 07:38:35 kernel: usie_uc_status_callback: info received, actlen=10
Feb 06 07:38:35 192.168.1.1 Feb  6 07:38:35 kernel: usie_uc_status_callback: param=2
Feb 06 07:38:35 192.168.1.1 Feb  6 07:38:35 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 06 07:38:35 192.168.1.1 Feb  6 07:38:35 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 06 07:38:35 192.168.1.1 Feb  6 07:38:35 kernel: usie_uc_status_callback: info received, actlen=10
Feb 06 07:38:35 192.168.1.1 Feb  6 07:38:35 kernel: usie_uc_status_callback: param=2
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: ugen1.2: <Sierra Wireless, Incorporated> at usbus1 (disconnected)
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie0: at uhub1, port 2, addr 2 (disconnected)
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_cns_req: param: 01:00:7e:68:f0:54:87:a1:d5:30:07:07:00:00:64:00
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_if_cmd: cmd=26
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 0/10
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_uc_status_callback: USB transfer error, USB_ERR_STALLED
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 1/10
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_uc_status_callback: USB transfer error, USB_ERR_CANCELLED
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 2/10
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 3/10
Feb 06 07:38:36 192.168.1.1 Feb  6 07:38:36 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 4/10
Feb 06 07:38:37 192.168.1.1 Feb  6 07:38:37 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 5/10
Feb 06 07:38:37 192.168.1.1 Feb  6 07:38:37 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 6/10
Feb 06 07:38:37 192.168.1.1 Feb  6 07:38:37 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 7/10
Feb 06 07:38:37 192.168.1.1 Feb  6 07:38:37 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 8/10
Feb 06 07:38:37 192.168.1.1 Feb  6 07:38:37 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 9/10
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: ugen1.2: <Sierra Wireless, Incorporated> at usbus1
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie0: <Sierra Wireless, Incorporated MC7710, class 0/0, rev 2.00/0.06, addr 2> on usbus1
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: fwattr=f
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=0
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=1
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=2
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=3
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=4
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: ifnum=7, ifidx=5
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: Found 5 interfaces.
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: enabling automatic suspend and resume
Feb 06 07:38:41 192.168.1.1 Feb  6 07:38:41 kernel: usie_attach: device attached
```


----------



## PseudoCylon (Feb 13, 2013)

Here is the most probable cause. All the documents I have are dated in 2009 and nothing about MC7xxx; all I could find was power save mode is commented out in sierra's most current driver. Hopefully, that is the cause.
	
	



```
[B]diff --git a/src/sys/dev/usb/net/if_usie.c b/src/sys/dev/usb/net/if_usie.c
index 6032350..91b4d60 100644
--- a/src/sys/dev/usb/net/if_usie.c
+++ b/src/sys/dev/usb/net/if_usie.c[/B]
[color="Blue"]@@ -75,10 +75,14 @@[/color] __FBSDID("$FreeBSD$");
 
 #include <dev/usb/net/if_usievar.h>
 
[color="Green"]+static int usie_pm = 0;
+SYSCTL_NODE(_hw_usb, OID_AUTO, usie, CTLFLAG_RW, 0, "sierra USB modem");
+SYSCTL_INT(_hw_usb_usie, OID_AUTO, power_mode, CTLFLAG_RW, &usie_pm, 0,
+    "usie power mode");
+[/color]
 #ifdef USB_DEBUG
 static int usie_debug = 1;
 
[color="Red"]-SYSCTL_NODE(_hw_usb, OID_AUTO, usie, CTLFLAG_RW, 0, "sierra USB modem");[/color]
 SYSCTL_INT(_hw_usb_usie, OID_AUTO, debug, CTLFLAG_RW, &usie_debug, 0,
     "usie debug level");
 #endif
[color="Blue"]@@ -443,7 +447,7 @@[/color] usie_attach(device_t self)
        if_attach(ifp);
        bpfattach(ifp, DLT_RAW, 0);
 
[color="Red"]-       if (fwattr & USIE_PM_AUTO) {
[color="Green"]+       if ((usie_pm == 1) && (fwattr & USIE_PM_AUTO)) {[/color]
                usbd_set_power_mode(uaa->device, USB_POWER_MODE_SAVE);
                DPRINTF("enabling automatic suspend and resume\n");
        } else {
[color="Blue"]@@ -1202,6 +1206,8 @@[/color] usie_if_init(void *arg)
        struct ifnet *ifp = sc->sc_ifp;
        uint8_t i;
 
[color="Green"]+       usie_if_sync_cb(sc, 0);
+[/color]
        mtx_lock(&sc->sc_mtx);
 
        /* write tx descriptor */
[color="Blue"]@@ -1556,7 +1562,7 @@[/color] usie_hip_rsp(struct usie_softc *sc, uint8_t *rsp, uint32_t len)
                        j = be16toh(hip->len);
                }
 #ifdef USB_DEBUG
[color="Red"]-               if (usie_debug == 0)[/color]
[color="Green"]+               if (usie_debug < 30)[/color]
                        continue;
 
                while (i < USIE_HIPCNS_MAX && j > 0) {
```

If this doesn't work,
after received IP addresses
	
	



```
AT!GSTATUS
```
whenever
	
	



```
ATI
```
and debug messages as before.


----------



## state_terror (Feb 13, 2013)

Hi,

No luck unfortunately.

Was there supposed to be an oid hw.usb.usie.usie_pm ?


```
$ sysctl hw.usb

hw.usb.no_boot_wait: 0
hw.usb.debug: 0
hw.usb.usb_lang_mask: 255
hw.usb.usb_lang_id: 9
hw.usb.template: 0
hw.usb.power_timeout: 30
hw.usb.no_pf: 0
hw.usb.no_cs_fail: 0
hw.usb.ucom.cons_baud: 9600
hw.usb.ucom.cons_subunit: 0
hw.usb.ucom.cons_unit: -1
hw.usb.usie.debug: 20
```

and I noticed this in the log when usb was reattached

Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: enabling automatic suspend and resume

Anyhow, I have included my if_usie.c in case I have patched it incorrectly.


MC7710 on FreeBSD after receiving DHCP but no connection	

AT!SELTRAT=00  Automatic

```
AT!GSTATUS?
!GSTATUS:
Current Time:  163908		Temperature: 27
Bootup Time:   83062		Mode:        ONLINE
System mode:   LTE          	PS state:    Attached
LTE band:      B3     		LTE bw:      10 MHz
LTE Rx chan:   1617		LTE Tx chan: 19617
EMM state:     Registered     	Normal Service
EMM connection:RRC Idle

RSSI (dBm):    -81		Tx Power:
RSRP (dBm):    -101		TAC:         2CB1 (11441)
RSRQ (dB):     -7		Cell ID:     0028A802 (2664450)
SINR (dB):     14.2
```

AT!SELTRAT=01  3G only

```
AT!GSTATUS?
!GSTATUS:
Current Time:  164119		Temperature: 28
Bootup Time:   83062		Mode:        ONLINE
System mode:   WCDMA      	PS state:    Attached
WCDMA band:    WCDMA 2100
WCDMA channel: 10761
GMM (PS) state:REGISTERED     	NORMAL SERVICE
MM (CS) state: IDLE           	NORMAL SERVICE

WCDMA L1 State:L1M_PCH_SLEEP  	RRC State:   CELL_PCH
RX level C0:   -79		LAC:         0478 (1144)
RX level C1:   -106		Cell ID:     00BEE62C (12510764)
```


AT!SELTRAT=06  4G only


```
AT!GSTATUS?
!GSTATUS:
Current Time:  164335		Temperature: 27
Bootup Time:   83062		Mode:        ONLINE
System mode:   LTE          	PS state:    Attached
LTE band:      B3     		LTE bw:      10 MHz
LTE Rx chan:   1617		LTE Tx chan: 19617
EMM state:     Registered     	Normal Service
EMM connection:RRC Idle

RSSI (dBm):    -81		Tx Power:
RSRP (dBm):    -101		TAC:         2CB1 (11441)
RSRQ (dB):     -7		Cell ID:     0028A802 (2664450)
SINR (dB):     14.2
```

MC7710 running 3G connection on Windows


```
AT!GSTATUS?
!GSTATUS:
Current Time:  229              Temperature: 30
Bootup Time:   1                Mode:        ONLINE
System mode:   WCDMA            PS state:    Attached
WCDMA band:    WCDMA 2100
WCDMA channel: 10786
GMM (PS) state:REGISTERED       NORMAL SERVICE
MM (CS) state: IDLE             NORMAL SERVICE

WCDMA L1 State:L1M_DCH          RRC State:   CELL_DCH
RX level C0:   -89              LAC:         0478 (1144)
RX level C1:   -106             Cell ID:     00BEC810 (12503056)


OK
```

MC7710 running 4G connection on Windows


```
AT!GSTATUS?
!GSTATUS:
Current Time:  453              Temperature: 27
Bootup Time:   1                Mode:        ONLINE
System mode:   LTE              PS state:    Attached
LTE band:      B3               LTE bw:      10 MHz
LTE Rx chan:   1617             LTE Tx chan: 19617
EMM state:     Registered       Normal Service
EMM connection:RRC Idle

RSSI (dBm):    -88              Tx Power:
RSRP (dBm):    -111             TAC:         2CB1 (11441)
RSRQ (dB):     -9               Cell ID:     0028A802 (2664450)
SINR (dB):      6.8


OK
```

MC8705 running connection on FreeBSD for comparison

AT!SELTRAT=01  3G only

```
AT!GSTATUS?
!GSTATUS:
Current Time:  164329		Temperature: 26
Bootup Time:   133611		Mode:        ONLINE
System mode:   WCDMA      	PS state:    Attached
WCDMA band:    IMT2000    	GSM band:    Unknown
WCDMA channel: 10761		GSM channel: 65535
GMM (PS) state:REGISTERED     	NORMAL SERVICE
MM (CS) state: IDLE           	NORMAL SERVICE

WCDMA L1 State:L1M_FACH       	RRC State:   CELL_FACH
RX level (dBm):-88
```

ATI


```
ATI
Manufacturer: Sierra Wireless, Incorporated
Model: MC7710
Revision: SWI9200X_03.00.08.02AP R3715 CARMD-EN-10526 2011/11/14 18:42:43
IMEI: 358178040511182
IMEI SV: 7
FSN: CCQ3042205710
3GPP Release 8
+GCAP: +CGSM


OK
```


$ usbconfig -u 1 -a 2 reset


```
Feb 13 17:59:29 192.168.1.1 Feb 13 17:59:29 kernel: usie0: at uhub1, port 2, addr 2 (disconnected)
Feb 13 17:59:29 192.168.1.1 Feb 13 17:59:29 kernel: usie_cns_req: param: 01:00:7e:46:75:6e:63:74:69:6f:6e:3a:20:62:74:6e
Feb 13 17:59:29 192.168.1.1 Feb 13 17:59:29 kernel: usie_if_cmd: cmd=26
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:29 kernel: usie0: <Sierra Wireless, Incorporated MC7710, class 0/0, rev 2.00/0.06, addr 2> on usbus1
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: fwattr=f
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=0
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=1
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=2
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=3
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=4
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: ifnum=7, ifidx=5
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: Found 5 interfaces.
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: enabling automatic suspend and resume
Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: device attached
```


AT!RESET produces


```
Feb 13 18:02:47 192.168.1.1 Feb 13 18:02:47 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 13 18:02:47 192.168.1.1 Feb 13 18:02:47 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 13 18:02:47 192.168.1.1 Feb 13 18:02:47 kernel: usie_uc_status_callback: info received, actlen=10
Feb 13 18:02:47 192.168.1.1 Feb 13 18:02:47 kernel: usie_uc_status_callback: param=2
Feb 13 18:02:49 192.168.1.1 Feb 13 18:02:49 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 13 18:02:49 192.168.1.1 Feb 13 18:02:49 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 13 18:02:49 192.168.1.1 Feb 13 18:02:49 kernel: usie_uc_status_callback: info received, actlen=10
Feb 13 18:02:49 192.168.1.1 Feb 13 18:02:49 kernel: usie_uc_status_callback: param=2
Feb 13 18:02:49 192.168.1.1 Feb 13 18:02:49 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 13 18:02:49 192.168.1.1 Feb 13 18:02:49 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 13 18:02:49 192.168.1.1 Feb 13 18:02:49 kernel: usie_uc_status_callback: USB transfer error, USB_ERR_CANCELLED
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:51 kernel: ugen1.2: <Sierra Wireless, Incorporated> at usbus1 (disconnected)
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:51 kernel: usie0: at uhub1, port 2, addr 2 (disconnected)
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:51 kernel: usie_cns_req: param: 01:00:7e:68:20:9e:87:71:d2:b9:9c:07:00:00:64:00
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:51 kernel: usie_if_cmd: cmd=26
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:51 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 0/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 1/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 2/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 3/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 4/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 5/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 6/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 7/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 8/10
Feb 13 18:02:52 192.168.1.1 Feb 13 18:02:52 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 9/10
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: ugen1.2: <Sierra Wireless, Incorporated> at usbus1
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie0: <Sierra Wireless, Incorporated MC7710, class 0/0, rev 2.00/0.06, addr 2> on usbus1
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: fwattr=f
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=0
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=1
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=2
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=3
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=4
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: ifnum=7, ifidx=5
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: Found 5 interfaces.
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: enabling automatic suspend and resume
Feb 13 18:02:57 192.168.1.1 Feb 13 18:02:57 kernel: usie_attach: device attached
```


----------



## PseudoCylon (Feb 14, 2013)

state_terror said:
			
		

> Was there supposed to be an oid hw.usb.usie.usie_pm ?


Actually, yes.`# sysctl hw.usb.usie`should return
	
	



```
hw.usb.usie.power_mode: 0
hw.usb.usie.debug: 1
```



			
				state_terror said:
			
		

> and I noticed this in the log when usb was reattached
> 
> Feb 13 17:59:30 192.168.1.1 Feb 13 17:59:30 kernel: usie_attach: enabling automatic suspend and resume


That should also be
	
	



```
usie_attach: USB power is always ON
```



			
				state_terror said:
			
		

> Anyhow, I have included my if_usie.c in case I have patched it incorrectly.


You have patched it right. You must be loading the old module. (I also load wrong module quite often.)


----------



## state_terror (Feb 14, 2013)

> You have patched it right. You must be loading the old module.



Er yes, apologies, something went horribly wrong <red face> for reasons I have yet to uncover.

Anyhow, I worked around it, but the MC7710 still failed to connect. 

MC7710 on FreeBSD after receiving DHCP but no connection

AT!SELTRAT=00 Automatic

```
AT!GSTATUS?
!GSTATUS:
Current Time:  2846		Temperature: 32
Bootup Time:   2110		Mode:        ONLINE
System mode:   LTE          	PS state:    Attached
LTE band:      B3     		LTE bw:      10 MHz
LTE Rx chan:   1617		LTE Tx chan: 19617
EMM state:     Registered     	Normal Service
EMM connection:RRC Idle

RSSI (dBm):    -77		Tx Power:
RSRP (dBm):    -101		TAC:         2CB1 (11441)
RSRQ (dB):     -7		Cell ID:     0028A802 (2664450)
SINR (dB):     13.6


OK
```


AT!SELTRAT=01 3G only	


```
AT!GSTATUS?
!GSTATUS:
Current Time:  2989		Temperature: 32
Bootup Time:   2110		Mode:        ONLINE
System mode:   WCDMA      	PS state:    Attached
WCDMA band:    WCDMA 2100
WCDMA channel: 10761
GMM (PS) state:REGISTERED     	NORMAL SERVICE
MM (CS) state: IDLE           	NORMAL SERVICE

WCDMA L1 State:L1M_PCH_SLEEP  	RRC State:   CELL_PCH
RX level C0:   -79		LAC:         0478 (1144)
RX level C1:   -106		Cell ID:     00BEE62C (12510764)


OK
```


AT!SELTRAT=06 4G only


```
AT!GSTATUS?
!GSTATUS:
Current Time:  2577		Temperature: 31
Bootup Time:   2110		Mode:        ONLINE
System mode:   LTE          	PS state:    Attached
LTE band:      B3     		LTE bw:      10 MHz
LTE Rx chan:   1617		LTE Tx chan: 19617
EMM state:     Registered     	Normal Service
EMM connection:RRC Idle

RSSI (dBm):    -77		Tx Power:
RSRP (dBm):    -101		TAC:         2CB1 (11441)
RSRQ (dB):     -7		Cell ID:     0028A802 (2664450)
SINR (dB):     13.0


OK
```


usbconfig -u 1 -a 2 reset


```
Feb 14 21:12:49 192.168.1.1 Feb 14 21:12:51 kernel: usie0: at uhub1, port 2, addr 2 (disconnected)
Feb 14 21:12:49 192.168.1.1 Feb 14 21:12:51 kernel: usie_cns_req: param: 01:00:7e:68:f0:23:88:21:a0:7f:b3:07:00:00:64:00
Feb 14 21:12:49 192.168.1.1 Feb 14 21:12:51 kernel: usie_if_cmd: cmd=26
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie0: <Sierra Wireless, Incorporated MC7710, class 0/0, rev 2.00/0.06, addr 2> on usbus1
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: fwattr=f
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=0
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=1
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=2
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=3
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=4
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: ifnum=7, ifidx=5
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: Found 5 interfaces.
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: USB power is always ON
Feb 14 21:12:50 192.168.1.1 Feb 14 21:12:52 kernel: usie_attach: device attached
```

AT!RESET


```
Feb 14 21:21:20 192.168.1.1 Feb 14 21:21:22 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 14 21:21:20 192.168.1.1 Feb 14 21:21:22 kernel: usie_uc_update_line_state: sc_uc_ifnum=3
Feb 14 21:21:20 192.168.1.1 Feb 14 21:21:22 kernel: usie_uc_status_callback: info received, actlen=10
Feb 14 21:21:20 192.168.1.1 Feb 14 21:21:22 kernel: usie_uc_status_callback: param=2
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: ugen1.2: <Sierra Wireless, Incorporated> at usbus1 (disconnected)
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie0: at uhub1, port 2, addr 2 (disconnected)
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_cns_req: param: 01:00:7e:00:45:00:00:34:57:1e:40:00:7f:06:59:64
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_if_cmd: cmd=26
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 0/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_uc_status_callback: USB transfer error, USB_ERR_STALLED
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 1/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_uc_status_callback: USB transfer error, USB_ERR_CANCELLED
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 2/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 3/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 4/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 5/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 6/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 7/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 8/10
Feb 14 21:21:22 192.168.1.1 Feb 14 21:21:24 kernel: usie_do_request: Control request failed: USB_ERR_NOT_CONFIGURED 9/10
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: ugen1.2: <Sierra Wireless, Incorporated> at usbus1
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie0: <Sierra Wireless, Incorporated MC7710, class 0/0, rev 2.00/0.06, addr 2> on usbus1
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: fwattr=f
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=0
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=1
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: NumEndpoints=2 bInterfaceNumber=2
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=3
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: NumEndpoints=3 bInterfaceNumber=4
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: ifnum=7, ifidx=5
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: Found 5 interfaces.
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: USB power is always ON
Feb 14 21:21:27 192.168.1.1 Feb 14 21:21:29 kernel: usie_attach: device attached
```


----------



## nscheffer (May 15, 2014)

Did someone finally got an MC7710 running fine with FreeBSD? Any help appreciated!


----------

