Hi,

On 11/16/07, Michael van Elst <mlelstv@serpens.de> wrote:
> marcotrillo@gmail.com ("Marco Trillo") writes:
>
> >detected as a umass(4). To make it work with ubsa(4) you just need to
> >make ubsa(4) recognize it as a supported model (its identifier is
> >already included in 'usbdevs').
>
> Yes, it is supposed to work.

Indeed, it works (at least I can talk with the device). However, it
needs to be plugged two times (keeping the 'assistant power' link
connected):

(first time)
Nov 17 14:43:43 ununoctium /netbsd: ubsa0 at uhub0 port 1
Nov 17 14:43:43 ununoctium /netbsd: ubsa0: HUAWEI Technologies HUAWEI
Mobile, rev 1.10/0.00, addr 3
Nov 17 14:43:43 ununoctium /netbsd: ubsa0: Could not find interrupt in
Nov 17 14:43:49 ununoctium /netbsd: ubsa0: at uhub0 port 1 (addr 3) disconnected
Nov 17 14:43:49 ununoctium /netbsd: ubsa0 detached
(second time)
Nov 17 14:44:05 ununoctium /netbsd: ubsa0 at uhub0 port 1
Nov 17 14:44:05 ununoctium /netbsd: ubsa0: HUAWEI Technologies HUAWEI
Mobile, rev 1.10/0.00, addr 3
Nov 17 14:44:05 ununoctium /netbsd: ucom0 at ubsa0

Apparently, it requires some quirk to switch from the mass storage
mode to the serial adapter mode; but with the workaround of replugging
it, it works with ubsa(4).

It may not be exactly an ubsa; this message appears multiple times
when you open a connection to the serial device:
ubsa0: ubsa_request: STALLED
but the serial link works.

> >Perhaps the difficult thing will be configuring PPP to issue all the
> >needed commands for the device to work (send PIN, select UMTS/GPRS/etc
> >network, etc.).
>
> You need to set the pin once.
>
> AT+CPIN?       query wether PIN is set
> AT+CPIN=XXXX   set PIN
>
> The 'endpoint' depends on the provider.
>
> AT_OPSYS=3,2
> AT+CGDCONF=1,"IP","..endpoint.."
> ATD*99***1#

At the moment I could not get the PPP to work.

I have a provider-customized Mac OS X binary that configures the modem
under Mac OS X (prompts for the pin, selects network to use, displays
signal strength, etc.). After this program configures it, you can use
the PPP utility with a custom modem script to open a connection.

So I ran the Mac OS X binary under 'ktrace' and took note of exactly
what commands it writes to the modem tty. The commands that the PPP
modem script utility writes can be got from the system log.
So I wrote a chat(8) script which writes exactly the same commands
(even the ones which are only informative).

But, oddly enough, there is one command that does not produce the same
result from my chat(8) script that from the Mac OS X binary.

The command is 'ATE0V1E1X1^SYSCFG=2,2,3FFFFFFF,1,2'. This command is
run just after the AT+CPIN=XXXX command.
Under the Mac OS X binary, the modem returns a 'OK' response.
But from my chat(8) script, it returns the following:

Nov 17 14:00:35 ununoctium chat[1501]: send
(ATE0V1E1X1^SYSCFG=2,2,3FFFFFFF,1,2^M)
Nov 17 14:00:36 ununoctium chat[1501]: expect (OK)
Nov 17 14:00:36 ununoctium chat[1501]: ^M
Nov 17 14:00:36 ununoctium chat[1501]: ATE0V1E1X1^SYSCFG=2,2,3FFFFFFF,1,2^M^M
Nov 17 14:00:36 ununoctium chat[1501]: COMMAND NOT SUPPORT^M

I tried to do a delay before this command, but still the same.

Anyway I just commented out this command and it seems to work just
fine... except that just after connecting, it hangs up immediately.

Nov 17 14:52:30 ununoctium chat[758]: send (ATD*99***1#^M)
Nov 17 14:52:30 ununoctium chat[758]: expect (CONNECT)
Nov 17 14:52:30 ununoctium chat[758]: ^M
Nov 17 14:52:30 ununoctium chat[758]: ATD*99***1#^M^M
Nov 17 14:52:30 ununoctium chat[758]: CONNECT
Nov 17 14:52:30 ununoctium chat[758]:  -- got it
Nov 17 14:52:30 ununoctium chat[758]: send ()
Nov 17 14:52:30 ununoctium pppd[1215]: Serial connection established.
Nov 17 14:52:30 ununoctium pppd[1215]: Using interface ppp0
Nov 17 14:52:30 ununoctium pppd[1215]: Connect: ppp0 <--> /dev/ttyU0
Nov 17 14:52:30 ununoctium pppd[1215]: Modem hangup
Nov 17 14:52:30 ununoctium pppd[1215]: Connection terminated.
Nov 17 14:52:32 ununoctium pppd[1215]: Exit.

If I use a simpler chat(8) script which does just the basic stuff, I
get the same results: immediate hangup.

Perhaps this is a defective pppd configuration.

In contrast, this is what pppd(8) logs in the Mac OS X console:

Nov 17 13:38:31 marco-trillos-computer ccl[388]: CCLWrite : ATD*99***1#\13
Nov 17 13:38:31 marco-trillos-computer ccl[388]: CCLMatched : CONNECT
Nov 17 13:38:34 marco-trillos-computer pppd[386]: Connect: ppp0 <-->
/dev/cu.HUAWEIMobile-Modem
Nov 17 13:38:38 marco-trillos-computer pppd[386]: Could not determine
remote IP address: defaulting to 10.64.64.64
Nov 17 13:38:38 marco-trillos-computer pppd[386]: local  IP address
77.209.27.189
Nov 17 13:38:38 marco-trillos-computer pppd[386]: remote IP address 10.64.64.64
Nov 17 13:38:38 marco-trillos-computer pppd[386]: primary   DNS
address 212.73.32.3
Nov 17 13:38:38 marco-trillos-computer pppd[386]: secondary DNS
address 212.73.32.67

Any ideas?

Thanks,
Marco.