Opened 6 years ago

Closed 3 years ago

#10770 closed defect (moved_to_github)

listening_ip in miniupnpd.conf generated with mask instead of CIDR

Reported by: Paulo Matias <paulo.matias@…> Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: miniupnpd cidr netmask Cc:


Someone having a config like


wouldn't be able to use miniupnpd, as the miniupnpd.conf file is generated by the init script using network.lan.netmask directly instead of converting it to CIDR notation.

When running upnpc -l in a client machine on the LAN, the problem is evidenced by the following error message in the router logs:

Jan 11 01:20:24 OpenWrt daemon.err miniupnpd[2497]: Can't find in which sub network the client is

Further debugging shows that the network mask is being misinterpreted by miniupnpd. By reading miniupnpd.c, line 545 (parselanaddr), it's clear that miniupnpd currently only supports CIDR notation for this configuration entry.

The attached patch is a proposed solution that worked for me, although a clearer solution would be desirable.

Attachments (1)

miniupnpd-openwrt-r29704.diff (587 bytes) - added by Paulo Matias <paulo.matias@…> 6 years ago.
Draft patch for converting network mask to CIDR in the miniupnpd init script

Download all attachments as: .zip

Change History (6)

Changed 6 years ago by Paulo Matias <paulo.matias@…>

Draft patch for converting network mask to CIDR in the miniupnpd init script

comment:1 Changed 6 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

Should be fixed with r29722

comment:2 Changed 6 years ago by arokh <trondah@…>

  • Resolution fixed deleted
  • Status changed from closed to reopened

Still not resolved after r29722. listening_ip in /tmp/etc/miniupnpd.conf shows so that doesn't seem to be the issue?

comment:3 Changed 6 years ago by jow

There are also legitimate causes for this log message, for example if search requests from a client outside of occur. I you don't specify a listening address at all the code is never reached, if you specify listening_ip without prefix bits, /24 is assumed, so unless the parsing code in miniupnpd is wrong (which it doesn't appear to be) I don't see what should still be fixed.

Please make sure that your M-SEARCH request notice is indeed from a 192.168.1.x host.

comment:4 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:5 Changed 3 years ago by jogo

  • Resolution set to moved_to_github
  • Status changed from reopened to closed

Miniupnpd is now maintained here:

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.