headers
David Miller | 5 Aug 2010 06:56
Favicon

Re: [PATCH] ppp: make channel_ops const

From: Stephen Hemminger <shemminger <at> vyatta.com>
Date: Wed, 4 Aug 2010 10:34:36 -0700

> The PPP channel ops structure should be const.
> Cleanup the declarations to use standard C99 format.
> 
> Signed-off-by: Stephen Hemminger <shemminger <at> vyatta.com>

Applied.
--
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
Permalink | Reply | 0 comments |
headers
Philip Prindeville | 9 Aug 2010 23:35

Using pppoa and Solos DSL card

  Hi.

I'm running 2.6.27.49 and using linux-atm-2.5.1.  I have a Solos ADSL2+ card.

My DSL provider (Qwest) recently bumped me from a PPPoE provisioned DSLAM to a PPPoA RT.

I was wondering what all I needed to get pppoa working, so I went googling for documents but most of what I
found was from linux-2.4 and ppp-2.3.0... is there more recent documentation?

Thanks,

-Philip

--
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
Permalink | Reply | 0 comments |
headers
Jouko Nikula | 11 Aug 2010 15:12
Favicon

Intervening IPCP Configure Requests


Hello,

I'm using pppd as a server and I would want to do the following: 
 1.) Client sends IPCP configure request including an IP-address for the
client
 2.) Before pppd responds I want to decide on accepting or rejecting the IP
address outside pppd
 3.) Based on the decision in 2.) I want either to ACK the IPCP configure
request or terminate the ppp connection.

Second use case is when client does not specify an IP-address. Then I would
want to acquire a dynamic address, again outside pppd. If I found out that
dynamic addresses are not allowed I would terminate the ppp connection,
otherwise I would want to NAK the IPCP configure request with the acquired
IP-address.

I have looked into pppd plugin interface, but if I understand correctly the
current interface only provides the address given on the command line or
options file, not the ip-address requested by the other end. The ip-up or
ip-pre-up scripts don't seem to work for me because they are called when the
IPCP negotiation has already ended.

Could you please give me some ideas how I could implement this? Should I
extend the plugin interface so that I add hooks for IPCP negotiation and
create a plugin for this?

Thanks in advance!

Regards,
(Continue reading)

Permalink | Reply | 4 comments |
headers
James Carlson | 12 Aug 2010 15:20

Re: Intervening IPCP Configure Requests

Jouko Nikula wrote:
> Second use case is when client does not specify an IP-address. Then I would
> want to acquire a dynamic address, again outside pppd. If I found out that
> dynamic addresses are not allowed I would terminate the ppp connection,
> otherwise I would want to NAK the IPCP configure request with the acquired
> IP-address.
> 
> I have looked into pppd plugin interface, but if I understand correctly the
> current interface only provides the address given on the command line or
> options file, not the ip-address requested by the other end. The ip-up or
> ip-pre-up scripts don't seem to work for me because they are called when the
> IPCP negotiation has already ended.

The existing allowed_address_hook() will allow you to filter IP
addresses for acceptability.  The argument is the address the peer
requested, and if you return -1 and there are no other addresses
allowable, then the link will be torn down.

And the existing ip_choose_hook() will allow you to set up an address
that you want the peer to use.  You can use the allowed_address_hook()
to determine if that address actually was used.

The existing code, though, doesn't really allow you to get into the
middle of negotiation as you're suggesting.  And, arguably, the
interfaces are not as flexible as they could be.

Getting the on-the-wire behavior right (in general) requires mechanisms
that can be run synchronously and without undue delay.  That's why the
existing code keeps those hooks out of the main line -- those external
functions are sometimes (and all too often) written to make calls to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouko Nikula | 16 Aug 2010 15:33
Favicon

Re: Intervening IPCP Configure Requests

First of all thanks a lot for your reply and sorry about my triple post. It seems that nabble was too
complicated for me.

James Carlson wrote 12.08.2010 16:20:

> The existing code, though, doesn't really allow you to get into the
> middle of negotiation as you're suggesting.  And, arguably, the
> interfaces are not as flexible as they could be.
> 

Yes, unfortunately I need to be able to get into the 
middle of negotiation. It's too late if the IPCP negotiation has already ended.

> Getting the on-the-wire behavior right (in general) requires mechanisms
> that can be run synchronously and without undue delay.  That's why the
> existing code keeps those hooks out of the main line -- those external
> functions are sometimes (and all too often) written to make calls to
> RADIUS or DHCP servers, or other sorts of things that can block for
> arbitrary periods of time.
> 

Yes my external calls will also be something that block for possibly long time.

> To put in a supportable set of hooks for what you're suggesting would (I
> believe) require either a set of non-blocking primitives plus completion
> callbacks and interfaces into the existing event handling structure or
> (gasp!) similar multithreaded mechanisms.  I might be missing something,
> but it doesn't look quite simple to me.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Carlson | 16 Aug 2010 16:07

Re: Intervening IPCP Configure Requests

On 08/16/10 09:33, Jouko Nikula wrote:
> First of all thanks a lot for your reply and sorry about my triple post. It seems that nabble was too
complicated for me.

No problem.  I did wonder what happened there.  ;-}

> James Carlson wrote 12.08.2010 16:20:
>> Of course, you've got the source, so if you just want to hack something
>> into the middle of ipcp_reqci() in pppd/ipcp.c, go ahead.  Depending on
>> how your "validation" functions work, you might produce odd results on
>> the wire, including possibly non-converging behavior with some peers.
>> But if you're not worried about that or if it works for you, then go
>>  for it.
> 
> I did some checks and I think this might work for me. For my application it should be ok that an IPCP configure
request blocks for maybe a long time, before it is either Ack'ed or connection is terminated. Do I
understand correctly that blocking is the part where you think that problems could arise?

Yes, it's the blocking that I'd be worried about.  Note that this blocks
everything in PPP negotiation -- not just IPCP, but all other protocols
that might be negotiating at the same time.

If it works for you, that's great, but I don't think it's the right
general approach to the problem.

> Also do I understand correctly that you are not interested in a patch where I would allow this behaviour
with synchronous hooks?

I'd be a little concerned that someone else in the future would try the
same thing and run himself into trouble ... but if the hooks can be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouko Nikula | 18 Aug 2010 12:59
Favicon

Re: Intervening IPCP Configure Requests

James Carlson wrote 16.08.2010 17:07:

> Yes, it's the blocking that I'd be worried about.  Note that this blocks
> everything in PPP negotiation -- not just IPCP, but all other protocols
> that might be negotiating at the same time.
> 
> If it works for you, that's great, but I don't think it's the right
> general approach to the problem.
> 

Ok, I understand. I think this should work in my case, so I'm gonna try this approach. Again, thanks for your
thorough answer!

regards,
Jouko Nikula

....................................................................
Luukku Plus -paketilla pääset eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku
--
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
Permalink | Reply | 0 comments |
headers
omar hasan | 19 Aug 2010 15:15
Picon

(unknown)

My name is Omar Hasan a merchant in Dubai, in the U.A.E. I have an urgent
bussiness to share with you, please get back to me for more details

--
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
Permalink | Reply | 0 comments |
headers
NOKIA MOBILE PROMO AWARD | 22 Aug 2010 00:56
Picon

Payment Information

--
FROM THE DESK OF THE PROMOTION OFFICER,
NOKIA MOBILE SWEEPSTAKES PROMO.
2ND FLOOR BERKLEY SQUARE HOUSE
BERKLEY SQUARE LONDON W1J 6BD,
LONDON. UNITED KINGDOM.

NOKIA MOBILE PROMO AWARD

OFFICIAL WINNING NOTIFICATION.

We are pleased to inform you of the release of the long
awaited results of Nokia LOTTERY promotion organized
in conjunction with T-MOBILE your email address emerged as
one of the seven others online Winning e-mails in the 2nd
category and therefore attracted a cash award of
$1,000.000.00 USD (ONE MILLION United States Dollars)

To begin your claim, do file for the release of your winning
by contacting our Foreign Transfer Manager with your
PERSONAL DETAILS (Compulsory)

Fill the form below:

NAME:
ADDRESS:
PHONE NO:
OCCUPATION:
AGE:
SEX:
(Continue reading)

Permalink | Reply | 0 comments |
headers
tony.chamberlain | 29 Aug 2010 06:56

more on the mail I just sent

Here is an additional error message.  And remember though I get this, the other ppp connection to the first
machine I mentioned is up and workign:

Aug 29 11:32:23 BJ9008 pptpd[11780]: GRE: read(fd=6,buffer=804e5e0,len=8196) from PTY failed: status
= -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax
and pppd logs

--
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
Permalink | Reply | 0 comments |

Gmane