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

El día Tuesday, May 06, 2008 a las 07:43:59PM +0200,
Matthias Apitz escribió:

> 
> Hello,
> 
> I'm on the way to port the above mentioned driver to
FreeBSD 7.0-REL;
> the work is based on the Linux driver of this card and
of some help I've
> got in frebsd-mobile, see thread:
> 
> ht
tp://groups.google.com/group/muc.lists.freebsd.mobile/browse
_thread/thread/6e4b18d5d292b0a7/0b1f42404c982b8e
> 
> the current state of the work is:
> 
> - driver attaches fine to the card on insert;
> - devices come up as /dev/cuaN0...4;
> - serial communication with, for example, kermit to
/dev/cuaN0 is fine;
> - PPPD can chat with AT-cmd's into UMTS network and
sign on;
> - LCP layer is fine, IP comes up, routing, etc;
> - with real TCP traffic the communication gets stuck,
for example with
>   SSH from the PPPD-laptop to some server in my
network;
> 
> I've watched with TCPDUMP the interface ppp0 of the
laptop and the eth0 of
> the server at the same time, ...

Hello,

without going into the details of the TCPDUMP, it shows that
the
three-way-handshake (SYN-SYN-ACK) is fine, the 1st data pkg
from SSH
server arrives, but the answer from PPPD with the ACK is
only to be seen
in the TCPDUMP on the PPPD site and does not arrive at
server;

I've instructed the driver to log a lot of stuff, and as
well the
contents of the buffers send to the card ... and compared
them against
the PPP specs I have handy in the TCP/IP Illustraded, Volume
I, from
Stevens;

for the LCP packages the frame look like this:

7e ff 03 c0 21 09 00 00 08 b7 b4 30 0b 54 b9 7e

7e    -- flag
ff    -- addr, always ff
03    -- control, always 03
c0 21 -- protocol, here LCP

and the frame ends with 7e, ok;

for the IP datagram containing the 1st (outgoing) SYN it
looks like:

7e 21 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f
0b c8 cc
fe 00 16 16 b9 37 7d 5d 00 00 00 00 a0 02 ff ff ef 58 00 00
02 04 05
b4 01 03 03 03 04 02 08 0a 00 1a 93 8e 00 00 00 00 79 f2 7e


7e    -- flag
21    -- ??? (could be part of 0021 indicating IP datagram)
45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8
-- IP header already
                                    4d 19 8f b7            
-- src addr 77.25.143.183
				                c1 1f 0b c8 -- dst addr

as well the ACK of SYN-SYN-ACK goes out like this:

7e 21 45 00 00 34 00 aa 40 00 40 06 90 62 4d 19 8f b7 c1 1f
0b c8 ...

and also the 1st real data (containing the protocol string
of the SSH client
looks like this:

7e 21 45 00 00 5b 00 af 40 00 40 06 90 36 4d 19 8f b7 c1 1f
0b c8 cc
fe 00 16 16 b9 37 7d 5e c5 c8 fd cc 80 18 20 50 04 fd 00 00
01 01 08
0a 00 1a 95 9e 4b 36 fd 6c 53 53 48 2d 32 2e 30 2d 4f 70 65
6e 53 53
48 5f 34 2e 35 70 31 20 46 72 65 65 42 53 44 2d 32 30 30 36
31 31 31
30 0a f1 62 7e

shouldn't they start with

7e ff 03 00 21 ...

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?

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 <matthias.apitzoclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
b http://gurucubano.blo
gspot.com/
Don't top-post, read RFC1855 http://www.faqs
.org/rfcs/rfc1855.html
A: Because it messes up the order in which people normally
read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on Usenet and in e-mail?
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

On Fri, 9 May 2008, Matthias Apitz wrote:
 > El día Tuesday, May 06, 2008 a las 07:43:59PM +0200,
Matthias Apitz escribió:
 > 
 > > 
 > > Hello,
 > > 
 > > I'm on the way to port the above mentioned driver
to FreeBSD 7.0-REL;
 > > the work is based on the Linux driver of this
card and of some help I've
 > > got in frebsd-mobile, see thread:
 > > 
 > > ht
tp://groups.google.com/group/muc.lists.freebsd.mobile/browse
_thread/thread/6e4b18d5d292b0a7/0b1f42404c982b8e
 > > 
 > > the current state of the work is:
 > > 
 > > - driver attaches fine to the card on insert;
 > > - devices come up as /dev/cuaN0...4;
 > > - serial communication with, for example, kermit
to /dev/cuaN0 is fine;
 > > - PPPD can chat with AT-cmd's into UMTS network
and sign on;
 > > - LCP layer is fine, IP comes up, routing, etc;
 > > - with real TCP traffic the communication gets
stuck, for example with
 > >   SSH from the PPPD-laptop to some server in my
network;
 > > 
 > > I've watched with TCPDUMP the interface ppp0 of
the laptop and the eth0 of
 > > the server at the same time, ...
 > 
 > Hello,
 > 
 > without going into the details of the TCPDUMP, it
shows that the
 > three-way-handshake (SYN-SYN-ACK) is fine, the 1st
data pkg from SSH
 > server arrives, but the answer from PPPD with the ACK
is only to be seen
 > in the TCPDUMP on the PPPD site and does not arrive at
server;
 > 
 > I've instructed the driver to log a lot of stuff, and
as well the
 > contents of the buffers send to the card ... and
compared them against
 > the PPP specs I have handy in the TCP/IP Illustraded,
Volume I, from
 > Stevens;
 > 
 > for the LCP packages the frame look like this:
 > 
 > 7e ff 03 c0 21 09 00 00 08 b7 b4 30 0b 54 b9 7e
 > 
 > 7e    -- flag
 > ff    -- addr, always ff
 > 03    -- control, always 03
 > c0 21 -- protocol, here LCP
 > 
 > and the frame ends with 7e, ok;
 > 
 > for the IP datagram containing the 1st (outgoing) SYN
it looks like:
 > 
 > 7e 21 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7
c1 1f 0b c8 cc
 > fe 00 16 16 b9 37 7d 5d 00 00 00 00 a0 02 ff ff ef 58
00 00 02 04 05
 > b4 01 03 03 03 04 02 08 0a 00 1a 93 8e 00 00 00 00 79
f2 7e
 > 
 > 
 > 7e    -- flag
 > 21    -- ??? (could be part of 0021 indicating IP
datagram)
 > 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f
0b c8 -- IP header already
 >                                     4d 19 8f b7       
     -- src addr 77.25.143.183
 > 				                c1 1f 0b c8 -- dst addr
 > 
 > as well the ACK of SYN-SYN-ACK goes out like this:
 > 
 > 7e 21 45 00 00 34 00 aa 40 00 40 06 90 62 4d 19 8f b7
c1 1f 0b c8 ...
 > 
 > and also the 1st real data (containing the protocol
string of the SSH client
 > looks like this:
 > 
 > 7e 21 45 00 00 5b 00 af 40 00 40 06 90 36 4d 19 8f b7
c1 1f 0b c8 cc
 > fe 00 16 16 b9 37 7d 5e c5 c8 fd cc 80 18 20 50 04 fd
00 00 01 01 08
 > 0a 00 1a 95 9e 4b 36 fd 6c 53 53 48 2d 32 2e 30 2d 4f
70 65 6e 53 53
 > 48 5f 34 2e 35 70 31 20 46 72 65 65 42 53 44 2d 32 30
30 36 31 31 31
 > 30 0a f1 62 7e
 > 
 > shouldn't they start with
 > 
 > 7e ff 03 00 21 ...
 > 
 > 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?

Just that in that time I've seen very few people using pppd
except some
people just coming over from linux, or those hoping to use
kde's dialer,
and have noticed little success reported with apparent pppd
bugs.

Almost invariably people seem better advised to use ppp or
more lately
mpd instead, if only because quite a few people here can
resolve config
and usage problems with either, whereas pppd appears to have
been all
but deprecated for some years - but perhaps I do it an
injustice.

HTH, Ian  (subscribed only to -net)

_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

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 bytesn", 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.uni
xarea.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

_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

On Sat, May 10, 2008 at 12:34 PM, Matthias Apitz
<gurusisis.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 bytesn", 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.uni
xarea.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-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"