From: Alain Fauconnet <alain@cscoms.net>
To: kuznet@ms2.inr.ac.ru
Cc: linux-kernel@vger.kernel.org, lve@ns.aanet.ru
Subject: Re: UPD: Frequent/consistent panics in 2.4.19 at ip_route_input_slow, in_dev_get(dev)
Date: Tue, 29 Oct 2002 11:13:30 +0700 [thread overview]
Message-ID: <20021029111330.C15782@cscoms.net> (raw)
In-Reply-To: <200210290130.EAA19804@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Oct 29, 2002 at 04:30:25AM +0300
On Tue, Oct 29, 2002 at 04:30:25AM +0300, kuznet@ms2.inr.ac.ru wrote:
> > I assume that the kernel is trying to use dynamic memory that has been
> > released already, right?
>
> Right.
>
> > What's next in tracing this one down?
>
> To tell what exactly driver makes this. Apparently, it continues
> to inject packets to the stack even after it has been destroyed.
>
In this case, would they be packets TO or FROM the ppp device?
(reminder: crash happens in ip_route_input_slow, called with struct
net_device *dev presumably pointing at what used to be the PPP device)
> If you did not see message "Freeing alive device", this means
> that driver unregistered it. Usual ppp seems to be sane...
No such message in logs, but "PPPIOCDETACH file->f_count=3" appears
quite often. If I understand it right, it'd mean that the ppp interface
is destroyed while having channels open to it... Does it give any
hint?
Let's try to summarize anything unusual this box has:
- pptp (PoPToP). But pptp is only userland software, how could it cause
such a problem? It merely forks pppd as a child.
- NAT, both SNAT and DNAT (for transparent redirection to a Squid), and
a lot of rules used to do traffic accounting so iptables configuration
is kind of hairy. Could it somehow cause packets to be "delayed" and
thus re-injected to the stack later than usual? (I'm probably just
talking nonsense here - sorry - trying to guess).
- assymetrical routing: packets come from clients over VPN, thus over the
PPP interface. They are routed back though a LAN interface that goes
to the satellite uplink. To do this, the route to the peer IP through
the PPP interface is deleted in the ip-up script.
Ah.. something else that could be relevant (??): I see that ifconfig
-a shows "duplicate" ppp devices e.g.:
ppp96 Link encap:Point-to-Point Protocol
inet addr:xxx.yyy.zzz.2 P-t-P:172.16.27.104 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:44238 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:2192741 (2.0 Mb) TX bytes:153 (153.0 b)
ppp96 Link encap:Point-to-Point Protocol
inet addr:xxx.yyy.zzz.2 P-t-P:172.16.27.104 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
Is this "normal"?
Greets,
_Alain_
next prev parent reply other threads:[~2002-10-29 4:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-21 3:02 UPD: Frequent/consistent panics in 2.4.19 at ip_route_input_slow, in_dev_get(dev) Alain Fauconnet
2002-10-21 16:40 ` kuznet
2002-10-22 3:24 ` Alain Fauconnet
2002-10-28 10:19 ` Alain Fauconnet
2002-10-29 1:30 ` kuznet
2002-10-29 4:13 ` Alain Fauconnet [this message]
2002-10-29 4:31 ` kuznet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021029111330.C15782@cscoms.net \
--to=alain@cscoms.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=lve@ns.aanet.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.