netdev - Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 06 Apr 2011 13:28:29 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hirofumi@...l.parknet.co.jp
Cc:	netdev@...r.kernel.org
Subject: Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output
 routes."

From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Date: Tue, 05 Apr 2011 22:05:10 +0900

> ipv4: Set rt->rt_iif more sanely on output routes.
> (1018b5c01636c7c6bda31a719bda34fc631db29a)
> 
> The above patch seems to be caused of avahi breakage.
> 
> I'm not debugging fully though, avahi is using IP_PKTINFO and checking
> in_pktinfo->ipi_ifindex > 0.
> 
> And if I reverted above patch, it seems to fix avahi's IP_PKTINFO problem.

in_pktinfo is given to the application only during recvmsg() calls, the
call chain is (for example):

udp_recvmsg()
	--> ip_cmsg_recv()
		--> ip_cmsg_recv_pktinfo()

Therefore we will only be working with receive packets, whose routes are
computed using ip_route_input*() which will fill in the rt_iif field
appropriately.

The only exception to this would be packets which are looped back, in
which case the cached output route attached to the packet will be used.

Your RFC patch should work, but we're trying to make "struct rtable"
smaller rather than larger.

In what way does routing break if you simply restore the original
rt_iif assignment in output route creation?  That's the most preferred
fix for this.
--
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