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]

Message-ID: <87ipuqsmwl.fsf@devron.myhome.or.jp>
Date:	Thu, 07 Apr 2011 13:31:06 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."

David Miller <davem@...emloft.net> writes:

> 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.

I see.

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

I felt it from git hisotry.

> 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.

I'm not pretty sure though, output message is

	ip_finish_output2: No header cache and no neighbour!

I'm not debugging this though,

static inline bool rt_is_output_route(struct rtable *rt)
{
	return rt->rt_iif == 0;
}

from review I guess the above is one of cause.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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