Re: [PATCH v6 01/26] flow: Common address information for initiating side

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 6189 bytes --]

On Wed, Jun 26, 2024 at 12:23:28AM +0200, Stefano Brivio wrote:
> On Fri, 14 Jun 2024 16:13:23 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > Handling of each protocol needs some degree of tracking of the
> > addresses and ports at the end of each connection or flow.  Sometimes
> > that's explicit (as in the guest visible addresses for TCP
> > connections), sometimes implicit (the bound and connected addresses of
> > sockets).
> > 
> > To allow more consistent handling across protocols we want to
> > uniformly track the address and port at each end of the connection.
> > Furthermore, because we allow port remapping, and we sometimes need to
> > apply NAT, the addresses and ports can be different as seen by the
> > guest/namespace and as by the host.
> > 
> > Introduce 'struct flowside' to keep track of address and port
> > information related to one side of a flow. Store two of these in the
> > common fields of a flow to track that information for both sides.
> > 
> > For now we only populate the initiating side, requiring that
> > information be completed when a flows enter INI.  Later patches will
> > populate the target side.
> > 
> > For now this leaves some information redundantly recorded in both generic
> > and type specific fields.  We'll fix that in later patches.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  flow.c       | 96 +++++++++++++++++++++++++++++++++++++++++++++++++---
> >  flow.h       | 16 +++++++++
> >  flow_table.h |  8 ++++-
> >  icmp.c       |  9 +++--
> >  passt.h      |  3 ++
> >  tcp.c        |  6 ++--
> >  6 files changed, 127 insertions(+), 11 deletions(-)
> > 
> > diff --git a/flow.c b/flow.c
> > index d05aa495..1819111d 100644
> > --- a/flow.c
> > +++ b/flow.c
> > @@ -108,6 +108,31 @@ static const union flow *flow_new_entry; /* = NULL */
> >  /* Last time the flow timers ran */
> >  static struct timespec flow_timer_run;
> >  
> > +/** flowside_from_af() - Initialise flowside from addresses
> > + * @fside:	flowside to initialise
> > + * @af:		Address family (AF_INET or AF_INET6)
> > + * @eaddr:	Endpoint address (pointer to in_addr or in6_addr)
> > + * @eport:	Endpoint port
> > + * @faddr:	Forwarding address (pointer to in_addr or in6_addr)
> > + * @fport:	Forwarding port
> > + */
> > +static void flowside_from_af(struct flowside *fside, sa_family_t af,
> > +			     const void *eaddr, in_port_t eport,
> > +			     const void *faddr, in_port_t fport)
> > +{
> > +	if (faddr)
> > +		inany_from_af(&fside->faddr, af, faddr);
> > +	else
> > +		fside->faddr = inany_any6;
> 
> I kind of wonder if, for clarity, we should perhaps:
> 
> #define inany_any		inany_any6
> 
> ?

That might be a good idea.

> And... I don't actually have in mind how IP versions are stored in the
> flow table for unspecified addresses, but I wonder if we're losing some
> information this way: if this is called with AF_INET as 'af', we're not
> saying anywhere in the flowside information that this is going to be an
> IPv4 flowside, right?

So, I've gone back and forth on this a bit, and it's not entirely
consistent in this version whether I always use :: for "blank", or
whether I use 0.0.0.0 for IPv4 cases.  Using :: everywhere does
technically lose some information, although you can generally tell
that a flowside is IPv4 from the other address.

The argument for using :: everywhere is that in many of the cases this
indicates "blank" or "missing" in a way that's not really dependent on
the IP version, and sometimes it's simpler to do this.  There are (or
may be in future) also some cases where an otherwise IPv4 flowside
might be routed through a dual-stack :: socket.

The argument for using 0.0.0.0 where accurate is that it makes for
more consistency across the flowside and makes matching up to
addresses from elswhere easier in some cases.

With the reworks for how I handle UDP, I'm going to need to revisit
this anyway, so I'll see where I land.

> > +	fside->fport = fport;
> > +
> > +	if (eaddr)
> > +		inany_from_af(&fside->eaddr, af, eaddr);
> > +	else
> > +		fside->eaddr = inany_any6;
> > +	fside->eport = eport;
> > +}
> > +
> >  /** flow_log_ - Log flow-related message
> >   * @f:		flow the message is related to
> >   * @pri:	Log priority
> > @@ -140,6 +165,8 @@ void flow_log_(const struct flow_common *f, int pri, const char *fmt, ...)
> >   */
> >  static void flow_set_state(struct flow_common *f, enum flow_state state)
> >  {
> > +	char estr[INANY_ADDRSTRLEN], fstr[INANY_ADDRSTRLEN];
> > +	const struct flowside *ini = &f->side[INISIDE];
> >  	uint8_t oldstate = f->state;
> >  
> >  	ASSERT(state < FLOW_NUM_STATES);
> > @@ -150,18 +177,28 @@ static void flow_set_state(struct flow_common *f, enum flow_state state)
> >  		  FLOW_STATE(f));
> >  
> >  	if (MAX(state, oldstate) >= FLOW_STATE_TGT)
> > -		flow_log_(f, LOG_DEBUG, "%s => %s", pif_name(f->pif[INISIDE]),
> > -			                            pif_name(f->pif[TGTSIDE]));
> > +		flow_log_(f, LOG_DEBUG, "%s [%s]:%hu -> [%s]:%hu => %s",
> > +			  pif_name(f->pif[INISIDE]),
> > +			  inany_ntop(&ini->eaddr, estr, sizeof(estr)),
> > +			  ini->eport,
> > +			  inany_ntop(&ini->faddr, fstr, sizeof(fstr)),
> > +			  ini->fport,
> > +			  pif_name(f->pif[TGTSIDE]));
> >  	else if (MAX(state, oldstate) >= FLOW_STATE_INI)
> > -		flow_log_(f, LOG_DEBUG, "%s => ?", pif_name(f->pif[INISIDE]));
> > +		flow_log_(f, LOG_DEBUG, "%s [%s]:%hu -> [%s]:%hu => ?",
> > +			  pif_name(f->pif[INISIDE]),
> > +			  inany_ntop(&ini->eaddr, estr, sizeof(estr)),
> > +			  ini->eport,
> > +			  inany_ntop(&ini->faddr, fstr, sizeof(fstr)),
> > +			  ini->fport);
> >  }
> >  
> >  /**
> > - * flow_initiate() - Move flow to INI, setting INISIDE details
> > + * flow_initiate_() - Move flow to INI, setting setting pif[INISIDE]
> 
> s/setting setting/setting/

Fixed.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]