On Sat, Sep 1, 2018 at 4:51 PM, David Miller wrote:
> From: Vasily Khoruzhick
> Date: Tue, 28 Aug 2018 19:48:25 -0700
>
>> Update 'confirmed' timestamp when ARP packet is received. It shouldn't
>> affect locktime logic and anyway entry can be confirmed by any higher-layer
>> protocol. Thus it mak
at fault, but we will need to accommodate.
Fixes: 7d472a59c0e5ec117220a05de6b370447fb6cb66
Signed-off-by: Ihar Hrachyshka
---
net/ipv4/arp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index ae96e6f..e9f3386 100644
--- a/net/ipv4/arp.c
+++ b/n
On 05/18/2017 01:49 PM, Julian Anastasov wrote:
All 4 patches look ok to me with only a small problem
which comes from patch already included in kernel. I see
that GARP replies can not work for 1394, is_garp will be
cleared. May be 'tha' check should be moved in if expression,
for exampl
On 05/23/2017 01:56 PM, Arnd Bergmann wrote:
This seems to have caused a build warning:
net/ipv4/arp.c:880:35: warning: 'addr_type' may be used uninitialized
in this function [-Wmaybe-uninitialized]
Not sure. How do you reproduce it? I just did 'make net' in the latest
tree that includes the p
not aligned in time when multiple IP address carriers send
them into network.
This patch enforces overriding of existing neigh entries by all incoming
gratuitous ARP packets, irrespective of their time of arrival. This will
make the kernel honour all incoming gratuitous ARP packets.
Signed-off-by: I
The code is quite involving already to earn a separate function for
itself. If anything, it helps arp_process readability.
Signed-off-by: Ihar Hrachyshka
---
net/ipv4/arp.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/arp.c b
t the costly operation will be executed for all setups.
The patch is the result of a discussion in net-dev:
http://marc.info/?l=linux-netdev&m=149506354216994
Suggested-by: Julian Anastasov
Signed-off-by: Ihar Hrachyshka
---
net/ipv4/arp.c | 24 +---
1 file changed, 17 i
the is_garp code deals just with gratuitous ARP packets, not every
unsolicited packet.
This patch is a result of a discussion in netdev:
http://marc.info/?l=linux-netdev&m=149506354216994
Suggested-by: Julian Anastasov
Signed-off-by: Ihar Hrachyshka
---
net/ipv4/arp.c | 2 +-
1 file cha
eview comments by Julian Anastasov
- fixed a mistake in a comment;
- postponed addr_type calculation to as late as possible.
Ihar Hrachyshka (4):
arp: fixed error in a comment
arp: decompose is_garp logic into a separate function
arp: postpone addr_type calculation to as late as possible
The code is quite involving already to earn a separate function for
itself. If anything, it helps arp_process readability.
Signed-off-by: Ihar Hrachyshka
---
net/ipv4/arp.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/arp.c b
not aligned in time when multiple IP address carriers send
them into network.
This patch enforces overriding of existing neigh entries by all incoming
gratuitous ARP packets, irrespective of their time of arrival. This will
make the kernel honour all incoming gratuitous ARP packets.
Signed-off-by: I
ch in the series moves is_garp code into a separate function
preparing the code base for the 2nd patch that actually implements the needed
change.
Ihar Hrachyshka (2):
arp: decompose is_garp logic into a separate function
arp: always override existing neigh entries with gratuitous ARP
net
On Mon, May 15, 2017 at 2:40 PM, Ihar Hrachyshka wrote:
> It's a common practice to send gratuitous ARPs after moving an
> IP address to another device to speed up healing of a service. To
> fulfill service availability constraints, the timing of network peers
> updating their c
layer. This would require tracking timestamps for state transitions
separately from timestamps when actual updates are received. This would
probably involve changes in neighbour struct. Therefore, the patch
doesn't tackle the issue of the first gratuitous APR ignored, leaving
it for a follow-up.
Signe
On Mon, May 15, 2017 at 2:16 PM, Ihar Hrachyshka wrote:
> When arp_accept is 1, gratuitous ARPs are supposed to override matching
> entries irrespective of whether they arrive during locktime. This was
> implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address
>
l ignore such
broadcasts. Note that they will still update existing ARP cache entries,
assuming they arrive out of locktime time interval.
Signed-off-by: Ihar Hrachyshka
---
v2:
- removed #ifdef for CONFIG_FIREWIRE_NET
---
net/ipv4/arp.c | 16 ++--
1 file changed, 14 insertions(+), 2
layer. This would require tracking timestamps for state transitions
separately from timestamps when actual updates are received. This would
probably involve changes in neighbour struct. Therefore, the patch
doesn't tackle the issue of the first gratuitous APR ignored, leaving
it for a follow-up.
Signe
On Mon, May 15, 2017 at 1:05 PM, Julian Anastasov wrote:
>
> It seems arp_accept value currently has influence on
> the locktime for GARP requests. My understanding is that
> locktime is used to ignore replies from proxy_arp
> routers while the requested IP is present on the LAN
> and repl
l ignore such
broadcasts. Note that they will still update existing ARP cache entries,
assuming they arrive out of locktime time interval.
Signed-off-by: Ihar Hrachyshka
---
net/ipv4/arp.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/arp.c b/ne
l ignore such
broadcasts. Note that they will still update existing ARP cache entries,
assuming they arrive out of locktime time interval.
Signed-off-by: Ihar Hrachyshka
---
net/ipv4/arp.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/arp.c b/ne
kle the issue of the first gratuitous APR ignored, leaving
it for a follow-up.
Signed-off-by: Ihar Hrachyshka
---
net/core/neighbour.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 58b0bcc..d274f81 100644
---
21 matches
Mail list logo
