[Ipsec-tools-commits] [ ipsec-tools-Bugs-878346 ] Racoon: Packets can be sent with wrong from addres
Brought to you by:
mit_warlord,
netbsd
From: SourceForge.net <no...@so...> - 2005-04-26 18:51:46
|
Bugs item #878346, was opened at 2004-01-16 07:49 Message generated for change (Comment added) made by lomew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=878346&group_id=74601 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Racoon: Packets can be sent with wrong from address Initial Comment: If racoon is bound to a virtual interface (ie eth0:0), it can send packets with the wrong source address. It seems the problems lies within the sendfromto. For IPV4 it sets PKTINFO on the packet. In the packet info it sets ipi_addr (to the source ip) and ifindex (to 0). The kernel ignores ipi_addr though so the packet gets sent with the ip address of the eth0 interface. Since racoon seems to call bind() on its sockets, cutting out the setting of the cmsg and pktinfo stuff fixes the problem. ale...@c2... ---------------------------------------------------------------------- Comment By: Bart Robinson (lomew) Date: 2005-04-26 11:51 Message: Logged In: YES user_id=564731 as far as i can tell this is fixed in versions 5.0 and newer. i was having problems using source-routing and moving to that version fixed it for me. sendfromto was changed to set the ipi_spec_dst member with the source address. setting ipi_addr was a bug (it is ignored on sends, only used for recvs). ipi_spec_dst is the way to set the source address on a per-datagram basis, overriding whatever was done with bind. this is why commenting it out also worked -- racoon binds to the right source address. the reason it failed with the previous code, setting ipi_addr, was that it was also setting ipi_spec_dst to zero, and effectively telling the kernel to ignore the previous (correct) bind setting, and to do a normal route lookup, in my case just using the default route. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-02-18 09:23 Message: Logged In: NO To clarify, racoon is bound to a specific ip address, the one that is used by eth0:0. It sends packets with a from ip address that corresponds to eth0. Given that racoon is version 0.2.4 and linux kernel is version 2.6.2, and that we are talking ipv4: In the sendfromto function in racoon's sockmisc.c, lines 585 and 586 set the ipi_addr and ifindex of the in_pktinfo. ipi_addr is set to from address, and ipi_ifindex is set to 0 (always). memcpy(&pi->ipi_addr, &src6.sin_addr, sizeof(src6.sin_addr)); pi->ipi_ifindex = ifindex; In the ip_cmsg_send function in kernel's net/ipv4/ip_sockglue.c, lines 169 and 170 set the ipcm_cookie data. oif is set to the ipi_ifindex from in_pktinfo and addr is set to ipi_spec_dst.s_addr of of the in_pktinfo. ipc->oif = info->ipi_ifindex; ipc->addr = info->ipi_spec_dst.s_addr; So.. the from address that was set in the in_pktinfo by racoon gets ignored, but the if index isn't, and that is always 0. Assuming my greps of the kernel code for IP_PKTINFO turned up the relevant function of course ;-) Anyway, commenting out lines 575-587 of sockmisc.c solves the problems for me and packets are sent with a from address corresponding to the ip address of eth0:0. ale...@c2... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-02-13 14:57 Message: Logged In: NO Linux kernel - 2.2.x and up internally uses addresses bound to physical device. eth0:0 does NOT exist in kernel space. Betst thing to do would be to tell rcaoon to bind to a specific IP address ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=878346&group_id=74601 |