Date: Thu, 24 Mar 2011 21:12:27 -0500 From: Ryan Coleman <editor@d3photography.com> To: Lawton Campbell <lcampbell@ironclad.mobi> Cc: freebsd-questions@freebsd.org Subject: Re: ppp.conf for Verizon Mifi 2200? Message-ID: <34738714-6D99-46EF-8D40-55DB1B821287@d3photography.com> In-Reply-To: <AANLkTinMbdUA7y8KsmvTfc00UWe_hG8==Xo8fZHnKByx@mail.gmail.com> References: <AANLkTimQBdXKiMy%2Bq5qRUutyOZxGCJC673mpTe__VFKP@mail.gmail.com> <FDCF5CDF-40F0-4F10-8D55-8031961F5662@d3photography.com> <AANLkTinMbdUA7y8KsmvTfc00UWe_hG8==Xo8fZHnKByx@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
No clue, I haven't touched it in two weeks. I'll try again next week - = after I wrap another shoot where I wish I had it. -- Ryan On Mar 24, 2011, at 9:03 PM, Lawton Campbell wrote: > On Thu, Mar 24, 2011 at 5:24 PM, Ryan Coleman = <editor@d3photography.com> wrote: >> Sounds alot like my query for the Virgin Mobile one ... I got = NOWHERE. >> :\ >=20 > Haha yeah, I was really excited when I originally found your thread. > What does yours do if you give it my ppp.conf (with your > phone/authname/authkey subbed in)? Does it also get stuck sending LCP > requests for configuration and never receiving an intelligible reply? >=20 >> On Mar 24, 2011, at 5:31 PM, Lawton Campbell wrote: >>=20 >>> Hey freebsd-questions! >>>=20 >>> 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) -- >>>=20 >>> http://www.mail-archive.com/freebsd-net@freebsd.org/msg36160.html >>>=20 >>> 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. >>>=20 >>> # THUS FAR >>>=20 >>> 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 >>>=20 >>> idVendor =3D 0x1410 >>> idProduct =3D 0x5041 >>>=20 >>> 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 -- >>>=20 >>> root@ffffff> camcontrol eject cd0 >>>=20 >>> Which gives us -- >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> 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). >>>=20 >>> 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" >>>=20 >>> set timeout 180 >>> enable dns >>>=20 >>> mifi: >>> set phone "#777" >>> set authname "XXXMYNUMBER@vzw3g.com" >>> set authkey "vzw" >>>=20 >>> set ifaddr 10.23.0.1 10.23.0.2 255.255.255.255 0.0.0.0 >>> add default HISADDR >>>=20 >>> However, when I run `ppp -ddial mifi`, I get -- >>>=20 >>> 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 >>>=20 >>> 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: >>>=20 >>> 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 >>>=20 >>> set timeout 180 >>> enable dns >>>=20 >>> mifi: >>> set phone "#777" >>> set authname "XXXMYNUMBER@vzw3g.com" >>> set authkey "vzw" >>>=20 >>> set ifaddr 10.23.0.1 10.23.0.2 255.255.255.255 0.0.0.0 >>> add default HISADDR >>>=20 >>> 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 =3D 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 =3D 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 =3D Req-Sent >>>=20 >>> 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: >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-usb/2009-August/007241.html >>>=20 >>> 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 -- >>>=20 >>> 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 =3D 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 =3D 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 =3D Req-Sent >>>=20 >>> 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? >>>=20 >>> (I'm off-list, so please CC me!) >>>=20 >>> Thanks :) >>> _______________________________________________ >>> freebsd-questions@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >>> To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org" >>=20 >>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34738714-6D99-46EF-8D40-55DB1B821287>