Request for testers: Option 3G cards, also Sierra, Huawei and Novatel

[Vladimir Grebenschikov]

On Tue, 2008-11-04 at 23:25 +0100, Nick Hibma wrote:
> > Now (5-days old current), everything looks fine, chat finishes, but ppp
> > failed to handshake (same ppp config works before with ubsa):
> >
> > Nov  5 00:57:35 vbook ppp[4644]: tun0: Phase: PPP Started (background
> > mode). Nov  5 00:57:35 vbook ppp[4644]: tun0: Phase: bundle: Establish
> > Nov  5 00:57:35 vbook ppp[4644]: tun0: Chat: Send: ATDT#777^M
> 
> Are you sure this phone number is correct? I'd have to check the 3GPP spec, 
> but something like
> 
> 	ATDT*99***1#
> 
> is more like the Huawei expects. The general format is 
> *<service>*<??>*<??>*<??>*<cgdcont>#. If you have set multiple PDP contexts 
> through AT+CGDCONT you can select the one you need by replacing the '1' in 
> the line above with the appropriate number.

Actually it is not exactly 3G modem - it is 
Huawei EC500 for CDMA2000 network (hybrid 2.5G / 3G - Skylink operator
in Russia)

ATDT#777 is usual dial for that operator.

> The 'Unexpected * in phase *' I've not seen before and would indicate that a 
> valid packet is received but one that is not appropriate at that point. You 
> might want to add some more logging options to see what is going on.
> 
> > It looks like that characters are delivered not reliable way through ucom
> > port: Same on U0.2 port:
> 
> Weird. Should not happen.

What I can do to help track the problem ?

> > - after disconnecting ppp from port card is not reset, so no more any
> > chat if start ppp again (you just need skip chat phase). - How to reset
> > card before start ?
> 
> We've had this problem with an EDGE card from Option, and we basically power 
> down the port and power up again the card to get it back. Patches have been 
> sent to Warner to get committed.

Nice, are these patches attached to some PR ?

> > - Disconnecting card crashes kernel, it is possible to catch that crash
> > with DDB, but dump can't be written. Modem is on cardbus device.
> > (probbaly will be fixed by new usb stack ?)
> 
> kldunload usb first. The USB stack crashes if the device disappears. This 
> takes some effort as you will have to unload all related modules. If you 
> have ums_load="YES" in your /boot/loader.conf without usb_load="YES", then 
> you are in luck as you should be able to unload ums and usb will unload as 
> well.
> 
> Once these are unloaded you should be able to unload the PCMCIA card without 
> problems. Works with Option cards this way.

Uhh, really need to try new USB stack (I will try).

> Nick

-- 
Vladimir B. Grebenschikov
vova at fbsd.ru