netdev - Re: netperf udp

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4817515F.4090500@hp.com>
Date:	Tue, 29 Apr 2008 09:48:31 -0700
From:	Rick Jones <rick.jones2@...com>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
CC:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	netdev@...r.kernel.org
Subject: Re: netperf udp_rr testing hang

Zhang, Yanmin wrote:
> I located the root cause.
> kernel is ok. It's an issue of netperf.
> 
> I instrumented kernel and turn on netperf debug to capture more data.
>  As a matter of fact, netserver on the Server1 machine binds ip
> 0.0.0.0 and the port to receive UDP packets, but netperf on Client1
> machine binds ip 192.168.1.164 by bind and remote ip 192.168.1.153 by
> connect. When Server1 sends back a response, it just chooses one ip
> of Server1 as the source ip to send out the packets, because server
> socket just binds 0.0.0.0. So kernel on Client1 just drops the
> packets.
> 
> The fix could be one of them:
> 1) Don't call connect in netperf for UDP testing; But it looks like
> the transactions just pass from one interface, not distributed on the
> 2 interface;
> 2) Pass remote_ip to server by udp_rr_request;
> 
> 1 is more simple.

Odd that this should come-up at this point - the netperf UDP_RR test has 
been operating that way since day one.  It goes backa long way, but I 
believe I did things that way on the premis that a client would 
"connect" to the server IP so it would "know" that the response 
came-back from the server to which the request was sent.

The only thing that _might_ have changed over the years was an explicit 
bind() creaping-in when the bind() used to be implicit with the 
connect() call.   If that is indeed involved, it would be seen by 
running say a, oh, 2.0 version of netperf from the repository.

rick jones
--
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