On Sat, May 10, 2008 at 12:34 PM, Matthias Apitz <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
