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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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