headers
Joakim Tjernlund | 2 Feb 14:18
Picon

IFF_RUNNING support for ppp interfaces?

I wonder how IFF_RUNNING is managed in recent pppd version(s). I very much 
like  to
use IFF_RUNNING to see if the link working in both ends.

 Jocke
--
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 | 5 comments |
headers
tony.chamberlain | 4 Feb 18:05

VPN disconnect

This is another VPN question.

We have a regular IP address which we use to connect to a PPTP VPN
which assigns us 10.0.1.29.  If the PPTP connection goes down, we
will lose that address.

Our software relies on our IP address being 10.0.1.29.  Is there a way,
if the VPN temporarily goes down, to maintain the IP address of
10.0.1.29 ?

--
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 | 2 comments |
headers
James Carlson | 4 Feb 18:11

Re: VPN disconnect

tony.chamberlain <at> lemko.com writes:
> This is another VPN question.
> 
> We have a regular IP address which we use to connect to a PPTP VPN
> which assigns us 10.0.1.29.  If the PPTP connection goes down, we
> will lose that address.
> 
> Our software relies on our IP address being 10.0.1.29.  Is there a way,
> if the VPN temporarily goes down, to maintain the IP address of
> 10.0.1.29 ?

You can tell pppd to request a particular address by adding it to your
options, like this:

	pppd 10.0.1.29: ipcp-accept-local

(The ":" at the end means "request this local address, and don't
insist on any particular peer address.")

pppd doesn't have an automatic means to save the last-used address for
a link and pick it up again.  Perhaps it should have one, but you
could do this in a script by having your own /etc/ppp/ip-up that
stores $IPREMOTE into a file, and then pull in that file's contents
for a later invocation of pppd.

Note that this just tells pppd to request a particular address.
There's no telling whether the peer understands what to do with such a
request, or if it can or will honor it.  Some servers may refuse to
negotiate at all under such conditions, causing the link to fail.
(Bugs are unfortunately common.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Carlson | 4 Feb 18:14

Re: IFF_RUNNING support for ppp interfaces?

Joakim Tjernlund writes:
> I wonder how IFF_RUNNING is managed in recent pppd version(s). I very much 
> like  to
> use IFF_RUNNING to see if the link working in both ends.

For most implementations, IFF_RUNNING cannot be controlled by anything
in user space (such as pppd).  Instead, it's set/cleared by the
kernel's PPP driver.

Defining "working" is difficult.  Usually, the IFF_RUNNING flag is set
if the link is either a demand link waiting for activity or if there's
an active serial link underneath the connection, and IFF_UP is set
when IPCP successfully negotiates addresses.

--

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>
--
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 | 4 comments |
headers
James Cameron | 5 Feb 01:41
Picon
Favicon

Re: VPN disconnect

On Wed, Feb 04, 2009 at 12:11:33PM -0500, James Carlson wrote:
> Note that this just tells pppd to request a particular address.
> There's no telling whether the peer understands what to do with such a
> request, or if it can or will honor it.  Some servers may refuse to
> negotiate at all under such conditions, causing the link to fail.
> (Bugs are unfortunately common.)

On the peer side, pptpd on Linux in the default configuration gives the
IP address to pppd on command line, and so the IP address is usually
non-negotiable.  I don't know about other peers.

--

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
--
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
Joakim Tjernlund | 8 Feb 20:23
Picon

Re: IFF_RUNNING support for ppp interfaces?

James Carlson <carlsonj <at> workingcode.com> wrote on 04/02/2009 18:14:44:
>
Sorry for the late reply, I got busy and forgot ..

> Joakim Tjernlund writes:
> > I wonder how IFF_RUNNING is managed in recent pppd version(s). I very 
much 
> > like  to
> > use IFF_RUNNING to see if the link working in both ends.
> 
> For most implementations, IFF_RUNNING cannot be controlled by anything
> in user space (such as pppd).  Instead, it's set/cleared by the
> kernel's PPP driver.

I haven't looked into how ppp is impl. in user/kernel space but I suspect
that user space would have to help/inform the kernel ppp driver about
RUNNING status.

> 
> Defining "working" is difficult.  Usually, the IFF_RUNNING flag is set
> if the link is either a demand link waiting for activity or if there's
> an active serial link underneath the connection, and IFF_UP is set
> when IPCP successfully negotiates addresses.

Perhaps, but one could flip RUNNING if echo replies stops or if
someone pulls the cable. That would be a start

 Jocke

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Carlson | 9 Feb 13:10

Re: IFF_RUNNING support for ppp interfaces?

Joakim Tjernlund writes:
> James Carlson <carlsonj <at> workingcode.com> wrote on 04/02/2009 18:14:44:
> >
> Sorry for the late reply, I got busy and forgot ..
>  
> > Joakim Tjernlund writes:
> > > I wonder how IFF_RUNNING is managed in recent pppd version(s). I very 
> much 
> > > like  to
> > > use IFF_RUNNING to see if the link working in both ends.
> > 
> > For most implementations, IFF_RUNNING cannot be controlled by anything
> > in user space (such as pppd).  Instead, it's set/cleared by the
> > kernel's PPP driver.
> 
> I haven't looked into how ppp is impl. in user/kernel space but I suspect
> that user space would have to help/inform the kernel ppp driver about
> RUNNING status.

The way it works today is that the daemon tears down the interface if
it detects that the interface has failed.

> > Defining "working" is difficult.  Usually, the IFF_RUNNING flag is set
> > if the link is either a demand link waiting for activity or if there's
> > an active serial link underneath the connection, and IFF_UP is set
> > when IPCP successfully negotiates addresses.
> 
> Perhaps, but one could flip RUNNING if echo replies stops or if
> someone pulls the cable. That would be a start
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joakim Tjernlund | 9 Feb 15:43
Picon

Re: IFF_RUNNING support for ppp interfaces?

James Carlson <carlsonj <at> workingcode.com> wrote on 09/02/2009 13:10:45:
> Joakim Tjernlund writes:
> > James Carlson <carlsonj <at> workingcode.com> wrote on 04/02/2009 18:14:44:
> > >
> > Sorry for the late reply, I got busy and forgot ..
> > 
> > > Joakim Tjernlund writes:
> > > > I wonder how IFF_RUNNING is managed in recent pppd version(s). I 
very 
> > much 
> > > > like  to
> > > > use IFF_RUNNING to see if the link working in both ends.
> > > 
> > > For most implementations, IFF_RUNNING cannot be controlled by 
anything
> > > in user space (such as pppd).  Instead, it's set/cleared by the
> > > kernel's PPP driver.
> > 
> > I haven't looked into how ppp is impl. in user/kernel space but I 
suspect
> > that user space would have to help/inform the kernel ppp driver about
> > RUNNING status.
> 
> The way it works today is that the daemon tears down the interface if
> it detects that the interface has failed.
> 
> > > Defining "working" is difficult.  Usually, the IFF_RUNNING flag is 
set
> > > if the link is either a demand link waiting for activity or if 
there's
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Carlson | 9 Feb 16:17

Re: IFF_RUNNING support for ppp interfaces?

Joakim Tjernlund writes:
> James Carlson <carlsonj <at> workingcode.com> wrote on 09/02/2009 13:10:45:
> > I don't think that's a problem with the current code.  If you do see a
> > problem here, then I think it'd be helpful to have the problem itself
> > described in some detail, rather than focussing on what solution you'd
> > like to see implemented.
> 
> I should have been clearer. I think it is a bit rude to tear down/delete
> the ppp interface when it looses a link. Compare with ethernet, when the 
> cable
> is pulled you still see the I/F but the running status is gone so you get 
> a clue
> to what is wrong. For ppp the I/F is just deleted and you can only guess 
> the cause,
> or start looking at logs to find out what happened.

Ah, this is a much higher-level issue, and is only slightly related to
IFF_RUNNING.

The real issue is that (a) there are at least two different "kinds" of
PPP links, (b) the identity of the IP-level object doesn't say
anything about the physical entity, and (c) a bit about pppd design
itself.

With Ethernet, you (generally) know that a "net0" interface is
connected to a single hardware instance, and that IFF_RUNNING
transitions represent changes in the status of that one instance.

With PPP, things are different.  First of all, to point (a), there are
different kinds of PPP links that we have no good way of
(Continue reading)

Permalink | Reply | 0 comments |
headers
admin | 17 Feb 19:44
Picon

MEETING

Estas buscando pareja.

 <http://www.ekipate.es/lists/lt.php?id=YR5QBAMLVwMYCFpMBg0EVww%3D>

--
To unsubscribe from this list visit
http://www.ekipate.es/lists/lt.php?id=YR5QBAMLVwwYCFpMBg0EVww%3D

To update your preferences visit
http://www.ekipate.es/lists/lt.php?id=YR5QBAMLVw0YCFpMBg0EVww%3D

--
Powered by PHPlist, www.phplist.com --

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