Date: Sat, 10 May 2008 18:34:17 +0200 From: Matthias Apitz <guru@Sisis.de> To: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org Cc: Ian Smith <smithi@nimnet.asn.au> Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R Message-ID: <20080510163417.GA17718@rebelion.Sisis.de> In-Reply-To: <Pine.BSF.3.96.1080510002225.18341A-100000@gaia.nimnet.asn.au> References: <20080509123521.GA11366@rebelion.Sisis.de> <Pine.BSF.3.96.1080510002225.18341A-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080510163417.GA17718>