File a jira with patch and I'll review it. Sent from my iPhone
On Jun 21, 2014, at 3:54 PM, "Bill Ross" <rossbcan@gmail.com> wrote:
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
<image001.png>
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org