Development February 2017

development@lists.ipfire.org

11 participants
34 discussions

Re: Interests on Kernel 4.9 with nDPI and Docker
by Benjamin Schweikert 22 Feb '17

22 Feb '17

With Docker it is possible to extend the FW much more without having to build all the Addons you like to play around (e.g. nginx, pmacct, transmission, tvheadend, etc..) It makes thinks much easier. For that a fast filesystem is usefull which is provided in newer kernels (overlayfs). The currently used Kernel is close to its EOL. nDPI is an interessting approche to filter and finally to classify the kind of traffic. E.g. I had never success bit l7 rules for TeamSpeak. Michael, what are you concerns about these new topics? Do you want to focus in Version 3 mainly and don't want to advance Version 2? Ben

2 1

Interests on Kernel 4.9 with nDPI and Docker
by Benjamin Schweikert 22 Feb '17

22 Feb '17

Hi all, currently I am doing some test with Kernel Version 4.9.9 (thanks Arne for the work) and added the netfilter tables for nDPI and added the Docker daemon. I am at a very beginning of the testing but would ask if anybody out there is interested in these config/adaptions and want to join the testing? After the first successful test I plan to post it at the forum. Cheers, Ben

2 1

[PATCH] suricata: Update to 3.2.1
by Stefan Schantl 16 Feb '17

16 Feb '17

This is a major update to the latest stable version of suricata. Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- suricata/suricata.nm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/suricata/suricata.nm b/suricata/suricata.nm index 035f9df..f3fe7f4 100644 --- a/suricata/suricata.nm +++ b/suricata/suricata.nm @@ -4,7 +4,7 @@ ############################################################################### name = suricata -version = 3.1 +version = 3.2.1 release = 1 groups = Networking/IDS @@ -29,7 +29,7 @@ build libnet-devel libpcap-devel libyaml-devel - libhtp-devel >= 0.5.5 + libhtp-devel >= 0.5.20 pcre-devel pkg-config zlib-devel >= 1.2.5-2 -- 2.9.3

2 1

[PATCH] grep: Update to 3.0
by Stefan Schantl 16 Feb '17

16 Feb '17

This is a major update to the new grep 3.0 series. Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- grep/grep.nm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grep/grep.nm b/grep/grep.nm index fcb182d..ca5db45 100644 --- a/grep/grep.nm +++ b/grep/grep.nm @@ -4,7 +4,7 @@ ############################################################################### name = grep -version = 2.25 +version = 3.0 release = 1 groups = Applications/Text -- 2.9.3

1 0

[PATCH] libhtp: Update to 0.5.20
by Stefan Schantl 16 Feb '17

16 Feb '17

This is an update to the latest stable version of libhtp. * Adjust github URL to official ones. * Enable testsuite. Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- libhtp/libhtp.nm | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/libhtp/libhtp.nm b/libhtp/libhtp.nm index e6604ad..ce7e7f5 100644 --- a/libhtp/libhtp.nm +++ b/libhtp/libhtp.nm @@ -4,11 +4,11 @@ ############################################################################### name = libhtp -version = 0.5.10 +version = 0.5.20 release = 1 groups = System/Libraries -url = https://github.com/ironbee/libhtp +url = https://github.com/OISF/libhtp license = BSD summary = LibHTP is a security-aware parser. @@ -17,24 +17,30 @@ description related bits and pieces. end -thisapp = htp-%{version} - -source_dl = https://github.com/ironbee/%{name}/releases/download/%{version}/ -sources = %{thisapp}.tar.gz +source_dl = https://github.com/OISF/%{name}/archive/%{version}.tar.gz#/ build requires - gcc + autoconf + automake + libtool pkg-config zlib-devel end + export LD_LIBRARY_PATH = %{DIR_APP}/htp/.libs + configure_options += \ --disable-static -end - + prepare_cmds + ./autogen.sh + end + test + make check + end +end packages package %{name} -- 2.9.3

1 0

[PATCH] guile: Update to 2.0.14
by Stefan Schantl 16 Feb '17

16 Feb '17

This is a minor update to the latest stable release of guile. Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- guile/guile.nm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guile/guile.nm b/guile/guile.nm index 61e491f..0219cfb 100644 --- a/guile/guile.nm +++ b/guile/guile.nm @@ -4,7 +4,7 @@ ############################################################################### name = guile -version = 2.0.11 +version = 2.0.14 release = 1 groups = Development/Tools -- 2.9.3

1 0

[PATCH] wget: Update to 1.19.1
by Stefan Schantl 16 Feb '17

16 Feb '17

This is a minor update to the latest available version of wget. Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- wget/wget.nm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wget/wget.nm b/wget/wget.nm index 60309f5..4d6d722 100644 --- a/wget/wget.nm +++ b/wget/wget.nm @@ -4,7 +4,7 @@ ############################################################################### name = wget -version = 1.19 +version = 1.19.1 release = 1 groups = Applications/Internet -- 2.9.3

1 0

Re: On-Demand IPsec VPN
by Michael Tremer 15 Feb '17

15 Feb '17

On Wed, 2017-02-15 at 10:56 -0500, Tom Rymes wrote: > Michael, et. al., > > I don't know if my message will get through to the mailing list, but here's my > $0.02: It will if you subscribe to that list. > This all started with a request I made about setting the Strongswan "auto" > feature to "route" instead of "start" for site-to-site tunnels. This setting > change does as you describe, which is to leave a tunnel "triggered" when it is > created or StrongSwan is started, then it is automatically established when > traffic flows. > > This has benefits for resources and entropy, I suppose, but those are not of a > significant benefit in my view. If you do implement a "timeout" setting for > tunnels to disconnect if there is no traffic, I would personally want to > disable that feature, though I can see how some might want to use it. HOWEVER: > the auto=route setting is what is recommended by StrongSwan, in part for > security reasons (also handled by IPFire's default iptables rules). At the moment that is not configurable. I think this is essentially the biggest benefit of all of this that not all connections are active all the time. Do you set your connections to auto=route in all branches or just in HQ? > Our experience is that using the auto=route setting GREATLY improves the > robustness of the tunnels when it come to re-establishing them after something > goes wrong. If a tunnel drops due to a network issue and that issue is not > resolved before Strongswan times out connecting that tunnel, that tunnel stays > down until manually brought back up when auto=start. If auto=route, though, > that tunnel will be re-established more reliably in such a scenario. Changing > that setting has substantially improved our tunnel reliability. > > Thanks for your attention to this, I know all of your time is in short supply! > I will do my utmost to try and test the changes. -Michael > > Tom > > > > > On Feb 15, 2017, at 9:54 AM, Michael Tremer <michael.tremer(a)ipfire.org> > > wrote: > > > > Hello guys, > > > > sorry for my absence in the last few days and weeks. This list has been more > > or > > less read-only for me and I would like to chance this. I would like to see > > more > > people involved in this project and take part in what we do here. So it is > > important that everyone is in the know about what is going on. > > > > This morning I worked on a small feature which is probably quite > > interesting: > > On-demand IPsec VPN tunnels. > > > > What does it do? It essentially installs triggers in the kernel instead of > > bringing up the VPN tunnel right away. As soon as the kernel is receiving a > > packet that is supposed to be sent through that VPN, it will ask strongSwan > > to > > bring up the tunnel and send the packet. > > > > When the VPN tunnel has not transferred any packets for 15 minutes, it will > > terminate it and restart it when it is needed again. > > > > Why is this such a great feature? It is simple, but in scenarios with many > > VPN > > tunnels (e.g. headquarters and many branch offices) it does not always make > > sense to keep all tunnels up all of the time. This feature will shut down > > any > > tunnels that are not needed and keep resources free. > > > > This is probably not much, but we have seen machines with only few entropy > > and > > we have seen IPsec becoming unstable then. > > > > The web user interface shows the status if a tunnel is idle or connected. > > > > Patches are in next: > > > > http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=dcb406cc675c42f9add4 > > a41c8a1e07eea7c3ab08 > > http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=1ee1666ee45268db405a > > 66b8ec05501c718e7702 > > http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8057ab15b9efeecf8eca > > 7ad4ebba170f141bd3de > > > > It would be cool if you all could have a look at them, test them, maybe > > complete > > translations for any languages that you speak, etc. > > > > I am not sure if this will cause some problems with some applications that > > rely > > on fast establishing of connections. > > > > Looking forward to hearing your feedback! > > > > Best, > > -Michael

1 0

On-Demand IPsec VPN
by Michael Tremer 15 Feb '17

15 Feb '17

Hello guys, sorry for my absence in the last few days and weeks. This list has been more or less read-only for me and I would like to chance this. I would like to see more people involved in this project and take part in what we do here. So it is important that everyone is in the know about what is going on. This morning I worked on a small feature which is probably quite interesting: On-demand IPsec VPN tunnels. What does it do? It essentially installs triggers in the kernel instead of bringing up the VPN tunnel right away. As soon as the kernel is receiving a packet that is supposed to be sent through that VPN, it will ask strongSwan to bring up the tunnel and send the packet. When the VPN tunnel has not transferred any packets for 15 minutes, it will terminate it and restart it when it is needed again. Why is this such a great feature? It is simple, but in scenarios with many VPN tunnels (e.g. headquarters and many branch offices) it does not always make sense to keep all tunnels up all of the time. This feature will shut down any tunnels that are not needed and keep resources free. This is probably not much, but we have seen machines with only few entropy and we have seen IPsec becoming unstable then. The web user interface shows the status if a tunnel is idle or connected. Patches are in next: http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=dcb406cc675c42f9add4… http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=1ee1666ee45268db405a… http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8057ab15b9efeecf8eca… It would be cool if you all could have a look at them, test them, maybe complete translations for any languages that you speak, etc. I am not sure if this will cause some problems with some applications that rely on fast establishing of connections. Looking forward to hearing your feedback! Best, -Michael

1 0

[PATCH] wget: Update to 1.19.1
by Matthias Fischer 14 Feb '17

14 Feb '17

Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- lfs/wget | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/wget b/lfs/wget index baf4df069..8d3d13c27 100644 --- a/lfs/wget +++ b/lfs/wget @@ -24,7 +24,7 @@ include Config -VER = 1.19 +VER = 1.19.1 THISAPP = wget-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = 1814393c5955a6148ff6d82c4a9e3c21 +$(DL_FILE)_MD5 = d30d82186b93fcabb4116ff513bfa9bd install : $(TARGET) -- 2.11.0

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development February 2017