hi, i found a bug with recvfrom/sendto. the affected kernel is the android one, sources can be found there: https://android.googlesource.com/kernel/msm/+/android-msm-mako-3.4-kitkat-mr2 configuration: https://android.googlesource.com/kernel/msm/+/android-msm-mako-3.4-kitkat-mr2/arch/arm/configs/mako_defconfig description: when a process call recvfrom on a PF_PACKET/SOCK_RAW socket when another process call sendto/write on a socket that use the same interface, the ethernet address is weird. recvfrom returns the following ethernet header: UU:XX:00:00:00:00:AA:AA:03:00:00:00:YY:ZZ instead of UU:XX:VV:VV:VV:VV:HH:HH:HH:HH:HH:HH:YY:ZZ where: HH:HH:HH:HH:HH:HH is the source MAC address UU:XX:VV:VV:VV:VV is the destination MAC address YY:ZZ is the ethernet type i think that recvfrom save the user buffer pointer somewhere because perform some 'long' work on the buffer ( like using a printf to debug this problem ) increase the error rate from 2/9480 bad headers to about 779/4301. i already opened various bug reports and questions. external references: http://stackoverflow.com/questions/27251904/recvfrom-read-wrong-ethernet-address-from-raw-socket https://code.google.com/p/android/issues/detail?id=81370 step to reproduce: sample program: http://pastebin.com/kkjUrft9 ( you have to change the hardcoded ip address ) > gcc -g -o -DSENDER main.c -o sender > gcc -g -o main.c -o receiver > ./receiver wlan0 & > ./sender wlan0 > Ctrl+C ( SIGINT ) after a while > fg > Ctrl+C ( SIGINT ) you should see the amount of sniffed packets and the amount of bad ones. commenting out the fprintf/fflush calls drastically reduce bad packets count. thanks in advance for any help.
i thought more about this problem, maybe it occurs when a big queue of packets have to be processed by recvfrom. the printf can introduce some delay between processing packets, thus the recvfrom queue may reach a huge number. i'm writing some C code to test this case.
If its Android please report it to the Android folks. Android differs somewhat significantly from upstream If you can reproduce it in a base upstream kernel then re-open the bug.