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]
Date:	Mon, 20 Apr 2015 12:00:38 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Rob Landley' <rob@...dley.net>, Tejun Heo <tj@...nel.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCHSET] printk, netconsole: implement reliable netconsole

From: Of Rob Landley
> Sent: 19 April 2015 08:25
> On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo <tj@...nel.org> wrote:
> > In a lot of configurations, netconsole is a useful way to collect
> > system logs; however, all netconsole does is simply emitting UDP
> > packets for the raw messages and there's no way for the receiver to
> > find out whether the packets were lost and/or reordered in flight.
> 
> Except a modern nonsaturated LAN shouldn't do that.
> 
> If you have two machines plugged into a hub, and that's _all_ that's
> plugged in, packets should never get dropped. This was the original
> use case of netconsole was that the sender and the receiver were
> plugged into the same router.
> 
> However, even on a quite active LAN the days of ethernet doing CDMA
> requiring retransmits are long gone, even 100baseT routers have been
> cacheing and retransmitting data internally so each connection can go
> at the full 11 megabytes/second with the backplane running fast enough
> to keep them all active at the same time. (That's why it's so hard to
> find a _hub_ anymore, it's all routers
...

Most machines are plugged into switches (not routers), many of them
will send 'pause' frames which the host mac may act on.
In which case packet loss is not expected (unless you have broadcast storms
when all bets are off).

Additionally, within a local network you shouldn't really get any packet
loss since no segments should be 100% loaded.
So for testing it is not unreasonable to expect no lost packets in netconsole
traffic.

	David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ