Normally I'm using for UMTS an 'Option GT 3G/3G quad datacard' which is
supported fine since FreeBSD 6.2++ by the ubsa(4) driver;
Yesterday I've got a new card (and was lucky not giving away the working
one) which does not attach to any driver; the only information I have is
what is written on the cover of the device:
upper side:
Vodafone Mobile Connect HSDPA/UMTS/EDGE datacard
lower side:
Model GT 3G+ EMEA
designed in E.U. by Option
SNR: NL246970CJ
on plug-in into the slot the kernel says:
May 2 16:58:23 rebelion kernel: cardbus0: <network> at device 0.0 (no driver attached)
May 2 16:58:23 rebelion root: Unknown Cardbus device: device 0x000c class 0x028000 vendor 0x1931 bus cardbus0
I've Google'd around with the vendor id 0x1931 and the only hit is some
thread in a French Linux kernel group about a patch for some piece of
code drivers/char/nozomi.c naming the device code 0x000c and vendor
id:
+#define VENDOR1 0x1931 /* Vendor Option */
+#define DEVICE1 0x000c /* HSDPA card */
Is there some work in FreeBSD for this card? Thx
matthias
--
Matthias Apitz
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthia...@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blogspot.com/
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "freebsd-mobil...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Matthias,
no real life of a working driver, but a preliminary piece of code, which
may get your device working can be found here:
http://bsd.vwsoft.com/3g/nozomi/
Please grab the Makefile and nozomi.c file.
Big fat warning: This code currently can't make it into the fBSD source
tree, as it contains portions of GPL'd code.
At least you should get your device in a working state with that code.
The host interface of that card is totally different to that of other
cards so you won't have any luck with any other drive from the base system.
Please report back to me if you find any issues (as I'm not using 3G
cards very often these days anymore).
HTH
Volker
> Matthias,
>
> no real life of a working driver, but a preliminary piece of code, which
> may get your device working can be found here:
>
> http://bsd.vwsoft.com/3g/nozomi/
>
> Please grab the Makefile and nozomi.c file.
>
> Big fat warning: This code currently can't make it into the fBSD source
> tree, as it contains portions of GPL'd code.
>
> At least you should get your device in a working state with that code.
> The host interface of that card is totally different to that of other
> cards so you won't have any luck with any other drive from the base system.
>
> Please report back to me if you find any issues (as I'm not using 3G
> cards very often these days anymore).
>
> HTH
>
> Volker
Hi Volker,
Thanks for the piece of software. I run into a small problem compiling
the code nozomi.c because the function bus_setup_intr() awaits one more
argument as it was called in nozomi.c; I checked the man page of
bus_setup_intr() and other divers how they call it and came up with this
small patch:
*** nozomi.c 2008-05-04 16:14:15.406582000 +0200
--- nozomi.c.orig 2007-04-18 00:47:50.000000000 +0200
***************
*** 1204,1210 ****
nozomi_tty_init(sc);
/* setup interrupt and interrupt handler */
! if(bus_setup_intr(dev, sc->intr_res, INTR_TYPE_TTY , NULL, nozomi_interrupt_handler, sc, &sc->intr_cookie)) {
printf("unable to register interrupt handler\n");
goto fail;
}
--- 1204,1210 ----
nozomi_tty_init(sc);
/* setup interrupt and interrupt handler */
! if(bus_setup_intr(dev, sc->intr_res, INTR_TYPE_TTY , nozomi_interrupt_handler, sc, &sc->intr_cookie)) {
printf("unable to register interrupt handler\n");
goto fail;
}
With this change the driver compiles fine and loads fine with
'kldload ./nozomi.ko'
On card insert it says:
May 4 16:19:54 rebelion kernel: nozomi0: <Option N.V. GlobeTrotter 3G+> mem 0xc8309000-0xc83097ff irq 16 at device 0.0 on cardbus0
May 4 16:19:54 rebelion kernel: nozomi0: [GIANT-LOCKED]
May 4 16:19:54 rebelion kernel: nozomi0: [ITHREAD]
May 4 16:19:55 rebelion kernel: nozomi0: ver. 3 with 2048 bytes of memory
May 4 16:19:55 rebelion kernel: nozomi0: initialization complete
As the next step I wanted to check with some serial line tool (kermit) how the
card answers on AT commands, but I don't see any /dev file coming up in
user space; am I missing something? what should be the name of the
device in user space? Thanks in advance
> On card insert it says:
>
> May 4 16:19:54 rebelion kernel: nozomi0: <Option N.V. GlobeTrotter 3G+> mem 0xc8309000-0xc83097ff irq 16 at device 0.0 on cardbus0
> May 4 16:19:54 rebelion kernel: nozomi0: [GIANT-LOCKED]
> May 4 16:19:54 rebelion kernel: nozomi0: [ITHREAD]
> May 4 16:19:55 rebelion kernel: nozomi0: ver. 3 with 2048 bytes of memory
> May 4 16:19:55 rebelion kernel: nozomi0: initialization complete
>
> As the next step I wanted to check with some serial line tool (kermit) how the
> card answers on AT commands, but I don't see any /dev file coming up in
> user space; am I missing something? what should be the name of the
> device in user space? Thanks in advance
I have digged into this and it turned out that ttycreate() is called with
incompatible (means: incompatible to FreeBSD 7.0-REL) arguments:
*** nozomi.c 2008-05-05 08:05:54.000000000 +0200
--- nozomi.c.orig 2007-04-18 00:47:50.000000000 +0200
***************
*** 1070,1078 ****
tmptty->t_modem = nzmodem;
tmptty->t_ioctl = nzioctl;
tmptty->t_sc = sc;
! // see /usr/src/sys/kern/tty.c:
! device_printf(sc->dev, "ttycreate for /dev/cuaN%d\n", i);
! ttycreate(tmptty, TS_CALLOUT, "N%r", i);
sc->port[i].tty_devunit = tmptty->t_devunit;
sc->port[i].tty_open_count = 0;
}
--- 1070,1076 ----
tmptty->t_modem = nzmodem;
tmptty->t_ioctl = nzioctl;
tmptty->t_sc = sc;
! ttycreate(tmptty, NULL, 0, 0, "N%r", i);
sc->port[i].tty_devunit = tmptty->t_devunit;
sc->port[i].tty_open_count = 0;
}
This and the missing argument for bus_setup_intr() let me think that the
driver was not ported to FreeBSD 7.0-REL (don't know if this interface
changed from 6.x to 7.0, will have a look into some older server when
I'm at work); anyway, with the above small change th devices /dev/cuaN0,
to /dev/cuaN4 get created and /dev/cuaN0 works fine with kermit and
responses on AT commands, like for example ATI2 to read the vendor
information;
I fired up as well PPPD the sign-in to the network works well with the
following chat script:
'' +++
'' AT
OK\r at_opsys=1,2
OK\r at+CGQREQ=?
OK\r at+cpin="xxxx"
O AT+CGDCONT=1,"IP","web.vodafone.de"
OK\r ATD*99***1#
CONNECT
the LCP layer worked as well, IP comes up, got an IP addr, routing came
up fine; the things went wrong when real TCP should be send encapsulated in
PPP frames, then even the LCP echo requests come out of sync:
May 4 17:50:12 rebelion pppd[3055]: sent [LCP EchoReq id=0x1 magic=0x725825f7]
May 4 17:50:12 rebelion pppd[3055]: rcvd [LCP EchoRep id=0x1 magic=0x4a0ab1cb 0a 0b 0c 0e]
May 4 17:50:42 rebelion pppd[3055]: sent [LCP EchoReq id=0x2 magic=0x725825f7]
May 4 17:50:46 rebelion pppd[3055]: rcvd [LCP EchoRep id=0x2 magic=0x4a0ab1cb 0a 0b 0c 0e]
May 4 17:51:12 rebelion pppd[3055]: sent [LCP EchoReq id=0x3 magic=0x725825f7]
May 4 17:51:42 rebelion pppd[3055]: sent [LCP EchoReq id=0x4 magic=0x725825f7]
May 4 17:51:42 rebelion pppd[3055]: rcvd [LCP EchoRep id=0x4 magic=0x4a0ab1cb 0a 0b 0c 0e]
which let me think that data sent by PPPD is not sent out properly to
the air (to UMTS); PPPD opens the device /dev/cuaN0 and sets 230400 baud
with CRTSCTS control;
will see what I can find out by enabling the debug printf()'s
thx for your comments, Volker, if you have any idea what's wrong;
matthias
> I'm at work); ...
I have checked this in a box running FreeBSD 6.1-REL:
the arguments to be passed to ttycreate() has changed between 6.1-REL and 7.0-REL
and the call 'ttycreate(tmptty, NULL, 0, 0, "N%r", i)' would work on
6.1;
matthias