[SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

nilesOien · 2017-12-01 17:28:42

Today I did my biweekly "pacman -Syu". As usual I did my two personal laptops first, made sure they updated OK, and then I updated my desktop. It seemed like a pretty nominal update, not much special, I answered 'Y' to all questions.

When I rebooted after the update, my work desktop had lost network access :

$ ping 8.8.8.8
connect: Network is unreachable

What's REALLY odd is that the icons in the top right of the gnome screen seem fine. They show a wired connection, as they always do. And the only thing that shows up as unusual in the boot sequence is that it fails to cross mount a couple of NFS mounts I have set up. It seems like the network starts up fine. But then I have no network access.

It's not hardware failure, when I boot off an Arch CD that I burned in September the network seems fine. There is a difference in that the CD boot uses DHCP and usually I have a static IP set up, but I don't imagine that's a big issue.

I think it has to be the Arch update, and I've no idea how to debug this. As I said the boot sequence seems fine.

Please help, I'm really puzzled by this and I'm not sure where to start debugging! I can work off my laptop for a while but I need my work desktop back. And on a more altruistic note, if this is a problem with the update I'd like to fix it before others fall into the problem. It seems quite significant!

Thanks,

Niles Oien.

Last edited by nilesOien (2017-12-04 18:09:35)

Slithery · 2017-12-01 17:29:40

What are you using to manage your networking?

jasonwryan · 2017-12-01 17:41:07

Disable your network manager and connect manually, that will provide you with the requisite debugging information.

Also, remove the redundant plea for help from your thread title: https://wiki.archlinux.org/index.php/Co … ow_to_post

ewaller · 2017-12-01 17:48:40

What is the output of ip addr

nilesOien · 2017-12-01 18:36:00

Good points/comments, all.

The redundant plea has been removed from the subject line.

I am using NetworkManager to manage the network.

The output of "ip addr" looks like :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b8:ac:6f:94:b4:17 brd ff:ff:ff:ff:ff:ff
    inet 172.23.19.12/24 brd 172.23.19.255 scope global noprefixroute enp5s0
       valid_lft forever preferred_lft forever
    inet6 fe80::baac:6fff:fe94:b417/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 16:bd:61:ad:54:cb brd ff:ff:ff:ff:ff:ff

Let me see what I can glean by stopping NetworkManager, trying to connect manually and/or using another method to manage the network. It isn't my forte, so there may be a delay in getting back to you here. Thanks!

Niles.

nilesOien · 2017-12-01 22:45:28

I had to take a break for a meeting, and it took me some time to debug this, but I *think* I have some information that is worth posting, although it's puzzling.

First, I can connect if I stop the way that I was connecting :

# systemctl disable NetworkManager.service
# systemctl disable NetworkManager-wait-online.service

And then reboot and connect manually, like so :

ip link set enp5s0 up
ip addr add 172.23.19.12/24 broadcast 172.23.19.255 dev enp5s0
ip route add 172.23.19.1 dev enp5s0
ip route add default via 172.23.19.1 dev enp5s0

That works, although I may have to put a nameserver in /etc/resolv.conf to be able to resolve anything, depending on what state that file was left in.

Puzzlingly, after a clean boot, I can start the method that I *used* to use to connect :

systemctl start netctl@nso_network.service

And that seems to work. But if I try to enable that, I get an error :

# systemctl enable netctl@nso_network.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

That puzzles me, because up to now if I can 'start' a service I can also 'enable' it, but that may be ineptitude with systemctl on my part.

Also, if I start NetworkManager , it doesn't give any errors, but also doesn't work :

# systemctl start NetworkManager-wait-online.service
# systemctl start NetworkManager.service
# ping 8.8.8.8
connect: Network is unreachable
# systemctl stop NetworkManager.service
# systemctl stop NetworkManager-wait-online.service

That's not too surprising, because NetworkManager has not been working throughout this. But what is surprising is that if I then try to start netctl, it doesn't work :

# systemctl start netctl@nso_network.service
Job for netctl@nso_network.service failed because the control process exited with error code.
See "systemctl  status netctl@nso_network.service" and "journalctl  -xe" for details.

Which puzzles me, because I would have thought that starting and stopping NetworkManager would have returned my system to the state it was in after reboot, when I could start netctl? The journalctl command it suggests shows this :

# journalctl  -xe
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit NetworkManager.service has begun shutting down.
Dec 01 15:08:36 spsc-nso19-12 NetworkManager[1028]: <info>  [1512166116.1546] caught SIGTERM, shutting down normally.
Dec 01 15:08:36 spsc-nso19-12 NetworkManager[1028]: <info>  [1512166116.1919] dns-mgr: Writing DNS information to /usr/bin/resolvconf
Dec 01 15:08:36 spsc-nso19-12 NetworkManager[1028]: <info>  [1512166116.2049] exiting (success)
Dec 01 15:08:36 spsc-nso19-12 systemd[1]: Stopped Network Manager.
-- Subject: Unit NetworkManager.service has finished shutting down
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit NetworkManager.service has finished shutting down.
Dec 01 15:08:36 spsc-nso19-12 gnome-shell[686]: Removing a network device that was not added
Dec 01 15:08:36 spsc-nso19-12 gnome-shell[453]: Removing a network device that was not added
Dec 01 15:09:12 spsc-nso19-12 systemd[1]: Created slice system-netctl.slice.
-- Subject: Unit system-netctl.slice has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit system-netctl.slice has finished starting up.
-- 
-- The start-up result is RESULT.
Dec 01 15:09:12 spsc-nso19-12 systemd[1]: Starting A basic static ethernet connection for Niles at CU...
-- Subject: Unit netctl@nso_network.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit netctl@nso_network.service has begun starting up.
Dec 01 15:09:12 spsc-nso19-12 network[1114]: Starting network profile 'nso_network'...
Dec 01 15:09:12 spsc-nso19-12 network[1114]: The interface of network profile 'nso_network' is already up
Dec 01 15:09:12 spsc-nso19-12 systemd[1]: netctl@nso_network.service: Main process exited, code=exited, status=1/FAILURE
Dec 01 15:09:12 spsc-nso19-12 systemd[1]: netctl@nso_network.service: Failed with result 'exit-code'.
Dec 01 15:09:12 spsc-nso19-12 systemd[1]: Failed to start A basic static ethernet connection for Niles at CU.
-- Subject: Unit netctl@nso_network.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit netctl@nso_network.service has failed.
-- 
-- The result is RESULT.

At that point, though, I can still connect by hand. I'm not sure what's going on? It seems like maybe NetworkManager-wait-online.service isn't working, although my understanding of that is vague. I think it just makes sure the NetworkManager has succeeded before it proceeds with the boot process to do things like mount NFS disks.

It's also puzzling to me that I can connect by hand and get no error messages, which is what I was looking for. It seems like maybe things are happening out of sequence? It also seems like attempting to connect one way is then affecting subsequent attempts to connect in other ways?

Also, output of "ip addr" is :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b8:ac:6f:94:b4:17 brd ff:ff:ff:ff:ff:ff
    inet 172.23.19.12/24 brd 172.23.19.255 scope global noprefixroute enp5s0
       valid_lft forever preferred_lft forever
    inet6 fe80::baac:6fff:fe94:b417/64 scope link 
       valid_lft forever preferred_lft forever

That's puzzling, because at one point there was an 'eth0' interface in there (and a corresponding 'eth0' file in /sys/class/net/) but eth0 seems like it's vanished now.

So, in summary, the hardware seems OK, connecting by hand succeeds without error, and there seems to be an interaction between connection attempts that I didn't expect, although that could be ineptitude on my part.

Did something change around how/when NetworkManager runs? This isn't an area I look at very often so I apologize if I'm not getting something that's obvious from the above.

Thanks,

Niles.

progandy · 2017-12-01 22:49:44

If my memory serves, then netctl needs the network interface to be down before you start it. I think that may be the problem when you try it after networkmanager.

Edit: I have no idea about networkmanager, I stopped using it long ago in favor of connman.

Last edited by progandy (2017-12-01 22:50:43)

cfr · 2017-12-01 23:35:58

What's in netctl@nso_network.service? This doesn't match any of the service files mentioned in the netctl manual page listing special units for systemd. It isn't standard, is it?

progandy · 2017-12-01 23:46:49

It looks to be original. There is no [Install] section which is needed to "enable" a service.
https://git.archlinux.org/netctl.git/tr … l@.service

I think you should simply enable "netctl.service" and start the profiles you want with the netctl tool. Then the netctl status will be saved on shutdown and all running profiles are restored on boot.

Edit: There is "netctl enable", which claims to do everything necessary to create and enable a systemd unit for a profile on boot.

Last edited by progandy (2017-12-01 23:52:06)

nilesOien · 2017-12-02 01:42:04

Thanks. nso_network is the specific network profile I have. You may well be correct, that may not be the way to start netctl. It's based on how I stopped it a while ago.

I ditched netctl some time ago because after an update it started starting things up such that the NFS mounts I have didn't come up, although a "mount -a" after boot brought them online. I was really just trying netctl as a debugging step. I'm not particularly enamoured of it. And now it seems like NetworkManager has an issue. I'm not sure if I want to keep hopping between network managers like this.

I did have one experience with connmanctl, on a debian box (actually a lego robot that I got to boot linux using the stuff at ev3dev.org). I might look into that. I think maybe I initially chose network managers that are maybe not being maintained so well, although that is highly speculative on my part.

It's Friday evening here now, I'll have to leave this for a while. I'm glad we figured out a workaround. It would not have occured to me to try to connect manually. I realize that in hindsight that sounds silly, but it wouldn't have. I really only wind up looking into this if there's an issue, it isn't very often.

I'll likely look more on Monday. With the work around I have some room to move.

seth · 2017-12-02 08:33:36

You somehow have two ethernet interfaces, check "ip route" on whether the correct (the one with carrier) one is actually used.

luminate · 2017-12-03 13:53:31

Does your desktop NIC use the e1000e driver (lsmod | grep e1000e) by chance?

I had a similar issue, seemingly caused by some link detection changes in the e1000e driver included in the last kernel update (4.14.3 / 4.9.66), that was solved by increasing the up and carrier timeouts in my netctl profile:

TimeoutUp=300
TimeoutCarrier=300

Your issue may be different, but it's worth a shot.

1. Disable NetworkManager and any other network managers
2. Add the two timeout options above to your netctl profile file (/etc/netctl/nso_network)
3. Enable the netctl profile (netctl enable nso_network)
4. Reboot and cross your fingers

liviucmg · 2017-12-04 10:22:51

@nilesOien Same thing happened to me after updating yesterday. I was running the linux-lts kernel, but also had the standard linux kernel installed as a backup. Booting with the standard one solves the problem - eth0 shows up properly when I run ifconfig. It's wierd because you seem to have a enp5s0 that replaced eth0, while for me it just dissapeared leaving me only with the local loopback lo.

My motherboard is ASRock P67 Pro3 with a built-in RTL8111/8168/8411 PCI Express Gigabit.

FMB · 2017-12-04 13:08:01

Also had an issue with last kernel and e1000e driver. luminate's solution didn't work for me, had to downgrade kernel to 4.13.12-1. Hope next version will fix it...

nilesOien · 2017-12-04 15:41:00

Thanks, all.

By way of an update : I have both linux and lunux-lts, I tried booting them both, but it made no difference.

I do not have the e1000e driver, "lsmod | grep e1000e" shows nothing.

When I first start up, without any network manager running, I have both enp5s0 and eth0 and "ip route" returns nothing :

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b8:ac:6f:94:b4:17 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 16:bd:61:ad:54:cb brd ff:ff:ff:ff:ff:ff

# ls /sys/class/net/
enp5s0	eth0  lo

# ip route
#

Then I do my manual connect :

ip link set enp5s0 up
ip addr add 172.23.19.12/24 broadcast 172.23.19.255 dev enp5s0
ip route add 172.23.19.1 dev enp5s0
ip route add default via 172.23.19.1 dev enp5s0
mount -a

After that, enp5s0 is up, I still have both eth0 and enp5so, and I have a route (so
basically I got what I asked for, but I have eth0 and enp5s0, which seems odd) :

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether b8:ac:6f:94:b4:17 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 16:bd:61:ad:54:cb brd ff:ff:ff:ff:ff:ff

# ls /sys/class/net/
enp5s0	eth0  lo

# ip route
default via 172.23.19.1 dev enp5s0 
172.23.19.0/24 dev enp5s0 proto kernel scope link src 172.23.19.12 
172.23.19.1 dev enp5s0 scope link

I *think* what's messing things up is that I have the two network interfaces? Embarrassingly, I've never looked at that but
I don't think it's correct, is it? I was thinking that this is an issue with NetworkManager but now I'm wondering
if it has to do with having those two interfaces, maybe that's a situation caused by something else and NetWorkManager
can't cope with it?

I'd like to solve this rather than trying other network managers if possible. It would be good to get to
the bottom of it I think. I don't think I'd be the only one affected, and given that I have a workaround
that gives us room to try debugging it.

Any thoughts appreciated, and Thanks,

Niles.

seth · 2017-12-04 15:49:04

lspci
lsusb

Did you do any of https://wiki.archlinux.org/index.php/Ne … evice_name ?
Your earlier post indicated that eth0 doesn't have a carrier (so basically no cable connection) - if NM tries to build a route on that interface, things won't work. Though I's think you have to configure the used interface even with NM (albeit maybe with a fancy GUI)

nilesOien · 2017-12-04 16:29:46

lspci shows :

# lspci
00:00.0 Host bridge: Intel Corporation 5520/5500/X58 I/O Hub to ESI Port (rev 22)
00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 22)
00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 (rev 22)
00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 (rev 22)
00:14.0 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub System Management Registers (rev 22)
00:14.1 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers (rev 22)
00:14.2 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub Control Status and RAS Registers (rev 22)
00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4
00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5
00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1
00:1c.5 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 6
00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller
00:1f.2 RAID bus controller: Intel Corporation SATA Controller [RAID mode]
00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller
02:00.0 VGA compatible controller: NVIDIA Corporation G96GL [Quadro FX 580] (rev a1)
05:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5761 Gigabit Ethernet PCIe (rev 10)
06:04.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 70)
3f:00.0 Host bridge: Intel Corporation Xeon 5500/Core i7 QuickPath Architecture Generic Non-Core Registers (rev 05)
3f:00.1 Host bridge: Intel Corporation Xeon 5500/Core i7 QuickPath Architecture System Address Decoder (rev 05)
3f:02.0 Host bridge: Intel Corporation Xeon 5500/Core i7 QPI Link 0 (rev 05)
3f:02.1 Host bridge: Intel Corporation Xeon 5500/Core i7 QPI Physical 0 (rev 05)
3f:03.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller (rev 05)
3f:03.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Target Address Decoder (rev 05)
3f:03.4 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Test Registers (rev 05)
3f:04.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Control Registers (rev 05)
3f:04.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Address Registers (rev 05)
3f:04.2 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Rank Registers (rev 05)
3f:04.3 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Thermal Control Registers (rev 05)
3f:05.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Control Registers (rev 05)
3f:05.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Address Registers (rev 05)
3f:05.2 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Rank Registers (rev 05)
3f:05.3 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Thermal Control Registers (rev 05)
3f:06.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Control Registers (rev 05)
3f:06.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Address Registers (rev 05)
3f:06.2 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Rank Registers (rev 05)
3f:06.3 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Thermal Control Registers (rev 05)

I think the only part of that that's relevant is :

05:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5761 Gigabit Ethernet PCIe (rev 10)

lsusb seems unremarkable, I see keyboard, mouse and iPhone plugged in (it's just charging). All of that is normal, by which I meant that everything worked with that setup before the upgrade.

# lsusb
Bus 002 Device 006: ID 045e:07b2 Microsoft Corp. 
Bus 002 Device 004: ID 413c:2106 Dell Computer Corp. Dell QuietKey Keyboard
Bus 002 Device 007: ID 05ac:12a8 Apple, Inc. iPhone5/5C/5S/6
Bus 002 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra Fast Media Reader
Bus 002 Device 003: ID 0424:2640 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

My /etc/udev/rules.d/ directory (as referenced at the web site you mentioned) is empty. I'm puzzled as to what's going on there - why would the update mean that I have to do a name change? I could be missing the point.

After looking at that page, though, one thing that puzzles me is that the two interfaces have different MAC addresses :

# cat /sys/class/net/enp5s0/address
b8:ac:6f:94:b4:17
# cat /sys/class/net/eth0/address
16:bd:61:ad:54:cb

There's definitely only one network card in the machine, though, so I'm puzzled by that.

Niles.

nilesOien · 2017-12-04 16:51:01

It looks like eth0 is my iPhone. When I unplug it, eth0 disappears, both from /sys/class/net and from "ip link". When I plug it back it, it's there.

I'm puzzled, because I generally plugged in my iPhone at work. It's never been a problem. I'm not sure why it's now seen as a network device. But I'll leave it unplugged from now on.

Things are still not working right, even with the iPhone unplugged. When I re-enabled NetworkManager, enp5s0 is up, but I still have to manually add the route :

ip route add 172.23.19.1 dev enp5s0
ip route add default via 172.23.19.1 dev enp5s0

Then everything works. Let me look at this some more, it's puzzling.

seth · 2017-12-04 16:53:06

You don't have to change interface names at all - just thought some broken rule would copy the interface.
The first one is a MAC from Dell, the second one has no registered OUI.

Did you toy around with virtual interfaces?
Check your dmesg on how the device ends up there...

Edit: tethering ;-)
Some udev rule setting up this automagically??
https://wiki.archlinux.org/index.php/IPhone_tethering

Last edited by seth (2017-12-04 16:54:40)

nilesOien · 2017-12-04 17:45:36

I think we've found the issue. Doing a 'diff' between `dmesg` with the phone connected and disconnected shows :

$ dmesg > noPhone.dat
$ dmesg > Phone.dat
$ diff noPhone.dat Phone.dat 
784a785,788
> [  595.876071] usb 2-3.1.3: new high-speed USB device number 8 using ehci-pci
> [  595.992292] ipheth 2-3.1.3:4.2: Apple iPhone USB Ethernet device attached
> [  595.998841] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [  595.999236] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

So it seems like Arch is seeing the phone as an ethernet device. When I connect the phone, the phone will ask me if I should "trust" the computer. I always say no because I just want the phone to charge, not interact. But it seems like now the phone is identifying itself as an ethernet device anyway?

I do have 'usbmuxd' and 'libmobiledevice' installed. At one point a while ago I was copying images off of my kid's iPad and I think I needed them. The page about tethering an iPhone mentions those packages. Maybe they play a role here, I don't know.

I did recently just upgrade the phone to the latest iOS, 11.2. A few days after that, apps on the phone started failing (I literally woke up late because the alarm clock failed overnight). I had to take it into Apple and they had to reset the OS software (essentially, re-install the OS as I understand it).

I'm wondering if it's a weird interaction between Arch and the latest iOS? It seems like the latest iOS identifies itself as an ethernet device even if you don't trust the computer you're plugging into with usb. And then somehow the phone gets written to and it overwrites the OS on the phone in some way? And it also breaks the network setup on Arch?

Everything is fine on Arch now, I had to go into the NetworkManager GUI and re-enable automatic route selection, and everything came back. When I plug the iPhone in, eth0 still appears, though.

I guess I'll mark this as [SOLVED] because Arch seems OK. It's a very strange interaction with the latest iOS, though. With the High Sierra root bug, Apple has had a rough time of it of late :

https://www.macworld.com/article/323886 … a-fix.html

If I can help look into this more, and that would be useful, I'd be happy to do it. I apologize if the chase was long-winded. When the network failed immediately after an Arch update, my first thought wasn't that it was my iPhone that was just plugged in for charging, especially since I've done that for a while now.

Niles.

seth · 2017-12-04 17:53:06

You could blacklist ipheth ("Apple iPhone USB Ethernet driver") but actually everything looks sane, the only problem is that NM then prefers it over the actual ethernet device.

This all happens because the "Personal Hotspot" is activated on your phone - if that's an undesired change by the idiot "genius" in the bar, just undo it.

nilesOien · 2017-12-04 17:56:32

Oddly, "Personal Hostspot" is off on the iPhone.

jasonwryan · 2017-12-04 17:57:16

Please edit your thread title to one that describes the issue, it may help others down the track: https://wiki.archlinux.org/index.php/Co … ow_to_post

seth · 2017-12-04 18:04:38

nilesOien wrote:

Oddly, "Personal Hostspot" is off on the iPhone.

Then this is part of apples recent efforts to make you use something else ;-)
But hey, you now at least got gender and ethnically correct emojis to express your anger

nilesOien · 2017-12-04 18:04:50

Thanks, Jason. I wanted to change the title, but wasn't sure if that would cause more issues. So I tried just adding "(iPhone connection)" to the end of the subject when I added "[SOLVED]" to the start of it. It sounds like changing the title completely isn't an issue, so let me do that.

Arch Linux

#1 2017-12-01 17:28:42

[SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#2 2017-12-01 17:29:40

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#3 2017-12-01 17:41:07

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#4 2017-12-01 17:48:40

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#5 2017-12-01 18:36:00

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#6 2017-12-01 22:45:28

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#7 2017-12-01 22:49:44

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#8 2017-12-01 23:35:58

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#9 2017-12-01 23:46:49

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#10 2017-12-02 01:42:04

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#11 2017-12-02 08:33:36

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#12 2017-12-03 13:53:31

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#13 2017-12-04 10:22:51

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#14 2017-12-04 13:08:01

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#15 2017-12-04 15:41:00

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#16 2017-12-04 15:49:04

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#17 2017-12-04 16:29:46

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#18 2017-12-04 16:51:01

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#19 2017-12-04 16:53:06

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#20 2017-12-04 17:45:36

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#21 2017-12-04 17:53:06

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#22 2017-12-04 17:56:32

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#23 2017-12-04 17:57:16

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#24 2017-12-04 18:04:38

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

#25 2017-12-04 18:04:50

Re: [SOLVED] Connected iOS 11.2 devices seen as eth0, can break networking

Board footer