| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <f69abfc31003150219u4e103b0fg3dc22628054e4327@mail.gmail.com> Date: Mon, 15 Mar 2010 10:19:56 +0100 From: Yegor Yefremov <yegorslists@...glemail.com> To: figo zhang <figo1802@...il.com> Cc: Dick Hollenbeck <dick@...tplc.com>, netdev@...r.kernel.org, zealcook@...il.com Subject: Re: KS8695: possible NAPI issue On Tue, Mar 9, 2010 at 2:50 AM, figo zhang <figo1802@...il.com> wrote: > 2010/3/8 Yegor Yefremov <yegorslists@...glemail.com>: >> This is ping afterwards: >> >> debian:~# ping -c 1 192.168.1.38 >> >> PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data. >> >> >> tx ram addr = c371c202 , data len = 62 >> >> dst:00:18:f3:fe:84:84 src:00:04:d9:80:94:cd type: 0x0800 > > => the print info is not clear, it had better just keep "print_mem()", > and remove other printk. > >> >> 0xc371c20e : 45 00 >> >> 0xc371c212 : 00 54 00 00 40 00 40 01 b6 f0 c0 a8 01 42 c0 a8 >> >> 0xc371c222 : 01 26 08 00 65 51 1a 07 00 01 92 00 95 4b 5f 57 >> >> 0xc371c232 : 07 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 >> >> 0xc371c242 : 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 >> >> 0xc371c252 : 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 >> >> 0xc371c262 : 36 37 >> >> >> >> tx ram addr = c371c202 , data len = 2a >> >> dst:00:18:f3:fe:84:84 src:00:04:d9:80:94:cd type: 0x0806 >> >> 0xc371c20e : 00 01 >> >> 0xc371c212 : 08 00 06 04 00 01 00 04 d9 80 94 cd c0 a8 01 42 > => it is a send arp packet, "c0 a8 01 42" is your curr ip addr > 192.168.1.66, tell the other side it's ip addr. >> >> 0xc371c222 : 00 00 00 00 00 00 c0 a8 01 26 >> >> >> >> rx ram addr = c35d2020 , data len = 3c >> >> dst:00:04:d9:80:94:cd src:00:18:f3:fe:84:84 type: 0x0806 >> >> 0xc35d202c : 00 01 >> >> 0xc35d2030 : 08 00 06 04 00 02 00 18 f3 fe 84 84 c0 a8 01 26 > > => it is a reply arp packet, "c0 a8 01 26" (192.168.1.38 ) is other > side ip addr. so the arp > request is finished. > >> >> 0xc35d2040 : 00 04 d9 80 94 cd c0 a8 01 42 00 00 00 00 00 00 >> >> 0xc35d2050 : 00 00 00 00 00 00 00 00 00 00 00 00 >> > => so , it should still send "IMCP" packet, you using "ping -c 1", it > send one IMCP packet , and wait for reply. at this point, it have not > send packet? I made some tests on Fr with a Netbook connected directly to our ks8695 based device and not to the companies network. During the test I couldn't encounter any problem. Than I connected ks8695 again to the companies network and the issue was there right away. So I decided to check how many broadcast I get and it turned out that I have one device on the network that is sending broadcast almost every second if not more frequent. It turned out that the network on ks8695 was not completely down, but very slow and many packets got lost. As soon as I removed the broadcast sending device I could ping ks8695. The consequences: 1. as long as I make no netcat transfer, the network responses are as usual regardless of many broadcasts 2. if during netcat a broadcast occurs, than the network is getting slow, so that if during a constant ping you get a broadcast that ping response gets lost Any idea how broadcast during transfer could affect NAPI in that way? Regards, Yeor -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists