FreeBSD, IPFW and the SIP/VoIP NAT problem
Hello, trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into several problems. My questions might have a "noobish" character, so my apology, my experiences with IPFW are not as thorough as they should be. Before I'll got into medias res, aquestion about Pine64/AARCH64: - port net/asterisk13 is supposed to build only on armv6, is aarch64 about coming soon also supported? - would a Pine64 running CURRENT (12) be sufficient as a PBX platform (assumed having 2 GB of RAM)? My main concern is about IPFW (we do not use PF for some reasons, I have to stay with IPFW). I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet IPv6. The FreeBSD system acting as a router is supposed to have a jail soon containing the Asterisk 13 IP PBX (at the moment running on the main system). To provide access to the VoIP infrastructure inside/behind the router/NAT system, the in-kernel NAT facility of FreeBSD is forwarding the relevant UPD/TCP ports for VoIP to its destination network, and here I have a problem to solve. While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, it is a mess and pain in the arse to forward a whole range, say 11000/udp - 35000/udp, which is a range one of my providers is sending RTP on. A second provider uses another range for RTP, starting at 5000/udp. So, the logical consequence would be a union set up UDP range to forward, which exapnds then form 5000/udp to 45000/udp - which is much more a pain ... One of the most disturbing and well known problems is that due to the stateful firewall the RTP session very often is half duplex - it seems one direction of the RTP connection doesn't make it through IPFW/NAT. As often I search the net, I always get informed this is a typical problem and solutions are provided by so called ALGs - since SIP protocol's SDP indicates within the payload of the packets on which UDP ports both ends wish to establish their RTP session, it would be "easy" to pinhole the IPFW on exactly those ports for a theoretical large number of sessions, if IPFW could "divert" those packets to an instance inspecting SDP (or whatever is used for the RTP port indication, I'm new to that, sorry for the terminology) and then pinholing the NAT/IPFW for exactly this purpose without the forwarding mess. I came along netgraph() while searching for hints and hooks, but it seems a complete Linux domain, when it somes to appliances like VoIP/IP PBX. Either, the problem is that trivial on FreeBSD, so no further mentioning is necessary (which would explain the vast emptyness of explanations, hints and so on) or FreeBSD is a complete wasteland on this subject - which I also suspect, since pfSense and OPNsense must have come along with such problems and I simply do not know or recognise the software used for those purposes. So, if someone enlightened in this matter stumbles over my question and could delegate me onto the right way (ports, ng_XXX netgraph ficilities to look at, some ipfw techniques relevant to the problem apart from the stupid simple forwarding large ranges of ports) - I'd appreciate this and thanks in advance for patience and help, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann wrote: > Hello, > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran > into > several problems. My questions might have a "noobish" character, so my > apology, > my experiences with IPFW are not as thorough as they should be. > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > coming soon also supported? > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > (assumed > having 2 GB of RAM)? > > My main concern is about IPFW (we do not use PF for some reasons, I have to > stay with IPFW). > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > IPv6. > The FreeBSD system acting as a router is supposed to have a jail soon > containing the Asterisk 13 IP PBX (at the moment running on the main > system). > To provide access to the VoIP infrastructure inside/behind the router/NAT > system, the in-kernel NAT facility of FreeBSD is forwarding the relevant > UPD/TCP ports for VoIP to its destination network, and here I have a > problem to > solve. > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, > it > is a mess and pain in the arse to forward a whole range, say 11000/udp - > 35000/udp, which is a range one of my providers is sending RTP on. A second > provider uses another range for RTP, starting at 5000/udp. So, the logical > consequence would be a union set up UDP range to forward, which exapnds > then > form 5000/udp to 45000/udp - which is much more a pain ... > > One of the most disturbing and well known problems is that due to the > stateful > firewall the RTP session very often is half duplex - it seems one direction > of the RTP connection doesn't make it through IPFW/NAT. As often I search > the > net, I always get informed this is a typical problem and solutions are > provided by so called ALGs - since SIP protocol's SDP indicates within the > payload of the packets on which UDP ports both ends wish to establish their > RTP session, it would be "easy" to pinhole the IPFW on exactly those ports > for > a theoretical large number of sessions, if IPFW could "divert" those > packets > to an instance inspecting SDP (or whatever is used for the RTP port > indication, I'm new to that, sorry for the terminology) and then pinholing > the > NAT/IPFW for exactly this purpose without the forwarding mess. I came along > netgraph() while searching for hints and hooks, but it seems a complete > Linux > domain, when it somes to appliances like VoIP/IP PBX. > > Either, the problem is that trivial on FreeBSD, so no further mentioning is > necessary (which would explain the vast emptyness of explanations, hints > and > so on) or FreeBSD is a complete wasteland on this subject - which I also > suspect, since pfSense and OPNsense must have come along with such problems > and I simply do not know or recognise the software used for those purposes. > > So, if someone enlightened in this matter stumbles over my question and > could > delegate me onto the right way (ports, ng_XXX netgraph ficilities to look > at, > some ipfw techniques relevant to the problem apart from the stupid simple > forwarding large ranges of ports) - I'd appreciate this and > > thanks in advance for patience and help, > > Oliver > Hi It might be easier if you just enable STUN on Asterisk, and build FreeBSD from source with my [largely neglected :( ] patch on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219918 That way Asterisk should dynamically discover consistent external mappings for connections, making port forwarding RTP unnecessary. Damjan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On 09/26/2017 10:35, O. Hartmann wrote: > Hello, > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into > several problems. My questions might have a "noobish" character, so my > apology, > my experiences with IPFW are not as thorough as they should be. > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > coming soon also supported? I'm maintaining the asterisk ports. At present I don't have any ARM64 hardware to test it on, but I plan to create an ARM64 jail in poudriere so I can try to make it at least build there. In such a case would you be willing to test port changes on the hardware to actually check it runs? > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform (assumed > having 2 GB of RAM)? That very much depends on the kind of load you are expecting. Asterisk can process a lot of calls. Especially if it can avoid being in the media path. On the other hand if you plan doing a lot of audio transcoding or some video transcoding, load can get up quite fast. Compressed codecs like the "simple" G729 will make your load grow relatively fast even with audio transcoding. Transcoding also lowers call quality so it should anyway be avoided as much as possible. Also load can go up if you're doing many disk operations. Monitoring and saving audio for a bunch of calls can be quite heavy on disk resources AND could require additional transcoding. > > My main concern is about IPFW (we do not use PF for some reasons, I have to > stay with IPFW). > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > IPv6. > The FreeBSD system acting as a router is supposed to have a jail soon > containing the Asterisk 13 IP PBX (at the moment running on the main system). > To provide access to the VoIP infrastructure inside/behind the router/NAT > system, the in-kernel NAT facility of FreeBSD is forwarding the relevant > UPD/TCP ports for VoIP to its destination network, and here I have a problem > to > solve. > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, it > is a mess and pain in the arse to forward a whole range, say 11000/udp - > 35000/udp, which is a range one of my providers is sending RTP on. A second > provider uses another range for RTP, starting at 5000/udp. So, the logical > consequence would be a union set up UDP range to forward, which exapnds then > form 5000/udp to 45000/udp - which is much more a pain ... The asterisk project has some suggestions on this here [1] RTP with NAT+FW is a pain. I'm not aware of any IPFW tools able to actively inspect SIP packets (which could also be encrypted if using SIPS, so there would be no clean way to inspect them). Depending on your phone providers you could use a stun and/or turn server by enabling the ICE protocol [2], which are all technologies supported by asterisk, but require support from your provider. Another option is symmetric RTP, which is a trick by creating symmetric port numbers connections which sometimes can trick firewalls properly configured. You setup also forces you to keep asterisk in the media path (direct_media=no in peer configuration) Unluckily none of these technologies is 100% bulletproof. RTP is not made to play well with NAT, so the professional solution is to spare an IP and redirect almost all ports to the SIP/RTP box. Also it's much better to do this with static rules, to avoid load problems on the FW (see later). You can sidestep the whole issue by running a proxy on your firewall machine, if you have control of it. There are a few in the ports tree. Take a look at: net/kamailio - It is really a SIP proxy, but can parse SIP/SDP packets and modify their content on the fly, allowing you to play neat tricks. Requires some knowledge of the protocol and work though. (maybe you can get him to punch holes in the firewall, but I have not checked if it's possible) net/rtpproxy: this is more specific and maybe your best bet. Beware of the load of proxying RTP in userland though. > > One of the most disturbing and well known problems is that due to the stateful > firewall the RTP session very often is half duplex - it seems one direction Depending on how many simultaneous SIP calls you plan to manage keep an eye on your firewall too. each call will create at least 3 states, one for SIP and one for each leg of the RTP stream, so it can pile up quite fast. > of the RTP connection doesn't make it through IPFW/NAT. As often I search the > net, I always get informed this is a typical problem and solutions are > provided by so called ALGs - since SIP protocol's SDP indicates within the This would require coding it in IPFW, and the load on the firewall could be significant. It could be done in userland maybe, leveraging divert(4) and having a daemon listening there and doing the extra work, but this would be quite expensive. D
FreeBSD, IPFW and the SIP/VoIP NAT problem
Hello, trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into several problems. My questions might have a "noobish" character, so my apology, my experiences with IPFW are not as thorough as they should be. Before I'll got into medias res, aquestion about Pine64/AARCH64: - port net/asterisk13 is supposed to build only on armv6, is aarch64 about coming soon also supported? - would a Pine64 running CURRENT (12) be sufficient as a PBX platform (assumed having 2 GB of RAM)? My main concern is about IPFW (we do not use PF for some reasons, I have to stay with IPFW). I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet IPv6. The FreeBSD system acting as a router is supposed to have a jail soon containing the Asterisk 13 IP PBX (at the moment running on the main system). To provide access to the VoIP infrastructure inside/behind the router/NAT system, the in-kernel NAT facility of FreeBSD is forwarding the relevant UPD/TCP ports for VoIP to its destination network, and here I have a problem to solve. While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, it is a mess and pain in the arse to forward a whole range, say 11000/udp - 35000/udp, which is a range one of my providers is sending RTP on. A second provider uses another range for RTP, starting at 5000/udp. So, the logical consequence would be a union set up UDP range to forward, which exapnds then form 5000/udp to 45000/udp - which is much more a pain ... One of the most disturbing and well known problems is that due to the stateful firewall the RTP session very often is half duplex - it seems one direction of the RTP connection doesn't make it through IPFW/NAT. As often I search the net, I always get informed this is a typical problem and solutions are provided by so called ALGs - since SIP protocol's SDP indicates within the payload of the packets on which UDP ports both ends wish to establish their RTP session, it would be "easy" to pinhole the IPFW on exactly those ports for a theoretical large number of sessions, if IPFW could "divert" those packets to an instance inspecting SDP (or whatever is used for the RTP port indication, I'm new to that, sorry for the terminology) and then pinholing the NAT/IPFW for exactly this purpose without the forwarding mess. I came along netgraph() while searching for hints and hooks, but it seems a complete Linux domain, when it somes to appliances like VoIP/IP PBX. Either, the problem is that trivial on FreeBSD, so no further mentioning is necessary (which would explain the vast emptyness of explanations, hints and so on) or FreeBSD is a complete wasteland on this subject - which I also suspect, since pfSense and OPNsense must have come along with such problems and I simply do not know or recognise the software used for those purposes. So, if someone enlightened in this matter stumbles over my question and could delegate me onto the right way (ports, ng_XXX netgraph ficilities to look at, some ipfw techniques relevant to the problem apart from the stupid simple forwarding large ranges of ports) - I'd appreciate this and thanks in advance for patience and help, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
net/asterisk13: memory leak under 12-CURRENT?
Befor starting a PR I'd liek to ask for some advice to document a supposedly existent memory leak in net/asterisk13 and 12-CURRENT. Background: Running recent 12-CURRENT (FreeBSD 12.0-CURRENT #58 r323999: Tue Sep 26 06:18:27 CEST 2017 amd64) on a PCengine APU 2C4, equipted with 4GB of RAM and 4080 KB free after the most recent SeaBIOS has been started, I try to utilise a net/asterisk13 as PBX on that platform. Asterisk13 has been build via poudriere and is compiled with CLANG/LLVM, not GCC! When FreeBSD (NanoBSD) has been started, depending on the recent revision of the OS/Kernel, top shows ~3680 - 3705 MBytes of free memory. Starting net/asterisk13 via "service asterisk onestart" indicates an overall usage of up to 100 MBytes of memory. After having now run the Asterisk 13.17.2 daemon for two days resulted in ~ 3100 MBytes of free memory, while the asterisk daemon was still running and doing nothing. But performing several restarts on a freshly started box gives the same result after ~ 10 restarts - and even after stopping asterisk and let the system run for a couple of days doesn't free the memory. I stopped after 15 restarts or so watching the loss of memory after each restart of asterisk, so i came to the conclusion that there must be a memory leak somewhere. now i try to provide more informations as needed for a PR. Can someone help? Thanks in advance, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: net/asterisk13: memory leak under 12-CURRENT?
On 09/26/2017 14:45, O. Hartmann wrote: Befor starting a PR I'd liek to ask for some advice to document a supposedly existent memory leak in net/asterisk13 and 12-CURRENT. Background: Running recent 12-CURRENT (FreeBSD 12.0-CURRENT #58 r323999: Tue Sep 26 06:18:27 CEST 2017 amd64) on a PCengine APU 2C4, equipted with 4GB of RAM and 4080 KB free after the most recent SeaBIOS has been started, I try to utilise a net/asterisk13 as PBX on that platform. Asterisk13 has been build via poudriere and is compiled with CLANG/LLVM, not GCC! I'm running asterisk on similar hardware and also building with clang, and have it going for months without any problems. I have disabled many modules in that build though. Problem could be caused by some ancillary library pulled in by some module. When FreeBSD (NanoBSD) has been started, depending on the recent revision of the OS/Kernel, top shows ~3680 - 3705 MBytes of free memory. Starting net/asterisk13 via "service asterisk onestart" indicates an overall usage of up to 100 MBytes of memory. After having now run the Asterisk 13.17.2 daemon for two days resulted in ~ 3100 MBytes of free memory, while the asterisk daemon was still running and doing nothing. But performing several restarts on a freshly started box gives the same result after ~ 10 restarts - and even after stopping asterisk and let the system run for a couple of days doesn't free the memory. I stopped after 15 restarts or so watching the loss of memory after each restart of asterisk, so i came to the conclusion that there must be a memory leak somewhere. now i try to provide more informations as needed for a PR. Can someone help? Not sure, restarting the daemon should free any leaked memory the daemon has. If a killed process leaves memory locked at the system level there should be some other cause. Have you tried diagnosing this memory with more tools? Depending on how deep you want to investigate ps, top and vmstat are simple to use and give you some indication. To go deeper you'll need to use more complicated tools. Others are better suited than me for suggesting those. DTrace could be a powerful but not easy to use instrument. Looking just at free memory (which under a UNIX OS can have various valid definitions, depending on how you account for inactive memory, buffers and laundry RAM) is definitely not enough. Have you seen asterisk process allocate more and more memory? You should check also what other processes in the system are doing. A computer software when running never really does "nothing"(except, maybe, when swapped out) and some memory usage can accumulate in many parts of the system. -- Guido Falsi ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, 26 Sep 2017 11:27:05 +0200 Guido Falsi wrote: > On 09/26/2017 10:35, O. Hartmann wrote: > > Hello, > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran > > into several problems. My questions might have a "noobish" character, so my > > apology, my experiences with IPFW are not as thorough as they should be. > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > > coming soon also supported? > > I'm maintaining the asterisk ports. At present I don't have any ARM64 > hardware to test it on, but I plan to create an ARM64 jail in poudriere > so I can try to make it at least build there. Hello Guido, I posted by accident the question again to this list as I introduced a typo when sending it also to the IPFW list. I'm sorry. I already tried to build net/asterisk13 on my AARCH64 jail, but since I'd like to have the databases/postgresql96-client aboard and this specific port fails to build, I gave up - it is, by the way, the only port (pgsql) as far as I know that fails in my poudriere cross compiling jail. I did not get further, but I saw that it is supposed to build only for amd64 and armv6. > > In such a case would you be willing to test port changes on the hardware > to actually check it runs? I'd like to if the efforts are not to much time consuming - I do not have a working Pine64 image anymore, but I have a Pine64 with 2GB RAM at hand. Months ago I started playing with cross compiling world/kernel for AARCH64, but I'm not familiar with crochet and preparing the SD image - but willing to do. But beware: my home box preparing the cross cimpilation is not the fastest! > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > (assumed having 2 GB of RAM)? > > That very much depends on the kind of load you are expecting. > > Asterisk can process a lot of calls. Especially if it can avoid being > in the media path. For the moment, the ARM based PBX should perform SoHo tasks - three, up to ten lines at maximum. > > On the other hand if you plan doing a lot of audio transcoding or some > video transcoding, load can get up quite fast. Compressed codecs like > the "simple" G729 will make your load grow relatively fast even with > audio transcoding. Transcoding also lowers call quality so it should > anyway be avoided as much as possible. Good to know. But the PBX is more like an experiment for "at home's PBX" and, if applicable, later for some fellows working scientifically in field and in need for some small and neat equipement. Video message/streaming is not so much the focus on the first attempts, but if possible, welcome. if not: not so tragic. > > Also load can go up if you're doing many disk operations. Monitoring and > saving audio for a bunch of calls can be quite heavy on disk resources > AND could require additional transcoding. There are Linux fellows running Asterisk 13 on raspberry Pi3 very successfully and this little box has only 1GB RAM as far as I know. Why should FreeBSD fail? > > > > > My main concern is about IPFW (we do not use PF for some reasons, I have to > > stay with IPFW). > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > > IPv6. The FreeBSD system acting as a router is supposed to have a jail soon > > containing the Asterisk 13 IP PBX (at the moment running on the main > > system). To provide access to the VoIP infrastructure inside/behind the > > router/NAT system, the in-kernel NAT facility of FreeBSD is forwarding the > > relevant UPD/TCP ports for VoIP to its destination network, and here I have > > a problem to solve. > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, > > it is a mess and pain in the arse to forward a whole range, say 11000/udp - > > 35000/udp, which is a range one of my providers is sending RTP on. A second > > provider uses another range for RTP, starting at 5000/udp. So, the logical > > consequence would be a union set up UDP range to forward, which exapnds then > > form 5000/udp to 45000/udp - which is much more a pain ... > > The asterisk project has some suggestions on this here [1] I know those references as I'm with the problem now for a couple of months ... > > RTP with NAT+FW is a pain. I'm not aware of any IPFW tools able to > actively inspect SIP packets (which could also be encrypted if using > SIPS, so there would be no clean way to inspect them). > > Depending on your phone providers you could use a stun and/or turn > server by enabling the ICE protocol [2], which are all technologies > supported by asterisk, but require support from your provider. Another > option is symmetric RTP, which is a trick by creating symmetric port > numbers connections which sometimes can trick firewalls properly configured. > > You setup also forces you to keep asterisk in the media path > (direct_media=
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann wrote: > On Tue, 26 Sep 2017 11:00:45 +0200 > Damjan Jovanovic wrote: > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann > > wrote: > > > > > Hello, > > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I > ran > > > into > > > several problems. My questions might have a "noobish" character, so my > > > apology, > > > my experiences with IPFW are not as thorough as they should be. > > > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 > about > > > coming soon also supported? > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > > (assumed > > > having 2 GB of RAM)? > > > > > > My main concern is about IPFW (we do not use PF for some reasons, I > have to > > > stay with IPFW). > > > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not > yet > > > IPv6. > > > The FreeBSD system acting as a router is supposed to have a jail soon > > > containing the Asterisk 13 IP PBX (at the moment running on the main > > > system). > > > To provide access to the VoIP infrastructure inside/behind the > router/NAT > > > system, the in-kernel NAT facility of FreeBSD is forwarding the > relevant > > > UPD/TCP ports for VoIP to its destination network, and here I have a > > > problem to > > > solve. > > > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other > ports, > > > it > > > is a mess and pain in the arse to forward a whole range, say 11000/udp > - > > > 35000/udp, which is a range one of my providers is sending RTP on. A > second > > > provider uses another range for RTP, starting at 5000/udp. So, the > logical > > > consequence would be a union set up UDP range to forward, which exapnds > > > then > > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > > > One of the most disturbing and well known problems is that due to the > > > stateful > > > firewall the RTP session very often is half duplex - it seems one > direction > > > of the RTP connection doesn't make it through IPFW/NAT. As often I > search > > > the > > > net, I always get informed this is a typical problem and solutions are > > > provided by so called ALGs - since SIP protocol's SDP indicates within > the > > > payload of the packets on which UDP ports both ends wish to establish > their > > > RTP session, it would be "easy" to pinhole the IPFW on exactly those > ports > > > for > > > a theoretical large number of sessions, if IPFW could "divert" those > > > packets > > > to an instance inspecting SDP (or whatever is used for the RTP port > > > indication, I'm new to that, sorry for the terminology) and then > pinholing > > > the > > > NAT/IPFW for exactly this purpose without the forwarding mess. I came > along > > > netgraph() while searching for hints and hooks, but it seems a complete > > > Linux > > > domain, when it somes to appliances like VoIP/IP PBX. > > > > > > Either, the problem is that trivial on FreeBSD, so no further > mentioning is > > > necessary (which would explain the vast emptyness of explanations, > hints > > > and > > > so on) or FreeBSD is a complete wasteland on this subject - which I > also > > > suspect, since pfSense and OPNsense must have come along with such > problems > > > and I simply do not know or recognise the software used for those > purposes. > > > > > > So, if someone enlightened in this matter stumbles over my question and > > > could > > > delegate me onto the right way (ports, ng_XXX netgraph ficilities to > look > > > at, > > > some ipfw techniques relevant to the problem apart from the stupid > simple > > > forwarding large ranges of ports) - I'd appreciate this and > > > > > > thanks in advance for patience and help, > > > > > > Oliver > > > > > > > > > Hi > > > > It might be easier if you just enable STUN on Asterisk, and build FreeBSD > > from source with my [largely neglected :( ] patch on > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219918 > > > > That way Asterisk should dynamically discover consistent external > mappings > > for connections, making port forwarding RTP unnecessary. > > > > Damjan > > STUN is enabled, but my providers do not support STUN. > > I try to figure out how SIP works exactly to make my problem more precise. > I > also try to understand the aim of your patch - as far as I know, it does > exactly as it is needed for the IPW/NAT/VoIP case. And I really regret that > there are objections to commit the patch ... > > Firstly, if your providers support NAT, you register to them (as opposed to they register to you, or no registration), and the only VoIP calls are to/from your providers and to/from the same IP:port you register to (as opposed to unknown external addresses), then none of this should be necessary. Just put these on every SIP peer in Asterisk (this is for chan_sip; not sure about chan_pjsip): directmed
Re: net/asterisk13: memory leak under 12-CURRENT?
On Tue, 26 Sep 2017 15:06:23 +0200 Guido Falsi wrote: > On 09/26/2017 14:45, O. Hartmann wrote: > > Befor starting a PR I'd liek to ask for some advice to document a supposedly > > existent memory leak in net/asterisk13 and 12-CURRENT. > > > > Background: > > > > Running recent 12-CURRENT (FreeBSD 12.0-CURRENT #58 r323999: Tue Sep 26 > > 06:18:27 CEST 2017 amd64) on a PCengine APU 2C4, equipted with 4GB of RAM > > and 4080 KB free after the most recent SeaBIOS has been started, I try to > > utilise a net/asterisk13 as PBX on that platform. Asterisk13 has been build > > via poudriere and is compiled with CLANG/LLVM, not GCC! > > > > I'm running asterisk on similar hardware and also building with clang, > and have it going for months without any problems. I have disabled many > modules in that build though. Problem could be caused by some ancillary > library pulled in by some module. Since I run net/asterisk with automatic module loading (I'm new to asterisk), this is very likely and might cause the problem somehow. > > > When FreeBSD (NanoBSD) has been started, depending on the recent revision > > of the OS/Kernel, top shows ~3680 - 3705 MBytes of free memory. Starting > > net/asterisk13 via "service asterisk onestart" indicates an overall usage > > of up to 100 MBytes of memory. After having now run the Asterisk 13.17.2 > > daemon for two days resulted in ~ 3100 MBytes of free memory, while the > > asterisk daemon was still running and doing nothing. But performing several > > restarts on a freshly started box gives the same result after ~ 10 restarts > > - and even after stopping asterisk and let the system run for a couple of > > days doesn't free the memory. I stopped after 15 restarts or so watching > > the loss of memory after each restart of asterisk, so i came to the > > conclusion that there must be a memory leak somewhere. now i try to provide > > more informations as needed for a PR. > > > > Can someone help? > > Not sure, restarting the daemon should free any leaked memory the daemon > has. If a killed process leaves memory locked at the system level there > should be some other cause. Even with no runnidng asterisk, memory level drops after the last shutdown of asterisk and keeps that low. Even for weeks! My router never shows that high memory consumption, even under load. > > Have you tried diagnosing this memory with more tools? top so far ... > > > Depending on how deep you want to investigate ps, top and vmstat are > simple to use and give you some indication. To go deeper you'll need to > use more complicated tools. Others are better suited than me for > suggesting those. DTrace could be a powerful but not easy to use instrument. Well, DTrace would be an overkill for me. I'd like to provide more informations in case any FreeBSD developer wants to look at this - in case there is a real bug in either FreeBSD CURRENT - or net/asterisk. > > Looking just at free memory (which under a UNIX OS can have various > valid definitions, depending on how you account for inactive memory, > buffers and laundry RAM) is definitely not enough. Have you seen > asterisk process allocate more and more memory? > > You should check also what other processes in the system are doing. A > computer software when running never really does "nothing"(except, > maybe, when swapped out) and some memory usage can accumulate in many > parts of the system. Well, since it is a well defined NanoBSD system which has run for weeks with the same memory consumptions ebven under load, it seems obvious that there must be a black hole for memory when it somes to loading/unloading asterisk. The memory drain can be reproduced. > The question would be: how to use vmstat to give hints for those familiar with memory subsystems to indicate a real bug? I tried to find some advices, but maybe my English isn't good enough to make google help. Kind regards, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, 26 Sep 2017 11:00:45 +0200 Damjan Jovanovic wrote: > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann > wrote: > > > Hello, > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran > > into > > several problems. My questions might have a "noobish" character, so my > > apology, > > my experiences with IPFW are not as thorough as they should be. > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > > coming soon also supported? > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > (assumed > > having 2 GB of RAM)? > > > > My main concern is about IPFW (we do not use PF for some reasons, I have to > > stay with IPFW). > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > > IPv6. > > The FreeBSD system acting as a router is supposed to have a jail soon > > containing the Asterisk 13 IP PBX (at the moment running on the main > > system). > > To provide access to the VoIP infrastructure inside/behind the router/NAT > > system, the in-kernel NAT facility of FreeBSD is forwarding the relevant > > UPD/TCP ports for VoIP to its destination network, and here I have a > > problem to > > solve. > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, > > it > > is a mess and pain in the arse to forward a whole range, say 11000/udp - > > 35000/udp, which is a range one of my providers is sending RTP on. A second > > provider uses another range for RTP, starting at 5000/udp. So, the logical > > consequence would be a union set up UDP range to forward, which exapnds > > then > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > One of the most disturbing and well known problems is that due to the > > stateful > > firewall the RTP session very often is half duplex - it seems one direction > > of the RTP connection doesn't make it through IPFW/NAT. As often I search > > the > > net, I always get informed this is a typical problem and solutions are > > provided by so called ALGs - since SIP protocol's SDP indicates within the > > payload of the packets on which UDP ports both ends wish to establish their > > RTP session, it would be "easy" to pinhole the IPFW on exactly those ports > > for > > a theoretical large number of sessions, if IPFW could "divert" those > > packets > > to an instance inspecting SDP (or whatever is used for the RTP port > > indication, I'm new to that, sorry for the terminology) and then pinholing > > the > > NAT/IPFW for exactly this purpose without the forwarding mess. I came along > > netgraph() while searching for hints and hooks, but it seems a complete > > Linux > > domain, when it somes to appliances like VoIP/IP PBX. > > > > Either, the problem is that trivial on FreeBSD, so no further mentioning is > > necessary (which would explain the vast emptyness of explanations, hints > > and > > so on) or FreeBSD is a complete wasteland on this subject - which I also > > suspect, since pfSense and OPNsense must have come along with such problems > > and I simply do not know or recognise the software used for those purposes. > > > > So, if someone enlightened in this matter stumbles over my question and > > could > > delegate me onto the right way (ports, ng_XXX netgraph ficilities to look > > at, > > some ipfw techniques relevant to the problem apart from the stupid simple > > forwarding large ranges of ports) - I'd appreciate this and > > > > thanks in advance for patience and help, > > > > Oliver > > > > > Hi > > It might be easier if you just enable STUN on Asterisk, and build FreeBSD > from source with my [largely neglected :( ] patch on > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219918 > > That way Asterisk should dynamically discover consistent external mappings > for connections, making port forwarding RTP unnecessary. > > Damjan STUN is enabled, but my providers do not support STUN. I try to figure out how SIP works exactly to make my problem more precise. I also try to understand the aim of your patch - as far as I know, it does exactly as it is needed for the IPW/NAT/VoIP case. And I really regret that there are objections to commit the patch ... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
