On 12/30/2017 8:09 AM, Thomas Goirand wrote:
On 12/30/2017 05:19 AM, Nye Liu wrote:
While I may agree with the above (I should check, as using the IP used
to work), how is this a Severity: serious? Please read the severity
definition:
serious is a severe violation of Debian policy (that is, the problem is
a violation of a 'must' or 'required' directive); may or may not affect
the usability of the package. Note that non-severe policy violations may
be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also
designate other bugs as 'serious' and thus release-critical; however,
end users should not do so.). For the canonical list of issues worthing
a serious severity you can refer to this webpage:
http://release.debian.org/testing/rc_policy.txt .
I don't see any violation of the Debian Policy here. Just maybe an issue
with the text explaining how to fill the field, especially considering
that you've found a workaround.
Well it should work correctly out of the box, IMO.
In addition, the defaults (and examples) in the packaged miniupnpd.conf
are not good (and should all be commented out), specifically:
# listening_ip=192.168.0.1/24 88.22.44.13
#listening_ip=192.168.0.1/24
listening_ip=192.168.10.109/24
the server prints an error regarding the (uncommented) 10.109 rule...
Also, the allow defaults should probably be changed to
allow 1024-65535 192.168.0.0/16 1024-65535
allow 1024-65535 10.0.0.0/8 1024-65535
deny 0-65535 0.0.0.0/0 0-65535
Or maybe even
allow 1024-65535 0.0.0.0/0 1024-65535
deny 0-65535 0.0.0.0/0 0-65535
or maybe just
deny 0-1023 0.0.0.0/0 0-1023
Or autogenerated?
In any case, it seems miniupnpd already throws away frames that aren't
from a local net...
