From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 317111381F3 for ; Mon, 5 Aug 2013 15:37:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C1B9EE0B83; Mon, 5 Aug 2013 15:37:33 +0000 (UTC) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 782C3E0B76 for ; Mon, 5 Aug 2013 15:37:32 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id p61so2610078wes.39 for ; Mon, 05 Aug 2013 08:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=1m89WEaNahOiiJzgtXxWmc1z35qmwZOHBPC7OcvQ2VE=; b=Ao5FF3gkvtfehLkDemtPlMGf9IGKJZMdNKkcGwRbb35Xr2vhu4b3+F7EzTV/pcSMGW B1npZs0GKp+usptSOTlYDcHvbncLKYKl2Acn3VkaF1awoxzanQaMX/d6WsGlLH0j/EgZ oq7mktV1UwAfYA7yIa7lepHTQ8CCODlgFHCekflAPd08BnzPnnZjEUTngsuS7gLOGN0p GsoeBtppITnsFgxoGjr7Dnl3fitu1ndGJA6YFKxan40m+pleSBHVrnB/XjHv5y8eIN+s xEXzaGOLN60oRsEUmogHTFr4plDV8P4hfZE6BpNLR3x2PzhIq6mMhreetxbDs+ltZUgr 7I3w== X-Received: by 10.180.21.234 with SMTP id y10mr7021222wie.55.1375717051130; Mon, 05 Aug 2013 08:37:31 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id nb12sm22257786wic.3.2013.08.05.08.37.29 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 08:37:30 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Browsers cannot access WWW while ping and host utilities work as expected. Date: Mon, 5 Aug 2013 16:37:13 +0100 User-Agent: KMail/1.13.7 (Linux/3.8.13-gentoo; KDE/4.10.5; x86_64; ; ) References: <20130805163144.69653f43@marcec> <20130805144109.GM25510@server> In-Reply-To: <20130805144109.GM25510@server> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7361163.TYH4QWWY22"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201308051637.23417.michaelkintzios@gmail.com> X-Archives-Salt: 47545428-97ff-4515-b391-cbd24aa3e4a1 X-Archives-Hash: 70ebe56356a195da4827239633dc0300 --nextPart7361163.TYH4QWWY22 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday 05 Aug 2013 15:41:09 Bruce Hill wrote: > On Mon, Aug 05, 2013 at 04:31:44PM +0200, Marc Joliet wrote: > > Am Mon, 5 Aug 2013 07:59:09 -0500 > >=20 > > schrieb Bruce Hill : > > > If this is "the new kernel naming scheme of NICs", why this in dmesg: > > >=20 > > > [ 4.725902] systemd-udevd[1176]: renamed network interface wlan0 to > > > enp0s18f2u2 > > >=20 > > > It looks as if systemd-udev renamed the NIC to me. Can you explain? > >=20 > > It already has been explained in the previous NIC renaming discussion: > > what's broken is renaming a device within the kernels internal > > namespace, which contains eth*, wlan* (and maybe others). The problem is > > that there is a race condition with the kernel when renaming ethX to > > ethY. What you *can* do is rename ethX to somethingelseX or > > somethingelseY, because then you are not racing against the kernel to > > hand out device names. > >=20 > > This is explained on the website that also explains the new default > > renaming scheme used by udev. I (and IIRC others, too) already linked to > > it in in the old > >=20 > > thread, and the relevant news item also referenced it, but here it is=20 again: > > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkIn= te > > rfaceNames/ >=20 > The fact is that udev renamed the NIC. For the average Joe with one NIC > (very large percentage of users) this is a non sequitur. For those of us > with 2 or more NICs, myself included, we have already setup our systems to > use multiple NICs for a purpose and configured the system so that nothing > can/will/needs to rename subsequent NICs. >=20 > My point is don't say "the new kernel naming scheme of NICs", say "the new > systemd naming scheme of NICs". Indeed! Thanks for bringing this to my attention. Here's my eth0: [ 6.437527] systemd-udevd[1407]: starting version 204 [ 7.457924] systemd-udevd[1428]: renamed network interface eth0 to enp11= s0 while my wireless NIC stays named as always was (wlan0): [ 7.822350] b43-phy0: Broadcom 4312 WLAN found (core revision 15) [ 7.838741] b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1 [ 7.838760] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062,=20 Revision 2 [ 15.771370] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:0= 7) [ 15.775217] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz. [ 17.157109] b43-phy0 debug: Chip initialized [ 17.157427] b43-phy0 debug: 64-bit DMA initialized [ 17.157888] b43-phy0 debug: QoS disabled [ 17.167424] b43-phy0 debug: Wireless interface started [ 17.172410] b43-phy0 debug: Adding Interface type 2 [ 17.173097] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready BTW, I have no systemd installed, only udev-204 and udev-init-scripts-26. =2D-=20 Regards, Mick --nextPart7361163.TYH4QWWY22 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAABAgAGBQJR/8azAAoJELAdA+zwE4YesYwIAIkakM89WMLKH2dPzELmfatp NywDa/HNCLJ9EoKMTEzIQjL3B7BegNutnWvv1ywF47zf7kzGXszyS65j4SG+I4Vz 5sZnyTcxnMM+lalkF+XBRNzQqJYu9QA9kUVTrPgAlROAXpiGIHxUPqt19zNoSdQ2 UjXsbGhUCVXM0Jaknu9KB7l1Zw1F0wBQhSaXVQkJjMUzl1cTjbayJ4ZaPxsvjI6P 39tLBCHlrUC3Ny89c5wwyGeLmFLk96JRtVVrqdHoHuuaLA0mdSDv7zCRKEuiAi2k b8os6cYEE9cqT9nmmATHpBf+F5PuRFXYHYek984XJkEMmCQe85Btz1XhmoN2msQ= =adPb -----END PGP SIGNATURE----- --nextPart7361163.TYH4QWWY22--