Matthias Fuchs wrote: > Hi Oliver, > > On Tuesday 05 January 2010 13:48, Oliver Hartkopp wrote: >> Matthias Fuchs wrote: >> >>> During testing I noticed a problem with loopback behavior. It's the same >>> problem >>> I ran into a while ago with 2.6.30: I always receive sent >>> frames on the same socket. The sockets behave as if CAN_RAW_RECV_OWN_MSGS >>> is enabled. >>> >>> Wolfgang, did you run into this issue when you did the sysfs 2.6.18 >>> backport? >> Hi Matthias, >> >> to make sure the CAN_RAW_RECV_OWN_MSGS is working properly, the pointer to >> the >> sock structure (sk) has to be set into the socketbuffer (skb) of the >> receiving >> skb. >> >> So there is code some that makes >> >> skb->sk = srcsk >> >> to restore the sk in the receiving skbuff. skb->sk is usually killed by >> skb_orphan(), so skb->sk = srcsk is needed here. >> >>> Any ideas where to dig? >> Please check in can_send() and can_rcv() if there are the same pointer values >> in skb->sk . > Good advice. I added some printks. On a 2.6.28 kernel skb->sk is identical in > can_send and can_rcv. Loopback is working fine. > > On 2.6.18 skb->sk is NULL in can_rcv.
grrr ... > can_get_echo_skb() still has the correct sock structure. I dare to say > that this might be a kernel 2.6.18 issue. This might be the case. I checked the code in http://lxr.linux.no/#linux+v2.6.18/net/core/dev.c but i did not find any problem on the first view. > I expected socketcan to handle > the loopback stuff correctly in 2.6.18 times. Or do I expect to much? No. It should work like this. As skb->sk is set to NULL somewhere between netif_rx(skb) invoked in can_get_echo_skb() and can_rcv() it looks like a 2.6.18 issue ... Unfortunately, i don't have a 2.6.18 environment here (as it won't boot on my Dell Latitude 830 due to missing SATA), so i'm not able to track skb->sk. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
