Date: Fri, 9 May 2008 14:35:21 +0200 From: Matthias Apitz <guru@Sisis.de> To: freebsd-drivers@freebsd.org, freebsd-net@freebsd.org Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R Message-ID: <20080509123521.GA11366@rebelion.Sisis.de> In-Reply-To: <20080506174359.GA2814@rebelion.Sisis.de> References: <20080506174359.GA2814@rebelion.Sisis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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.apitz@oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080509123521.GA11366>