Bug #13755
closed
Multiple incorrect configuration paths in recent UPnP code changes
100%
Description
The automatic rule pass multicast traffic to miniupnpd is never created.
Updated by Marcos M about 2 years ago
The miniupnp auto rule has been broken since the code was committed due to the invalid config path access, and due to the protocol being tcp instead of udp. The default allow rule already passes the traffic, hence simply remove the broken code.
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/979
Updated by Marcos M about 2 years ago
- Status changed from New to Pull Request Review
Updated by Jim Pingle about 2 years ago
- 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.
Updated by Jim Pingle about 2 years ago
- 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.
Updated by Jim Pingle about 2 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 374dd9fe6a456d09cb41515b913396ac0992467d.
Updated by Jim Pingle about 2 years ago
- 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.