James, Thank you for answering request for identifying resources and beyond for the specific testing. I had been using udevadm, but not monitor. Your point about possible racing is supported by observations noted in previous post. The pattern of lengthening "no-auto-default" line in NetworkManager.conf may also show varying boot paths.
A topic of interest is web discussions of failures of NetworkManager-wait-online.service as typified by: purschel.eu/linux/centos-7-networkmanager-wait-online-service-failed/ MetworkManager-wait-online.service functions on activation of interface and does not wait for interface to obtain IP address and then come online. NetworkManager-wait-online.service is enabled on XO (systemctl is-name). The parts in the above example fix (nohup,nm-online) are on the XO. Do not know ExecStart part. systemd-networkd-wait-online.service used by other examples is not on XO . Application machanger has been used in other examples. My more immediate concern is bringing up the small starter network with provided Village Telco routers for these XO's in a dense inner city neighborhood. Will have to come back to this topic later. Appreciate the kick-starter. N. C. Riddle > On July 25, 2018 at 6:41 AM James Cameron <qu...@laptop.org> wrote: > > > In my tests just now on OLPC OS 13.2.9 and an XO-4, my USB ethernet > adapters always come back after reconnection or reboot with the same > MAC address. With or without Network Manager running. So that > suggests that for adapters with a physical address ROM or > preprogrammed flash, they will appear predictable. > > My tests above were not with Raspberry Pi Zero. So I now turn to > testing with one; > > 1. the MAC addresses change on each boot of the Zero, and are > unpredictable, > > 2. the MAC address shown on each end is different; comparing usb0 on > the XO vs usb0 on the Zero, > > 3. turning off Network Manager has no effect; therefore this is not a > Network Manager behaviour as you surmised, > > I've also tested with kernel v4.15 on an OLPC NL3, and the same > unpredictable MAC address behaviour occurs. > > Perhaps it is udev? Using udevadm --monitor --property, shows > several events from the kernel, and the first one to mention the > MAC address eventually used is this one; > > UDEV [861.284453] add > /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1:1.0/net/enp0s20u4u1 > (net) > .MM_USBIFNUM=00 > ACTION=add > DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/1-4.1:1.0/net/enp0s20u4u1 > ID_BUS=usb > ID_MM_CANDIDATE=1 > ID_MODEL=RNDIS_Ethernet_Gadget > ID_MODEL_ENC=RNDIS\x2fEthernet\x20Gadget > ID_MODEL_FROM_DATABASE=Linux-USB Ethernet/RNDIS Gadget > ID_MODEL_ID=a4a2 > ID_NET_DRIVER=cdc_ether > ID_NET_LINK_FILE=/lib/systemd/network/99-default.link > ID_NET_NAME=enp0s20u4u1 > ID_NET_NAME_MAC=enxca2a7e605b6f <-- encx followed by the address > ID_NET_NAME_PATH=enp0s20u4u1 > ID_PATH=pci-0000:00:14.0-usb-0:4.1:1.0 > ID_PATH_TAG=pci-0000_00_14_0-usb-0_4_1_1_0 > ID_REVISION=0409 > ID_SERIAL=Linux_4.9.35+_with_20980000.usb_RNDIS_Ethernet_Gadget > ID_TYPE=generic > ID_USB_CLASS_FROM_DATABASE=Communications > ID_USB_DRIVER=cdc_ether > ID_USB_INTERFACES=:0202ff:0a0000:020600: > ID_USB_INTERFACE_NUM=00 > ID_VENDOR=Linux_4.9.35+_with_20980000.usb > ID_VENDOR_ENC=Linux\x204.9.35+\x20with\x2020980000.usb > ID_VENDOR_FROM_DATABASE=Netchip Technology, Inc. > ID_VENDOR_ID=0525 > IFINDEX=7 > INTERFACE=enp0s20u4u1 > INTERFACE_OLD=usb0 > SEQNUM=3175 > SUBSYSTEM=net > SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp0s20u4u1 > TAGS=:systemd: > USEC_INITIALIZED=861268742 > > So the MAC address originates from the kernel or systemd, not Network > Manager. > > As there is a udev event, it should be possible to write a udev rule > to change the MAC address when this or one of the later events > arrives. > > However, perhaps we can see if this MAC address comes from the kernel > or systemd; the event above references > /lib/systemd/network/99-default.link which says' > > [Link] > NamePolicy=kernel database onboard slot path > MACAddressPolicy=persistent > > Now, setting MACAddressPolicy to none has no effect, which > suggests the random address is coming from the kernel. > > My guess is that the reason why your udev rpi script fails is that it > is triggered on more than one udev event, or races with other things > for access to the device. Add more logging and debugging to it. > > Reference: > > https://www.freedesktop.org/software/systemd/man/systemd.link.html > > On Fri, Jul 20, 2018 at 11:20:57PM -0400, Carrol Riddle wrote: > > The difficulty is that a new connection is started on each boot and starts > > as "automatic" IPv4 instead of the desired "share with other computers" This > > results from a randomized MAC address, which appears to be controlled by > > Network Manager. If the MAC address persists on next boot, > > then the connection file will persist. > > > > The MAC address in the cmdline.txt on Zero is vestige of efforts. It was > > left since I suspect it will be part of the solution. Retested without and > > it makes no difference when no other changes are made (i.e., only with > > essentials in cmdline.txt). I have tried static IP on Zero via adding > > ip=192.168.1.2 to cmdline.txt or in dhcpcd.config and udev rule on XO for > > ip=198.168.1.1 . Uncertain if udev rule needs additional specification > > (parent ATTRS ?). > > > > Reasoned that host_addr was telling Zero where to find existing MAC on XO > > and udev rule then tried with hw to assure it was there. Have tried adding > > mac-cloned-address to NetworkManager.conf > > > > NetworkManager randomization of MAC addresses is widely discussed in search > > results and variety of solutions proposed. I have had periods where MAC was > > persistent, but only have it fail a few hours later (just powered off). One > > case of oddity was the persistence on every other boot, if the intervening > > boot was without Zero attached. However, my work with wired links to > > routers (TP-Link MR3020 and Village Telco MP20) shows persistence in boot of > > router. > > > > A competent programmer might just modify the started connection file (using > > awk, grep, sed ?) and restart NetworkManager. :) . I tried replacing > > (cp) with model files, but that has problems (date stamp). > > /etc/NetworkManger/connections > > > > What I see points me to NetworkManager, > > > > Carrol Riddle > > > > > On July 14, 2018 at 1:07 AM James Cameron <qu...@laptop.org> wrote: > > > > > > > > > Interesting. > > > > > > But why do you need to give a MAC address on cmdline.txt on the RPi > > > and in the XO udev script? g_ether should assign an address, and > > > cdc_ether should receive it from USB descriptors. > > > > > > On Tue, Jul 10, 2018 at 10:50:44AM -0400, Carrol Riddle wrote: > > > > Soliciting info or pointers to resources for disabling mac address > > > > randomization by NetworkManager for USB0 (eth1) on XO's. Wifi mac > > > > addresses are not randomized. > > > > > > > > An XO can share its Wifi over wired ethernet link (USB0) where it can be > > > > used by > > > > a Chromium browser on a linked Raspberry Pi Zero (not W). SSH -X on the > > > > link > > > > allows XO keyboard and display to be used for Chromium. > > > > > > > > The several setup steps are simple, but must be repeated with each boot > > > > since > > > > NetworkManager (version 0.9.8.* on XO's) supplies a different mac > > > > address for > > > > the link on each boot. To provide a simple Sugar wrapper to run > > > > Chromium, a > > > > consistent mac address would be needed. > > > > > > > > Methods from web searches have not been successful in disabling > > > > randomization, > > > > largely since they use features added after 0.9.8. Using a udev rule > > > > to "ifconfig > > > > usb0 hw ether address" has come the closest, but breaks after a few > > > > boots and returns to > > > > randomization. > > > > > > > > BACKGROUND > > > > > > > > For those interested, details are below, but are only peripheral to > > > > question. This use of the XO's display, keyboard and wifi by Chromium / > > > > Zero provides a low cost way to access a widely accepted browser. The > > > > Zero can be plugged into XO USB for power and signals. The Zero is > > > > available for < $10, and with SD card and plug, total cost should be $15 > > > > - 20 > > > > USD. > > > > > > > > > > > > ______________________________________ > > > > > > > > > > > > MANUAL METHOD - XO (after Pi Zero setup) > > > > > > > > In Sugar, connect to wifi . This needs to be done only the first time > > > > and is > > > > persistent between boots. Switch to Gnome and disconnect from the > > > > "Wired > > > > connection ?" that just formed. Edit the connection : IPv6 to ignore, > > > > IPv4 to > > > > require IPv4 and "shared to other computers" and save. Connect to > > > > this > > > > connection. The connection info should show ip address starting with > > > > 10: . > > > > This link is not persistent between boots. > > > > > > > > systemctl enable sshd.service > > > > > > > > PI ZERO SETUP (prior) > > > > > > > > Raspberry Pi Zero with Raspbian Desktop installed. To > > > > /boot/config.txt on Pi > > > > SD edit and add dtoverlay=dwc2 . To /boot/cmdline.txt add after > > > > "rootwait" > > > > modules-load=dwc2,g_ether host_addr=00:22:82:ff:ff:20 > > > > dev_addr=00:22:82:ff:ff:22 (Substitute local mac addresses.) > > > > To start with SSH, add dummy "ssh" file to /boot directory. On XO, > > > > ssh pi@raspberrypi.local with password raspberry . Configure Zero to > > > > boot to > > > > command line (CLI) with raspi-config . To use Raspbian desktop, ssh > > > > -X > > > > pi@raspberry.local, and then /etc/X11/Xsession. The Pi Tool Bar > > > > partially > > > > overlaps the Gnome Tool Bar, but selecting "medium display size" > > > > minimizes > > > > affects. > > > > > > > > UDEV INFO FOR RULES (but not able to make work) > > > > > > > > DRIVERS=="cdc_ether" > > > > > > > > ATTRS{idVendor=1d6b} > > > > > > > > ATTRS{idProduct=0001} > > > > > > > > RUN+="/etc/udev/scripts/rpi" > > > > > > > > > > > > Script rpi: > > > > > > > > ifconfig usb0 down > > > > > > > > ifconfig usb0 hw ether 00:22:82:FF:FF:20 > > > > > > > > ifconfig usb0 up > > > > > > > > _____________________________ > > > > > > > > Carrol Riddle > > > > > > > > ebox...@scishare.com > > > > _______________________________________________ > > > > Devel mailing list > > > > Devel@lists.laptop.org > > > > http://lists.laptop.org/listinfo/devel > > > > > > -- > > > James Cameron > > > http://quozl.netrek.org/ > > > _______________________________________________ > > > Devel mailing list > > > Devel@lists.laptop.org > > > http://lists.laptop.org/listinfo/devel > > _______________________________________________ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > -- > James Cameron > http://quozl.netrek.org/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
