Re: [PATCH v2 0/2] ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY

David Miller wrote [01.15.18]: > From: Jim Westfall > Date: Sun, 14 Jan 2018 04:18:49 -0800 > > > This used to be the previous behavior in older kernels but became broken in > > a263b3093641f (ipv4: Make neigh lookups directly in output packet path) > > and then l

[PATCH v2 0/2] ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY

| 56231|8487| 0| 65602|4685| 0| 79697|7047| 0| 90733|5517| 0| v2: - fixes coding style issues Jim Westfall (2): net: Allow neigh contructor functions ability to modify the primary_key ipv4: Make neigh lookup keys for loopback/point-to

[PATCH v2 2/2] ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY

0bb4087cbec0 (ipv4: Fix neigh lookup keying over loopback/point-to-point devices) because it was broken. Signed-off-by: Jim Westfall --- include/net/arp.h | 3 +++ net/ipv4/arp.c| 7 ++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/include/net/arp.h b/include/net/arp.h

[PATCH v2 1/2] net: Allow neigh contructor functions ability to modify the primary_key

Use n->primary_key instead of pkey to account for the possibility that a neigh constructor function may have modified the primary_key value. Signed-off-by: Jim Westfall --- net/core/neighbour.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/neighbour.c b/

[PATCH 2/2] ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY

0bb4087cbec0 (ipv4: Fix neigh lookup keying over loopback/point-to-point devices) because it was broken. Signed-off-by: Jim Westfall --- include/net/arp.h | 3 +++ net/ipv4/arp.c| 7 ++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/include/net/arp.h b/include/net/arp.h

[PATCH 1/2] net: Allow neigh contructor functions ability to modify the primary_key

Use n->primary_key instead of pkey to account for the possibility that a neigh constructor function may have modified the primary_key value. Signed-off-by: Jim Westfall --- net/core/neighbour.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/neighbour.c b/

[PATCH 0/2] ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY

| 56231|8487| 0| 65602|4685| 0| 79697|7047| 0| 90733|5517| 0| Jim Westfall (2): net: Allow neigh contructor functions ability to modify the primary_key ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY include

Re: NOARP devices and NOARP arp_cache entires

Jim Westfall wrote [01.11.18]: > Hi > > I'm seeing some weird behavior related to NOARP devices and NOARP > entries in the arp cache. > > I have a couple gre tunnels between a linux box and a upstream router that > send/recv a large amount of packets with unique

NOARP devices and NOARP arp_cache entires

n older kernels (3.2 time range) these NOARP entries didn't get added for ipv4, but they did for ipv6 if you pushed ipv6 through the ipv4 tunnel. 2804:14c:f281:a1d8:61a2:a30:989f:3eb1 dev tun1 lladdr 0.0.0.0 NOARP 2607:8400:2122:4:e9f9:dbb8:2d44:75d1 dev tun2 lladdr 0.0.0.0 NOARP Thanks Jim Westfall

[PATCH] llc: dont trust payload size on test cmd

Hi In testing its not safe to trust the payload length we are given in a received llc test command header. Instead we should calculate this ourselves or run the risk of an skb_over_panic() if the received length in the header is > then the actual payload size. Signed-off-by: Jim Westf

Re: [PATCH] llc: fix skb size for test responses

David Miller <[EMAIL PROTECTED]> wrote [02.24.08]: > From: Jim Westfall <[EMAIL PROTECTED]> > Date: Sun, 24 Feb 2008 11:07:58 -0800 > > > Hi > > > > The llc test command is used for a layer2 ping and contains a variable > > length payload that we m

[PATCH] llc: fix skb size for test responses

what was a hard coded skb of size 128. Signed-off-by: Jim Westfall <[EMAIL PROTECTED]> diff -urp linux-2.6.24.2.org/net/llc/llc_s_ac.c linux-2.6.24.2/net/llc/llc_s_ac.c --- linux-2.6.24.2.org/net/llc/llc_s_ac.c 2008-02-10 21:51:11.0 -0800 +++ linux-2.6.24.2/net/llc/llc_

Re: kernel BUG at net/core/skbuff.c:95!

David Miller <[EMAIL PROTECTED]> wrote [02.20.08]: > From: Jim Westfall <[EMAIL PROTECTED]> > Date: Wed, 20 Feb 2008 21:46:48 -0800 > > > static inline void llc_pdu_init_as_test_rsp(struct sk_buff *skb, > >

Re: kernel BUG at net/core/skbuff.c:95!

c packet onto the 128 byte skb, which triggers the panic. thanks jim Jim Westfall <[EMAIL PROTECTED]> wrote [02.19.08]: > Hi > > I have a reproducible crash that can be triggered remotely at the layer2 > level. Example crash outputs is as follows > > kernel: skb_over_panic

kernel BUG at net/core/skbuff.c:95!

Hi I have a reproducible crash that can be triggered remotely at the layer2 level. Example crash outputs is as follows kernel: skb_over_panic: text:c0541fc7 len:1000 put:997 head:c166ac00 data:c166ac2f tail:0xc166b017 end:0xc166ac80 dev:eth0 kernel: [ cut here ] kernel:

tg3 losing promisc rx_mode bit

Hi I have a number of ibm x336 servers that have the following 2 onboard nics (eth0/1 are 2 other bcm57xx nics on a PCIX card). kernel version is 2.6.15.4, though I have tried 2.4.32/2.6.14-rc4 and they both have the issue below. ACPI: PCI Interrupt :06:00.0[A] -> GSI 16 (level, low) ->