Re: [Lksctp-developers] Problems with sctp_bind() - help?

[Jon G. <jg...@au...>]

"Gonzalez, Inaky" wrote:
>=20
> > sk->net_pinfo.af_inet6.rcv_saddr, which is
> > actually v6_1 (because the v4_2 is temporarily saved in
> > sk->rcv_saddr from
> > sctp_bind(), however, sctp_get_port() got it wrong based on
> > sk->family)!!!!! So, the sctp_cmd_addr() will pass  the
> > address comparison
> > because indeed v6_1 =3D=3D v6(v4)_2.
> >       Make sense?
>=20
> Woah, it does!! You just saved me an awful evening wading through code =
(I
> will do anyway, I want to understand it). However, now I guess that the
> sollution is to add the address to the endpoint in V6 format (even if V=
4)
> when the PF is INET6. Makes sense?
>=20

There would be a bit of ripple effect you'll need to think through on
any proposal.  Lookups on would need to know how to lookup a v4 address
that is possibly in v6 format with suggestion.  =20

OTOH, a common internal format for address based on v6 has some appeal
to me.. since v4 comparisons to v4-mapped-on-v6 addresses become very,
very easy.  I think this would be the long term direction.=20


Other issues:  rcv_saddr and saddr.  I really dislike the way these sk
fields are used as arguments into get_port talk about hokey.  Do we
really need them?  Hmmm....

rcv_saddr:  I don't see why we care about this one at all.  We don't use
it for our lookups and it looks like there is only one dependency..
IP_PKTINFO, but we'd have to catch that to make it work (if we really
wanted to)....and 2.5 has cleaned that particular case up to no longer
need sk->rcv_saddr instead pulling such information from an skb
directly.  netfilter seems to use rcv_saddr, but only for TCP.  That's
all I see at least. =20

saddr:  This goes away when we do our own source address selection.=20
Today we are at the whim of the routing table... saddr is used assist in
the route lookup, but is not necessarily part of the route chosen.. we
need to control what happens there, minimally to prevent us from using
addresses not in our association (if we are subset bound).  More
advanced, we should have more control to help HA, by flipping between
source addresses (not only destination addresses).  But until we do
something in this area we look dependant on this field.  Looks like 2.4
and 2.5.  Hmmm. closer exmination of this field shows it not even used
in get port, only rcv_saddr is.. it is just used later in transmission,
so maybe its a non-issue for get_port.  =20


Hokey get_port interface(): =20
in our bindx/bind (and in tcp where our code looks like its copied from)
the code saves away the old rcv_saddr & saddr  blasts in the recommended
new address into both fields and calls get_port() since these are not
passed in as direct arguments (Hey! only rcv_saddr is really used)..=20
Yuck, what a hokey interface.  We could start using our own sctp sock
specific field, but do we really need to propogate this???  I understand
that the current interface is used by the AF_INET for inet_autobind(),
but in that case it doesn't use rcv_saddr as its binding to INADDR_ANY
and doesn't bother setting even setting up rcv_saddr.   We could ask for
an interface change to give us a void *arg, for us to do something
interesting (tcp/udp could take advantage of this too).  Or we could
just do so internally by having a different interface for bind than we
give to af_inet->get_port(). =20

e.g.=20
__sctp_get_port(sk, *int, sctp_addr_t *naddr);
sctp_get_port(sk, *int); =20


Where sctp_get_port would manufacture an INADDR_ANY naddr to call into
__sctp_get_port().  The bind wouldn't have to jump through hoops saving
away  the previous rcv_saddr.. Depending on what we want to do with
address formats, the above sctp_addr_t may be a sock_addr_t or always a
PF_INET6 address (of which may encapsulate a v4 addr). =20


btw, isn't there a bunch of unused code in there for reuse and fast
reuse???  Does SO_REUSE_ADDR even have a well defined meaning on SCTP
sockets? =20

Hmmm.. sctp_autobind() is called from sctp_sendmsg()?  I don't remember
why it is needed there if inet_autobind already calls our get_port() to
do the same thing.  Does this sctp_sendmsg() ever really call
sctp_autobind()?? =20


Just some thoughts,
Jon

Ugh.  No more notes for me today or I'll get nothing done. =20


O

> I=F1aky P=E9rez Gonz=E1lez::ina...@in...
> I do not speak for Intel Corp, opinions are my own.
>=20
> _______________________________________________
> Lksctp-developers mailing list
> Lks...@li...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers