On 2016/12/15 4:15, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 14 Dec 2016, YueHaibing wrote:
>
>> On 2016/11/26 4:40, Julian Anastasov wrote:
>>>
>>> So, the idea is to move TCP and other similar
>>> users to the new dst_confirm_sk() method. If other
>>> dst_confirm() users are
Hello,
On Wed, 14 Dec 2016, YueHaibing wrote:
> On 2016/11/26 4:40, Julian Anastasov wrote:
> >
> > So, the idea is to move TCP and other similar
> > users to the new dst_confirm_sk() method. If other
> > dst_confirm() users are left, they should be checked
> > if dsts with
On 2016/11/26 4:40, Julian Anastasov wrote:
>
> Hello,
>
> On Fri, 25 Nov 2016, Hannes Frederic Sowa wrote:
>
>> On 25.11.2016 09:18, Julian Anastasov wrote:
>>>
>>> Another option would be to add similar bit to
>>> struct sock (sk_dst_pending_confirm), may be ip_finish_output2
>>>
Hello,
On Fri, 25 Nov 2016, Hannes Frederic Sowa wrote:
> On 25.11.2016 09:18, Julian Anastasov wrote:
> >
> > Another option would be to add similar bit to
> > struct sock (sk_dst_pending_confirm), may be ip_finish_output2
> > can propagate it to dst_neigh_output via new arg and
On 25.11.2016 09:18, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 24 Nov 2016, Hannes Frederic Sowa wrote:
>
>> I think some people are thinking about it already (me also ;) ).
>>
>> But it is not easy to come up with a solution. First of all, we need to
>> look up the L2 address again
Hello,
On Thu, 24 Nov 2016, Hannes Frederic Sowa wrote:
> I think some people are thinking about it already (me also ;) ).
>
> But it is not easy to come up with a solution. First of all, we need to
> look up the L2 address again in the neighbor cache and confirm the
> appropriate
On 24.11.2016 10:06, YueHaibing wrote:
> On 2016/11/24 15:51, Julian Anastasov wrote:
>>
>> Hello,
>>
>> On Wed, 23 Nov 2016, Eric Dumazet wrote:
>>
>>> On Wed, 2016-11-23 at 15:37 +0100, Hannes Frederic Sowa wrote:
>>>
Irregardless about the question if bonding should keep the MAC
On 2016/11/24 15:51, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 23 Nov 2016, Eric Dumazet wrote:
>
>> On Wed, 2016-11-23 at 15:37 +0100, Hannes Frederic Sowa wrote:
>>
>>> Irregardless about the question if bonding should keep the MAC address
>>> alive, a MAC address can certainly
Hello,
On Wed, 23 Nov 2016, Eric Dumazet wrote:
> On Wed, 2016-11-23 at 15:37 +0100, Hannes Frederic Sowa wrote:
>
> > Irregardless about the question if bonding should keep the MAC address
> > alive, a MAC address can certainly change below a TCP connection.
>
> Of course ;)
>
> >
On Wed, 2016-11-23 at 15:37 +0100, Hannes Frederic Sowa wrote:
> Irregardless about the question if bonding should keep the MAC address
> alive, a MAC address can certainly change below a TCP connection.
Of course ;)
>
> dst_entry is 1:n to neigh_entry and as such we can end up confirming an
>
On 23.11.2016 13:05, Eric Dumazet wrote:
> On Wed, 2016-11-23 at 10:33 +0200, Julian Anastasov wrote:
>> Hello,
>>
>> On Wed, 23 Nov 2016, yuehaibing wrote:
>>
>>> As to my topo,HOST1 and HOST3 share one route on HOST2, tcp connection
>>> between HOST2 and HOST3 may call tcp_ack to set
On Wed, 2016-11-23 at 10:33 +0200, Julian Anastasov wrote:
> Hello,
>
> On Wed, 23 Nov 2016, yuehaibing wrote:
>
> > As to my topo,HOST1 and HOST3 share one route on HOST2, tcp connection
> > between HOST2 and HOST3 may call tcp_ack to set dst->pending_confirm.
> >
> > So
Hello,
On Wed, 23 Nov 2016, yuehaibing wrote:
> As to my topo,HOST1 and HOST3 share one route on HOST2, tcp connection
> between HOST2 and HOST3 may call tcp_ack to set dst->pending_confirm.
>
> So dst_neigh_output may wrongly freshed n->confirmed which stands for
>
Hi,
I've encountered a arp cache aging failed bug in 4.9 kernel.The topo is
as follow:
HOST1 -
IP1 | Switch |IP2-| HOST2 |
|
14 matches
Mail list logo
