Date: Tue, 4 Nov 2008 23:25:25 +0100 From: Nick Hibma <nick@van-laarhoven.org> To: Vladimir Grebenschikov <vova@fbsd.ru> Cc: Andrea Guzzo <aguzzo@anywi.com>, FreeBSD CURRENT Mailing List <current@freebsd.org>, FreeBSD Hardware Mailing list <hardware@freebsd.org> Subject: Re: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel Message-ID: <200811042325.26574.nick@van-laarhoven.org> In-Reply-To: <1225836292.3428.37.camel@localhost> References: <200810092344.10388.nick@van-laarhoven.org> <1225836292.3428.37.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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. > - 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. > - 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. Nick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811042325.26574.nick>