Success.... At last! I was getting no where on Debian 8, glancing at Debian 9 spec, it said it had support for G4 modems, so I install debian 9, with network mangager..............still no joy .........ssssssiiiiggghhhhhh. Anyway this morning I was ready for a challaenge so I decided to have another go. I ran the command "nmcli connection show" to see what was happening and was stunned to find the following report........... ---------------------------------------------------------------- enx0c5b8f279a64: connected to Wired connection 3 "HUAWEI MOBILE" ethernet (rndis_host), 0C:5B:8F:27:9A:64, hw, mtu 1500 ip4 default inet4 192.168.8.100/24 inet6 fe80::4636:a274:6574:96fa/64 enp5s0: unavailable "Marvell 88E8056 PCI-E Gigabit Ethernet Controller (Motherboard)" ethernet (sky2), 20:CF:30:7E:C3:09, hw, mtu 1500 lo: unmanaged loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 DNS configuration: servers: 192.168.8.1 interface: enx0c5b8f279a64 servers: 192.168.254.1 domains: mydomain.example interface: enp6s0 --------------------------------------------------------- Its enx0c5b8f279a64 that I am looking for, it now works OK, interestingly connection time is slower than with windows but transfer rates appear to be good. Why I did not do this before, god knows............ God its great to getaway from bl...y awfull windows................. Now all (ALL!!!) I have to do is to reconfig my fire wall on to this box and my small network is back on the air. Lindsay
On 06.09.17 10:27, Ray via luv-main wrote:
Success.... At last!
I was getting no where on Debian 8, glancing at Debian 9 spec, it said it had support for G4 modems, so I install debian 9, with network mangager..............still no joy .........ssssssiiiiggghhhhhh.
Anyway this morning I was ready for a challaenge so I decided to have another go.
I ran the command "nmcli connection show" to see what was happening and was stunned to find the following report........... ---------------------------------------------------------------- enx0c5b8f279a64: connected to Wired connection 3 "HUAWEI MOBILE" ethernet (rndis_host), 0C:5B:8F:27:9A:64, hw, mtu 1500 ip4 default inet4 192.168.8.100/24 inet6 fe80::4636:a274:6574:96fa/64
enp5s0: unavailable ...
Its enx0c5b8f279a64 that I am looking for, it now works OK, interestingly connection time is slower than with windows but transfer rates appear to be good.
Why I did not do this before, god knows............
An upgrade now and then is warranted, then. :-) Incidentally, it's not necessary to endure the loony Systemdix¹ interface naming, taken from /dev/urandom, just to annoy users. On debian 9.0, I've adopted the now common: In /etc/default/grub, change the GRUB_CMDLINE_LINUX=”” to: GRUB_CMDLINE_LINUX="net.ifnames=0" Or, if biosdevname is installed: GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0" $ sudo update-grub $ sudo reboot Now eth0 is eth0, and wlan0 is wlan0, a la established *nix usage, free of any crappy /dev/urandom-inspired Poetterwank, like enx0c5b8f279a64. (Or whatever it comes up as next week)
God its great to getaway from bl...y awfull windows.................
I know how you feel, despite never having used M$ - Systemdix is engineered in the same meddlesome monolithic mould, and farnarkle it's great to get away from its most odious manifestations. Whether the next stop is devuan or freeBSD remains to be seen. Erik ¹ As systemd consumes all in its path, demolishing *nix conventions on the way, the OS can no longer be called linux. But then, that is the goal. -- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. - Poul Anderson
On 06/09/17 14:52, Erik Christiansen via luv-main wrote:
Now eth0 is eth0, and wlan0 is wlan0, a la established *nix usage, > free of any crappy /dev/urandom-inspired Poetterwank, like > enx0c5b8f279a64. (Or whatever it comes up as next week) On the other hand, you now revert to the problem this change was introduced to address: Your network interfaces may change names arbitrarily if you make any hardware changes - for example, inserting or removing USB devices that provide a network interface (such as a mobile phone in tethering mode), or a new PCI network adapter. You may then need to use the udev MAC address based network interface renaming to avoid issues.
Cheers, Andrew
On 06.09.17 15:04, Andrew Pam via luv-main wrote:
On 06/09/17 14:52, Erik Christiansen via luv-main wrote:
Now eth0 is eth0, and wlan0 is wlan0, a la established *nix usage, free of any crappy /dev/urandom-inspired Poetterwank, like enx0c5b8f279a64. (Or whatever it comes up as next week)
On the other hand, you now revert to the problem this change was introduced to address: Your network interfaces may change names arbitrarily if you make any hardware changes - for example, inserting or removing USB devices that provide a network interface (such as a mobile phone in tethering mode), or a new PCI network adapter. You may then need to use the udev MAC address based network interface renaming to avoid issues.
If device replacement should ever happen, then either that or I just install ifrename, and have it automatically handled by e.g.: $ more /etc/iftab # This file assigns persistent names to network interfaces. See iftab(5). eth0 mac 00:40:e0:83:e9:97 eth1 mac 00:15:00:30:82:17 OK, ifrename has to run before the interfaces come up, but it's worth delving into init scripts once or twice a decade, just for familiarity. In any event, interface names chosen by me are the non-negotiable requirement. A little effort to achieve that is amusing, and the opportunity to repel linux saboteurs is a bonus. At two companies I've looked after 12 - 20 hosts each, never replacing a NIC in over 2 decades, but adding two. Fiddling with interface names was bog standard sysadmin fare. Once done, recognisable names remained. Simples. Erik
On 06.09.2017 10:27, Ray via luv-main wrote:
Success.... At last!
I was getting no where on Debian 8, glancing at Debian 9 spec, it said it had support for G4 modems, so I install debian 9, with network mangager..............still no joy .........ssssssiiiiggghhhhhh.
Anyway this morning I was ready for a challaenge so I decided to have another go.
I ran the command "nmcli connection show" to see what was happening and was stunned to find the following report........... ---------------------------------------------------------------- enx0c5b8f279a64: connected to Wired connection 3 "HUAWEI MOBILE" ethernet (rndis_host), 0C:5B:8F:27:9A:64, hw, mtu 1500 ip4 default inet4 192.168.8.100/24 inet6 fe80::4636:a274:6574:96fa/64
enp5s0: unavailable "Marvell 88E8056 PCI-E Gigabit Ethernet Controller (Motherboard)" ethernet (sky2), 20:CF:30:7E:C3:09, hw, mtu 1500
lo: unmanaged loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration: servers: 192.168.8.1 interface: enx0c5b8f279a64
servers: 192.168.254.1 domains: mydomain.example interface: enp6s0 ---------------------------------------------------------
Its enx0c5b8f279a64 that I am looking for, it now works OK, interestingly connection time is slower than with windows but transfer rates appear to be good.
Why I did not do this before, god knows............
God its great to getaway from bl...y awfull windows.................
Now all (ALL!!!) I have to do is to reconfig my fire wall on to this box and my small network is back on the air.
Lindsay _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
An explanation is required, sorry............ enx0c5b8f279a64 is NOT random 0c5.......64 is the MAC address of the 4G dongle so will only change if the dongle changes. Why it does not use a USB ethernet naming convention (if there is one) I do not know. I was wondering though about some of these weird device id's Lindsay
On 06.09.17 18:14, Ray via luv-main wrote:
On 06.09.2017 10:27, Ray via luv-main wrote:
I ran the command "nmcli connection show" to see what was happening and was stunned to find the following report........... ---------------------------------------------------------------- enx0c5b8f279a64: connected to Wired connection 3 "HUAWEI MOBILE" ethernet (rndis_host), 0C:5B:8F:27:9A:64, hw, mtu 1500 ip4 default inet4 192.168.8.100/24 inet6 fe80::4636:a274:6574:96fa/64
enp5s0: unavailable ...
enx0c5b8f279a64 is NOT random 0c5.......64 is the MAC address of the 4G dongle so will only change if the dongle changes. Why it does not use a USB ethernet naming convention (if there is one) I do not know.
OK, I could buy that for a hotplug dongle, but enp5s0 looks awfully short for a MAC? (Mine came out as enp2s0, before I gave it the flick.)
I was wondering though about some of these weird device id's
The excuse made for the obfuscated interface names at the user level is that they "avoid name volatility in the event of NIC replacement". However, if it's the MAC address which provides the enx0c5b8f279a64 and enp5s0 hoo-ha, then that instead _causes_ name volatility as soon as a NIC is replaced. It is difficult to recognise that funny way of doing things as a solution. Erik
On 06/09/17 19:20, Erik Christiansen via luv-main wrote:
OK, I could buy that for a hotplug dongle, but enp5s0 looks awfully short for a MAC? (Mine came out as enp2s0, before I gave it the flick.)
<https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/> Hope that helps. Cheers, Andrew
On 06.09.17 23:31, Andrew Pam via luv-main wrote:
On 06/09/17 19:20, Erik Christiansen via luv-main wrote:
OK, I could buy that for a hotplug dongle, but enp5s0 looks awfully short for a MAC? (Mine came out as enp2s0, before I gave it the flick.)
<https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>
Hope that helps.
Thanks Andrew. It seems mendacious to pretend that a writable root fs is required for stable ethx naming, when in reality, reading /etc/iftab suffices. When systemdix is able to write its /dev/urandom crap, it would be equally capable of writing useful names instead, if it were not a Poetterwank. If the implementation would be streamlined by writing temporary bumpf, then it is not beyond the power of a competent programmer to rectify naming stepwise as the system comes up. Paragraph 4 admits as much, recognising that others have respect for users, and provide usability which systemdix willfully avoids. It describes the superior alternative, maintaining traditional naming behaviour and NIC management effort. It confirms that systemdix is not linux. Paragraph 5 loses the plot again, though, by willfully choosing obfuscating perversity. If enp5s0 hoo-ha can be provided, then so can eth0. No, I'm not going in to muck with their code, as they'd just find other ways to pervert good design, making my effort as big a waste as theirs. It is sufficient for me to move out of reach of systemdix. Erik -- (5) It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. RFC-1925
On Wed, Sep 06, 2017 at 07:20:56PM +1000, luv-main@luv.asn.au wrote:
On 06.09.17 18:14, Ray via luv-main wrote:
enx0c5b8f279a64 is NOT random 0c5.......64 is the MAC address of the 4G dongle so will only change if the dongle changes. Why it does not use a USB ethernet naming convention (if there is one) I do not know.
OK, I could buy that for a hotplug dongle, but enp5s0 looks awfully short for a MAC? (Mine came out as enp2s0, before I gave it the flick.)
Predictable Network Interface Names (or PNIN): https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfac... ... [..NIC naming supported by udev...] 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1) 1. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1) 1. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0) 1. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da) 1. Classic, unpredictable kernel-native ethX naming (example: eth0) ...
I was wondering though about some of these weird device id's
The excuse made for the obfuscated interface names at the user level is that they "avoid name volatility in the event of NIC replacement".
It's about more than that. And it's about more than dealing with extra NICs being added or NICs being removed or moved from one slot to another. The kernel explicitly DOES NOT GUARANTEE that a NIC will get the same name across reboots. There are many factors that may cause a device to get renamed, including module load order and even upgrading the kernel to a new version. PNIN exists to **solve** "random" NIC renaming, not to create it. Relying on something that the kernel devs explicitly tell you can not be relied upon is crazy. Use udev rules. or ifrename if you must (but udev works better). craig -- craig sanders <cas@taz.net.au>
participants (4)
-
Andrew Pam -
Craig Sanders -
Erik Christiansen -
zlinew9＠virginbroadband.com.au