before when we get the list of router ids for gossip it was highly bias towards outbound sessions.
instead now we get a full list of link session router ids in random order, truncate them to be at most MaxGossipPeers number of keys, and then put them into an unordered set
Removes stuff we didn't end up needing/using:
- Lokinet.modulemap
- apple bits from lokinet.cpp (we don't use lokinet.cpp at all on macos
anymore).
- dnsproxy/extension C++ headers
- apple-specific network extension config in llarp::config::Config
When we enable/disable exit mode on this restarts the unbound DNS
responder with the DNS trampoline (or restores upstream, when disabling)
to properly route DNS requests through the tunnel (because libunbound's
direct requests don't get tunneled because unbound is inside the network
extension).
This runs a DNS listener on localhost:1053 that bounces requests to the
upstream DNS through the tunnel. The idea here is that, when we turn on
exit mode, we start libunbound bouncing the requests through the
trampoline (since if it makes direct requests they won't go through the
tunnel).
(The actual libunbound configuration is still to follow).
Thus when a user goes looking for it they'll find the (commented out)
default in the right place and can edit it.
(That right place is: ~/Library/Containers/com.loki-project.lokinet.network-extension/Data/lokinet.ini)
Don't squash this commit so that the swift version stays around in
history in case we need to resurrect it again some day (i.e. when Apple
decides to kill off Objective-C support).
- Add a C callback interface (context_wrapper.h) between lokinet and the
objective-C code so that:
- we can use objective-C (rather than objective-C++), which seems more
likely to be supported by Apple into the future;
- we minimize the amount of code that needs to be aware of the Apple
APIs.
- this replaces apple logger objective c++ implementation with a plain
c++ implementation that takes a very simple C callback (provided
from the obj-c code) to actually make the call to NSLog.
- Add various documentation to the code of what is going on.
- Send all DNS traffic to the primary IP on the tun interface. The
match prefixes simply don't work as advertised, and have weird shit
(like even if you get it working for some domains, "instagram.com"
still doesn't because of god-knows-what Apple internal politics).
- Drop the dns proxy code as we don't need it anymore.
- Don't use 9.9.9.9 for default DNS. (We might consider the unfiltered
9.9.9.10 as an alternative default, but if we do it should be a global
lokinet change rather than a Mac-specific change).
- Parse a lokinet.ini in the data directory, if it exists. (Since we
are sandboxed, it is an app-specific "home" directory so is probably
buried god knows where, but at least the GUI ought to be able to get
it to let users add things to it).
- This commit also adds a swift version of the PacketTunnelProvider
glue, which ought to work in theory, but the *tooling* for cmake is so
underdeveloped that I couldn't find any way to actually get the damn
thing working. So I'm committing it here anyway (and will revert it
away in the next commit) in case we someday want to switch to it.
-
- Added contrib/macos/README.txt with description of the cancer
happening here.
- Add provisioningprofiles that Apple wants to make things work properly
- Made the entitlements files match the provisioningprofiles
- Remove configured entitlements files; we *can't* change any of the
things here because they are closedly tied to the provisioningprofiles
-- which means if someone wants to build their own Lokinet, they have
to replace a bunch of crap and change application IDs throughout.
This is the hostile-to-open-source Apple way.
- Remove unused old lokinet binary, as we're no longer using it on macos
- Use a POST_BUILD rather than install to copy things around into the
right places
- Convert all the configure_file's to consistently use @ONLY
- Misc cleanups
PR #1725 reversed argument orders but UnboundResolver was still using
(from,to) ordering in its callbacks, which leaked through to make a
wrong order in our reply function (which simply forwards arguments).
This fixes that bug by making UnboundResolver callback argument order
consistent (i.e. using to, from) with the PacketHandler argument order.
The reason the dns fix on android didn't work is that the DnsInterceptor
had a reversed to/from argument order for its
`SendServerMessageBufferTo` overload, and so android/mac needed the
to/from to be reversed so that the second reverse cancelled out the
first one.
Upon review, the DnsInterceptor order (to, from) is more intuitive than
the base order (from, to), so this reapplies the dns fix and swaps
everything *except* DnsInterceptor to match the (to, from) argument
order.
This reverts commit dace0224ec.
This reportedly didn't fix things on Android, and most definitely breaks
macOS (with this we get a bunch of errors about expecting inbound when
we have outbound).
