Richard Ray Zhang | 4 Jul 22:15

pppoe problem on an arm-based device.

Hi, all
I encountered a problem with pppoe on an arm-based device.

The target environment is arm-linux 2.4.18, glibc 2.3.3.
The cross-compiler is armv4l-linux-gnu-gcc 3.4.2.

I have cross-compiled pppd 2.4.3 and rp-pppoe 3.8 to device.
I can dial the normal 56K modem correctly by pppd. I think that the pppd
should be correct.

When I dial the ADSL modem, I found that the PADI packet was incorrect.
The PADI header generated by device is bigger than the correct one,
which is generated by PC. After checking the code, I found the ethhdr in
PPPoEPacketStruct was aligned incorrectly. So, I changed the
PPPoEPacketStruct as the following codes.

--------------------code modification-----------------------
typedef struct __attribute__ ((packed)) PPPoEPacketStruct {
    struct __attribute__ ((packed)){
        unsigned char   h_dest[ETH_ALEN];       /* destination eth addr
*/
        unsigned char   h_source[ETH_ALEN];     /* source ether addr
*/
        unsigned short  h_proto;                /* packet type ID field
*/
    } ethHdr;   /* Ethernet header */
#ifdef PACK_BITFIELDS_REVERSED
    unsigned int type:4;        /* PPPoE Type (must be 1) */
    unsigned int ver:4;         /* PPPoE Version (must be 1) */
#else
(Continue reading)

Ray Van Dolson | 5 Jul 21:40

Re: Radius plugin bug.

Well have been working on this a little, and may have found a potential
solution that works.

Feedback would be appreciate from real programmers as to negative
consequences of reorganizing the code a little...

Basically, I am removing the calls to free the ppp interface from the
link_terminated function and relocating them to later in the process --
after the plugin cleanup functions have been called removing the radius
attribute file.

Seems to be working OK so far on our server...

diff -uNrp ppp-2.4.3.orig/pppd/auth.c ppp-2.4.3/pppd/auth.c
--- ppp-2.4.3.orig/pppd/auth.c	2004-11-12 02:30:51.000000000 -0800
+++ ppp-2.4.3/pppd/auth.c	2006-07-05 12:03:47.000000000 -0700
@@ -83,6 +83,7 @@
 #include <sys/socket.h>
 #include <utmp.h>
 #include <fcntl.h>
 #if defined(_PATH_LASTLOG) && defined(__linux__)
 #include <lastlog.h>
 #endif
@@ -621,6 +622,7 @@ link_terminated(unit)
      * the ppp unit back to the loopback.  Set the
      * real serial device back to its normal mode of operation.
      */
+    /*
     if (fd_ppp >= 0) {
 	remove_fd(fd_ppp);
(Continue reading)

Picon

Re: pppd stuck in ioctl(TIOCSETD) in Linux 2.6.15.4+

On Friday 30 June 2006 00:26, Paul Mackerras wrote:
> Jorge Daniel Sequeira Matias writes:
> >   It didn't solve. After running 2.6.17.1 for almost 48 hours I already
> > have 4 pppd processes stuck in "ioctl(TIOCSETD..." in the connection
> > finish section.
>
> Try the newly-released version 2.4.4 of pppd, please.

  I have tried pppd v2.4.4 and didn't see any problem because with 2.6.17.1 I 
have a new problem.
  With 2.6.17.1, the "pptpctrl" processes, are heating all the CPU even if the 
VPN user traffic is low (like 40kbits/sec).
  I think this new problem is hiding the "pppd" problem because the VPN server 
is so slow that less people establishes connections. The OS network is now 
very lagged ...

Regards,
Jorge Matias
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ray Van Dolson | 11 Jul 17:25

Re: Radius plugin bug.

On Wed, Jul 05, 2006 at 12:40:21PM -0700, Ray Van Dolson wrote:
> Well have been working on this a little, and may have found a potential
> solution that works.
> 
> Feedback would be appreciate from real programmers as to negative
> consequences of reorganizing the code a little...
> 
> Basically, I am removing the calls to free the ppp interface from the
> link_terminated function and relocating them to later in the process --
> after the plugin cleanup functions have been called removing the radius
> attribute file.
> 
> Seems to be working OK so far on our server...

Been a few days, and still having no problems with this patch.  Problems
still arise if a customer connects and then disconnects before the ip-up
scripts have completed their initial run, but this isn't as much of an
issue. :)

Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

J Richard Glass | 11 Jul 19:13

perl implementation of passwordfd.so

Hi,

I was working with the C example for the passwordfd.so plugin and got
it to work with a dial up ppp connection but I really want to use this
plugin with perl. So I am hoping that someone on this list has some
experience using perl with passwordfd.

I keep getting the error... "Can't read secret from fd". I've set up
my script to fork and create a pipe to a READER file handle and a
WRITER file handle. I write to the password to the WRITER FH (close
the handle) and pass the file descriptor (fileno READER) to pppd in an
exec(). The interaction with the modem works and the last message I
get is Connect: ppp0 <--> /dev/ttyS0 before the error can't read from
fd.

Any help would be greatly appreciated.

Thanks.

Richard

Here's the gist in code and the resulting OUTPUT:

  defined(my $pid = fork) or die "Can't fork: $!";
  if ($pid > 0) {
    pipe(PPPD_RDR, PPPD_WTR) || die "pipe failed: $!";

    PPPD_WTR->autoflush(1);
    close PPPD_WTR;

(Continue reading)

J Richard Glass | 12 Jul 00:42

Re: perl implementation of passwordfd.so

Figured it out. I needed to increase the $SYSTEM_FD_MAX ($^F) before
opening the pipe. The default only passes system file descriptors to
exec()ed processes. Sorry for the trouble.

Thanks.

Richard

> Hi,
>
> I was working with the C example for the passwordfd.so plugin and got
> it to work with a dial up ppp connection but I really want to use this
> plugin with perl. So I am hoping that someone on this list has some
> experience using perl with passwordfd.
>
> I keep getting the error... "Can't read secret from fd". I've set up
> my script to fork and create a pipe to a READER file handle and a
> WRITER file handle. I write to the password to the WRITER FH (close
> the handle) and pass the file descriptor (fileno READER) to pppd in an
> exec(). The interaction with the modem works and the last message I
> get is Connect: ppp0 <--> /dev/ttyS0 before the error can't read from
> fd.
>
> Any help would be greatly appreciated.
>
> Thanks.
>
> Richard
>
> Here's the gist in code and the resulting OUTPUT:
(Continue reading)

James Cameron | 12 Jul 00:53
Picon
Favicon

Re: pppd stuck in ioctl(TIOCSETD) in Linux 2.6.15.4+

On Tue, Jul 11, 2006 at 01:18:33PM +0100, Jorge Daniel Sequeira Matias wrote:
> I have tried pppd v2.4.4 and didn't see any problem because with
> 2.6.17.1 I have a new problem.
> With 2.6.17.1, the "pptpctrl" processes, are heating all the CPU even
> if the VPN user traffic is low (like 40kbits/sec).

I'm the maintainer of pptpctrl.  Could you describe this problem
technically please?  Write to poptop-server <at> lists.sourceforge.net.
We do not have a goal of cooling a CPU, so heating is expected.

>   I think this new problem is hiding the "pppd" problem because the
>   VPN server is so slow that less people establishes connections. The
>   OS network is now very lagged ...

You've given your perceptions but not any measurements.  To obtain
measurements, downgrade to the previous configuration and do some tests.
We have test scripts in pptpd and pptp CVS.

--

-- 
James Cameron
http://ftp.hp.com.au/sigs/jc/
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Picon

Re: pppd stuck in ioctl(TIOCSETD) in Linux 2.6.15.4+

On Tuesday 11 July 2006 23:53, James Cameron wrote:
> On Tue, Jul 11, 2006 at 01:18:33PM +0100, Jorge Daniel Sequeira Matias 
wrote:
> > I have tried pppd v2.4.4 and didn't see any problem because with
> > 2.6.17.1 I have a new problem.
> > With 2.6.17.1, the "pptpctrl" processes, are heating all the CPU even
> > if the VPN user traffic is low (like 40kbits/sec).
>
> I'm the maintainer of pptpctrl.  Could you describe this problem
> technically please?  Write to poptop-server <at> lists.sourceforge.net.
> We do not have a goal of cooling a CPU, so heating is expected.

  Sorry for my English. What I meant was it as consuming all the CPU process 
time.
  Meanwhile I saw a reference to this problem in this e-mail

  "2.6.18-rc1-mm1 - VPN chewing CPU like crazy.." in
     http://lkml.org/lkml/2006/7/11/8

  But I have only seen the problem starting with 2.6.17.1

> >   I think this new problem is hiding the "pppd" problem because the
> >   VPN server is so slow that less people establishes connections. The
> >   OS network is now very lagged ...
>
> You've given your perceptions but not any measurements.  To obtain
> measurements, downgrade to the previous configuration and do some tests.
> We have test scripts in pptpd and pptp CVS.

  Unfortunatly I have no time at the moment to do any tests. For now I will be 
(Continue reading)

Bianca | 12 Jul 19:47

See/Listen what CNN,Fox News,ABC says..

Hello,

Easy to sell/market product online and offline.
The hottest product and the greatest bizniz on the net today.

And they have another great product, the D-1280x 
that launched 4th of July.

There is absolutely NO COST to pre-enroll and a 
free website upon pre-enroll.
Pls Check and hurry;
     http://www.legitimatebiz.us.tt

Thank You and regards
Bianca(PowerCharge Inc)

====================================================
To not receive emails from me again, 
please reply and put "Delete" in the subject. 

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane