Interesting. I don't get the crash, and I don't run scc. I run soundmodem
and KISS. Does anyone running hardware other than scc ever
get this? (Or the 'is buggy' in the log?) Or does anyone running
scc never get this crash?
> I have already sent the forwarded message, but I found that those
> crashes don't have anything to do with the kernel messages that I'm
> getting.
>They are indeed harmless. I've found the place that generates these
>warnings... It only happens when received packets get sent to processes
l>ike listen(1) in raw mode: Sometimes they get mangled before the
>r>eceiving process gets them, and those warnings show exactly that this is
>happening. It seems to be a buglet in the ax25 receive routine. Harmless,
>because all that can happen is listen showing a broken frame now or then...
>(The data the application or TCP/IP stack gets is correct.)
Now, I'm totally confused. Isn't dev_queue_xmit trying to send a packet
to scc? I believe his log showed protocol is 0, and dev is scc. This is
the outbound scc queue, isn't it?
/* Never send packets back to the socket
* they originated from - MvS ([EMAIL PROTECTED])
*/
if ((ptype->dev == dev || !ptype->dev) &&
((struct sock *)ptype->data != skb->sk))
{
struct sk_buff *skb2;
/* Code, following below is wrong.
ONLY packet sockets receive outgoing
packets. If such a packet will be (occasionally)
received by normal packet handler, which expects
that mac header is pulled...
*/
/* More sensible variant. skb->nh should be
correctly
set by sender, so that the second statement is
just protection against buggy protocols.
*/
skb2->mac.raw = skb2->data;
What I thought it was saying, I think, was that someone queued a packet, but
didn't
initialize nh.raw somewhere. Even if something fussed with the data,
why would nh.raw go bad? I agree, this does hint at something in
ax25 and not scc, though I haven't gotten as far as deciding that it's
harmless -- and something really bad.
if (skb2->nh.raw < skb2->data || skb2->nh.raw >=
skb2->tail) {
if (net_ratelimit())
printk(KERN_DEBUG "protocol %04x is
buggy, dev %s
\n", skb2->protocol, dev->name);
skb2->nh.raw = skb2->data;
if (dev->hard_header)
skb2->nh.raw +=
dev->hard_header_len;
}
Here's the relevant quote from dev.c:
* BEWARE!!! Protocol handlers, mangling input packets,
* MUST BE last in hash buckets and checking protocol handlers
* MUST start from promiscous ptype_all chain in net_bh.
* It is true now, do not change it.
* Explantion follows: if protocol handler, mangling packet, will
* be the first on list, it is not able to sense, that packet
* is cloned and should be copied-on-write, so that it will
* change it and subsequent readers will get broken packet.
* --ANK (980803)
>I don't quite understand what a protocol handler is supposed to do,
>quite frankly I don't understand much of the "new" (as of 2.1.x)
>networking code anyway...
Me neither. And, I kept thinking it was something in scc.c. That driver
does a lot of interrupt code. That he has interaction with his ethernet
sort of hints to me that there could be some kind of weird confusion,
there. Though this is only susperstition.
