2021-11-25 00:31:54 info kernel[]: [ 535.553115] device tun_turris entered promiscuous mode
2021-11-25 00:31:54 info kernel[]: [ 535.593096] device tun_turris left promiscuous mode
If I stop openvpn server, these messages stop. When I restart it, they start again. I used the reforis openvpn plugin to set it up. These messages were not there before the update.
Turris MOX - after reflash new TurrisOS 5.3.1 from medkit (clear installation)
reForis - every attempt to change WAN or LAN settings fails … an unknown API error occurred.
I tried to set it via first installation guide too and result is the same.
EDIT: This note is not related to testing branch, but unfortunately for the stable one.
Hi,
as after most of updates, i have problem with re-connection of the two Turrises again.
The Omnia which is openvpn server and sits in my flat seems to be ok in current particular case, I can connect to it from my windows PC at work and even from my android phone.
But the Mox, which is unfortunately 40 km away, didn’t reconnect and I have no information what went wrong.
Unfortunately there is only mobile network connection, so as the vpn is dead I’m unable to do anything about it, but get in the car and drive. I am also ill at the time, so it’s much more complicated (!@#$%^&*!!!).
I know you can’t do anything for me right now, but please, try to improve the update&restart process for the upcoming future.
Update from 5.2.7 did not go smoothly on IGG Omnia with NAS.
After 3 approvals, one unexpected restart and one expected, the device is now broken.
My /srv is gone. Well, shit.
On top of that Transmission webapp now asks for basic auth password, and does not load. I used to have 2 transmission apps there, now there’s only one - the broken one.
I’m fairly sure that the new kernel is the culprit. Before that everything worked just fine.
Edit: so here’s my setup: 1 HDD - that hosts samba and is mounted via fstab using UUID mounted to /mnt/sda, 1 SSD - that is a Foris storage drive (no Raid), mounted to /srv
After removing the UUID mount for the HDD from fstab, /srv is now up.
I am thinking that this does not have anything to do with our update process. It could be related to our HW specific issue for rebooting on Turris MOX device. May I know if unplugging and plugging back power cord helps? If yes, then you can reach our technical support department and they will provide you workaround, which could help with reboots, but unfortunately, it does not it solve completely or try to help you as much as they can. In the meantime, we are still working with SoC manufacturer, in this case Marvell, to investigate and try to fix it.
We are sorry for any inconvience caused by this. I understand that this could be quite annoying , but thanks for letting us know.
Would it be possible to open a web developer console in your browser and see if there is some stack trace from the backend? It could be helpful. I appreciate your cooperation.
This should be fixed in this update, but it seems it is not. Can you please reach our support department? They will gather more details, reproduce it once again, and pass it to the responsible developer to fix it.
Unfortunately, I can’t go there until Tuesday afternoon.
I will try to prepare for the firmware flash, but I hope pleadingly, that at the time at which I’ll go back home, it will be running and not bricked.
I have plan B also. There is PLC for home automation, i will try to connect the power supply via relay and program it to cycle the Mox, when the network is unavailable, but there is also a risk of creating endless reboot loop.
Any ideas what could have caused the tun_turris device entering and leaving promisc mode every second? I haven’t seen any relevant package updated in this update…
sentinel-dynfw-client[3326]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added
Nov 27 17:57:17 turris sentinel-dynfw-client[3326]: 2021-11-27 18:57:17,184 - WARNING - Error running ipset command: return code 1.
Nov 27 17:58:52 turris haas-proxy-start[7453]: 2021-11-27T18:58:52 CRITICAL twisted ‘channel open failed, direct-tcpip is not allowed’
With both errors/warnings, there is nothing wrong. It works. That’s important.
You can verify new sessions on HaaS and by running command: ipset list for DynFW
MOX A(SDIO), simple AP-configuration (disabled firewall, dnsmasq and odhcp). Update went without problems from 5.3 to 5.3.1, but reboot failed. I had one more time to un- and replug the powerplug.
When will this problem finally be solved by Turris team?
edit/remark: normal reboots work really smooth - but the critical ones have been and continue to be the ones from updates. Without this working automatical updates cannot be activated without update approvals…
I have had the same issue. The reboot after update failed in my Mox classic, similar to the updates before. I have applied the patch, v4. But it does not help for reboot after upgrade. The reboot otherwise works fine.
Does it affect all Moxes, or only a particular batch? Can one fix it by single part replacement? My Mox is not covered by warranty anymore, I bought it in Indiegogo campaign.
Sorry! I’ve just pushed the tags.
, but thanks for letting us know.
