Opened 7 years ago

Closed 4 years ago

#42 closed Bug / Defect (fixed)

Default gateway not found on darwin 10.6 x86_64

Reported by: samuli Owned by: cron2
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


Under darwin 10.6 x86_x64 the default gateway is not found. Openvpn (2.1_rc21 and 15) reports default_gateway= 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 7 years ago by samuli

Originally reported to by Serge Droz (

comment:2 Changed 7 years ago by samuli

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


comment:3 Changed 6 years ago by davids

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 5 years ago by samuli

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 5 years ago by samuli

  • Keywords gateway darwin added

comment:6 Changed 4 years ago by cron2

  • Owner set to cron2
  • Status changed from new to 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 4 years ago by cron2

  • 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 4 years ago by cron2

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 right now to see when it was changed in SVN...

comment:9 Changed 4 years ago by cron2

  • Resolution set to fixed
  • Status changed from assigned to 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.

Note: See TracTickets for help on using tickets.