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]
Message-Id: <20110406.132829.116375350.davem@davemloft.net>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ