ppp.conf for Verizon Mifi 2200?

[Ryan Coleman]

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 at d3photography.com> wrote:
>> Sounds alot like my query for the Virgin Mobile one ... I got NOWHERE.
>> :\
> 
> 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?
> 
>> On Mar 24, 2011, at 5:31 PM, Lawton Campbell wrote:
>> 
>>> 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 at 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 at 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 at 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 at 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 at 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 at 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 :)
>>> _______________________________________________
>>> freebsd-questions at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>> 
>>