From owner-freebsd-net@FreeBSD.ORG Sat May 10 17:08:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BEF11065674 for ; Sat, 10 May 2008 17:08:01 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id BFA818FC17 for ; Sat, 10 May 2008 17:08:00 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2995967rvf.43 for ; Sat, 10 May 2008 10:08:00 -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-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 17:08:01 -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