Guy Harris <guy <at> alum.mit.edu> writes: > > Somebody who works on the PF_PACKET socket code in the Linux kernel? > My *guess* is that there's something wrong with the code that handles > memory-mapped access to the socket (if it weren't using the > memory-mapped code, it might not be any less likely to panic, but it might > be less likely to get a segmentation fault in user-mode code) when more than > one process is using it. > > netsniff-ng: > > http://netsniff-ng.org/ > > apparently also uses memory-mapped access to PF_PACKET sockets, and > doesn't use libpcap; see what happens if you compile it for your embedded > board and try to run two instances of it. If you have > problems with that, then libpcap isn't involved at all, and you'd need to get > some of the Linux networking code developers involved. (If that works, then > it is probably still at least in part a Linux kernel issue, given that you're > getting kernel panics, but there *might* also be an issue with how libpcap is > using the memory-mapped mechanism.) >
OK, I'v just cross-compiled netsniff-ng, and run it on my board. With only one instance of netsniff-ng, my board reboot. If I disable all my network interfaces (ifdown -a), no reboot, netsniff-ng just don't find an interface. With gdb, I notice that my board reboots after the last instruction of __init_stage_fallback_dev function (from netsniff-ng's code). This function is use to initialize the listening interface (i.e: eth0). So, I think the problem is not libpcap. The problem might be the hardware or the kernel configuration... - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
