[ECOS] Problems with ppp and Windows

[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

Re: [ECOS] Problems with ppp and Windows - Checked by AntiVir DEMO vers

[Roland Caßebohm]

Hello,

I don't know if this could be the problem, but in my codes I 
also initialize the sin_len member of the sockaddr_in 
structure like:

sin.sin_len = sizeof(sin);

Although I know that under Linux the structure seems not to 
have this member.

I remember that I had some problems under eCos without doing 
this, but I don't remember which problems.

Best regards,
Roland

Am Donnerstag, 22. April 2004 14:37 schrieb Øyvind Harboe:
> 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.

-- 

___________________________________________________

VS Vision Systems GmbH, Industrial Image Processing
Dipl.-Ing. Roland Caßebohm
Aspelohe 27A, D-22848 Norderstedt, Germany
Mail: roland.cassebohm@visionsystems.de
http://www.visionsystems.de
___________________________________________________


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

Re: [ECOS] Problems with ppp and Windows - Checked by AntiVir DEMO vers

[Øyvind Harboe]

tor, 22.04.2004 kl. 17.13 skrev Roland Caßebohm:
> Hello,
> 
> I don't know if this could be the problem, but in my codes I 
> also initialize the sin_len member of the sockaddr_in 
> structure like:
> 
> sin.sin_len = sizeof(sin);

I do as well in my eCos code.

The example I attached to my email was modified to compile under CygWin.


-- 

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

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

[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] 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] Problems with ppp and Windows

[Øyvind Harboe]

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

I did one more test:

- accept() does not hang when eCos ppp connects to a pppd server under
Linux(knoppix). 
- The TCPOPT_CC is not received by eCos ppp when connecting to pppd
Linux.
- Linux log from successful connect from eCos ppp to to pppd server
attached.


-- 

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



[-- Attachment #2: syslog.txt --]
[-- Type: text/plain, Size: 4866 bytes --]

Apr 22 07:34:34 gremlin pppd[1999]: pppd 2.4.2 started by knoppix, uid 1000
Apr 22 07:34:34 gremlin chat[2000]: expect (CLIENTCLIENT)
Apr 22 07:35:01 gremlin anacron[1919]: Job `cron.daily' started
Apr 22 07:35:01 gremlin anacron[2019]: Updated timestamp for job `cron.daily' to 2004-04-22
Apr 22 07:35:03 gremlin chat[2000]: CLIENTCLIENT
Apr 22 07:35:03 gremlin chat[2000]:  -- got it 
Apr 22 07:35:03 gremlin chat[2000]: send (CLIENTSERVER)
Apr 22 07:35:04 gremlin pppd[1999]: Serial connection established.
Apr 22 07:35:04 gremlin pppd[1999]: using channel 18
Apr 22 07:35:04 gremlin pppd[1999]: Using interface ppp0
Apr 22 07:35:04 gremlin pppd[1999]: Connect: ppp0 <--> /dev/ttyS0
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [LCP ConfReq id=0x1 <magic 0x575266ea> <pcomp> <accomp>]
Apr 22 07:35:04 gremlin pppd[1999]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Apr 22 07:35:04 gremlin pppd[1999]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x842dce14> <pcomp> <accomp>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [LCP ConfAck id=0x1 <magic 0x575266ea> <pcomp> <accomp>]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x842dce14> <pcomp> <accomp>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [LCP EchoReq id=0x0 magic=0x842dce14]
Apr 22 07:35:04 gremlin pppd[1999]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.222.117>]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [LCP EchoReq id=0x0 magic=0x575266ea]
Apr 22 07:35:04 gremlin pppd[1999]: sent [LCP EchoRep id=0x0 magic=0x842dce14]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [IPCP ConfNak id=0x1 <addr 192.168.222.206>]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [LCP EchoRep id=0x0 magic=0x575266ea]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [CCP ConfReq id=0x1]
Apr 22 07:35:04 gremlin pppd[1999]: sent [CCP ConfAck id=0x1]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [CCP ConfRej id=0x1 <deflate 15>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [CCP ConfReq id=0x2 <deflate(old#) 15> <bsd v1 15>]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 192.168.222.117>]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [IPCP ConfReq id=0x2 <addr 192.168.222.206> <compress VJ 0f 01>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [IPCP ConfAck id=0x2 <addr 192.168.222.206> <compress VJ 0f 01>]
Apr 22 07:35:04 gremlin pppd[1999]: found interface eth0 for proxy arp
Apr 22 07:35:04 gremlin pppd[1999]: local  IP address 192.168.222.117
Apr 22 07:35:04 gremlin pppd[1999]: remote IP address 192.168.222.206
Apr 22 07:35:04 gremlin pppd[1999]: Script /etc/ppp/ip-up started (pid 2036)
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [CCP ConfRej id=0x2 <deflate(old#) 15>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [CCP ConfReq id=0x3 <bsd v1 15>]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [CCP ConfRej id=0x3 <bsd v1 15>]
Apr 22 07:35:04 gremlin pppd[1999]: sent [CCP ConfReq id=0x4]
Apr 22 07:35:04 gremlin pppd[1999]: rcvd [CCP ConfAck id=0x4]
Apr 22 07:35:05 gremlin pppd[1999]: Script /etc/ppp/ip-up finished (pid 2036), status = 0x0
Apr 22 07:37:34 gremlin pppd[1999]: No response to 4 echo-requests
Apr 22 07:37:34 gremlin pppd[1999]: Serial link appears to be disconnected.
Apr 22 07:37:34 gremlin pppd[1999]: Script /etc/ppp/ip-down started (pid 2073)
Apr 22 07:37:34 gremlin pppd[1999]: sent [LCP TermReq id=0x2 "Peer not responding"]
Apr 22 07:37:34 gremlin pppd[1999]: Script /etc/ppp/ip-down finished (pid 2073), status = 0x0
Apr 22 07:37:37 gremlin pppd[1999]: sent [LCP TermReq id=0x3 "Peer not responding"]
Apr 22 07:37:40 gremlin pppd[1999]: sent [LCP TermReq id=0x4 "Peer not responding"]
Apr 22 07:37:43 gremlin pppd[1999]: sent [LCP TermReq id=0x5 "Peer not responding"]
Apr 22 07:37:46 gremlin pppd[1999]: sent [LCP TermReq id=0x6 "Peer not responding"]
Apr 22 07:37:49 gremlin pppd[1999]: sent [LCP TermReq id=0x7 "Peer not responding"]
Apr 22 07:37:52 gremlin pppd[1999]: sent [LCP TermReq id=0x8 "Peer not responding"]
Apr 22 07:37:55 gremlin pppd[1999]: sent [LCP TermReq id=0x9 "Peer not responding"]
Apr 22 07:37:58 gremlin pppd[1999]: sent [LCP TermReq id=0xa "Peer not responding"]
Apr 22 07:38:01 gremlin pppd[1999]: sent [LCP TermReq id=0xb "Peer not responding"]
Apr 22 07:38:04 gremlin pppd[1999]: Connection terminated.
Apr 22 07:38:04 gremlin pppd[1999]: Connect time 2.5 minutes.
Apr 22 07:38:04 gremlin pppd[1999]: Sent 457 bytes, received 139 bytes.
Apr 22 07:38:04 gremlin pppd[1999]: Connect time 2.5 minutes.
Apr 22 07:38:04 gremlin pppd[1999]: Sent 457 bytes, received 139 bytes.
Apr 22 07:38:04 gremlin pppd[1999]: Exit.
Apr 22 07:38:25 gremlin logger: Cron job - running checkerr as mail


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