Hi Arthur,
Sorry for the immense delay, fortunately David ping()ed me on this
issue a few days ago.
On Tue, Jul 20, 2010 at 10:08 PM, Arthur Titeica <art...@psw.ro> wrote:
> On Tuesday 20 July 2010 01:25:47 David Sommerseth wrote:
>> On 19/07/10 22:32, Arthur Titeica wrote:
>> > On Sunday 02 May 2010 02:34:47 Peter Rabbitson wrote:
>> >> David Sommerseth wrote:
>> >>> On 01/05/10 21:39, Peter Rabbitson wrote:
>> >>>> Peter Rabbitson wrote:
>> >>>>> Peter Rabbitson wrote:
>> >>>>>> Samuli Seppänen wrote:
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>> Is someone successfully using the --multihome option on latest
>> >>>>>>> OpenVPN release? Or is this bug report still valid:
>> >>>>>>>
>> >>>>>>> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562099>
>> >>>>>>
>> >>>>>> I am sorry I dropped the ball on testing that one. Will test the
>> >>>>>> coming night EST, and update.
>> >>>>>
>> >>>>> Looking more at the *debian* changelog, I see that there was a 3rd
>> >>>>> party ipv6 patch, which *could* have caused these problems. However
>> >>>>> it is not very easy for me to compile a "clean" openvpn on the
>> >>>>> multihomed server. Please let me know if this can be diagnosed in
>> >>>>> any other way, if not - I will find a way to test with vanilla
>> >>>>> openvpn.
>> >>>>
>> >>>> And unfortunately I was right (proven with the help of [1]) :(
>> >>>>
>> >>>> openvpn_2.1~rc20-1_i386.deb works
>> >>>> openvpn_2.1~rc20-2_i386.deb does not
>> >>>>
>> >>>> The only code-change between the two is:
>> >>>> * patches/jjo-ipv6-support.patch: Added ipv6 support. (Closes:
>> >>>> #307846)
>> >>>>
>> >>>> Patch from JuanJo Ciarlante.
>> >>>>
>> >>>> So this got to be the culprit. Attaching a -U10 diff between the
>> >>>> sources of both debian packages (not too long):
>> >>>>
>> >>>> [1] http://snapshot.debian.org/package/openvpn/
>> >>>
>> >>> Thank you very much, Peter, for tracking this one down! One question
>> >>> though. Do you have configuration files and a "how to test it"
>> >>> description available which you could share with us? That would help
>> >>> others to test it out as well - and it might help JJO to follow this
>> >>> one further.
>> >
>> > Hello,
>> > I'm using the latest git
>> > (git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git)
>> > and multihome doesn't seems to work as far as I've tested.
>> >
>> > I have 2 links balanced with something like
>> >
>> > # ip route show
>> > ...
>> > default
>> >
>> > nexthop via x.x.x.x dev eth2 weight 2
>> > nexthop via y.y.y.y dev ppp5 weight 1
>> >
>> > and openvpn somehow fails with or without multihome.
>> >
>> > I'm not a programmer but I'dd gladly help with anything else (making
>> > tests, patches or even providing a test multihomed openvpn server).
>>
>> (moving over to the developers mailing list)
>>
>> Thank you for your testing! If you put together some configuration
>> files for client and server and a clear description of how to test this,
>> that would save a lot of time for us when digging into the code.
>>
>> If your config files makes use of certificates, please make your test
>> environment work by using the keys in the source tree, located in the
>> sample-keys/ directory.
>>
>> Please try to make the config files for us as close to your setup as
>> possible. This will really help us get closer to understand what
>> exactly happens.
>>
>> I have opened a bug ticket on this issue, to not forget this issue. It
>> can be tracked here:
>> <https://community.openvpn.net/openvpn/ticket/28>
>>
>> Please report back with configuration files and a description of how to
>> prepare an environment for reproducing this behaviour.
>>
>>
>
> Hello,
> I've managed to setup a test dual-homed server with the following configs:
>
> server: http://psw.ro/tmp/test-server.conf
> client: http://psw.ro/tmp/test-client.conf
>
> With verb 6 on the client after successfully connecting thru one of the links
> - connecting thru the second link hangs for a period of ~10 minutes with the
> following log:
>
> client-log1: http://psw.ro/tmp/client-log1.log
>
> If needed I'll try to find some time to better describe my network setup.
I think I fixed it, is there a chance you could try recompiling openvpn
with the attached patch ?
Cheers!,
>
> Thanks.
>
> --
> Arthur Titeica
> PharmEc Software Constanta
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
>
--
--JuanJo ; echo j...@gomosglep.com | sed 's/[SPAM]//g'
From 1b96baa8fc964bfba8bfba87f1e0e1fbabf0b47b Mon Sep 17 00:00:00 2001
From: JuanJo Ciarlante <jjo...@google.com>
Date: Thu, 23 Sep 2010 01:15:35 +0200
Subject: [PATCH] * fix --multihome for ipv4: cmsg_len must compare against in_pktinfo
size, not the full 4+6 union, also use saner variable names.
---
socket.c | 27 ++++++++++++++-------------
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/socket.c b/socket.c
index 288b58a..810bb23 100644
--- a/socket.c
+++ b/socket.c
@@ -2436,6 +2436,7 @@ print_link_socket_actual_ex (const struct link_socket_actual *act,
{
struct openvpn_sockaddr sa;
CLEAR (sa);
+ sa.addr.in4.sin_family = AF_INET;
sa.addr.in4.sin_addr = act->pi.in4.ipi_spec_dst;
buf_printf (&out, " (via %s)", print_sockaddr_ex (&sa, separator, 0, gc));
}
@@ -2779,7 +2780,7 @@ link_socket_read_tcp (struct link_socket *sock,
struct openvpn_in4_pktinfo
{
struct cmsghdr cmsghdr;
- struct in_pktinfo pi;
+ struct in_pktinfo pi4;
};
#ifdef USE_PF_INET6
struct openvpn_in6_pktinfo
@@ -2790,9 +2791,9 @@ struct openvpn_in6_pktinfo
#endif
union openvpn_pktinfo {
- struct openvpn_in4_pktinfo cmsgpi;
+ struct openvpn_in4_pktinfo msgpi4;
#ifdef USE_PF_INET6
- struct openvpn_in6_pktinfo cmsgpi6;
+ struct openvpn_in6_pktinfo msgpi6;
#endif
};
#pragma pack()
@@ -2815,7 +2816,7 @@ link_socket_read_udp_posix_recvmsg (struct link_socket *sock,
mesg.msg_name = &from->dest.addr;
mesg.msg_namelen = fromlen;
mesg.msg_control = &opi;
- mesg.msg_controllen = sizeof (opi);
+ mesg.msg_controllen = sizeof opi;
buf->len = recvmsg (sock->sd, &mesg, 0);
if (buf->len >= 0)
{
@@ -2826,7 +2827,7 @@ link_socket_read_udp_posix_recvmsg (struct link_socket *sock,
&& CMSG_NXTHDR (&mesg, cmsg) == NULL
&& cmsg->cmsg_level == SOL_IP
&& cmsg->cmsg_type == IP_PKTINFO
- && cmsg->cmsg_len >= sizeof (opi))
+ && cmsg->cmsg_len >= sizeof (struct openvpn_in4_pktinfo))
{
struct in_pktinfo *pkti = (struct in_pktinfo *) CMSG_DATA (cmsg);
from->pi.in4.ipi_ifindex = pkti->ipi_ifindex;
@@ -2914,15 +2915,15 @@ link_socket_write_udp_posix_sendmsg (struct link_socket *sock,
{
case AF_INET:
{
- struct openvpn_in4_pktinfo opi;
+ struct openvpn_in4_pktinfo msgpi4;
struct in_pktinfo *pkti;
mesg.msg_name = &to->dest.addr.sa;
mesg.msg_namelen = sizeof (struct sockaddr_in);
- mesg.msg_control = &opi;
- mesg.msg_controllen = sizeof (opi);
+ mesg.msg_control = &msgpi4;
+ mesg.msg_controllen = sizeof msgpi4;
mesg.msg_flags = 0;
cmsg = CMSG_FIRSTHDR (&mesg);
- cmsg->cmsg_len = sizeof (opi);
+ cmsg->cmsg_len = sizeof (struct openvpn_in4_pktinfo);
cmsg->cmsg_level = SOL_IP;
cmsg->cmsg_type = IP_PKTINFO;
pkti = (struct in_pktinfo *) CMSG_DATA (cmsg);
@@ -2934,15 +2935,15 @@ link_socket_write_udp_posix_sendmsg (struct link_socket *sock,
#ifdef USE_PF_INET6
case AF_INET6:
{
- struct openvpn_in6_pktinfo opi6;
+ struct openvpn_in6_pktinfo msgpi6;
struct in6_pktinfo *pkti6;
mesg.msg_name = &to->dest.addr.sa;
mesg.msg_namelen = sizeof (struct sockaddr_in6);
- mesg.msg_control = &opi6;
- mesg.msg_controllen = sizeof (opi6);
+ mesg.msg_control = &msgpi6;
+ mesg.msg_controllen = sizeof msgpi6;
mesg.msg_flags = 0;
cmsg = CMSG_FIRSTHDR (&mesg);
- cmsg->cmsg_len = sizeof (opi6);
+ cmsg->cmsg_len = sizeof (struct openvpn_in6_pktinfo);
cmsg->cmsg_level = IPPROTO_IPV6;
cmsg->cmsg_type = IPV6_PKTINFO;
pkti6 = (struct in6_pktinfo *) CMSG_DATA (cmsg);
--
1.7.1
