porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R

Niki Denev nike_d at cytexbg.com
Sat May 10 17:08:01 UTC 2008


On Sat, May 10, 2008 at 12:34 PM, Matthias Apitz <guru at sisis.de> wrote:
> El día Saturday, May 10, 2008 a las 12:49:02AM +1000, Ian Smith escribió:
>
>>  > Stevens explains further more that client and server could handshake to
>>  > omit the constant flag (7e) and adress field (ff) and reduce the
>>  > protocol field (0021) to one byte (21), but in the above packages 'flag' is there
>>  > while 'addr' and 'control' are missing?
>>  >
>>  > any PPP expert here to explain this? could this be the reason that the
>>  > connection gets stuck?
>>
>> Probably not the sort of help you wanted, and I'm no PPP expert, but
>> having run ppp(8) in and out for ten years and more recently mpd(8)
>> outbound, I have to ask, does this gig depend on using pppd?
>        ...
>
> I've checked a short moment mpd5(8) (installed it from the ports and
> checked the manual about configuration); it seems that it would me take
> some time to get the CHAT part working;
>
> because, on the other hand, my installed pppd(8) works just fine,
> with older UMTS cards, I don't think that this is the problem;
>
> I've spent some more hours as well on debugging and now I have it clear
> a) what the problem is with the TCP packages
> b) why LCP works just nicely
> c) why CHAT works as well nicely
> d) why telneting to the ECHO port works also if (and only if) you enter
>   only a few characters on the line, say up to five
>
> the problem is the size of the buffer coming down from user space in the
> nzstart() function:
>
>        ...
>        data = tty->t_outq.c_cf;
>        cbp = (struct cblock *) ((intptr_t) tty->t_outq.c_cf & ~CROUND);
>        cnt = min((char *) (cbp+1) - tty->t_outq.c_cf, tty->t_outq.c_cc);
>
>        if(cnt == 0)
>                goto out;
>
>        buf = malloc(sizeof(struct fifo_buf), M_DEVBUF, M_NOWAIT);
>        memcpy(buf->data, data, cnt < sizeof(buf->data) ? cnt : sizeof(buf->data));
>        buf->size = cnt;
>
>        printf("nzdebug: nzstart() -> STAILQ_INSERT_TAIL() of %d bytes\n", cnt);
>        STAILQ_INSERT_TAIL(&fifo_head, buf, fifo_bufs);
>        ndflush(&tty->t_outq, cnt);
>        intr_ul(sc, pidx, ENABLE);
>        ...
>
> I saw frames upto 108 bytes length;
>
> and later send_data(), which puts the data into the card's buffer, picks
> the data up like this:
>
>        buf = STAILQ_FIRST(&fifo_head);
>        size = buf->size;
>
>        memcpy(sc->send_buf, buf->data, ul_size < SEND_BUF_MAX ?  ul_size : SEND_BUF_MAX );
>
>        STAILQ_REMOVE_HEAD(&fifo_head, fifo_bufs);
>        free(buf, M_DEVBUF);
>
>        port->tx_data += size;
>
>        /* Write length + data */
>        bus_write_4(sc->res, ul_offs, size);
>        bus_write_region_4(sc->res, ul_offs + 4, (u_int32_t *)sc->send_buf, size);
>
> SEND_BUF_MAX is 1024 but the 'ul_size' (size of the up link part of the
> card) is only 68!! that's why parts of the PPP frames are just thrown
> away if the frame size is bigger than 64 (4 bytes are needed for the
> size); I got to know this comparing the hex dumps of the buffer in the
> nzstart() and send_data() parts;
>
> at the moment I have no idea how to fix this :-((
> I've put the driver here:
>
> http://www.unixarea.de/nozomi/nozomi.c
>
> if someone wants to have a look and give me some hint; thanks in advance;
>
> it's Saturday evening and sunny, time for go out...
>
>        matthias
>

I can see that this is the initial port of the Linux nozomi driver that i did
back in 2006, and i got stuck exactly with the same problem,
ppp connection get's established, but only small packets are passed.
I will see if I can get my hands on this HSDPA/UMTS card
(i don't have it anymore) and help.

Niki


More information about the freebsd-net mailing list