From owner-freebsd-questions@FreeBSD.ORG Thu Mar 24 23:25:14 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 255001065676 for ; Thu, 24 Mar 2011 23:25:14 +0000 (UTC) (envelope-from editor@d3photography.com) Received: from server.cwis.biz (70-89-202-5-invergrove-mn.hfc.comcastbusiness.net [70.89.202.5]) by mx1.freebsd.org (Postfix) with ESMTP id CD9F58FC0C for ; Thu, 24 Mar 2011 23:25:13 +0000 (UTC) Received: from server.cwis.biz (localhost [127.0.0.1]) by server.cwis.biz (Postfix) with ESMTP id 7C8E42639E78; Thu, 24 Mar 2011 18:25:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at cwis.biz Received: from server.cwis.biz ([127.0.0.1]) by server.cwis.biz (server.cwis.biz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6F0mYHnR0fh; Thu, 24 Mar 2011 18:25:24 -0500 (CDT) Received: from [10.0.1.198] (70-89-202-1-invergrove-mn.hfc.comcastbusiness.net [70.89.202.1]) by server.cwis.biz (Postfix) with ESMTPSA id 131482639A41; Thu, 24 Mar 2011 18:25:24 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ryan Coleman In-Reply-To: Date: Thu, 24 Mar 2011 18:24:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lawton Campbell X-Mailer: Apple Mail (2.1082) Cc: freebsd-questions@freebsd.org Subject: Re: ppp.conf for Verizon Mifi 2200? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 23:25:14 -0000 Sounds alot like my query for the Virgin Mobile one ... I got NOWHERE. :\ On Mar 24, 2011, at 5:31 PM, Lawton Campbell wrote: > 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: at = usbus1 > Mar 25 06:06:36 ffffff kernel: u3g0: 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"