[ECOS] Problems with ppp and Windows

[ECOS] Problems with ppp and Windows

[Øyvind Harboe]

> 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

[ECOS] Re: Problems with ppp and Windows

[Kelvin Lawson]

Hi Øyvind,

>>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.
> 
> 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.

By client I mean the machine from which the Telnet session is launched. 
I get the same problem using a Windows or Linux Telnet client (or FTP or 
anything that contacts an eCos server sitting in accept()). I also had 
the same problem whether the PPP session itself was between eCos and 
Win2k or between eCos and Linux. I can't imagine it makes any difference 
whether eCos "dials up" the other end, or visa versa.

I'm surprised that this is only a problem connecting with Windows via 
PPP. Was there anything different about your setup when you connected to 
Linux ? Maybe on your Windows configuration the eCos target had an 
Ethernet interface up as well ? (that will use up a few network 
buffers). Or is your Linux PPPD perhaps running with the "novj" option ?


>>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.

If you need to save some RAM, perhaps an alternative would be to disable 
VJ compression. On a brief look in ipcp.c it looks like it's possible to 
refuse by setting neg_vj = 0. Presumably there will be a few other 
tweaks around the PPP code to handle this properly.

It would be nice to handle the failed slcompress MALLOC by refusing to 
negotiate VJ compression. Either that or a big printf/assert on the 
failed MALLOC would have saved me a few hours debugging.

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

[ECOS] Problems with ppp and Windows

[Øyvind Harboe]

Ah! progress!

After your tip about running out of memory(which I really 
should have figured out on my own!), I finally bit the bullit and
configured my EB40a with the AT91MEC board. This gives me 2MB of ram.

I'm now able to connect and get my telnet session going aginst Windows 
and Linux PPP servers. Although I haven't investigated, the difference between
Linux and Windows PPP servers is probably that Windows causes the eCos PPP client 
to use a tiny bit of extra memory.  I'll be playing around with PPP on my AT91MEC powered EB40a.

What now?

As you point out in http://ecos.sourceware.org/ml/ecos-discuss/2004-06/msg00144.html, 
there are really two areas worthy of attention: debugging and memory usage.

- eCos could be a bit more friendly with the developer when running out of memory. Perhaps
there are suitable facilities for detecting these situations. 
In addition to the suggestions you made, perhaps it would be a good idea to add a fn that
is invoked by the memory allocator when running out of memory? By default this could be
an empty fn(handy breakpoint site), and the application could override it with something
else(e.g. reset the board, invoke debugger, etc.).

- reduce memory requirements for PPP and freebsd networking stack. 

- It is a bit hard to *know* how much memory is required. It would be nice to have a simple
way of figuring this out at compile time.

-- 
Ø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

[ECOS] Re: Problems with ppp and Windows

[Kelvin Lawson]

Hi Øyvind,

> Ah! progress!

Excellent!

> - eCos could be a bit more friendly with the developer when running out of memory. Perhaps
> there are suitable facilities for detecting these situations. 
> In addition to the suggestions you made, perhaps it would be a good idea to add a fn that
> is invoked by the memory allocator when running out of memory? By default this could be
> an empty fn(handy breakpoint site), and the application could override it with something
> else(e.g. reset the board, invoke debugger, etc.).

Yes, sounds fine. In my case I'd be happy with just a debug message or 
assert in cyg_net_malloc() when not enough memory is available. I would 
think this should be a build option, rather than a default operation.

I think the proper place to add some debug notification is at the usage 
points of network mallocs. In the case of PPP, after the MALLOC() 
failed, it ought to have done something about it or printed some debug, 
rather than just carrying on broken.

> - reduce memory requirements for PPP and freebsd networking stack. 

For PPP there are a bunch of configuration options that aren't covered 
by the cyg_ppp_options_t structure. I've added a few options here to 
handle authorisation for dialin connections. Similarly you could extend 
it to disable things like VJ compression to reduce the memory requirements.

> - It is a bit hard to *know* how much memory is required. It would be nice to have a simple
> way of figuring this out at compile time.

Difficult to gauge in advance I would think. Perhaps someone could 
comment on where the default calculation comes from 
(256*1024)+(MAXSOCKETS*1024) ? On my system this was enough for one 
Ethernet device and plenty of connections. But it wasn't enough when 
adding PPP to the mix (unless I disabled eth0).

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

[ECOS] Re: Problems with ppp and Windows

[Øyvind Harboe]

> Yes, sounds fine. In my case I'd be happy with just a debug message or 
> assert in cyg_net_malloc() when not enough memory is available. I would 
> think this should be a build option, rather than a default operation.

I've put together a memory allocation debug feature patch... 

http://ecos.sourceware.org/ml/ecos-discuss/2004-06/msg00161.html

Notice the complication that the networking stack sometimes goes to
sleep waiting for more memory to become availble. I've done my best to
allow for setting a breakpoint for the case where a function does not
return :-)



> I think the proper place to add some debug notification is at the usage 
> points of network mallocs. In the case of PPP, after the MALLOC() 
> failed, it ought to have done something about it or printed some debug, 
> rather than just carrying on broken.

Does it make any sense at all to bring up the PPP connection if these
initial allocations fail?

Note that I saw the lockup on accept() even if the VJC compression
buffers could be allocated.

> > - reduce memory requirements for PPP and freebsd networking stack. 
> 
> For PPP there are a bunch of configuration options that aren't covered 
> by the cyg_ppp_options_t structure. I've added a few options here to 
> handle authorisation for dialin connections. Similarly you could extend 
> it to disable things like VJ compression to reduce the memory requirements.

Care to share? :-)

> > - It is a bit hard to *know* how much memory is required. It would be nice to have a simple
> > way of figuring this out at compile time.
> 
> Difficult to gauge in advance I would think.

It may be difficult, but I can't imagine it being anything but
absolutely necessary to know in advance.


-- 
Ø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

[ECOS] Re: Problems with ppp and Windows

[Kelvin Lawson]

Hi Øyvind,

> I've put together a memory allocation debug feature patch... 
> 
> http://ecos.sourceware.org/ml/ecos-discuss/2004-06/msg00161.html

It looks useful, thanks for that.

>>I think the proper place to add some debug notification is at the usage 
>>points of network mallocs. In the case of PPP, after the MALLOC() 
>>failed, it ought to have done something about it or printed some debug, 
>>rather than just carrying on broken.
> 
> Does it make any sense at all to bring up the PPP connection if these
> initial allocations fail?

Well that depends. If only a VJC allocation fails then it may be 
possible to bring up a PPP interface that refuses to negotiate VJC. I 
don't know if we really need to worry about providing this kind of 
fallback operation though.

> Note that I saw the lockup on accept() even if the VJC compression
> buffers could be allocated.

Your generic malloc fail patch should be pretty useful then, to catch 
any kind of allocation failing.

>>For PPP there are a bunch of configuration options that aren't covered 
>>by the cyg_ppp_options_t structure. I've added a few options here to 
>>handle authorisation for dialin connections. Similarly you could extend 
>>it to disable things like VJ compression to reduce the memory requirements.
> 
> Care to share? :-)

Certainly. I'm just experimenting with it at the moment though, so I'm 
not yet confident that it should go into the eCos tree. But in the 
meantime if you want to investigate, here's a summary:

. Set auth_required = 1 if you want to require authentication from the 
other end.
. Set wo->neg_chap and wo->neg_upap to 1 depending on which you want to 
use for authentication (see lcp.c)
. You can extend cyg_ppp_options_t to accomodate the above 3 options.
. Finally fix up the functions in auth.c to do your username/password 
lookup (maybe you want them in a fixed array, or read a password file 
off a disk or whatever). For CHAP, you can use get_secret() to look up 
the user/pass. For PAP, use check_passwd(), ensuring that 
have_pap_secret() returns 1. Also think about whether you will accept 
the IPs offered by the peer, and see function ip_addr_check().

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

[ECOS] Problems with ppp and Windows

[Øyvind Harboe]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

I've run out of food and drink. This will be my last note in my log :-)

- 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. 
- As near as I can tell, Windows believes it is connected, because I
receive packets in my eCos application for the text I typed into the
telnet session before I kill the telnet process.
- I've submitted various patches lately in this regard, but nothing
earthshattering.


Attached: echo.c CygWin/Linux echo app. Same code gets stuck on accept()
w/PPP, Windows PPP server when running under eCos.

-- 

Øyvind Harboe
http://www.zylin.com



[-- Attachment #2: echo.c --]
[-- Type: text/x-c, Size: 1341 bytes --]


#include	<netdb.h>
#include	<netinet/in.h>
#include	<sys/types.h>
#include	<sys/socket.h>
#include	<stdio.h>
#include	<time.h>
#include	<signal.h>
#include	<string.h>


int main()
{
	int 	 sd, sd_current;
	struct   sockaddr_in sin;
	struct   sockaddr_in pin;
 
	/* get an internet domain socket */
	if ((sd = socket(AF_INET, SOCK_STREAM, 0)) != -1) 
	{
		/* complete the socket structure */
		memset(&sin, 0, sizeof(sin));
		sin.sin_family = AF_INET;
		sin.sin_addr.s_addr = INADDR_ANY;
		sin.sin_port = htons(23);

		/* bind the socket to the port number */
		if (bind(sd, (struct sockaddr *) &sin, sizeof(sin)) != -1) 
		{
			/* show that we are willing to listen */
			if (listen(sd, SOMAXCONN) != -1) 
			{
				/* wait for a client to talk to us */
			    socklen_t addrlen = sizeof(pin);
				if ((sd_current = accept(sd, (struct sockaddr *)  &pin, &addrlen)) != -1) 
				{
					for (;;)
					{
						/* get a message from the client */
						char dir[10];
						int len;
						len=recv(sd_current, dir, sizeof(dir), 0);
						if (len == -1) 
						{
							break;
						}
					
						/* acknowledge the message, reply w/ the file names */
						if (send(sd_current, dir, len, 0) != len) 
						{
							break;
						}
					}
		    	    /* close up both sockets */
					close(sd_current); 
				}
			}
		}
		close(sd);
	}
	return 0;
}



[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Problems with ppp and Windows

[Kelvin Lawson]

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