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

[Ian Smith]

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:
 > > 
 > > http://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)