I recently swapped my router for a Billion 7800VDOX, and noticed some attempted connections to my iMac from external addresses. On investigation I found that a uPnP port had been opened on the router with port range 0-0 (internal and external.) This has the effect, verified with an external port scanner, of opening ALL port numbers on the router and directing them to the iMac. I deleted the mapping and ran Wireshark and captured an external address request at the same time as the mapping was restored.

Frame 496: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
Ethernet II, Src: Apple_d0:7e:eb (d4:9a:20:d0:7e:eb), Dst: BillionE_cb:49:27 (00:04:ed:cb:49:27)
Internet Protocol Version 4, Src:, Dst:
User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5351 (5351)
Source Port: 5353
Destination Port: 5351
Length: 68
Checksum: 0x8527 [validation disabled]
[Stream index: 0]
Port Control Protocol, Map Request
Version: 2
0... .... = R: Request
.000 0001 = Opcode: Map (1)
Reserved: 0
Requested Lifetime: 7200
Client IP Address: ::ffff:
Map Request
    Mapping Nonce: f88237920f8cd6c0a3765f39
    Protocol: 6
    Reserved: 0
    Internal Port: 9
    Suggested External Port: 0
    Suggested External IP Address: ::ffff:xxx.181.81.112

This was preceded by a SOAP request to get the external IP address of the router. Checking the source port (5353) with lsof I found it owned by mDNSResponder.

My assumption as to what is happening is that mDNSResponder is using this just to get the external IP address of the router, and doing so using a supposedly harmless request to map port 0, which should be an invalid port. However the Billion router is treating this as, either by design or programming error, as a request to open all ports. Turning off uPnP on the router solves the problem (even though as pointed out this is not actually uPnP.)

Anyone have any other suggestions?

  • NAT-PMP is not uPnP, a request to learn the external IP address is not a request for a port mapping, and you haven't shown a captured packet of either a uPnP or NAT-PMP request for any port mapping, much less for port 0. It would be good to see packets showing the Mac doing what you seem to think it's doing. But you're probably on the right track that the Billion router is buggy.
    – Spiff
    Commented Jun 15, 2016 at 3:51
  • @Spiff Ok, I have edited the question. Turning off "uPnP" on the router makes the problem go away. Even though the router appears to be buggy, I'm still puzzled why mDNSResponder should be doing this.
    – Clyde
    Commented Jun 15, 2016 at 4:18

1 Answer 1


The packet you captured shows a Port Control Protocol (PCP: the IETF standards-track successor to NAT-PMP) port mapping request. The client port for the requested mapping is 9/TCP. The client doesn't have any suggestion for what the external port should be, so it leaves the suggested external port field set to zero. IETF RFC 6887, which defines PCP, makes clear that zero means "no suggestion" in this field.

I think whoever implemented PCP for this Billion router misread the RFC. You see, in some very limited and well-defined cases, a zero in the OTHER port field could mean "all ports". Like when the Requested Lifetime for this mapping request is zero, a zero client port would mean "delete all mappings for all ports on this client IP address".

But again, in the suggested external port field, zero is always supposed to mean "no suggestion". It is never supposed to mean "all ports" in this field.

So it seems pretty clear you've found a PCP bug in this Billion router.

One other weird thing here is the client port. Traditionally, 9/TCP is the discard service's port, but the discard service is deprecated, so I'm not sure who'd be running it any more, or why anything would be requesting a port mapping for it.

As for why mDNSResponder is sending these requests, it's simply because mDNSResponder acts as the PCP/NAT-PMP/UPnP daemon on macOS in addition to its usual mDNS, DNS-SD, and DNS resolver duties. When any process on macOS triggers the system to request a port mapping from the router, it's always mDNSResponder's job to create and send the actual port mapping request packets.

  • There is nothing listening on port 9 on my machine. I have turned on logging on mDNSResponder and will see if anything shows up. I did not know that it acted as a proxy for mapping requests.
    – Clyde
    Commented Jun 15, 2016 at 5:22
  • With debug logging on from mDNSResponder I see 15/06/2016 4:08:55.731 PM mDNSResponder[108]: LNT_MapPort 15/06/2016 4:08:55.731 PM mDNSResponder[108]: SendPortMapRequest: internal 0 external 0 and digging into the source code of mDNSResponder it seems this is part of the Bonjour support. Why the requested port is 0 is unclear.
    – Clyde
    Commented Jun 15, 2016 at 6:33
  • I think the bottom line is that there is a bug in the router, and what is probably a bug in mDNSResponder, and the two interact to produce the outcome I have seen. I note that at least one other person has seen this with the same router
    – Clyde
    Commented Jun 15, 2016 at 6:38
  • That log message makes it look like it may have sent 0 as the client port number that time. If you can capture a PCP or NAT-PMP packet from the Mac asking for a port mapping to client port 0 with a nonzero requesred lifetime, that would be very interesting to see. BTW, do you have any idea what embedded OS your Billion uses? Or what PCP implementation it uses?
    – Spiff
    Commented Jun 15, 2016 at 7:40
  • It claims to send 0 every time. I don't know why wireshark reports 9.
    – Clyde
    Commented Jun 15, 2016 at 9:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .