[Swan-dev] whack [-oppotproto <protocol>]

Andrew Cagney andrew.cagney at gmail.com
Wed Feb 10 01:37:01 UTC 2021


My understanding of the kernel's opportunistic code is that the
following happens:

- something tries send a packet to LOCAL
- the packet is captured and the all the details - version, address,
protocol [and port when applicable], ... are all provided to pluto
- the details are formed into endpoints and then fed into
build_outgoing_opportunistic_connection() which finds and instantiates
a connection

the big takeaway is that two endpoints precisely define the
source/dest for the triggering packet - nothing left to chance (well
ok, for ICMP some information is currently lost :-().

However, when initiating using whack and the options:

        { "oppohere", required_argument, NULL, OPT_OPPO_HERE + OO },
        { "oppothere", required_argument, NULL, OPT_OPPO_THERE + OO },
        { "oppoproto", required_argument, NULL, OPT_OPPO_PROTO + OO },
        { "oppodport", required_argument, NULL, OPT_OPPO_DPORT + OO },

(whack --help needs another update)
(no there isn't oppoSport and what's with oppoDport vs oppoTHERE?)

build_outgoing_opportunistic_connection() ends having to also handle
what I think is best described as a homeopathic memory of the kernel
trigger.

I'd like to see this changed so that the whack command, like for the
kernel, exactly specifies the trigger.  Is it safe to assume this is
ok and we've a fairly free hand here?  Any suggestions?

My initial thought is to use ICMP ping-request as a template.  This
makes triggering a ping request very easy vis:
    --oopohere 1.1.1.1 --oppothere 8.8.8.8
However trying to trigger anything else is more cumbersome vis:
   --oppohere 1.2.3.4 --oppothere 8.8.8.8 --oppoproto 6 --opposport 22
--oppodport 22
Perhaps we live with that - this is for testing.

Andrew


More information about the Swan-dev mailing list