Re: pkg/33926 (rp-pppoe report asyncReadFromPPP error on NetBSD-3.0)

["Water He" <water%infor-trans.com@localhost>]

I traced the problem and now report the result here:

asyncReadFromPPP() is used to read data from pppd,
but comment in patch gived by martin said that it read from BPF.
I think I couldn't agree it.

pppoe-server fork pppd, pppd fork pppoe. so data-stream is like below:
pppd <---> pppoe <---> BPF/ethernet

safe_fork() in src/dist/pppd/pppd/main.c says:
pppd create a pipe and used to communicates with forked progcess (here is 
pppoe).

because of safe_fork()'s works,
pppoe read from stdin (fd=0) means read from pppd,
pppoe write to stdout (fd=1) means write to pppd,

Now I find out a problem, 
when pppoe call openInterface() to get BPF fd (calling in session() of pppoe.c)
it return 0;
So, in fact, as like I traced:
asyncReadFromPPP() alwasy read data from BPF. But it should read from pipe of 
pppd.

I notice that openInterface() return 3 in program pppoe-server.
Why it return 0 in program pppoe?
Because pppd close stdin, stdout,stderr before call execl()?

I guess that if openInterface() return >= 3 will resolve the problem.
Right?
How?

Thanks.



----- Original Message ----- 
From: "Martin Husemann" <martin%duskware.de@localhost>
To: <martin%NetBSD.org@localhost>; <gnats-admin%NetBSD.org@localhost>; 
<pkgsrc-bugs%NetBSD.org@localhost>; <water%infor-trans.com@localhost>
Sent: Saturday, August 05, 2006 10:15 PM
Subject: Re: pkg/33926 (rp-pppoe report asyncReadFromPPP error on NetBSD-3.0)


> The following reply was made to PR pkg/33926; it has been noted by GNATS.
> 
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: 
> Subject: Re: pkg/33926 (rp-pppoe report asyncReadFromPPP error on NetBSD-3.0)
> Date: Sat, 5 Aug 2006 16:12:43 +0200
> 
> --RASg3xLB4tUQ4RcS
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> The package seems broken in multiple ways. The patches patch-ac and
> patch-ad (both noops and unecessary) should be removed.
> 
> The patch below fixes the obvious EINVAL problem reported in this PR, but
> it does not make the package work - to me it seems after restructuring
> rp-pppoe completely there has been no testing on OSes using BPF.
> 
> If noone volunteers to debug the package all way through we should either
> mark it broken or consider downgrading it.
> 
> Martin
> 
> --RASg3xLB4tUQ4RcS
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: attachment; filename=patch-ah
> 
> --- src/ppp.c.orig 2002-07-08 16:38:24.000000000 +0200
> +++ src/ppp.c 2006-08-05 15:49:46.000000000 +0200
> @@ -164,13 +164,27 @@
>  void
>  asyncReadFromPPP(PPPoEConnection *conn, PPPoEPacket *packet)
>  {
> -    unsigned char buf[READ_CHUNK];
> -    unsigned char *ptr = buf;
> +    unsigned char *ptr;
>      unsigned char c;
> +    extern int bpfLength;
> +    static int readLength = 0;
> +    unsigned char *buf = NULL;
>  
>      int r;
>  
> -    r = read(0, buf, READ_CHUNK);
> +    if (readLength == 0) {
> + /*
> + * We need to read everything from BPF in the size the kernel
> + * told us (bpfLength), if we are using BPF.
> + * Otherwise just use READ_CHUNK.
> + */
> + if (bpfLength == 0)
> +     readLength = READ_CHUNK;
> + else
> +     readLength = bpfLength;
> +    }
> +    ptr = buf = malloc(readLength);
> +    r = read(0, buf, readLength);
>      if (r < 0) {
>  fatalSys("read (asyncReadFromPPP)");
>      }
> @@ -193,7 +207,7 @@
>  }
>  
>  /* Still waiting... */
> - if (PPPState == STATE_WAITFOR_FRAME_ADDR) return;
> + if (PPPState == STATE_WAITFOR_FRAME_ADDR) goto done;
>  
>  while(r && PPPState == STATE_DROP_PROTO) {
>      --r;
> @@ -202,7 +216,7 @@
>      }
>  }
>  
> - if (PPPState == STATE_DROP_PROTO) return;
> + if (PPPState == STATE_DROP_PROTO) goto done;
>  
>  /* Start building frame */
>  while(r && PPPState == STATE_BUILDING_PACKET) {
> @@ -234,6 +248,8 @@
>      }
>  }
>      }
> +done:
> +    free(buf);
>  }
>  
>  /**********************************************************************
> 
> --RASg3xLB4tUQ4RcS--
> 
> 
>