ZupoLlask Posted September 20, 2017 Posted September 20, 2017 Hi guys! How far are we from next release to be Stretch based? What needs to be done? Is anyone coordinating those efforts? Is this a priority?
Igor Posted September 20, 2017 Posted September 20, 2017 14 minutes ago, ZupoLlask said: Hi guys! How far are we from next release to be Stretch based? What needs to be done? Is anyone coordinating those efforts? Is this a priority? Basic things are working but it's not very much tested. I remember two bugs that are out there and haven't been fixed yet: - LIRC Configuration - our custom build hostapd does not want to install or fails to work. We won't use upstream version Nobody is coordinating this and help is needed otherwise this will take some time ...
zador.blood.stained Posted September 20, 2017 Posted September 20, 2017 Regarding LIRC I would propose to drop most of the LIRC related configurations (really, out of all supported devices how many of them have a matching remote in the kit? Apart from Beelink X2) and add LIRC related options to armbian-config.
Igor Posted September 20, 2017 Posted September 20, 2017 30 minutes ago, zador.blood.stained said: and add LIRC related options to armbian-config Agree. I'll move it there and cleanup from configs.
zador.blood.stained Posted September 20, 2017 Posted September 20, 2017 Regarding building additional packages for Stretch - I tested some initial changes today, but it will need some work: [ warn ] Following packages failed to build: [ .... ] xf86-video-fbturbo:stretch:armhf [ .... ] fswebcam-gc2035:stretch:armhf [ .... ] guvcview:stretch:armhf [ .... ] hostapd:stretch:armhf [ .... ] hostapd-realtek:stretch:armhf [ .... ] libmali-sunxi-r3p0:stretch:armhf [ .... ] sunxi-tools:stretch:armhf [ .... ] swconfig:stretch:armhf [ .... ] xf86-video-fbturbo:stretch:arm64 [ .... ] hostapd:stretch:arm64 [ .... ] hostapd-realtek:stretch:arm64 [ .... ] sunxi-tools:stretch:arm64
Igor Posted September 23, 2017 Posted September 23, 2017 pin-priority is not set ... Example: apt-get install hostapd is installed from upstream ... I can't find in build script where do we set this?
zador.blood.stained Posted September 23, 2017 Posted September 23, 2017 5 minutes ago, Igor said: Example: apt-get install hostapd is installed from upstream ... I can't find in build script where do we set this? Currently - nowhere, we are relying on Armbian package versions being higher than upstream.
Igor Posted September 23, 2017 Posted September 23, 2017 OK. Then I'll simply go up with our versions.
zador.blood.stained Posted September 23, 2017 Posted September 23, 2017 1 minute ago, Igor said: OK. Then I'll simply go up with our versions. We could also try to adapt the upstream 2.5 version, at least for the non-realtek variant.
Igor Posted September 23, 2017 Posted September 23, 2017 Just now, zador.blood.stained said: We could also try to adapt the upstream 2.5 version, at least for the non-realtek variant. How do you mean? To not make on our own? Changing this https://github.com/armbian/build/blob/master/packages/extras-buildpkgs/90-hostapd.conf#L4-L5 to 2.6 should do the trick? I have no proper/better idea.
zador.blood.stained Posted September 23, 2017 Posted September 23, 2017 5 minutes ago, Igor said: Changing this https://github.com/armbian/build/blob/master/packages/extras-buildpkgs/90-hostapd.conf#L4-L5 to 2.6 should do the trick? I have no proper/better idea. Right now we should set local package_upstream_version="2:2.5" In the future we can try to use upstream 2.6, but it will require adjusting some patches.
Igor Posted September 24, 2017 Posted September 24, 2017 This adjust source version while package remains the same. Source: wpa (2.5~armbian5.33.170922+1) Version: 1:2.5~armbian5.33.170922+1 Source: wpa (2:2.5~armbian5.33.170925+1) Version: 1:2.5~armbian5.33.170925+1
Igor Posted September 27, 2017 Posted September 27, 2017 Another bug. Haven't pinpointed yet but it most likely comes from upstream. Wireless connection (using nmtui-connect) timeouts on initial connect very often, while the exact same setup works perfectly fine on Ubuntu Xenial. When setting up an AP it works fine.
zador.blood.stained Posted September 28, 2017 Posted September 28, 2017 15 hours ago, Igor said: Wireless connection (using nmtui-connect) timeouts on initial connect very often, while the exact same setup works perfectly fine on Ubuntu Xenial. When setting up an AP it works fine. Can it be related to the random MAC address "feature"? https://github.com/armbian/build/issues/741#issuecomment-332072152
Igor Posted September 28, 2017 Posted September 28, 2017 Yes, it's related. Shall we add this by default?
zador.blood.stained Posted September 28, 2017 Posted September 28, 2017 24 minutes ago, Igor said: Yes, it's related. Shall we add this by default? Yes, as a drop-in for Stretch only, I'll add it later.
tkaiser Posted September 28, 2017 Posted September 28, 2017 44 minutes ago, Igor said: Shall we add this by default? I'm really not sure since MAC address randomization should be considered an essential feature these days especially when we think about supporting devices like PineBook. At least I would suggest to first check whether stopping device renaming isn't the better option as described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839605#25 Does this apply to Stretch too?
zador.blood.stained Posted September 28, 2017 Posted September 28, 2017 24 minutes ago, tkaiser said: I'm really not sure since MAC address randomization should be considered an essential feature these days especially when we think about supporting devices like PineBook. We can always override settings by adding another file specifically for the Pinebook.
tkaiser Posted September 28, 2017 Posted September 28, 2017 28 minutes ago, zador.blood.stained said: We can always override settings by adding another file specifically for the Pinebook. And then reverting the additional NM defaults change back? Also individually for the Pinebook? As far as I understood the 'problems' are nmtui connect problem reported by Igor (most probably since NM changing MAC address in between call of nmtui and trying to establish connection?) According to the github issue syslog spamming (which I consider not being a problem since 'attaching to a network seems to have stopped the noise as well') According to the same github issue 'NetworkManager is keeping the CPU busy'. Does this change after stopping MAC address randomization? Is NM silent now or is it still busy bot now with the same MAC address? Adding to the above I wonder what's the state of affairs wrt Wi-Fi powermanagement and NM in Stretch (since dmesg output on Github seems to indicate it's not working as on Jessie or Xenial). I haven't looked into this myself but to me the issues that should been looked at a little bit closer wrt Stretch are powermanagement settings constant try to search for networks (how to disable this would be my first question) nmtui-connect problems (if we can stop NM from permanently searching for open Wi-Fis on its own is this still an issue then?) Adopting a workaround that's 'recommended' by countless Debian/Ubuntu users reminds of the 'UAS is evil' stupidity mess we have to deal with in the Linux world.
tkaiser Posted September 28, 2017 Posted September 28, 2017 2 hours ago, Igor said: Shall we add this by default? Hmm... by looking around I came accross this (which doesn't seem to make sense to me but is reported to work) [device-mac-randomization] wifi.scan-rand-mac-address=no [connection-mac-randomization] ethernet.cloned-mac-address=random wifi.cloned-mac-address=random And then when reading about NM doing a Wi-Fi background scan every 120 seconds by default (can be disabled by locking the BSSID to the profile) and problems with some Wi-Fi driver this reminded me of the reported Wi-Fi reliability issues we had (only when connecting with NM/nmtui/nmcli and not happening when establishing Wi-Fi 'the traditional way'). Since I can't remember whether this occured with all sorts of drivers or only with one (eg. 8189fs for example?) may I ask whether someone else remembers? Just to decide with which board to further test...
Igor Posted September 28, 2017 Posted September 28, 2017 I noticed problems with external adapters first. There are not many working ones and if those working ones are further crippled by this feature, there are no woking left Well, let's do some more tests.
Igor Posted September 28, 2017 Posted September 28, 2017 [connection-mac-randomization] ethernet.cloned-mac-address=random wifi.cloned-mac-address=random After adding this part, connections starts to go cycle up / down / up / down ... checked on three different drivers. Ralink, Atheros, Mediatek. http://sprunge.us/MLdL
tkaiser Posted September 28, 2017 Posted September 28, 2017 14 minutes ago, Igor said: http://sprunge.us/MLdL Hehe... this is your setup with 40 Wi-Fi USB devices connected? Yeah, setting connection-mac-randomization to random doesn't make much sense. And still not knowing with which device to test first (since trying to keep it simple first with only one available Wi-Fi device connected, preferrable onboard)
zador.blood.stained Posted September 28, 2017 Posted September 28, 2017 Just dist-upgraded from Xenial to Zesty (in hope to find a way to test HDMI CEC) but managed to hit the same issue: RTL8192CU based USB wireless adapter failed to connect to a wireless network until I added [device-mac-randomization] wifi.scan-rand-mac-address=no to NetworkManager.conf
chymian Posted October 1, 2017 Posted October 1, 2017 may I chime in with my latest experiences on self-build stretch images for the XU4/HC1: in stretch, the former eth0 get renamed to enx001e0630cdfb (on the XU4), and surly to other names on other HW. that does not happen when upgraded from jessie. see also: https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names that leads to: 1. the default /etc/network/interface config with 'eth0 dhcp' does work here somehow – but it shouldn't. don't know for other HW. 2. but setting up an bridge br0 with eth0 as interface does not work. it needs the new interface name. so it seems a little bit random and might leave one with an unreachable device. suggestion: adapt all /etc/network/interface* files with an automatic script at firstboot to the interface-name the kernel uses (i.e. in /proc/net/dev) somthing like this should do it: IFNAME=`grep en /proc/net/dev|cut -d: -f1` or IFNAME=`basename $(ls -d /sys/class/net/en*)` sed -i s/eth0/$IFNAME/g /etc/network/interfaces* same applies to wlan-interfaces
Igor Posted October 1, 2017 Posted October 1, 2017 ... or more simple solution by removing /etc/network/interfaces to leave Network manager to take care of this?
zador.blood.stained Posted October 1, 2017 Posted October 1, 2017 20 minutes ago, Igor said: ... or more simple solution by removing /etc/network/interfaces to leave Network manager to take care of this? It should take care of this already, that's why renamed interfaces "magically" work
chymian Posted October 1, 2017 Posted October 1, 2017 10 minutes ago, zador.blood.stained said: It should take care of this already, that's why renamed interfaces "magically" work so it was NM who gave the HC1 the dhcp-ip on the "enx001e0630cdfb"-interface, not the ifupdown-scripts. makes sense. and why was it not reachable after I added a bridge-config to interfaces (with eth0), not touching NM. that shouldn't have touched the NM setup of "enx001e0630cdfb" - right? tracing the traffic shows, that both, the fixed bridge-ip (eth0) and the NM-dhcp-ip (enx001e0630cdfb) responds to arp-packages, but not to ping or ssh. it seems to be buggy and leads to inconsistent behavior. so, relaying on NM would also mean removing /etc/network/interfaces and at least add a BFW to the other interfaces.*-files about the changed name, to make it less confusing. it left me with an headless server (HC1) which was not net-reachable. and for an server-like device, I experienced over the years, is an fixed config much more reliable then NM. just my 2cent
zador.blood.stained Posted October 1, 2017 Posted October 1, 2017 25 minutes ago, chymian said: and for an server-like device, I experienced over the years, is an fixed config much more reliable then NM. I kind of agree with this, but as long as the device has only one Ethernet port, no wireless devices and disabled "predictable interface names". Since we started to attract a lot of inexperienced users when we added support for cheap H3 boards it was decided to install NM by default on all images (both server and desktop) so inexperienced users could benefit from it, and advanced users can always disable/remove/customize stuff as they want.
botfap Posted October 1, 2017 Posted October 1, 2017 I thought I had a LOT of problems with NetworkManager on stretch, xenial & artful (arm+x64 but not Armbian): Unreliable connections on the WiFi side Interfaces that magically shut down with no log on the wired side MAC address randomisation mid way through setting up a wifi connection causing the connection to fail to negotiate (realtek & ralink in particular) Network device names changing between boot (not strictly NM but related) PPTP interfaces not coming up automatically NM wiping out custom bridge configs, etc I found that the problem was not actually NetworkManager in most cases but caused by inconsistencies (polite description) in systemd behaviour. The only problem that was down to NM was the point at which it randomises MAC addresses when negotiating a wifi connection. The other problems were down to systemd / udev fucking with device names, not just at boot but in response to changes in network device status. Devices disappear for a few seconds instead of just changing status. Easy way to fix the randomisation problem is disable it, but it shouldn't be a huge issue to re-sequence NM code to randomise before it scans not after. The device names problems can be fixed with "net.ifnames=1 biosdevname=0" on your boot args which switches back to old style naming conventions for devices.
Recommended Posts