On Tuesday 05 January 2010 18:06, Oliver Hartkopp wrote: > 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.
I did some further testing. Doing the same tests on a Debian Etch system were successful (Debian kernel 2.6.18-6-486). The problem seems to be with the Centos/RHEL kernel 2.6.18-164.6.1.el5. This kernel contains a huge amount of Redhat patches. I will see if any of them touch net/core/dev.c. Grr :-( Matthias _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
