| 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
| ||
|
Date: Wed, 4 Aug 2010 16:40:09 +0200 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 Mon, Mar 15, 2010 at 11:19 AM, Yegor Yefremov <yegorslists@...glemail.com> wrote: > 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? Tried 2.6.35. Have still the same problems. Another observation: if I add eth0 to a bridge (br0), then I have no problems. So ks8695 network driver is still involved, but the upper level seems to make the difference. Any idea? Regards, Yegor -- 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