From owner-freebsd-drivers@FreeBSD.ORG Tue May 6 17:48:44 2008 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1FDD106564A for ; Tue, 6 May 2008 17:48:44 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: from hunter.Sisis.de (hunter.sisis.de [193.31.11.194]) by mx1.freebsd.org (Postfix) with ESMTP id 08C658FC0A for ; Tue, 6 May 2008 17:48:43 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: (from mail@localhost) by hunter.Sisis.de (8.8.8/8.8.8) id TAA09035 for ; Tue, 6 May 2008 19:37:26 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) Received: from ppp-93-104-123-77.dynamic.mnet-online.de(93.104.123.77) by hunter.Sisis.de via smap (V2.1) id xma008814; Tue, 6 May 08 19:36:30 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m46Hhx5E003802 for freebsd-drivers@freebsd.org; Tue, 6 May 2008 19:43:59 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Tue, 6 May 2008 19:43:59 +0200 From: Matthias Apitz To: freebsd-drivers@freebsd.org Message-ID: <20080506174359.GA2814@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-RELEASE (i386) Subject: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2008 17:48:44 -0000 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, here are both traces; you will see that the PPP outbound package (marked with ^^^^^^^^^^^^^^^^^) does not reach the server (and perhaps does not go out to UMTS) and the server is sending its SSH-good-morning string again and again because of missing ACK: TCPDUMP on PPPD site: 14:03:54.890785 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: S 3468691149:3468691149(0) win 65535 14:03:54.993387 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: S 1963911431:1963911431(0) ack 3468691150 win 5792 14:03:54.993445 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: . ack 1 win 8272 14:03:55.142728 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 14:03:55.142976 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: P 1:40(39) ack 24 win 8272 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 14:03:55.513520 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 14:03:55.513569 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: P 40:792(752) ack 24 win 8272 14:03:56.243482 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 14:03:56.243513 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: . ack 24 win 8272 14:03:57.460382 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: P 1:792(791) ack 24 win 8272 14:03:57.714044 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 14:03:57.714125 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: . ack 24 win 8272 14:04:00.643527 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 14:04:00.643564 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: . ack 24 win 8272 14:04:01.895706 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: P 1:792(791) ack 24 win 8272 14:04:03.594932 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: F 792:792(0) ack 24 win 8272 14:04:06.493335 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 14:04:06.493370 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: F 792:792(0) ack 24 win 8272 TCPDUMP on SSHD site (193.31.xxx.xxx): 15:03:21.929767 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: S 3468691149:3468691149(0) win 65535 15:03:21.930193 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: S 1963911431:1963911431(0) ack 3468691150 win 5792 15:03:22.050901 IP 77.25.44.116.58392 > 193.31.xxx.xxx.22: . ack 1 win 8272 15:03:22.079679 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 15:03:22.444768 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 15:03:23.176653 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 15:03:24.640438 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 15:03:27.567996 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 15:03:33.423109 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 15:03:45.133330 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 15:04:08.553772 IP 193.31.xxx.xxx.22 > 77.25.44.116.58392: P 1:24(23) ack 1 win 1448 I've instructed the source with printf's in the sending code, which looks like this: 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); and the resulting log is this (I've marked what the output contains): May 6 14:03:21 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 1 bytes <-- PPPD chat to network May 6 14:03:21 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 1 bytes <-- PPPD chat to network May 6 14:03:21 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 1 bytes <-- PPPD chat to network May 6 14:03:21 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 1 bytes <-- PPPD chat to network May 6 14:03:21 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 1 bytes <-- PPPD chat to network May 6 14:03:21 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 1 bytes <-- PPPD chat to network May 6 14:03:27 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 45 bytes <-- LCP May 6 14:03:27 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 55 bytes <-- LCP May 6 14:03:27 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:27 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 41 bytes <-- LCP May 6 14:03:27 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:28 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:29 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:30 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:31 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:32 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:32 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 16 bytes <-- LCP May 6 14:03:32 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 10 bytes <-- LCP May 6 14:03:54 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 65 bytes <-- TCP SYN May 6 14:03:55 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 57 bytes <-- TCP ACK May 6 14:03:55 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 96 bytes <-- TCP 39 byte which does not go out May 6 14:03:55 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 108 bytes May 6 14:03:55 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 108 bytes May 6 14:03:56 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 108 bytes May 6 14:03:56 Rebelion kernel: nzdebug: STAILQ_INSERT_TAIL() inserting 108 bytes the full source and its Makefile are here: http://www.unixarea.de/nozomi/nozomi.c http://www.unixarea.de/nozomi/Makefile Any idea about what could be wrong is pretty much welcome; thanks in advance; The source is GPL'ed and can not be taken in this form into FreeBSD; 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 - 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? From owner-freebsd-drivers@FreeBSD.ORG Fri May 9 12:47:27 2008 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D07B106564A; Fri, 9 May 2008 12:47:27 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id F35938FC0A; Fri, 9 May 2008 12:47:26 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([193.31.10.34]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 14:38:26 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m49CZLtL012385; Fri, 9 May 2008 14:35:21 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Fri, 9 May 2008 14:35:21 +0200 From: Matthias Apitz To: freebsd-drivers@freebsd.org, freebsd-net@freebsd.org Message-ID: <20080509123521.GA11366@rebelion.Sisis.de> References: <20080506174359.GA2814@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080506174359.GA2814@rebelion.Sisis.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-RELEASE (i386) X-OriginalArrivalTime: 09 May 2008 12:38:26.0419 (UTC) FILETIME=[93B0FC30:01C8B1D1] Cc: Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2008 12:47:27 -0000 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 - 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? From owner-freebsd-drivers@FreeBSD.ORG Fri May 9 15:27:08 2008 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82066106564A for ; Fri, 9 May 2008 15:27:08 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8ADBD8FC0C for ; Fri, 9 May 2008 15:27:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with ESMTP id AAA21020; Sat, 10 May 2008 00:49:03 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 10 May 2008 00:49:02 +1000 (EST) From: Ian Smith To: Matthias Apitz In-Reply-To: <20080509123521.GA11366@rebelion.Sisis.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2008 15:27:08 -0000 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) From owner-freebsd-drivers@FreeBSD.ORG Sat May 10 16:38:07 2008 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 760371065671; Sat, 10 May 2008 16:38:07 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: from hunter.Sisis.de (mail.oclc.de [193.31.11.194]) by mx1.freebsd.org (Postfix) with ESMTP id 90CF18FC16; Sat, 10 May 2008 16:38:06 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: (from mail@localhost) by hunter.Sisis.de (8.8.8/8.8.8) id SAA00281; Sat, 10 May 2008 18:27:12 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) Received: from ppp-88-217-95-224.dynamic.mnet-online.de(88.217.95.224) by hunter.Sisis.de via smap (V2.1) id xma000146; Sat, 10 May 08 18:26:50 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m4AGYHwL018619; Sat, 10 May 2008 18:34:17 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Sat, 10 May 2008 18:34:17 +0200 From: Matthias Apitz To: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org Message-ID: <20080510163417.GA17718@rebelion.Sisis.de> References: <20080509123521.GA11366@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-RELEASE (i386) Cc: Ian Smith Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 16:38:07 -0000 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 From owner-freebsd-drivers@FreeBSD.ORG Sat May 10 17:35:46 2008 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E83E1065675 for ; Sat, 10 May 2008 17:35:46 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA158FC16 for ; Sat, 10 May 2008 17:35:45 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3004830rvf.43 for ; Sat, 10 May 2008 10:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=CFXAzyeY1HvgpUK1XvVFxEliU3x6CcfCs/ylYUH19Mw=; b=IDeEutc8uEwfaaQo29KD3uJBL83LVfqW/jk5I2nZ5HXTiquvF2xPzYDUn5Z8rADpHhgh7K2Hx84nggNEJUuGhUBLMgzy3KWrEdb3u6pGXbIfciMuADCH5gkE3n/MUFuEA8OPwVzkr1Rt63wpnL2IqF7EhbjlOLxHTk0I/fgaBTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=r79E9hp+XoLO2kPuAU4aEInM05MJefYzegTuFGmYayY84NF1Zxngsp9zS4mn8GurpAKiIHX5ErGeWebGH2JS4inLRdXNftNu82i6p4x+4E5dSrZRNpHe7roSMTP7X5Hu2Hl8AQhsPlnvbOLRp6ocFWgyB1o6ksovvm0JteaNTw8= Received: by 10.140.249.20 with SMTP id w20mr2797345rvh.103.1210439280118; Sat, 10 May 2008 10:08:00 -0700 (PDT) Received: by 10.141.171.3 with HTTP; Sat, 10 May 2008 10:08:00 -0700 (PDT) Message-ID: <2e77fc10805101008ybafe7b3g8b9210cb8d2955d@mail.gmail.com> Date: Sat, 10 May 2008 13:08:00 -0400 From: "Niki Denev" Sender: ndenev@gmail.com To: "Matthias Apitz" In-Reply-To: <20080510163417.GA17718@rebelion.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20080509123521.GA11366@rebelion.Sisis.de> <20080510163417.GA17718@rebelion.Sisis.de> X-Google-Sender-Auth: 3ca67c6bdfd94d7b Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org, Ian Smith Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 17:35:46 -0000 On Sat, May 10, 2008 at 12:34 PM, Matthias Apitz wrote: > El d=EDa Saturday, May 10, 2008 a las 12:49:02AM +1000, Ian Smith escribi= =F3: > >> > 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 'fl= ag' is there >> > while 'addr' and 'control' are missing? >> > >> > any PPP expert here to explain this? could this be the reason that th= e >> > 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 =3D tty->t_outq.c_cf; > cbp =3D (struct cblock *) ((intptr_t) tty->t_outq.c_cf & ~CROUND); > cnt =3D min((char *) (cbp+1) - tty->t_outq.c_cf, tty->t_outq.c_cc)= ; > > if(cnt =3D=3D 0) > goto out; > > buf =3D malloc(sizeof(struct fifo_buf), M_DEVBUF, M_NOWAIT); > memcpy(buf->data, data, cnt < sizeof(buf->data) ? cnt : sizeof(buf= ->data)); > buf->size =3D 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 =3D STAILQ_FIRST(&fifo_head); > size =3D 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 +=3D 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 d= id 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