Opened 14 years ago
Closed 10 years ago
#42 closed Bug / Defect (fixed)
Default gateway not found on darwin 10.6 x86_64
Reported by: | Samuli Seppänen | Owned by: | Gert Döring |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Networking | Version: | OpenVPN 2.1.0 / 2.1.1 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | gateway darwin |
Cc: | plaisthos |
Description
Under darwin 10.6 x86_x64 the default gateway is not found. Openvpn (2.1_rc21 and 15) reports default_gateway=0.0.0.0 rather than the correct gatway. Thus no packets ever reach the server. Compiling as an 32 bit binary seems to work though.
Change History (9)
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
Original SF.net comments:
Date: 2010-02-26 11:52:22 EET Sender: dazo Could you please provide complete log files (verb set to 4) and configuration files? --- Date: 2010-02-26 13:36:46 EET Sender: sdroz Here are the requested files. THe scripts called are actaually never called with the 64bit versione (it just doesn't get that far), so I haven't provided them. Serge
comment:3 Changed 12 years ago by
The problem is in get_default_gateway() in route.c. Old versions of the rt_metrics and rt_msghdr structures are included rather than using <net/route.h>. The u_long definitions in the older versions have been replaced with u_int32_t references, which means that get_default_gateway() is built for a 64-bit platform, it is obtaining the wrong values when looking at the data returned from the routing socket.
One simple fix is to delete lines 1772-1819, and include <net/route.h>, with the result looking like:
#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <net/route.h> struct { struct rt_msghdr m_rtm; char m_space[512]; } m_rtmsg;
comment:4 Changed 11 years ago by
This bug report was filed against a very old OpenVPN version. Can somebody confirm that this is still an issue with latest OpenVPN versions?
comment:5 Changed 11 years ago by
Keywords: | gateway darwin added |
---|
comment:6 Changed 10 years ago by
Owner: | set to Gert Döring |
---|---|
Status: | new → assigned |
there is a good chance that the issue is still there, given trac#340 and the "locally copied" route structures.
I'll look into it.
comment:7 Changed 10 years ago by
Cc: | plaisthos added |
---|
It works on my 10.5 system, but that is i386 only anyway.
It actually fails on OpenBSD 4.9 (Could not retrieve default gateway from route socket:: Protocol not supported (errno=43)), while it works on FreeBSD 9.1/amd64...
Plaisthos, could you test on current MacOS 64bit? Just verifying that this problem still exists.
comment:8 Changed 10 years ago by
This code is quite a mess (see also #340, which is related).
OpenBSD, FreeBSD, Dragonfly and NetBSD share one "copy" of the code, which uses "long" for this arithmetic (#define ROUNDUP ...), while DARWIN uses "uint32_t". On FreeBSD, this really has to be "long", using uint32_t will make it fail on amd64 systems - so I guess that could be the reason why it's working on MacOS 32bit, and failing on MacOS 64bit.
I think that *this* bug has actually fixed long ago, as the MacOS copy of "that code" in route.c removed the local copies of the definitions, and is nicely doing the #include <net/route.h> - and from what "git blame" is telling me, this was actually fixed (for MacOS) before 2.1_beta1 even started. I can't check svn.openvpn.net right now to see when it was changed in SVN...
comment:9 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Found someone with a brand new apple laptop with a 64bit OSX on it (Mavericks even) and OpenVPN 2.3-alpha1 (from Tunnelblick 3.3beta21b) works correct regarding --show-gateway.
So we can close this, as it got fixed on MacOS long ago. #340 will keep me busy for a bit longer.
Originally reported to SF.net by Serge Droz (http://sourceforge.net/users/sdroz).