iris_tusks

I have a Verizon Pantech MHS291L. It is on the list of potentially compatible modems. As you can see in that list, we need to switch the vendor and product IDs from 10a9:6080 to 10a9:6085. Following the provided link provides some insight but it's a little murky. Here's what I've learned so far. First, run lsusb to see the vendor and product ID's currently in use: root@Pineapple:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 003: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter Bus 001 Device 005: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 006: ID 10a9:6080 SK Teletech Co., Ltd MHS291LVW LTE Modem [Verizon Jetpack 4G LTE Mobile Hotspot MHS291L] (Zero CD Mode) As you can see, it's 10a9:6080. We want it to be 10a9:6085. To get there, we need a file called "10a9:6080" at /etc/usb_modeswitch.d/ with the contents: # Pantech LTE Modem DefaultVendor=0x10a9 DefaultProduct=0x6080 TargetVendor=0x10a9 TargetProduct=0x6085 PantechMode=1 Once this file is added, theoretically usb_modeswitch will know what to do with this thing and everything will be happy... except that it doesn't work. root@Pineapple:~# usb_modeswitch -c /etc/usb_modeswitch.d/10a9\:6080 Looking for target devices ... No devices in target mode or class found Looking for default devices ... found matching product ID adding device Found device in default mode, class or configuration (1) Accessing device 006 on bus 001 ... Getting the current device configuration ... OK, got current device configuration (1) Ambiguous Class/InterfaceClass: 0xef/0x08 Using first interface: 0x00 Using endpoints 0x02 (out) and 0x82 (in) Inquiring device details; driver will be detached ... Looking for active driver ... No driver found. Either detached before or never attached SCSI inquiry data (for identification) ------------------------- Vendor String: PANTECH Model String: CD-ROM Revision String: 0000 ------------------------- USB description data (for identification) ------------------------- Manufacturer: Pantech, Incorporated Product: PANTECH MHS291LVW Serial No.: PTMHS291LVW20630784 ------------------------- Warning: no switching method given. -> Run lsusb to note any changes. Bye. Running lsusb gives the exact same output as before. Chasing this further, I found the release notes for usb_modeswitch. It appears that Pantech support was added at: Version 1.2.7, 2013/08/07 Two new dedicated control message functions to support Pantech LTE (thanks to Adam Goode) and Blackberry Q10/Z10 (thanks to Daniel Mende) There have also been two updates in 2015 fixing various Pantech stuff. Note that I'm using MarkV firmware 2.4.0. The version usb_modeswitch that's included is 1.2.3: root@Pineapple:~# usb_modeswitch -e * usb_modeswitch: handle USB devices with multiple modes * Version 1.2.3 (C) Josua Dietze 2012 * Based on libusb0 (0.1.12 and above) Looks like this is the version bundled with OpenWRT 12.09 "Attitude Adjustment", upon which the Mark V firmware is based (I think). I figured it might be as simple as updating to a newer version, as in: root@Pineapple:~# opkg install http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base/usb-modeswitch_2014-07-18-01ecc3b9764d1dd89cf36ede0a2d98f9adb0cd33_ar71xx.ipk But, though that command succeeds, we are simply left apparently without any usb_modeswitch binary, which clearly won't help. I also tried this version but that install command fails, and also leaves us without a binary. I'm guessing there's probably something I don't understand about OpenWRT and installing packages or installing packages across versions or some such thing... but in any case, so far I'm stuck with usb_modeswitch 1.2.3 which does not support the Pantech LTE devices. Thoughts? Is there any way to install a newer version of usb_modeswitch?

Oh wait, I just tried again... downloaded successfully.

Downloads are broken again/still. Sorry guys!

Ok, must not be thinking clearly. So, the blacklist keeps Karma from deauthing me and thus karma'ing me, but if it's broadcasting the SSIDs, of course they'll show up. What I need to do is blacklist my own SSIDs as well so that the networks I want to connect to with my blacklisted devices don't get karma'ed and therefore I can continue to connect to them. That still leaves the problem of the web interface hanging after visiting the recon view, and the karma'ed SSIDs not accepting connections. I suspect I should probably run in whitelist mode instead to limit the amount of effort the pineapple has to spend on doing all the ssid broadcasting etc., -- i wonder if it simply can't handle broadcasting 40+ SSIDs, listening for other probes, and still accept connections and keep the web portal running... More testing is in my immediate future...

Hi Sebkinne, do you have a planned release date for 2.3 yet?

I too am having some issues -- as mentioned above, blacklisting my own MAC addresses doesn't seem to do anything (I still see the karma'ed SSIDs) and after some period of time I can't connect to any of them anymore anyway. I also lose access to the web interface anytime I go into the recon view -- it runs its first 15 second scan and shows me the results, but any subsequent scans appear to start and never finish, taking the web interface down with it. Anyone have any ideas?