Hi Brian;

“doesn’t behave like you think”

OK, but, IMHO it should.

Dug into this a bit deeper:

caller code: src/switch_nat.c

static int init_upnp(void)

...

       const char *multicastif = 0;

        const char *minissdpdpath = switch_core_get_variable("local_ip_v4");

...

devlist = upnpDiscover(3000, (multicastif?multicastif:0) , minissdpdpath, 0);

callee code: libs/miniupnpc/miniupnpc.c

struct UPNPDev * upnpDiscover(int delay, const char * multicastif,

                              const char * minissdpdsock, int sameport)

...

    sockudp_r.sin_addr.s_addr = INADDR_ANY;

...

        if(multicastif)

        {

                struct in_addr mc_if;

                mc_if.s_addr = inet_addr(multicastif);

        sockudp_r.sin_addr.s_addr = mc_if.s_addr;

                if(setsockopt(sudp, IPPROTO_IP, IP_MULTICAST_IF, (const char *)&mc_if, sizeof(mc_if)) < 0)

                {

                        PRINT_SOCKET_ERROR("setsockopt");

                }

        }

The Problem ( The IP address INADDR_ANY usage):

When sending, a socket bound with INADDR_ANY binds to the default IP address, which is that of the lowest-numbered interface.

In my case, it is binding to eth1, NOT the lowest-numbered interface (eth0) because eth0 has no IP address, since it is bridged to br-lan.

Tried this:

devlist = upnpDiscover(3000, minissdpdpath  , minissdpdpath, 0);

meaning it will always transmit on "local_ip_v4". I recommend this as a global change, since we always want UPnP to use lan.

Results:

Nat Type: UPNP, ExtIP: 192.0.XXX.XXX

NAT port mapping enabled.

port,proto,proto_num,sticky

5060,udp,0,0

5060,tcp,1,0

5080,udp,0,0

5080,tcp,1,0

[INFO] switch_nat.c:434 NAT detected type: upnp, ExtIP: '192.0.XXX.XXX'

NAT PMP still not working and I see no requests on either interface. Will debug and advise if affects FS

Regards;

Bill Ross

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West
Sent: June-21-14 1:54 PM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] upnp sending M-SEARCH to wan, as opposed to lan ethernet interface

If FreeSWITCH is on that device and has access to the WAN i.e. public network and the LAN i.e. the private network then the concept of UPNP/NATPMP doesn’t behave like you think.  Its for when FreeSWITCH is BEHIND a router that has UPNP/NATPMP enabled so it can poke holes in the firewall in your case its not going to behave like that.  On Windows it would behave this way, but not on linux.

--

Brian West
brian@freeswitch.org



Twitter: @FreeSWITCH , @briankwest
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com

T: +1.918.420.9001  |  F: +1.918.420.9002  |  M: +1.918.424.WEST
iNUM: +883 5100 1420 9001
ISN: 410*543
Skype:briankwest
PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)

On Jun 21, 2014, at 12:14 PM, Bill Ross <rossbcan@gmail.com> wrote:

Hi Brian;

Yes, it is my router an integrated appliance which FS is part of.

Regards; Bill