Search results

Can you run the stock driver with debug level of 1 until the problem occurs? # sysctl hw.usb.run.debug=1

Please change len to size. (Leave m_pkthdr.len as is.) DPRINTFN(11, "sending frame len=%u xferlen=%u @ index %d\n", - m->m_pkthdr.len, len, index); + m->m_pkthdr.len, size, index);

Just recapping, 1) The AP was working until device timeout error message appears. 2) After applied the patch, the device timeout disappears, but no station can associate with the AP. Then, I guess I screwed creating the patch. The patch should bediff --git a/if_run.c b/if_run.c ---...

Actually,run0: device timeoutandrun_do_request: Control request failed, USB_ERR_TIMEOUT (retrying) are 2 different error. I could not see any run0: device timeout in the attached output. In other words, the deceive should have been working when you got the output, I believe. The device needs...

If you have compiled the kernel or the driver with USB_DEBUG option, the following will print out some debug information.# sysctil hw.usb.run.debug=1 You could try un-comment the following line at or around line 683 in if_run.c, though it might cause LOR. (The LOR was fixed in...

That's good to know. For 11n support, you are more than welcome to try the driver at gitorious and report any problem. So far, I have figured out what registers to poke, but BBPs. There are 3 different versions (Linux, Ralink, and OpenBSD) of drivers, and they are slightly different each...

@gnoma, Your device uses ral, totally different driver. As far as I know, no one is working on adding 11n support at this moment. @wbedard, I do not have any device with this chipset, but the driver on gitorious should (or hopefully) work. But, patch and see if device time out disappears before...

Here is the original post, but his device uses different chipset. http://forums.freebsd.org/showthread.php?p=156885#post156885 9.2-RELEASE should do the job. Whether using CURRENT or the latest RELEASE, you will be end up checking-out the latest source and re-compile when there are important...

That fix didn't go into 8.* You need to manually patch the code because you are running 8.3 RELEASE.diff --git a/if_run.c b/if_run.c --- a/if_run.c +++ b/if_run.c @@ -2747,6 +2747,9 @@ run_bulk_tx_callbackN(struct usb_xfer *xfer, usb_error_t error, unsigned int index) size =...

Actually, yes.sysctl hw.usb.usieshould returnhw.usb.usie.power_mode: 0 hw.usb.usie.debug: 1 That should also beusie_attach: USB power is always ON You have patched it right. You must be loading the old module. (I also load wrong module quite often.)

Briefly, this has caused trap#7 0xffffffff816bbc76 in zfs_freebsd_remove (ap=Variable "ap" is not available.) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1855The function zfs_freebsd_remove() was called with an inappropriate pointer to a...

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.diff --git a/src/sys/dev/usb/net/if_usie.c b/src/sys/dev/usb/net/if_usie.c...

Actually, there should be more debug messages earlier than you have attached here. They should be right afterusieO: < Sierra Wireless, Incorporated MC7710, ...and look likeusie_attach: ifnum=N, ifidx=N usie_attach: NumEndpoints=N bInterfaceNumber=NI set debug level to 1, so boot or reset with...

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.diff --git a/src/sys/dev/usb/net/if_usie.c b/src/sys/dev/usb/net/if_usie.c index...

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. AT!MAPUART?and usbconfig -d N.N...

usbconfig -d your.ugen_num dump_device_descand 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 -rplease. As far as I know, LTE devices have device ID of 0x68aa. Did you follow the steps on the very first...

You cannot throw random info in. First, you said, Now, Some recapping would be nice. While you are writing, keep in mind that I don't know anything what is going on at you place. In the mean time, I just go for same result as before, so that encryption is working. Try capture bootp packets...

Does /dev/bpf0 present? Can you try without encryption and see if it works?

What do you mean by not getting ip? The log says dhclient has received it. Oct 13 09:16:55 mbp dhclient: New IP Address (wlan0): 10.0.1.5 Oct 13 09:16:55 mbp dhclient: New Subnet Mask (wlan0): 255.255.255.0 Oct 13 09:16:55 mbp dhclient: New Broadcast Address (wlan0): 10.0.1.255 Oct 13 09:16:55...

If ndis doesn't work, no unless you or someone writes the driver. Besides, due to number of fixes in IEEE80211 stack, it is unpractical to run any device in 11n mode on 8.X. I would upgrade to 9.X before spending any time on the driver.