From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28717 invoked by alias); 15 Jun 2004 21:36:53 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 28709 invoked from network); 15 Jun 2004 21:36:51 -0000 Received: from unknown (HELO mail.broadpark.no) (217.13.4.2) by sourceware.org with SMTP; 15 Jun 2004 21:36:51 -0000 Received: from famine (217-13-20-38.dd.nextgentel.com [217.13.20.38]) by mail.broadpark.no (Postfix) with ESMTP id 429911128; Tue, 15 Jun 2004 23:37:14 +0200 (MEST) From: =?ISO-8859-1?Q?=D8yvind?= Harboe To: ecos-discuss@ecos.sourceware.org, klawson@ad-holdings.co.uk In-Reply-To: <1087322512.28254.ezmlm@ecos.sourceware.org> References: <1087322512.28254.ezmlm@ecos.sourceware.org> Content-Type: text/plain; charset=ISO-8859-1 Organization: Zylin AS Message-Id: <1087335408.28465.10.camel@famine> Mime-Version: 1.0 Date: Tue, 15 Jun 2004 21:36:00 -0000 Content-Transfer-Encoding: 8bit Subject: [ECOS] Problems with ppp and Windows X-SW-Source: 2004-06/txt/msg00141.txt.bz2 > I've just had what appears to be the same problem as this. accept() > wasn't returning until the client killed the telnet process. This is precisely what I observed. > However in my case it was the same with Windows or Linux clients. When you say "client", are you referring to the machine on which the telnet session is launched? I find that the problem is with a Windows PPP *server*. It doesn't matter whether or not I start the telnet session from Windows or Linux. > What it boiled down to was a lack of network buffers. pppalloc() > allocates some memory for VJ compression, but in my case the > cyg_net_malloc() failed. This breaks the VJ compression for the PPP > connection (sc->sc_comp == NULL). I will most certainly take this for a spin to see if I'm running into the same problem. > When a client (e.g. Telnet on Windows) connected to my server process in > eCos, the first packet of the TCP handshake (SYN) came in uncompressed. > eCos responded with SYN ACK, and then the client sent the final part > (ACK), but this time with protocol VJC_UNCOMP. ppp_inproc() tries to > handle the VJC, but fails because VJC was not initialised correctly > (sc->sc_comp == NULL). > > So because VJC is not initialised properly, the final packet of the 3 > way handshake always fails at ppp_inproc(). It never makes it up into > the IP/TCP stack, and therefore the server thread is never woken up from > sleeping in accept(). eCos keeps resending SYN ACK to the client, and > the client keeps resending the final ACK. > > I'm not sure if this will be your problem, but it's worth a go. Try > adding some more memory to CYGPKG_NET_MEM_USAGE. The VJC structure needs > a little over 4KB on my target. You can confirm whether this is your > problem by checking the result of the MALLOC in pppalloc(). I've been toying with PPP on an EB40a card board, which only has 256kbytes of memory. I've set CYGPKG_NET_MEM_USAGE = ~90k. > Cheers, > Kelvin. Its great to have some feedback on this one! Thanks! :-) > > ______________________________________________________________________ -- Øyvind Harboe http://www.zylin.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss