Hi guys, as I told here (http://www.udoo.org/forum/threads/solved-vnc-remote-control.6123/) I want you know about a strange dhcp behaviour in UDOO neo. How to reproduce: - Flash a Udoobuntu distro in your UDOO Neo; - Plug the client (Elementary OS in my case) to the UDOO Neo; - The client gets the usb IP; - Everything works, I can connect to the webPanel connecting to 192.168.7.2 - Reboot the client - The client doesn't reacquire the IP to connect to UDOO ElementaryOS - ifconfig Code: gorgo@dago:~$ ifconfig enp0s20u2 enp0s20u2 Link encap:Ethernet IndirizzoHW 4e:71:9d:14:b1:2f indirizzo inet6: fe80::658a:aef6:b029:a92a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:36 errors:0 dropped:0 overruns:0 frame:0 TX packets:586 errors:0 dropped:0 overruns:0 carrier:0 collisioni:0 txqueuelen:1000 Byte RX:6205 (6.2 KB) Byte TX:125411 (125.4 KB) ElementaryOS - journalctl -fln Code: nov 16 16:45:29 dago NetworkManager[870]: <info> [1479311129.5562] policy: auto-activating connection 'Connessione via cavo 1' nov 16 16:45:29 dago NetworkManager[870]: <info> [1479311129.5575] device (enp0s20u2): Activation: starting connection 'Connessione via cavo 1' (c9b84d27-36ac-3cb7-9f80-1b907ecd432c) nov 16 16:45:29 dago NetworkManager[870]: <info> [1479311129.5578] device (enp0s20u2): state change: disconnected -> prepare (reason 'none') [30 40 0] nov 16 16:45:29 dago NetworkManager[870]: <info> [1479311129.5586] device (enp0s20u2): state change: prepare -> config (reason 'none') [40 50 0] nov 16 16:45:29 dago NetworkManager[870]: <info> [1479311129.5592] device (enp0s20u2): state change: config -> ip-config (reason 'none') [50 70 0] nov 16 16:45:29 dago NetworkManager[870]: <info> [1479311129.5598] dhcp4 (enp0s20u2): activation: beginning transaction (timeout in 45 seconds) nov 16 16:45:29 dago NetworkManager[870]: <info> [1479311129.5668] dhcp4 (enp0s20u2): dhclient started with pid 32220 nov 16 16:45:29 dago dhclient[32220]: DHCPDISCOVER on enp0s20u2 to 255.255.255.255 port 67 interval 3 (xid=0xcd6f273f) nov 16 16:45:29 dago gnome-session[1606]: Failed to register: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying nov 16 16:45:31 dago avahi-daemon[806]: Joining mDNS multicast group on interface enp0s20u2.IPv6 with address fe80::658a:aef6:b029:a92a. nov 16 16:45:31 dago avahi-daemon[806]: New relevant interface enp0s20u2.IPv6 for mDNS. nov 16 16:45:31 dago avahi-daemon[806]: Registering new address record for fe80::658a:aef6:b029:a92a on enp0s20u2.*. nov 16 16:45:32 dago dhclient[32220]: DHCPDISCOVER on enp0s20u2 to 255.255.255.255 port 67 interval 7 (xid=0xcd6f273f) nov 16 16:45:33 dago gnome-session[1606]: [1:40:1116/164533:ERROR:ffmpeg_demuxer.cc(1595)] OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 nov 16 16:45:37 dago dhclient[31055]: No DHCPOFFERS received. nov 16 16:45:37 dago dhclient[31055]: No working leases in persistent database - sleeping. nov 16 16:45:39 dago dhclient[32220]: DHCPDISCOVER on enp0s20u2 to 255.255.255.255 port 67 interval 7 (xid=0xcd6f273f) nov 16 16:45:43 dago gnome-session[1606]: [1:40:1116/164543:ERROR:ffmpeg_demuxer.cc(1595)] OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 nov 16 16:45:46 dago dhclient[32220]: DHCPDISCOVER on enp0s20u2 to 255.255.255.255 port 67 interval 9 (xid=0xcd6f273f) nov 16 16:45:53 dago smartd[791]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 38 to 37 nov 16 16:45:54 dago gnome-session[1606]: [1:40:1116/164553:ERROR:ffmpeg_demuxer.cc(1595)] OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 nov 16 16:45:55 dago dhclient[32220]: DHCPDISCOVER on enp0s20u2 to 255.255.255.255 port 67 interval 9 (xid=0xcd6f273f) nov 16 16:46:04 dago gnome-session[1606]: [1:40:1116/164604:ERROR:ffmpeg_demuxer.cc(1595)] OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 nov 16 16:46:04 dago dhclient[32220]: DHCPDISCOVER on enp0s20u2 to 255.255.255.255 port 67 interval 9 (xid=0xcd6f273f) nov 16 16:46:08 dago gnome-session[1606]: (gnome-settings-daemon:1723): GLib-CRITICAL **: Source ID 21123 was not found when attempting to remove it nov 16 16:46:13 dago dhclient[32220]: DHCPDISCOVER on enp0s20u2 to 255.255.255.255 port 67 interval 15 (xid=0xcd6f273f) nov 16 16:46:14 dago gnome-session[1606]: [1:40:1116/164614:ERROR:ffmpeg_demuxer.cc(1595)] OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 nov 16 16:46:14 dago NetworkManager[870]: <warn> [1479311174.5213] dhcp4 (enp0s20u2): request timed out nov 16 16:46:14 dago NetworkManager[870]: <info> [1479311174.5214] dhcp4 (enp0s20u2): state changed unknown -> timeout nov 16 16:46:14 dago NetworkManager[870]: <info> [1479311174.5380] dhcp4 (enp0s20u2): canceled DHCP transaction, DHCP client pid 32220 nov 16 16:46:14 dago NetworkManager[870]: <info> [1479311174.5381] dhcp4 (enp0s20u2): state changed timeout -> done nov 16 16:46:14 dago NetworkManager[870]: <info> [1479311174.5387] device (enp0s20u2): state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5] nov 16 16:46:14 dago NetworkManager[870]: <warn> [1479311174.5391] device (enp0s20u2): Activation: failed for connection 'Connessione via cavo 1' nov 16 16:46:14 dago NetworkManager[870]: <info> [1479311174.5395] device (enp0s20u2): state change: failed -> disconnected (reason 'none') [120 30 0] nov 16 16:46:14 dago avahi-daemon[806]: Withdrawing address record for fe80::658a:aef6:b029:a92a on enp0s20u2. nov 16 16:46:14 dago avahi-daemon[806]: Leaving mDNS multicast group on interface enp0s20u2.IPv6 with address fe80::658a:aef6:b029:a92a. nov 16 16:46:14 dago avahi-daemon[806]: Interface enp0s20u2.IPv6 no longer relevant for mDNS. UDOO - ps -aux | grep dhcp Code: udooer@udooneo:~$ ps -aux | grep dhcp dhcpd 964 0.0 0.4 5844 4204 ? Ss 2015 0:00 dhcpd -user dhcpd -group dhcpd -f -q -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf UDOO - ifconfig usb0 Code: usb0 Link encap:Ethernet HWaddr 4e:71:9e:14:b1:2f inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252 inet6 addr: fe80::4c71:9eff:fe14:b12f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:630 errors:0 dropped:0 overruns:0 frame:0 TX packets:71 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:98135 (98.1 KB) TX bytes:16459 (16.4 KB) Possible workaround: - Extend subnet range in /ect/dhcp/dhcpd.conf to Code: subnet 192.168.7.0 netmask 255.255.255.0 { option routers 192.168.7.2; option subnet-mask 255.255.255.0; range 192.168.7.1 192.168.7.100; } and in /etc/network/interfaces, change the usb0 netmask to netmask 255.255.255.0 - Set static IP to the client I set 192.168.7.1, netmask 255.255.255.252 and gateway 193.168.7.0 in NetworkManager Question to devs: Is it correct this behaviour? Shouldn't the UDOO's DHCP renew the client's IP if it reboots? Do you have this problem too?
With other clients - like Ubuntu 16.04 - we don't get the same behaviour. The IP assigned is hold after reboot and is 192.168.7.1 Is anyone else registering this behaviour?
Ciao Andrea, We tested it with a MacOS+VM(Ubuntu 16.04) too. If we plug the UDOO, Ubuntu says that It's trying to connect but eventually fails. uname -a: Code: Linux ubuntu 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ifconfig: Code: ens33 Link encap:Ethernet HWaddr 00:0c:29:80:8c:58 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:186 errors:0 dropped:0 overruns:0 frame:0 TX packets:319 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:28951 (28.9 KB) TX bytes:36718 (36.7 KB) ens35u1 Link encap:Ethernet HWaddr 4e:71:9d:b9:52:4b inet6 addr: fe80::6be9:dc7f:1499:6b47/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28 errors:0 dropped:0 overruns:0 frame:0 TX packets:111 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4407 (4.4 KB) TX bytes:25162 (25.1 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:991 errors:0 dropped:0 overruns:0 frame:0 TX packets:991 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:74645 (74.6 KB) TX bytes:74645 (74.6 KB)
MacOS+VM(OpenSuse tumbleweed) uname -a Code: Linux linux-k01o 4.8.6-2-default #1 SMP PREEMPT Thu Nov 3 13:00:34 UTC 2016 (1d89b44) x86_64 x86_64 x86_64 GNU/Linux ifconfig Code: no167777 Link encap:Ethernet HWaddr 00:0C:29:1A:5D:08 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:31448 errors:0 dropped:0 overruns:0 frame:0 TX packets:18693 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:43239198 (41.2 Mb) TX bytes:1117257 (1.0 Mb) Interrupt:19 Base address:0x2000 ens35u2 Link encap:Ethernet HWaddr D6:72:1A:A8:1E:3B inet6 addr: fe80::2bae:d7c8:d76a:344/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:35 errors:0 dropped:0 overruns:0 frame:0 TX packets:71 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6111 (5.9 Kb) TX bytes:18079 (17.6 Kb) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2086 errors:0 dropped:0 overruns:0 frame:0 TX packets:2086 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:168716 (164.7 Kb) TX bytes:168716 (164.7 Kb) It tries and it says "Wired connection deactivated. IP configuration unavailable" eventually. ------------------------------------------------------------------------------------------------------------------- Note: UDOO Neo is only connected via USB to the laptop. UDOO uname -a Code: Linux udooneo 3.14.56-udooneo-02023-g8d371df #5 SMP PREEMPT Thu Jul 28 15:48:30 UTC 2016 armv7l armv7l armv7l GNU/Linux
I've had these problems with UDOObuntu 2.1 as well, particularly after installing the udoo-softap meta package as per http://www.udoo.org/docs-neo/Wireless_Communication/WiFi_SoftAP.html and then uninstalling it again. Solution was to rm /var/lib/dhcp/dhcp.leases. Background seems to be that there is exactly one lease to give by default, and after the occasional reboot, in my case it was still marked as being held by "hardware ethernet 4e:71:9d:aa:bb:cc;" rather than "hardware ethernet 4e:71:9d:8b:e3:fd;" and with a different UID than my client decided to register for. An alternative work-around would be to fix the address and delete the UID line. Not sure what a best practice would be, but i guess that single USB lease (and copies of it) should always be removed from the leases file upon boot, while leaving other leases untouched.
Yes, that was just a sure way for me to trigger the problem. It surfaced under other circumstances as well, but i didn't investigate at that time and just re-wrote the clean image to start over again. Anyhow, does deleting dhcp.leases work for you?
Up. Another very annoying problem Udoo has is that it "overwrites" the laptop route and it stops its connection. I'm not an expert of this dynamics, but I'll try to explain the problem and the annoying workaround: - Udoobuntu image on a sd into the Udoo FULL. - Plug the Udoo to a laptop with a usb cable - When the laptop gets the usb connection it looses the right route. Before udoo: Code: gorgo@dago:~$ ip r default via 192.168.1.254 dev wlo1 proto static metric 600 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-466d62c4cc01 proto kernel scope link src 172.18.0.1 linkdown 192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.110 metric 600 After: Code: default via 192.168.7.2 dev enp0s20u9 proto static metric 100 default via 192.168.1.254 dev wlo1 proto static metric 600 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-466d62c4cc01 proto kernel scope link src 172.18.0.1 linkdown 192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.110 metric 600 192.168.7.0/30 dev enp0s20u9 proto kernel scope link src 192.168.7.1 metric 100 And in order to restore wifi connection I have to: Code: gorgo@dago:~$ sudo ip r del default via 192.168.7.2 EVERYTIME. This doesn't happen with other boards I tried (that they use some dhcp procedure).
