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
| ||
|
Message-ID: <alpine.LFD.2.00.1210232317400.1780@ja.ssi.bg> Date: Wed, 24 Oct 2012 03:15:01 +0300 (EEST) From: Julian Anastasov <ja@....bg> To: Sergey Popovich <popovich_sergei@...l.ru> cc: netdev@...r.kernel.org Subject: Re: Incorrect ARP behavior when multiple/none IPv4 address assigned to interface Hello, On Tue, 23 Oct 2012, Sergey Popovich wrote: > Hello! > > We have following setup: > ------------------------ > > PC1 | | > ip: 10.0.1.2/24 | | Linux Router (3.7-rc2) > gw: 10.0.1.1 |--------eth0-| Lo0: 10.10.10.10/32 > | Lo255: 10.0.1.1/24 > PC2 |--------eth1-| 10.0.2.1/24 > ip: 10.0.1.3/24 | | eth[0-2]: no ip address > gw: 10.0.1.1 | | ip route 10.0.1.2/32 dev eth0 src 10.0.1.1 > +-| ip route 10.0.1.3/32 dev eth1 src 10.0.1.1 > | | ip route 10.0.2.2/32 dev eth2 src 10.0.2.1 > PC3 |-----eth2--+ > ip: 10.0.2.2/24 | > gw: 10.0.2.1 | > > > Problem with ARP Requests sent with incorrect source address (10.10.10.10 > instead of 10.0.1.1): > > # tcpdump -vv -ieth0 -s1500 -nnpe 'arp' > 13:28:57.395181 08:00:27:3b:63:ae > 0a:00:27:00:00:00, ethertype ARP (0x0806), > length 42: Ethernet (len 6),. > IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28 What kind of packet triggers ARP request here? May be this IP packet already has saddr=10.10.10.10 ? arp_solicit() when eth0/arp_announce=0 (default) just ensures that this saddr is local. Or it is a forwarding case and inet_select_addr is used? Also, any reason to put addresses on loopback and not on eth0? > 13:28:58.395257 08:00:27:3b:63:ae > 0a:00:27:00:00:00, ethertype ARP (0x0806), > length 42: Ethernet (len 6),. > IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28 > 13:28:59.395207 08:00:27:3b:63:ae > 0a:00:27:00:00:00, ethertype ARP (0x0806), > length 42: Ethernet (len 6),. > IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28 > 13:29:01.393739 08:00:27:3b:63:ae > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), > length 42: Ethernet (len 6),. > IPv4 (len 4), Request who-has 10.0.1.2 tell 10.0.1.1, length 28 > 13:29:01.393862 0a:00:27:00:00:00 > 08:00:27:3b:63:ae, ethertype ARP (0x0806), > length 60: Ethernet (len 6),. > IPv4 (len 4), Reply 10.0.1.2 is-at 0a:00:27:00:00:00, length 46 > > Detailed information about this (and other, that triggers same case with ARP) > network topology usage in real world > can be found at https://bugzilla.kernel.org/show_bug.cgi?id=49311 Your case 2 can be also solved with proper ordering of the primaries, eg. first add /32 primaries, then /31, ... /25, /24. You can also use decreasing scope for the addresses if global scope is not needed for them, it can help for the ordering. For the proposed patch: providing iph->saddr to inet_select_addr() in icmp_send() looks better than before. Still, inet_select_addr() is incorrect function to use from icmp_send(), there is the risk to expose scope link addresses. The other part from patch in inet_select_addr() looks correct to me but comes with some price for the arp_solicit() and icmp_send() cases, a slowdown that may not be liked by others. About fib_info_update_nh_saddr: same fib_info can be used for different subnets, so we can not check the destination. But routes to directly connected hosts usually come with prefsrc (proto kernel), so it is not a problem. > Sorry for early bug report. > > -- > SP5474-RIPE > Sergey Popovich Regards -- Julian Anastasov <ja@....bg> -- 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