On Thu, Jan 21, 2010 at 08:02:26PM +0100, Oliver Hartkopp wrote:
> Kurt Van Dijck wrote:
> > Oliver,
> >
> > in the patch below, I identified a line which I don't understand.
> > The targeted statement is within can_send(), when loopback is requested
> > but not supported by the device driver.
> > can_send() clones the skb (newskb) which will soon be injected in the
> > receive flow of the net_device.
> > By setting the type to PACKET_BROADCAST (over PACKET_LOOPBACK), a
> > socketcan receiver cannot distinguish between loopback'd and external
> > broadcasted can messages, which I tought was the reason to set
> > PACKET_LOOPBACK in the first place (a few lines up).
> >
> > I seem not to understand the logic. Where did I go wrong?
>
> Hi Kurt,
>
> you need to distinguish skb->pkt_type in downstream and upstream.
I see, can_put_echo_skb() changes the pkt_type. I had not noticed
before :-)
>
> I remember we had to check, if the skb's got mangled inside the network stack
> when setting wrong skb->pkt_type values.
ok. I appreciate the work done there.
>
> Every received CAN skb has the type PACKET_BROADCAST in upstream, as we're
> dealing with 'broadcasted' CAN frames. And there is no difference (for a
> subscribed receiver) whether the frame has been received from a 'real' bus or
> if it has been sent on the 'real' bus (and is therefore looped back).
> Therefore there is no reason for the receiver to know the pkt_type at all.
>
> In the downstream we use PACKET_HOST and PACKET_LOOP to tell the driver
> whether a loopback is required or not.
>
> That's all.
Thanks for the explanation!
>
> Regards,
> Oliver
Kurt
>
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
