to be compliant with UPnP UDA 1.0, 1.1 and 2.0
fixes#698
UDA 1.0 1.2.3 Discovery: Search: Response (p21) :
CACHE-CONTROL
Required. Must have max-age directive that specifies number of seconds
the advertisement is valid. After this duration, control points should
assume the device (or service) is no longer available. Should be greater
than or equal to 1800 seconds (30 minutes), although exceptions are defined
in the text above. Specified by UPnP vendor. Integer.
UDA 1.1 1.3.3 Search response (p34) :
CACHE-CONTROL
REQUIRED. Field value MUST have the max-age directive (“max-age=”) followed
by an integer that specifies the number of seconds the advertisement
is valid. After this duration, control points SHOULD assume the device
(or service) is no longer available; as long as a control point has
received at least one advertisement that is still valid from a root
device, any of its embedded devices or any of its services, then the
control point can assume that all are available. The number of seconds
SHOULD be greater than or equal to 1800 seconds (30 minutes), although
exceptions are defined in the text above. Specified by UPnP vendor.
Other directives MUST NOT be sent and MUST be ignored when received.
UDA 2.0 1.3.3 Search response (p40) :
CACHE-CONTROL
Required. Field value shall have the max-age directive (“max-age=”) followed
by an integer that specifies the number of seconds the advertisement
is valid. After this duration, control points should assume the device
(or service) is no longer available; as long as a control point has
received at least one advertisement that is still valid from a root
device, any of its embedded devices or any of its services, then the
control point can assume that all are available. The number of seconds
should be greater than or equal to 1800 seconds (30 minutes), although
exceptions are defined in the text above. Specified by UPnP vendor.
Other directives shall not be sent and shall be ignored when received.
you now can setup :
listening_ip=igb1 bridge0 xxx0 xxx1 ...
miniupnpd will use igd1 address, but will not complain when receiving
packets from either igb1, bridge0, xxx0 or xxx1
fixes#379
see also #408
If several different interfaces share same ipv4 address on different
subnets (i.e. eth0 192.168.1.1/24 + eth1 192.168.1.1/16), miniupnpd
may pick any one of them, possibly wrong one w/o respecting exact
listening_ip interface.
syslog will contain something similar to:
miniupnpd: sendto(udp_notify=6, 192.168.1.1): No such device
miniupnpd: sendto(udp_notify=6, 192.168.1.1): No such device
miniupnpd: try_sendto(sock=6, len=464, dest=239.255.255.250:1900): sendto: No such device
miniupnpd: try_sendto(sock=6, len=464, dest=239.255.255.250:1900): sendto: No such device
miniupnpd: try_sendto failed to send 11 packets
Fix that with specifying exact outgoing mcast interface for each
notify socket with help of IP_MULTICAST_IF/mreqn struct.
Since OpenAndConfSSDPNotifySocket() now takes lan_addr_s struct,
OpenAndConfSSDPNotifySocketIPv6() was similary changed for api
consistency.
fixes#267
there were several errors in ProcessSSDPData()
in the parsing of ST: MX: and MAN: headers
so a few bytes could be read after the end of the buffer.
