I have had to re-install the OS on my Vero V and am now in process of re-building.
As I have reported earlier it is impossible to connect to an hidden SSID for the first connection so I have had to set up an AP with the SSID exposed to get the first connection. I can then hide the SSID but it still connects ok.
I now have a problem because the dhcp lease does not last and every time I use ssh I find my connection has a different address within my subnet. When I look at the lease table I see that every available lease has been filled with osmc, each with a lease time of 2 hours.
I can probably now set a static ip on the device but I would like to understand what is going on and why the lease is being released and a new dhcp address selected without any action from me. Is there a timing setting that I need to reconfigure?
I now have problem trying to set a static IP and am getting an unhandled exception error. How do I send you the log please?
Without having any logs or any idea what DHCP server your Vero-V is connecting to :
If you set a static IP address (associated with the MAC address of the Vero-V), each time the lease expires (after 2 hours) it should renew the lease for another 2 hours to the same IP address. How is the DHCP server configured ?
Many thanks for the reply but I need help sending the log.
The DHCP server is on a UTM which manages several subnets and I no not believe this is causing the problem. I usually connect the Vero devices with copper but while I am setting up the device I have it on my desk and use wifi connection. Setting a static IP in these circumstances is not very convenient. My static IPs are normally taken from outwith the pool of DHCP addresses.
My problem here is the very flaky behaviour I am getting on the Vero V. My other Vero devices, 4K and +4K are rock solid and seldom a problem. I just need reminding how to send the log assuming the wifi connection lasts long enough!
Surely the leasing is entirely determined by your DHCP server? If the problem is exactly as per the title, why not just extend the lease time on that server?
Here, all my veros are allocated an IP based on their MAC (different for both WiFi and ethernet) and IIRC leased for at least a day.
What exactly do you mean by ‘flaky’ behaviour, is it the reliability of the wi-fi connection ? or is it the DHCP behaviour ?
If its the wifi stability why dont you try a wired ethernet connection ?
We might be able to help you if we have debug enabled logs.
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
- enable debug logging at settings->system->logging
- reboot the OSMC device twice(!)
- reproduce the issue
- upload the log set (all configs and logs!) either using the
Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
- publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
OSMC skin screenshot:
Also, is this a Sophos UTM you are using ? i.e.
Hi Chris,
By flaky I mean unreliable. Now I cannot get any connection so I connected temporarily to copper. I have enabled logging, set my skill level as expert (forgive me!) and booted twice. To reproduce I have unplugged the copper connection and at present the wifi is working so I have uploaded the log to:-
https://paste.osmc.tv/juxudaluju
I hope this is working and many thanks for your patience here.
PS
Out of interest I checked the IP of my connection on the wifi with copper disconnected. When I uploaded the log the ip address was 192.168.168.171 and it is now 192.168.169.253. This is what I mean by flaky. After another re-boot it is now 192.168.169.219!
Thanks for the logs.
You can’t have the same IP address for both wifi and ethernet (copper) when assigning them statically, within the same leasing period, as these have different hardware MAC addresses.
Your DHCP server assigns a STATIC ip address based on a unique hardware MAC address. The Vero has two MAC addresses, one for the Ethernet port and the other for WIFI.
I am not entirely sure what you are trying to achieve here, perhaps you can explain.
Are you try to use the same IP address for wifi and ethernet (on the same subnet), IN THE SAME LEASE timeout ? If so, then you must let the leases expire, before you can reassign them to another MAC address.
PS
Out of interest I checked the IP of my connection on the wifi with copper disconnected. When I uploaded the log the ip address was 192.168.168.171 and it is now 192.168.169.253. This is what I mean by flaky. After another re-boot it is now 192.168.169.219!
The IP addresses are handed out by your DHCP server, I dont see that the Vero-V is flaky at all. Have you checked the criteria with which they are handed out in the DHCP configuration ?
Hi Chris,
Of course I cannot have the same address on wifi and copper and I understand there are two MAC addresses. That is why the dhcp pool of addresses is not the whole subnet. I usually set the wifi to use dhcp and the copper connection to use one of the reserved IPs not in the pool.
What I am trying to achieve is to have a working wifi connection. All the leases on the UTM are set for 24 hours (86,400 seconds) and I am certain the dhcp server is working correctly.
What appears to be happening is that the supplicant is initiating a connection but this is not maintained for more than a minute or so. To test, as I tried to explain, I unplugged the copper connection and have been checking the IP address given. Usually once a device is installed this address is persistent even if turned off because, when turned on again I the same address is given even after a week or so. In this case that is not the case so all the IP addresses I have posted have been used today and when I look now after receiving your reply I see that the Network IP address is shown as Busy and I have no connection.
You asked me what I am trying to do…
I am trying to get my new Vero V working in the same way as I have had my other Vero 4s working. I am about to re-install the OS for the third time but meanwhile what does the log tell you?
You can see from your logs that a succesful wifi connection was made (wlan0 to 192.168.169.171), however the persistence of that established connection is unclear, the logs do not show it being lost.
====================== ifconfig =================== pi3lDrO1
eth0: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC> mtu 1500
ether 94:cc:04:60:0e:09 txqueuelen 1000 (Ethernet)
RX packets 185 bytes 18865 (18.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 162 bytes 20493 (20.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 70 bytes 13891 (13.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 70 bytes 13891 (13.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 192.168.169.171 netmask 255.255.255.128 broadcast 192.168.169.255
ether 6e:4f:40:51:27:e2 txqueuelen 1000 (Ethernet)
RX packets 529 bytes 75209 (73.4 KiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 215 bytes 35102 (34.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
---------------------- ifconfig END --------------- pi3lDrO1
Some points to try:
-
Sometimes it helps to shorten DHCP leases to say 10 minutes for testing purposes.
-
Have you tried using the wireless connection on its own, without a parellel ethernet connection ?
-
If you have both the ethernet and wifi interfaces using the same gateway, you will run into problems with conflicting client ip addresses, one of these routes will need to be removed manually, this may be causing the connection to terminate.
i.e. https://www.reddit.com/r/raspberry_pi/comments/uez91e/use_wifi_and_ethernet_at_the_same_time_raspberry/#:~:text=There%20are%20some%20situations%20where,interfaces%20and%20the%20routing%20table.
-
See below
Hi Chris,
Many thanks. I usually disable the wifi connection when I am connected to the lan. For my testing to date I have had the copper connection disconnected as I have been using wifi. I can understand why the logs do not show the disconnection because this occurred after I had uploaded the log but be assured the device drops and reconnects until I get a segmentation fault and then no connection.
I am giving up on the wifi for now. I have done a fresh installation ab initio and am working with a copper connection as I need the device to be working and as it is replacing the 4K+ where it will have a copper connection anyhow. Once I know all is well and working I can revisit the wifi.
Many thanks for your time. Sorry we couldn’t identify the issue. Out of interest what program is being used for the wifi. It is strange that a new connection cannot be made to an hidden SSID even when it is known.
Thanks again,
Budgie
connmanctl is the latest way of configuring your network devices, part of ‘Connman’. This is in the current version of debian 11 used by OSMC.
Connmanctl can handle most network connections. It can be used to enable/disable any technology that exists on the system, display a list of services available, connect/disconnect networks, show properties of the system, the technologies, and any individual service, and configure all of the properties. It is also able to monitor changes in the properties of the services, technologies, and the system.
Hi Chris,
Many thanks. OK Connman has been the preferred app for embedded devices which is OK, but why can it not handle hidden ssids? I don’t have this problem on NM? Very strange.
Either its hidden or it isn’t.
If its hidden, then the profile its not accesible.
Seems OK to me … its easy to hide and unhide to access profile and connect.
Common sense really.
1 Like
I think that is the crucial point: For whatever reasons your wlan0 mac address is not fix but it should!
If you do a mac oui lookup of your wlan0 mac address 6e:4f:40:51:27:e2 you provided, you do not get a hardware vendor for it → it looks like a virtual/artificial/randomized mac!!!
If I do such lookup on my Vero5s I always get the same fix mac for the specific device and the MAC OUI lookup gives A0:67:20 China Dragon Technology Limited. So, your wlan0 mac should start with A0:67:20.
Btw.: The eth0 mac address seems to be a fix one on your Vero5 since you get vendor 94:CC:04:60:00:00/28 Sam Nazarko Trading Ltd.
So, the logical questions is: What did you do on the Vero5, so you now have a dynmaic assigned mac address for the wifi if?
The only unusual config I see is the subnet mask/CIDR 255.255.255.128/25 you use … no idea this has anything to do with it.
1 Like
Mar 29 14:06:34.714060 osmc systemd[1]: Starting Network Manager...
...
Mar 29 14:06:34.995447 osmc NetworkManager[2438]: <info> [1743257194.9952] NetworkManager (version 1.30.6) is starting... (for the first time)
Mar 29 14:06:34.995496 osmc NetworkManager[2438]: <info> [1743257194.9954] Read config: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf)
Mar 29 14:06:35.006358 osmc NetworkManager[2438]: <info> [1743257195.0062] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
...
Mar 29 14:06:35.007292 osmc systemd[1]: Started Network Manager.
Mar 29 14:06:35.010161 osmc systemd[1]: Starting Network Manager Wait Online...
So for whatever reason I see NetworkManager installed on your system but OSMC uses connman. Please, reinstall the device from scratch using a fresh Vero5 OSMC image and avoid such manipulations.
3 Likes
Hi Jim,
I have no idea how NM got onto my system. I have been starting with a fresh installation as I reported and I am not qualified to manipulate anything. I had been working with openvpn so perhaps that came from me inadvertently but surely a fresh installation from the USN installer would have erased anything, manipulated or otherwise but thanks for the heads up.
BTW is the version of OSMC closest to Nexus of Omega version of Kodi?
Don’t quite follow the question.
