headers
Davy Leon | 5 Oct 19:40
Picon

ppp question

Hi folks

I have a question. Every time I dialup to the internet pppd executes an 
script called ip-up. My question is, everytime someone dials in it's 
executed too? If the answer is yes, how can I handle the script to execute 
one part when dianing out and another part when dialing in. I meant 
something like

if dialing in then

...
...

if dialing out then

...
....

Thanks in advance

David 

--
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 | 5 Oct 19:38

Re: ppp question

Davy Leon wrote:
> I have a question. Every time I dialup to the internet pppd executes an
> script called ip-up. My question is, everytime someone dials in it's
> executed too?

Yes.  It's executed every time an IP interface is brought up by PPP.

Note that PPP itself knows nothing about dialing in or out; those are
attributes of the lower layer -- the chat script and modems or other
communications gear involved.  PPP is symmetric and peer-to-peer.
There's no "client" or "server."

> If the answer is yes, how can I handle the script to
> execute one part when dianing out and another part when dialing in. I
> meant something like

The man page has a number of environment variables documented that you
could use for this task.  $PEERNAME is fairly useful -- it will be set
only if you have an authenticated peer name.

If you have different devices for dialing in and out (it's often a good
idea to do this, but not always done), then $DEVICE might tell you what
you want to know.

If you want to get fancier, you can use $LINKNAME with the "linkname"
option.

The simple answer would be:

	if [[ -n ${PEERNAME:+I_am_server} ]]; then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Unruh | 5 Oct 19:33
Picon
Picon
Favicon

Re: ppp question

On Mon, 5 Oct 2009, Davy Leon wrote:

> Hi folks
>
> I have a question. Every time I dialup to the internet pppd executes an 
> script called ip-up. My question is, everytime someone dials in it's executed 
> too? If the answer is yes, how can I handle the script to execute one part 
> when dianing out and another part when dialing in. I meant something like

One of the arguments given to ip-up is the IP addresses assigned to the remote
and local systems. Since when someone calls in the IP address is assigned by
you and is almost certainly different from the IP address assigned to you when
you dial out. You can base the response on the IP address range

man pppd

>
> if dialing in then
>
> ...
> ...
>
> if dialing out then
>
> ...
> ....
>
>
>
> Thanks in advance
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jarek Poplawski | 15 Oct 13:40
Picon

Re: NOHZ: local_softirq_pending 08

On 12-10-2009 13:25, Tilman Schmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, 12 Oct 2009 03:32:46 -0700 (PDT), David Miller wrote:
>> The PPP receive paths in ppp_generic.c do a local_bh_disable()/
>> local_bh_enable() around packet receiving (via ppp_recv_lock()/
>> ppp_recv_unlock() in ppp_do_recv).
>>
>> So at least that part is perfectly fine.
>>
>> ppp_input(), as called from ppp_sync_process(), also disables BH's
>> around ppp_do_recv() calls (via read_lock_bh()/read_unlock_bh()).
>>
>> So that's fine too.
>>
>> Do you have a bug report or are you just scanning around looking
>> for trouble? :-)
> 
> I have encountered the message in the subject during a test of
> the Gigaset CAPI driver, and would like to determine whether
> it's a bug in the driver, a bug somewhere else, or no bug at
> all. The test scenario was PPP over ISDN with pppd+capiplugin.
> In an alternative scenario, also PPP over ISDN but with
> smpppd+capidrv, the message did not occur.
> 
> Johannes' answer pointed me to the netif_rx() function.
> The Gigaset driver itself doesn't call that function at all.
> In the scenario where I saw the message, it was the SYNC_PPP
> line discipline that did. But from your explanation I gather
(Continue reading)

Permalink | Reply | 24 comments |
headers
Michal Ostrowski | 19 Oct 05:34
Picon

Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces

Here's my theory on this after an inital look...

Looking at the oops report and disassembly of the actual module binary
that caused the oops, one can deduce that:

Execution was in pppoe_flush_dev().  %ebx contained the pointer "struct
pppox_sock *po", which is what we faulted on, excuting "cmp %eax, 0x190(%ebx)".
%ebx value was 0xffffffff (hence we got "NULL pointer dereference at 0x18f").

At this point "i" (stored in %esi) is 15 (valid), meaning that we got a value
of 0xffffffff in pn->hash_table[i].

From this I'd hypothesize that the combination of dev_put() and release_sock()
may have allowed us to free "pn".  At the bottom of the loop we alreayd
recognize that since locks are dropped we're responsible for handling
invalidation of objects, and perhaps that should be extended to "pn" as well.
--
Michal Ostrowski
mostrows <at> gmail.com

---
 drivers/net/pppoe.c |   86 ++++++++++++++++++++++++++----
--------------------
 1 files changed, 45 insertions(+), 41 deletions(-)

diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 7cbf6f9..720c4ea 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -296,6 +296,7 @@ static void pppoe_flush_dev(struct net_device *dev)
(Continue reading)

Permalink | Reply | 32 comments |
headers
Eric Dumazet | 19 Oct 14:36
Picon
Gravatar

Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces

Michal Ostrowski a écrit :
> Here's my theory on this after an inital look...
> 
> Looking at the oops report and disassembly of the actual module binary
> that caused the oops, one can deduce that:
> 
> Execution was in pppoe_flush_dev().  %ebx contained the pointer "struct
> pppox_sock *po", which is what we faulted on, excuting "cmp %eax, 0x190(%ebx)".
> %ebx value was 0xffffffff (hence we got "NULL pointer dereference at 0x18f").
> 
> At this point "i" (stored in %esi) is 15 (valid), meaning that we got a value
> of 0xffffffff in pn->hash_table[i].
> 
>>From this I'd hypothesize that the combination of dev_put() and release_sock()
> may have allowed us to free "pn".  At the bottom of the loop we alreayd
> recognize that since locks are dropped we're responsible for handling
> invalidation of objects, and perhaps that should be extended to "pn" as well.
> --
> Michal Ostrowski
> mostrows <at> gmail.com
> 
> 

Looking at this stuff, I do believe flush_lock protection is not
properly done.

At the end of pppoe_connect() for example we can find :

err_put:
        if (po->pppoe_dev) {
(Continue reading)

Permalink | Reply | 29 comments |
headers
Michal Ostrowski | 19 Oct 15:19
Picon

Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces

The entire scheme for managing net namespaces seems unsafe.  We depend
on synchronization via pn->hash_lock, but have no guarantee of the
existence of the "net" object -- hence no way to ensure the existence
of the lock itself.  This should be relatively easy to fix though as
we should be able to get/put the net namespace as we add remove
objects to/from the pppoe hash.

Once you solve this existence issue, the flush_lock can be eliminated
altogether since all of the relevant code paths already depend on a
write_lock_bh(&pn->hash_lock), and that's the lock that should be use
to protect the pppoe_dev field.

Another patch to follow later...

--
Michal Ostrowski
mostrows <at> gmail.com

On Mon, Oct 19, 2009 at 7:36 AM, Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
> Michal Ostrowski a écrit :
>> Here's my theory on this after an inital look...
>>
>> Looking at the oops report and disassembly of the actual module binary
>> that caused the oops, one can deduce that:
>>
>> Execution was in pppoe_flush_dev().  %ebx contained the pointer "struct
>> pppox_sock *po", which is what we faulted on, excuting "cmp %eax, 0x190(%ebx)".
>> %ebx value was 0xffffffff (hence we got "NULL pointer dereference at 0x18f").
>>
>> At this point "i" (stored in %esi) is 15 (valid), meaning that we got a value
(Continue reading)

Permalink | Reply | 28 comments |
headers
Eric Dumazet | 19 Oct 19:12
Picon
Gravatar

Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces

Michal Ostrowski a écrit :
> Here's a bigger patch that just gets rid of flush_lock altogether.
> 
> We were seeing oopses due to net namespaces going away while we were using
> them, which turns out is simply due to the fact that pppoew wasn't claiming ref
> counts properly.
> 
> Fixing this requires that adding and removing entries to the per-net hash-table
> requires incrementing and decrementing the ref count.  This also allows us to
> get rid of the flush_lock since we can now depend on the existence of
> "pn->hash_lock".
> 
> We also have to be careful when flushing devices that removal of a hash table
> entry may bring the net namespace refcount to 0.
> 

Your patch is mangled (tabulation -> white spaces),

and I dont believe namespace refcount can reach 0 inside pppoe_flush_dev(),
it would be a bug from core network code.

--
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 | 25 comments |
headers
Cyrill Gorcunov | 19 Oct 21:29
Picon
Gravatar

Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces

[Eric Dumazet - Mon, Oct 19, 2009 at 08:44:52PM +0200]
...
| 
| Not really :)
| 
| I dont believe you should care of namespace, and/or mess with its refcount at all.
| 
| Please dont use maybe_get_net() : This function should not ever be used in drivers/net
| 
| You can add a BUG_ON(dev_net(xxxx)->count <= 0) if you really want, but if this
| assertion is false, this is not because of pppoe.
| 
...
| So pppoe_flush_dev() can run concurently and dev_put(po->ppoe_dev) at same time.
| 
| In fact pppoe_flush_dev() can change po->ppoe_dev anytime, so you should check
| all occurences of po->ppoe_dev use in the code and check if appropriate locking is done.
| 
| pppoe_rcv_core() is not safe
| pppoe_ioctl() is not safe
| pppoe_sendmsg() is not safe
| __pppoe_xmit() is not safe
| 

Sigh... seem so (which is mostly my fault not Michal). Every time we touch pppoe_dev we
should dev_hold on it and dev_put as only done all we need. Async nature
of notifier seem to be a key here.

	-- Cyrill
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrill Gorcunov | 19 Oct 22:57
Picon
Gravatar

Re: kernel panic in latest vanilla stable, while using nameif with "alive" pppoe interfaces

[Eric Dumazet - Mon, Oct 19, 2009 at 08:44:52PM +0200]
...
| 
| There is still a race here, since you do a dev_put(po->ppoe_dev); without any lock held
| 
| So pppoe_flush_dev() can run concurently and dev_put(po->ppoe_dev) at same time.
| 
| In fact pppoe_flush_dev() can change po->ppoe_dev anytime, so you should check
| all occurences of po->ppoe_dev use in the code and check if appropriate locking is done.
| 
| pppoe_rcv_core() is not safe
| pppoe_ioctl() is not safe
| pppoe_sendmsg() is not safe
| __pppoe_xmit() is not safe
| 

Eric, Michal, please take a look (compile-test only).
There is still unclear moment for NETDEV_CHANGEMTU
since one could be doing this in say endless loop from
userspace calling device to flush all the time which
implies dev_put as a result :(

Comments are welcome (and complains as well). I'll be able to
continue handling (or reply to mail) tomorrow evening only.
Anyway -- this patch is ugly enough but may happen to work.

	-- Cyrill
---
 drivers/net/pppoe.c |   79 ++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 62 insertions(+), 17 deletions(-)
(Continue reading)

Permalink | Reply | 15 comments |

Gmane