From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9022 invoked by alias); 15 Jun 2004 10:30:55 -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 9003 invoked from network); 15 Jun 2004 10:30:53 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by sourceware.org with SMTP; 15 Jun 2004 10:30:53 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BaBDM-00015c-00 for ; Tue, 15 Jun 2004 12:30:50 +0200 Received: from 62.24.130.166 ([62.24.130.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jun 2004 12:30:48 +0200 Received: from klawson by 62.24.130.166 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jun 2004 12:30:48 +0200 To: ecos-discuss@sources.redhat.com From: Kelvin Lawson Date: Tue, 15 Jun 2004 10:30:00 -0000 Message-ID: References: <1082637454.19993.21.camel@famine> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.24.130.166 User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) In-Reply-To: <1082637454.19993.21.camel@famine> Subject: [ECOS] Re: Problems with ppp and Windows X-SW-Source: 2004-06/txt/msg00134.txt.bz2 Hi Øyvind, > - the problem is that accept() in the attached application does not wake > up until I kill the telnet process. I'm pretty confident that this app > is correct, because it works when I compile and runit from CygWin. > - Debugging TCP/IP is really difficult without an in depth knowledge of > TCP/IP and the freebsd stack. However, I believe that accept() should be > awoken by the invocation of soisconnected() from tcp_input.c since this > is what happens when I kill the windows telnet process. I don't know > what the significance, if any, it is that TCPOPT_CC is not received and > hence a "3 way handshake" is to be used instead. I've just had what appears to be the same problem as this. accept() wasn't returning until the client killed the telnet process. However in my case it was the same with Windows or Linux clients. 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). 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(). Cheers, Kelvin. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss