On some platforms and/or some libpcap verisons, libpcap doesn't support a
timeout which makes interactive stop not possible. So we now use a UNIX
signal to break out. Obviously this works only on *nix platforms - which
includes MacOS. For now the problem is not seen on Windows with WinPCAP,
so we should be fine. May need to revisit when we add Npcap support.
Fixes#215, #234
Enable logs if '-d' command-line option is given.
Additional command-line options -
-v : print version
-h : print usage
Drone only:
-p <port-number> : use given port number for the RPC service
For 64-bit arch, Qt defines quint64 as unsigned long long (and quint32 as unsigned int), but Protobuf's google::protobuf::uint64 is defined as unsigned long. Now Qt defines qbswap only for the Qt defined 8/16/32/64 integer types aka q[u]intXXX. So qbswap<unsigned long long> and qbswap<unsigned int> is defined but not qbswap<unsigned long>.
mld.cpp was using qToBigEndian (which uses qbswap in turn) with a protobuf uint64 triggering the undefined references on some 64bit platforms.
Fixes#265
Since build is now the last step during "apply", use that to mark sync
complete. Since build will always be called irrespective of whether any
changes were made to devices/streams, we can now send the stream RPCs
only if required.
Additionally log RPC calls only if they are actually made.
Results will be displayed in a message box - if we have a new version or
if we are running the latest version.
Update check at startup will show message box only once in 5 days, other
times it will be shown in the status bar. If we are already on latest
version, nothing is shown.
* Fix SA_SIZE definition for MacOS
* Use sdl_index instead of rtm_index as the ifIndex
* Remove the embedded ifIndex in link local addresses
* Extract default IPv6 gateway correctly
The most time spent during apply is during packet rebuilding.
Unfortunately, there is no feedback from the drone to know the actual
progress, so this is just a busy indicator for now.
I tried to put a jump url to the FAQ on why it takes time, but 'coz the
app cursor is a "wait cursor", user cannot click on any widgets/elements
inside the dialog box - so this won't work.
Iterate on this dialog and what it displays based on user feedback.
This better reflects the following -
RPC fail : complete failure of the RPC; no changes were made
RPC error: partial failure of the RPC; some changes were made, some had
errors
Currently these are printed at the end of init when we start waiting for
client connections - this was done so that this info doesn't get lost in
the barrage of init logs. The downside is if there is a crash during
init, we don't get to know the version/revision from the logs. With this
change this info is printed twice - first thing when we start and just
after init when we start waiting for client connections
