Bug #13755
closed
Multiple incorrect configuration paths in recent UPnP code changes
Added by Marcos M almost 2 years ago.
Updated almost 2 years ago.
Plus Target Version:
23.01
Release Notes:
Force Exclusion
Description
The automatic rule pass multicast traffic to miniupnpd
is never created.
- Status changed from New to Pull Request Review
- Assignee changed from Marcos M to Jim Pingle
There is at least one other place using the same incorrect test for upnp being enabled, and I'd prefer a slightly different approach to fixing the rules than the one in the PR. I'll take care of these.
- Subject changed from Automatic rules for miniupnp are not created. to Multiple incorrect configuration paths in recent UPnP code changes
I spotted another incorrect configuration path usage in there as well as I was testing. Commit coming shortly.
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
- Status changed from Feedback to Resolved
All working well on current snapshots:
- No trace of UPnP anchors/rules in ruleset when UPnP is disabled
- Enabling UPnP starts the service and reloads the ruleset
- UPnP anchors/rules are present after enabling UPnP
- When disabling UPnP, the service is stopped and the rules are reloaded, removing all traces again
- At boot, the message saying UPnP is starting only prints when UPnP is enabled.
Also available in: Atom
PDF