netdev - Re: [PATCH RESEND] ip_gre: sendto/recvfrom NBMA address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Oct 2007 08:54:42 +0300
From:	Timo Teräs <timo.teras@....fi>
To:	Alexey Kuznetsov <kuznet@....inr.ac.ru>
CC:	Patrick McHardy <kaber@...sh.net>, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH RESEND] ip_gre: sendto/recvfrom NBMA address

Hi,

Alexey Kuznetsov wrote:
>> The only dubious case is when next hop is set using routing tables.
>> But code in ipgre_tunnel_xmit() is ready to accept this situation,
>> it checks for zero destination address and fixes it when it is able to.
> 
> Nevertheless, it does not work.
> 
> Another thoughts?

Could you explain this a little more?

I was able to set a nbma gre tunnel, add routes to it and it worked
perfectly ok.

Link-level next hop worked:
ip route add <route> via <link-level-address> dev <tunnel-dev> onlink

Also normal route with static neighbor worked:
ip neigh add <router-tunnel-ip> lladdr <link-level-address> nud permanent dev <tunnel-dev>
ip route add <route> via <router-tunnel-ip>

In both cases packets were routed as expected to hosts accessible using
the added route. And sendto() sent a packet correctly with destination
link-level-address set. Did I miss/misunderstand something?

Cheers,
  Timo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html