Re: Kernel 2.2.18: Protocol 0008 is buggy
> Is this really supposed to be done in the HW driver / support code level, > or is it supposed to be done in the protocol (IP / ARP) level?? oops I was half asleep Driver sets skb->mac.raw skb->pkt_type skb->protocol (see net/ethernet/eth.c) skb->h.raw and skb->nh.raw are set by the receive action code On transmit nh.raw is set by the protocol Note that non -ac kernels have a bug where a packet consisting of pure mac header causes bogus warnings - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
On Wed, 31 Jan 2001, Alan Cox wrote: > > It should be set before netif_rx() is called on the packet. Typically that > means the driver or its support code sets protocol and nh.raw and if a > second header is pulled up then they are set again by whichever code does that > and calls netif_rx again Another question. The function that prints the "buggy protocol" msg is dev_queue_xmit_nit(), which is called by dev_queue_xmit(). Isn't that a Tx function?? What would it have to do with netif_rx() (which from what I understand is called to send Rx packets upstream, not used in the Tx datapath)?? Thanks again! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
On Wed, 31 Jan 2001, Alan Cox wrote: > > What I'd like to know is: what exactly causes this msg?? It seems that > > it's printed when someone sends a packet without properly setting > > skb->nh.raw first, but who's supposed to set skb->nh.raw?? The HW driver?? > > The data link (HDLC) driver?? The kernel protocol drivers? How should I go > > about fixing this problem, where should I start?? > > It should be set before netif_rx() is called on the packet. Typically that > means the driver or its support code sets protocol and nh.raw and if a > second header is pulled up then they are set again by whichever code does that > and calls netif_rx again Alan, Could you please tell me where I can find an example of this?? I searched the whole drivers/net directory, and couldn't find any occurrence. Is this really supposed to be done in the HW driver / support code level, or is it supposed to be done in the protocol (IP / ARP) level?? Thanks for the reply!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
> The msg comes from net/core/dev.c, and this device is using the Cisco HDLC > protocol in drivers/net/hdlc.c . However, AFAIK, 0008 and 0608 represent > IP and ARP (respectively), not Cisco HDLC. So ... > > What I'd like to know is: what exactly causes this msg?? It seems that > it's printed when someone sends a packet without properly setting > skb->nh.raw first, but who's supposed to set skb->nh.raw?? The HW driver?? > The data link (HDLC) driver?? The kernel protocol drivers? How should I go > about fixing this problem, where should I start?? It should be set before netif_rx() is called on the packet. Typically that means the driver or its support code sets protocol and nh.raw and if a second header is pulled up then they are set again by whichever code does that and calls netif_rx again - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
On Wed, 31 Jan 2001, Alan Cox wrote: What I'd like to know is: what exactly causes this msg?? It seems that it's printed when someone sends a packet without properly setting skb-nh.raw first, but who's supposed to set skb-nh.raw?? The HW driver?? The data link (HDLC) driver?? The kernel protocol drivers? How should I go about fixing this problem, where should I start?? It should be set before netif_rx() is called on the packet. Typically that means the driver or its support code sets protocol and nh.raw and if a second header is pulled up then they are set again by whichever code does that and calls netif_rx again Alan, Could you please tell me where I can find an example of this?? I searched the whole drivers/net directory, and couldn't find any occurrence. Is this really supposed to be done in the HW driver / support code level, or is it supposed to be done in the protocol (IP / ARP) level?? Thanks for the reply!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
On Wed, 31 Jan 2001, Alan Cox wrote: It should be set before netif_rx() is called on the packet. Typically that means the driver or its support code sets protocol and nh.raw and if a second header is pulled up then they are set again by whichever code does that and calls netif_rx again Another question. The function that prints the "buggy protocol" msg is dev_queue_xmit_nit(), which is called by dev_queue_xmit(). Isn't that a Tx function?? What would it have to do with netif_rx() (which from what I understand is called to send Rx packets upstream, not used in the Tx datapath)?? Thanks again! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
Is this really supposed to be done in the HW driver / support code level, or is it supposed to be done in the protocol (IP / ARP) level?? oops I was half asleep Driver sets skb-mac.raw skb-pkt_type skb-protocol (see net/ethernet/eth.c) skb-h.raw and skb-nh.raw are set by the receive action code On transmit nh.raw is set by the protocol Note that non -ac kernels have a bug where a packet consisting of pure mac header causes bogus warnings - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.2.18: Protocol 0008 is buggy
Hello, I have a customer who's getting tons of these msgs in his LOGs: kernel: protocol 0008 is buggy, dev hdlc0 kernel: protocol 0608 is buggy, dev hdlc0 The msg comes from net/core/dev.c, and this device is using the Cisco HDLC protocol in drivers/net/hdlc.c . However, AFAIK, 0008 and 0608 represent IP and ARP (respectively), not Cisco HDLC. So ... What I'd like to know is: what exactly causes this msg?? It seems that it's printed when someone sends a packet without properly setting skb->nh.raw first, but who's supposed to set skb->nh.raw?? The HW driver?? The data link (HDLC) driver?? The kernel protocol drivers? How should I go about fixing this problem, where should I start?? I'm at a total loss here. Any help would be really appreciated. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.2.18: Protocol 0008 is buggy
Hello, I have a customer who's getting tons of these msgs in his LOGs: kernel: protocol 0008 is buggy, dev hdlc0 kernel: protocol 0608 is buggy, dev hdlc0 The msg comes from net/core/dev.c, and this device is using the Cisco HDLC protocol in drivers/net/hdlc.c . However, AFAIK, 0008 and 0608 represent IP and ARP (respectively), not Cisco HDLC. So ... What I'd like to know is: what exactly causes this msg?? It seems that it's printed when someone sends a packet without properly setting skb-nh.raw first, but who's supposed to set skb-nh.raw?? The HW driver?? The data link (HDLC) driver?? The kernel protocol drivers? How should I go about fixing this problem, where should I start?? I'm at a total loss here. Any help would be really appreciated. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
