Date: Thu, 24 Mar 2011 16:31:45 -0600 From: Lawton Campbell <lcampbell@ironclad.mobi> To: freebsd-questions@freebsd.org Subject: ppp.conf for Verizon Mifi 2200? Message-ID: <AANLkTimQBdXKiMy%2Bq5qRUutyOZxGCJC673mpTe__VFKP@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hey freebsd-questions! I've been trying to get a Verizon MiFi 2200 to work on my 8.2-RELEASE box for the past couple of days and can't seem to get the ppp.conf to work properly. I found a couple of recent threads about similar devices (apparently it's just novatel stuff that gets repackaged for different 3G providers) -- http://www.mail-archive.com/freebsd-net@freebsd.org/msg36160.html It doesn't look like they got the Virgin Mobile version of the device working, unfortunately. I'm stuck in a slightly different place, so making a new thread (dunno if freebsd-net or freebsd-questions is more appropriate, so erring to -questions). Anyway, let's get started! Going to walkthrough what I have so far, then finally get to where I'm stuck and detail some questions. # THUS FAR One quirk of the device is that you have to detach /dev/cd0 when it mounts to expose the modem interface for u3g to grab. Looking at usbconfig, the relevant identifiers for the device are idVendor = 0x1410 idProduct = 0x5041 AFAIK, u3gstub is supposed to take care of this automagically, but perhaps either I've misread the man page or it's missing the vendor/product IDs. In any case, it's probably easy enough to fix with a devd rule, so I'm not too worried about it. In any case, when the device is attached, `camcontrol eject cd0` (or whatever cd# is generated) has to be run -- root@ffffff> camcontrol eject cd0 Which gives us -- Mar 25 06:06:36 ffffff kernel: ugen1.2: <Novatel Wireless Inc.> at usbus1 Mar 25 06:06:36 ffffff kernel: u3g0: <Data Interface> on usbus1 Mar 25 06:06:36 ffffff kernel: u3g0: Found 5 ports. root@ffffff> ls /dev/cuaU0.* /dev/cuaU0.0 /dev/cuaU0.1.init /dev/cuaU0.2.lock /dev/cuaU0.4 /dev/cuaU0.0.init /dev/cuaU0.1.lock /dev/cuaU0.3 /dev/cuaU0.4.init /dev/cuaU0.0.lock /dev/cuaU0.2 /dev/cuaU0.3.init /dev/cuaU0.4.lock /dev/cuaU0.1 /dev/cuaU0.2.init /dev/cuaU0.3.lock I just grabbed the stock ppp.conf from the handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/userppp.html) with some bits removed (the login chat script, specifically -- we'll know if that's broken when we get there). root@ffffff> cat /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) set speed 115200 set device /dev/cuaU0.0 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" set timeout 180 enable dns mifi: set phone "#777" set authname "XXXMYNUMBER@vzw3g.com" set authkey "vzw" set ifaddr 10.23.0.1 10.23.0.2 255.255.255.255 0.0.0.0 add default HISADDR However, when I run `ppp -ddial mifi`, I get -- Mar 25 06:17:43 ffffff ppp[10491]: tun0: Chat: Send: AT^M Mar 25 06:17:43 ffffff ppp[10491]: tun0: Chat: Expect(5): OK Mar 25 06:17:49 ffffff ppp[10491]: tun0: Chat: Expect timeout Mar 25 06:17:49 ffffff ppp[10491]: tun0: Warning: Chat script failed Which means we're not even communicating with the modem. Kinda weird -- I think it's a problem in the dial script. Let's just take out the non-default dial script and see what happens: root@ffffff> cat /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) set speed 115200 set device /dev/cuaU0.1 set timeout 180 enable dns mifi: set phone "#777" set authname "XXXMYNUMBER@vzw3g.com" set authkey "vzw" set ifaddr 10.23.0.1 10.23.0.2 255.255.255.255 0.0.0.0 add default HISADDR Mar 25 06:20:15 ffffff ppp[10518]: tun0: Phase: deflink: closed -> opening Mar 25 06:20:15 ffffff ppp[10518]: tun0: Phase: deflink: Connected! Mar 25 06:20:15 ffffff ppp[10518]: tun0: Phase: deflink: opening -> dial Mar 25 06:20:15 ffffff ppp[10518]: tun0: Phase: deflink: dial -> carrier Mar 25 06:20:16 ffffff ppp[10518]: tun0: Phase: deflink: /dev/cuaU0.1 doesn't support CD Mar 25 06:20:16 ffffff ppp[10518]: tun0: Phase: deflink: carrier -> login Mar 25 06:20:16 ffffff ppp[10518]: tun0: Phase: deflink: login -> lcp Mar 25 06:20:16 ffffff ppp[10518]: tun0: LCP: FSM: Using "deflink" as a transport Mar 25 06:20:16 ffffff ppp[10518]: tun0: LCP: deflink: State change Initial --> Closed Mar 25 06:20:16 ffffff ppp[10518]: tun0: LCP: deflink: State change Closed --> Stopped Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: deflink: LayerStart Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: ACFCOMP[2] Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: PROTOCOMP[2] Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: ACCMAP[6] 0x00000000 Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: MRU[4] 1500 Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: MAGICNUM[6] 0x72c1cbf0 Mar 25 06:20:17 ffffff ppp[10518]: tun0: LCP: deflink: State change Stopped --> Req-Sent Mar 25 06:20:21 ffffff ppp[10518]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Mar 25 06:20:21 ffffff ppp[10518]: tun0: LCP: ACFCOMP[2] Mar 25 06:20:21 ffffff ppp[10518]: tun0: LCP: PROTOCOMP[2] Mar 25 06:20:21 ffffff ppp[10518]: tun0: LCP: ACCMAP[6] 0x00000000 Mar 25 06:20:21 ffffff ppp[10518]: tun0: LCP: MRU[4] 1500 Mar 25 06:20:21 ffffff ppp[10518]: tun0: LCP: MAGICNUM[6] 0x72c1cbf0 Mar 25 06:20:21 ffffff ppp[10518]: tun0: Phase: Unknown protocol 0x0013 (reserved (transparency inefficient)) Mar 25 06:20:21 ffffff ppp[10518]: tun0: LCP: deflink: SendProtocolRej(1) state = Req-Sent Aha! So we've got a connection to the provider at this point, but they're not responding properly to our LCP configuration requests. Not quite sure why, to be honest. A little bit of googling turns up this thread: http://lists.freebsd.org/pipermail/freebsd-usb/2009-August/007241.html Which suggests adding "disable pred1 deflate deflate24 protocomp acfcomp shortseq vj mppe" to the ppp.conf. After making this modification, I get the following response -- Mar 25 06:24:49 ffffff ppp[10593]: tun0: LCP: deflink: State change Closed --> Stopped Mar 25 06:24:50 ffffff ppp[10593]: tun0: LCP: deflink: LayerStart Mar 25 06:24:50 ffffff ppp[10593]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Mar 25 06:24:50 ffffff ppp[10593]: tun0: LCP: ACCMAP[6] 0x00000000 Mar 25 06:24:50 ffffff ppp[10593]: tun0: LCP: MRU[4] 1500 Mar 25 06:24:50 ffffff ppp[10593]: tun0: LCP: MAGICNUM[6] 0x09fbbcd0 Mar 25 06:24:50 ffffff ppp[10593]: tun0: LCP: deflink: State change Stopped --> Req-Sent Mar 25 06:24:54 ffffff ppp[10593]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent Mar 25 06:24:54 ffffff ppp[10593]: tun0: LCP: ACCMAP[6] 0x00000000 Mar 25 06:24:54 ffffff ppp[10593]: tun0: LCP: MRU[4] 1500 Mar 25 06:24:54 ffffff ppp[10593]: tun0: LCP: MAGICNUM[6] 0x09fbbcd0 Mar 25 06:24:57 ffffff ppp[10593]: tun0: LCP: deflink: SendConfigReq(1) state = Req-Sent So now we're not getting _anything_ back from the provider. It looks like `disable acfcomp` is what's squelching those errors, but frankly I have no idea what acfcomp is or does. I suspect that the modem isn't really speaking PPP, but I don't know how to try PPPoE or anything else. At this point I am completely confounded. Any ideas? (I'm off-list, so please CC me!) Thanks :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimQBdXKiMy%2Bq5qRUutyOZxGCJC673mpTe__VFKP>