Project

General

Profile

Feature #4321

Enable IPv6 for miniupnpd

Added by Daniel Becker almost 5 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Category:
uPNP
Target version:
Start date:
01/27/2015
Due date:
% Done:

100%

Estimated time:

Description

Miniupnpd supports IPv6; this can be enabled by adding the "IPV6" and "UPNP_IGDV2" make options to the port. See attached patch.

enable_ipv6.patch (444 Bytes) enable_ipv6.patch Daniel Becker, 01/27/2015 02:10 PM

Associated revisions

Revision 679c4ac7 (diff)
Added by Renato Botelho about 4 years ago

Enable IPV6 and UPNP_IGDV2 on net/miniupnpd, fixes #4321

Revision 512b8b22 (diff)
Added by Chris Buechler almost 4 years ago

Revert IPv6 and IGD2 change as it appears it's responsible for breaking many formerly-working upnp circumstances. Ticket #5730. Originally added as part of Ticket #4321

Revision 95246771 (diff)
Added by Chris Buechler almost 4 years ago

Re-enable IPV6 for miniupnpd, seems it's not responsible for any issues. Ticket #5730 and Ticket #4321

History

#1 Updated by Kill Bill over 4 years ago

Duplicate of #1835

#2 Updated by Renato Botelho about 4 years ago

  • Target version set to 2.3

#3 Updated by Renato Botelho about 4 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#4 Updated by Jim Thompson about 4 years ago

  • Assignee set to Chris Buechler

assigned to cmb for followup

#5 Updated by Jim Pingle about 4 years ago

The daemon appears to have IPv6 active now and it sees an IPv6 SSDP message but it doesn't like it for some reason. May be the setup I'm using (not static IP, track6 LAN), claims the sending system isn't in LAN

Nov 13 14:50:54     miniupnpd[70037]: write: Invalid argument
Nov 13 14:50:54     miniupnpd[70037]: SSDP packet sender [2001:db8:1:ee30:2dde:9d99:912d:3acb]:35998 not from a LAN, ignoring

Though that is in the same /64 as the LAN interface miniupnpd is set to listen upon so I'm not sure what it's complaining about. Needs more testing.

#6 Updated by Daniel Becker about 4 years ago

Could it be trying to prefix-match against the link-local address?

#7 Updated by Jim Pingle about 4 years ago

It's possible. I can't find a local client program that claims IPv6 UPnP support to test with aside from upnpc and it doesn't select the link-local when sending, and does not have a way to nudge it that I can see. I even tried backing off a client to have link-local only and then send SSDP but miniupnpd didn't show any sign it saw the packets.

May be the fault of the client here -- we need a lead on a proper piece of client software that will actually send IPv6 UPnP how the daemon expects to see it.

#8 Updated by Kill Bill about 4 years ago

#9 Updated by Daniel Becker about 4 years ago

Looks like a bug in miniupnpd to me: https://github.com/miniupnp/miniupnp/issues/160

#10 Updated by Chris Buechler about 4 years ago

  • Target version changed from 2.3 to Future

Similar with upnpc here.

miniupnpd[7253]: HTTP peer [2605:6000:abcd:8888:4d74:74b9:50b7:4f9f]:34904 is not from a LAN, closing the connection

Looked through a slew of torrent clients and other things, can't seem to find anything that actually sends v6 upnp, putting off since it's a miniupnpd issue (which from the looks of it will be fixed at some point) and we can't seem to find anything that actually uses it anyway.

Daniel: if it's something you'd like to pursue further, feel free to follow up here if upstream issue's resolved.

#11 Updated by Daniel Becker about 4 years ago

Fixes for this and a few other BSD-related issues have been accepted upstream. They're included in the most recent tarball on the miniupnp download page (miniupnpd-1.9.20151118.tar.gz), but I don't believe the FreeBSD port has been updated yet.

#12 Updated by Daniel Becker about 4 years ago

Filed PR 204694 to update the FreeBSD port.

#13 Updated by Chris Buechler about 4 years ago

  • Status changed from Feedback to Assigned
  • Assignee changed from Chris Buechler to Renato Botelho
  • Target version changed from Future to 2.3

Thanks Daniel. That looks straight forward enough, Renato should be able to get that committed easily.

#14 Updated by Renato Botelho about 4 years ago

  • Status changed from Assigned to Feedback
  • Assignee changed from Renato Botelho to Chris Buechler

I took FreeBSD PR, but need to wait for maintainer approval or timeout after 14 days.

Anyway, I've pushed the update to out FreeBSD-ports repo and rebuilt packages, new version is available on 2.3 snaps.

#15 Updated by Jim Pingle about 4 years ago

Behavior is slightly different with upnpc now, though it's still not working.

Server log is the same saying the client IP address is no on a LAN, client now shows that it found a UPnP device on the network but then says "No valid UPNP Internet Gateway Device found" after listing the server.

#16 Updated by Daniel Becker about 4 years ago

Strange, works fine here (albeit on 2.2.5):

$ upnpc -m lagg0 -S
upnpc : miniupnpc library test client, version 1.9.
 (c) 2005-2015 Thomas Bernard.
Go to http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://172.20.0.1:2189/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://172.20.0.1:2189/ctl/IPConn
Local LAN ip address : 172.20.3.3
FirewallEnabled: 1 & Inbound Pinhole Allowed: 1
GetFirewallStatus:
   Firewall Enabled: Yes
   Inbound Pinhole Allowed: Yes
Bytes:   Sent: 1765229673    Recv: 1856554871
Packets: Sent: 52641488    Recv: 103007220
$ upnpc -6 -m lagg0 -S
upnpc : miniupnpc library test client, version 1.9.
 (c) 2005-2015 Thomas Bernard.
Go to http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more information.
setsockopt(IP_MULTICAST_TTL,...): Invalid argument
List of UPNP devices found on the network :
 desc: http://[2601:646:x:x:x:x:x:x]:2189/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://[2601:646:x:x:x:x:x:x]:2189/ctl/IPConn
Local LAN ip address : 2601:646:x:x:x:x:x:x
FirewallEnabled: 1 & Inbound Pinhole Allowed: 1
GetFirewallStatus:
   Firewall Enabled: Yes
   Inbound Pinhole Allowed: Yes
Bytes:   Sent: 1766304397    Recv: 1863805814
Packets: Sent: 52649204    Recv: 103017871

#17 Updated by Daniel Becker about 4 years ago

Can you manually restart miniupnpd in foreground mode (-d)? That gives a bit more info beyond what's in the log.

#18 Updated by Chris Buechler almost 4 years ago

  • Status changed from Feedback to Resolved

option's enabled. Does show up as a valid IGD on IPv6 in upnpc. Haven't found any real applications that use IPv6 upnp

Also available in: Atom PDF