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 in the neighbor cache and confirm the >> appropriate neighbor. Secondly we should only do that for packets which >> we can actually confirm (that means passing the TCP recv tests or some >> other kind of confirmation besides simply spamming the box etc). Also it >> needs to be fast. > > 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 then to > reset it.
I don't understand how this can help? Maybe I understood it wrong? > Or to change n->confirmed via some new inline sock > function instead of changing dst_neigh_output. At this place > skb->sk is optional, may be we need (skb->sk && dst == > skb->sk->sk_dst_cache) check. Also, when sk_dst_cache changes > we should clear this flag. In "(skb->sk && dst == skb->sk->sk_dst_cache)" where does dst come from? I don't see a possibility besides using mac_header or inner_mac_header to look up the incoming MAC address and confirm that one in the neighbor cache so far (we could try to optimize this case for rt_gateway though). Bye, Hannes
