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?