This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Problems with ppp and Windows
- From: Kelvin Lawson <klawson at ad-holdings dot co dot uk>
- To: ecos-discuss at sources dot redhat dot com
- Date: Tue, 15 Jun 2004 11:28:58 +0100
- Subject: [ECOS] Re: Problems with ppp and Windows
- References: <1082637454.19993.21.camel@famine>
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