miniupnpd: Does not send byebye before alive on startup (IGDv2 compliance)
Self-Hosting-Group opened this issue · comments
Upon startup, UPnP IGD DCP MUST broadcast an ssdp:byebye before sending the initial
ssdp:alive onto the local network. Sending an ssdp:byebye as part of the normal start up process
for a UPnP device ensures that UPnP control points with information about the previous device
https://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf#page=9
OK, that's a change between IGDv1 and IGDv2
@miniupnp Can this also be activated if UPNP_STRICT is not set?
@miniupnp Can this also be activated if UPNP_STRICT is not set?
Why ?
@miniupnp Can this also be activated if UPNP_STRICT is not set?
Why ?
To comply with the specification, the daemon is set with a random SOAP/HTTP port by default. If it is not shut down properly (e.g. disconnected from power), the clients still have the old port in the cache, which is no longer valid after the restart, the byebye then invalidates the description URL with the old port. The considerations in the specification make sense to me.
So you have not understood... In the case you are describing it is almost useless to broadcast byebye after the restart because the old port is not known (because of the restart).
That part of the specification makes little sense. All that kind of feature are enabled only when miniupnpd is built with UPNP_STRICT.
So you have not understood... In the case you are describing it is almost useless to broadcast byebye after the restart because the old port is not known (because of the restart).
Let me try to explain it with more details...
You are free to build miniupnpd with UPNP_STRICT enabled in order to enable all the features which makes it comply more closely with the standards.
but most are theses features are useless for most people.
When the daemon is started, it is advertised via SSDP multicast and its unique UUID and the corresponding root description URL in the location header with a random port (for the runtime of the daemon).
Clients now learn that there is an IGD device and all its services. If the router is now unexpectedly disconnected from the power supply, no byebye is sent via SSDP multicast which invalidates the advertising.
Now the daemon restarts and advertises with the same UUID with a new port, since the older advertisement is not declared invalid it is still valid and is in the client cache with the new one (with a different random port). However, the daemon only responds to the new port, no port mapping can be done under the old one, only after the max-age of the cache-control header has expired is the advertising invalidated and the client cache is valid again.
I hope this explanation helps to understand my request.
thank you for your explanation.
But you have not understood what I have just explained to you :
In you case, as the router is unexpectedly disconnected from the power supply, the old port is not known after the restart. So the router is enable to broadcast the byebye message about the old port.
Have you understood now ?
Also as there should be only one IGD on the network, the clients will very probably use the freshest one, so advertising the new one is sufficient in real life conditions.
@Self-Hosting-Group Let me be clear : I thank you for opening this issue and helping me improve the IGDv2 standard compliance.
But this feature is useless in real-life condition, which explains why nobody never bothered about it.
Have you understood now ?
In SSDP, the deavertising with byebye does NOT contain a location header (including the port), only the UUID, and invalidates all advertisements of that UUID.
But this feature is useless in real-life condition, which explains why nobody never bothered about it.
Yes, of course it was hard to notice that miniupnpd still has the far too small cache-control max-age by default to match the UDA 1.0 (and newer) recommended range of 1800s-1d of the spec for notifications. Currently, miniupnpd still has a default value of 60/120 (depending on whether miniupnpd.conf is used or not) instead of the minimum 1800 seconds. Miniupnpd is currently a real multicast spammer :-( which also consumes more power on mobile client devices. See details in PR #698
Other UPNP IGD also multicast advertisement every 2 or 3 minutes.
Have you understood now ?
In SSDP, the deavertising with byebye does NOT contain a location header (including the port), only the UUID, and invalidates all advertisements of that UUID.
either the "old" generated UUID are not known upon reboot
or the UUID is fixed and there is no need to broadcast byebye message as the new advertisement messages will use it and inform the control points of the new location and state of the rebooted IGD.
either the "old" generated UUID are not known upon reboot or the UUID is fixed and there is no need to broadcast byebye message as the new advertisement messages will use it and inform the control points of the new location and state of the rebooted IGD.
I do NOT interpret the standard to mean that advertisements with the old port are replaced by the new one with the same UUID, but that newly discovered ports (through the location header in notifications) are added/combined and can only expire or be deavertised with byebye.
In my opinion, this is the reason for the introduction of byebye.
Other UPNP IGD also multicast advertisement every 2 or 3 minutes.
Often implementations have copied/adopted many code/defaults from miniupnp because the project is already old and because the UDA/IGD standards in particular are not easy to read/interpret.
Other UPNP IGD also multicast advertisement every 2 or 3 minutes.
Often implementations have copied/adopted many code/defaults from miniupnp because the project is already old and because the UDA/IGD standards in particular are not easy to read/interpret.
that's kind to think that miniupnpd was the inspiration from most implementation, but miniupnpd mimicked already existing implementations using the intel UPNP SDK (now libupnp ?).
I think one of the first home router vendor which implemented UPNP IGD was linksys and they opensourced their firmware.