Intervening IPCP Configure Requests

Intervening IPCP Configure Requests

[Jouko Nikula]

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,
Jouko Nikula
-- 
View this message in context: http://old.nabble.com/Intervening-IPCP-Configure-Requests-tp29408130p29408130.html
Sent from the linux-ppp mailing list archive at Nabble.com.

Re: Intervening IPCP Configure Requests

[James Carlson]

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
RADIUS or DHCP servers, or other sorts of things that can block for
arbitrary periods of 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.

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.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Intervening IPCP Configure Requests

[Jouko Nikula]

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

Ok. I understand and agree, making the hooks asynchronous does not sound easy to me either.

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

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

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

Re: Intervening IPCP Configure Requests

[James Carlson]

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
inserted cleanly and coherently, I wouldn't be opposed.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: Intervening IPCP Configure Requests

[Jouko Nikula]

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