MiniDLNA creates new media server with every reboot (random server UUID on reboot)

I can see in my Fritzbox Lan Device List that during reboot
the
IPv4 Machine remains unchanged
but the
IPv6 Machine is regenerated each time.
How Can I disable this in openwrt ?
or How to Disable IPv6 completely ?

I narrowed it down to this line
[ 3.361328] mtk_soc_eth 1e100000.ethernet: generated random MAC address 32:33:a8:89:9d:4a

This happens only 3 sec after the boot began.

However I have no idea how to disable this function.
I even removed the wan6 interface which is supposed to be the ipv6 interface.

Maybe removing ipv6 packages would help, but seems a little bit difficult since I do not know which. I did remove necessary packages before which made the system not boot anymore.
Also I might need ipv6 some day, so just disabling it would be best.

The random MAC generation is neither a "function" (in the feature sense) nor is it related to IPv6.

It is an indication that the board support is incomplete (factory MAC location in flash is unknown) or that the flash partition containing that data is corrupted. Since you didn't mention the affected router model, it is hard to give further specifics.

@jow It says DIR-860L Rev B1 in his ubus dump.

3 Likes

Ah, sorry I missed that part.

Yes it is a DIR-860L Rev B1 which should be supported.
I was wondering about the fact that this random MAC generation happens so early in the boot. Maybe it is some sort of standard settings used before the real settings were loaded. I don't know.

What I do know it that my FritzBox shows this newly generated MAC Address in Relation with (only) an IPv6 IP Address which I did not enter. I try to avoid any IPv6 Setup. DHCPv6 is off, so I really don't know where this IPv6 IP comes from.

It also seems that this IPv6 IP vanishes later.
The FritzBox shows it when the openwrt starts. Later its gone.
Looks to me like a temporary thing which only lives shortly during the boot. Still it causes trouble because my TV and other DLNA Clients think thats a new DLNA Server and add it to the list which is soon full. The real DLNA Server is then kicked out of the list and no longer shown.

IPv6 hosts can autoconfigure themselves. There's also plenty of types of IPv6 addresses (like 192.168.1.x is private and not world routable in IPv4, e.g.). I wouldn't worry about it.

I haven't had any issues with my WAN MAC address and my Fritz!box (ISP supplied) consistently shows my RT-AC57U behind it and 'recognises' it; I presume that means it's not changing MACs every time it reboots or I flash it, otherwise the Fritz!box would not know which device it is.

1 Like

A Network Device should not bring a random MAC / IP into a LAN as long as that is not wanted by the User.
According to the log the root is mounted after 5sec, this random MAC thing happens after 3sec, so I think that makes it impossible to change this at all.

The FritzBox can handle that, although its internal memory is flooded with devices that will never apear again. So its just wasted memory.

My DLNA Clients can not handle it.
They do the same thing like the FritzBox so they see every reboot. And each time they add the "new server" to the list of servers. After 10 Servers its full, then any more reboot does not add the server anymore. Its then invisible.

I was wondering about the fact that this random MAC generation happens so early in the boot. Maybe it is some sort of standard settings used before the real settings were loaded. I don't know.

Yes it is. MAC address for some devices is randomly generated like that, and then it is corrected by OpenWrt system after root is mounted (and OpenWrt can read the true MAC from where it is stored). But this should not matter, as this swapping should happen BEFORE the OpenWrt system starts up network interfaces and advertises any service like DLNA on it.

I think your issue is not MAC. At least not directly. Random MAC for network does not matter much. It only needs to be unique.

No devices care about random IPv6 either, so let's leave that too.

I think your issue is that the DLNA server is changing either its serial or its UUID code on reboot. This would cause the "new server detected" issue you say.
Because serial and UUID are used to uniquely identify the server. If these codes change, devices will think this is a new server.

By looking at the documentation, http://manpages.ubuntu.com/manpages/cosmic/en/man5/minidlna.conf.5.html

 serial  Set the serial number reported to clients. Defaults to MAC address od network
         interface.
 uuid    Specify device's UPnP UUID minidlna should use. By default MAC address is used to
         build uniq UUID.

it seems MiniDLNA server can generate automatically serial and UUID on boot by looking at MAC address if they are not set in the config. It seems this is failing for some reason and you get random serial and/or UUID.

Serial is a setting you can write with uci and web interface, it should be default "123456" in the OpenWrt config, so I don't think this is the issue.
UUID is NOT a setting defined in OpenWrt configuration so it's empty and will be autogenerated.
I guess this is the issue here. To workaround this you need to hack the init script that reads the UCI config and generates the minidlna config to force a set UUID.

Please edit /etc/init.d/minidlna, locate the
minidlna_cfg_addstr "$cfg" root_container '.'
line and after it add a new line:
minidlna_cfg_addstr "$cfg" uuid '019f9a56-ff60-44c0-9edc-eae88d09fa05'
Save and close the file.

You can install nano to edit files through the ssh terminal. opgk install nano
then open the file with nano /etc/init.d/minidlna

The UUID code in the line above was randomly generated by me, it is not special, you can use a UUID you created if you prefer.
Now the UUID is written in a config and will NOT change after a reboot.

Then clean the DLNA server list in your TV and devices, and reboot the OpenWrt device.
The devices should see a new DLNA server now, (using that UUID), and if you reboot again you should not have any more "new" DLNA servers.

Please report back with any results of this workaround so I can try to contribute a fix.

5 Likes

Hello bobafetthotmail

That makes a lot of sense. All of it.
I know that this random mac thing was happening, but I could not explain how this would cause the dlna server listing. DLNA is not running at that time and later that random mac was gone. Also the server name appeared too, that is just impossible.

Therefore I'm really happy that I got your answer.

I will try what you suggested as soon as possible
and will let you know the result.

Thank you very much.
Nico

Hm, this other people seem to have the same issue in another custom firmware project (asuswrt-merlin).
I find a lot of dead media server devices (practically a new media server each time you rebooted router) that I have to delete manually.
https://www.snbforums.com/threads/solved-media-servers-uuid-universally-unique-identifier-fixed.37303/
The fix is the same as what I said above (set a static UUID in the config), it's just using different configuration file in a different place, that we don't care about for OpenWrt.

I understand.
But according to your link the "random UUID" which is now generated should be this
"By default MAC address is used to build uniq UUID."
This should be the same every time, or not ?

Is there any way to see the current UUID / Serial which is used now ?
If the UUID is the same every time I reboot it would not be a solution what you offered. (Of course I want to believe that it is a solution).

Nico

Theoretically, yes it should. Applications commonly read MAC address to get a "unique" and also "device-specific" code.

From the init script priority number in the source, network is initialized BEFORE minidlna, so any MAC read by minidlna should be the right one, not the randomly generated one.

But I don't know how minidlna is reading the MAC. Maybe it is using a way that does not work, so it can only randomly generate a UUID.

Seeing that this happens on very different devices running a different firmware makes me believe that the issue is in minidlna, and not in OpenWrt or your device.

I don't know to do this from OpenWrt.
From Windows it's shown in the linked forum thread. in the folder "Devices and Printers" of Windows, you should find many different media server devices and by right-click on the one currently connected you can see the UUID as in the screenshot.

There is a very strong indication that the UUID is changing every reboot.
If your TV or devices see a "new DLNA server" it means minidlna has changed UUID, that's the UUID purpose, I don't need to see the UUID changing.

That is why I said you should try to set a static UUID with the little hack above.

If you report that it's working, I'll contribute a default config with an UUID and the field to change it from Luci web interface (if needed, for example if you have more than one device with minidlna in your network they should have different UUIDs for obvious reasons). Which is a more "proper" way to do what I asked you to do.

I don't know how to fix the random UUID generation issue in minidlna application, or even if it can be fixed at all for OpenWrt devices.

Besides, there are devices in OpenWrt where the MAC address is indeed randomized on boot because they can't read where the true MAC is stored.
Having a static UUID in the config would be the best solution imho.

1 Like

OK I will try today and let you know as soon as possible.

You do know a lot, thats great.
Maybe you can help me with another problem later ?
But first we do this.

Thank you
Nico

I can try. I won't guarantee I can solve it though.

This works :slight_smile:
Thank you
Nico

3 Likes

Good, thanks for reporting back.

If you update the package, this little hack will be overwritten and you will need to do it again.

I'll contribute a proper fix as I said above, so the hack will not be needed in the future.

1 Like

15 posts were merged into an existing topic: USB-SSD not waking (spinning) up quick enough, causing read/write-errors

ok I sent the fix to OpenWrt, someone will review it eventually https://github.com/openwrt/packages/pull/10778

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.