Re: j1939: bind() and connect()

[David Jander <david@protonic.nl>]

On Tue, 15 Aug 2017 11:16:44 +0200
Marc Kleine-Budde <mkl@pengutronix.de> wrote:

> On 08/15/2017 11:01 AM, David Jander wrote:
> > On Tue, 15 Aug 2017 10:14:18 +0200
> > Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> >   
> >> On 08/14/2017 07:37 PM, Marc Kleine-Budde wrote:  
> >>> - Should a second bind() be allowed on a previously bind() socket?
> >>>
> >>> As far as I understand the code, there's some support, but when the
> >>> interface is switched, j1939_ifindex_stop() is not called.    
> >>
> >> Ah, there's a check, that you cannot re-bind() to another interface:
> >>  
> >>> 		if (bound_dev_if != addr->can_ifindex)    
> > 
> > This makes sense. re-bind() to another interface only would make sense if
> > bind() to any interface is also permitted, but that would imply separate
> > address-claims on all different interfaces with potentially different
> > source-address being claimed on each one.... don't think the stack should take
> > care of such complex scenarios, at least not at first IMHO.  
> 
> Bind to any interface doesn't work, you cannot send anything:
> 
> > static int j1939sk_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
> > {  
> [...]
> > 	ifindex = jsk->ifindex_started;
> > 	if (!ifindex)
> > 		return -EBADFD;  
> 
> And you will probably not receive anything, as the rx-register, which
> takes place in j1939_ifindex_start() is not done if you try to bind to
> any device (bound_dev_if == 0).
> 
> > 	if (bound_dev_if && bound_dev_if != jsk->ifindex_started) {  
> [...]
> > 
> > 		ret = j1939_ifindex_start(bound_dev_if);  
> 
> Then I'll add proper test, that you have to bind to a specific
> interface. That will make the code much simpler.

I agree. Don't know if the case for bind-any will ever be necessary in the
context of J1939, but we certainly should keep things simple for now.
I've had cases myself where an ECU would talk J1939 on two interfaces at the
same time, but not yet something like a Group-Function server exporting the
same functions on more than one interface. I could think of that use-case
happening though, but it can also be solved easily in user-space opening more
than one socket...

Best regards,

-- 
David Jander
Protonic Holland.