Development June 2013

development@lists.ipfire.org

8 participants
8 discussions

DynDNS support for ddns project.
by Stefan Schantl 16 Jun '14

16 Jun '14

Hello guys, i've created a patch for the Dynamic DNS client for IPFire. (http://git.ipfire.org/?p=oddments/ddns.git;a=summary) My patch will add support for the very popular "dyndns.org" provider. However I wasn't able to test my changes, because I don't have any account there and I seems new members have to purchase to use use it. So, I need your help to test my changes and finally be able to support that provider in the next major version of IPFire. Best regards, Stefan

2 3

Re: pyload
by Erik K. 24 Jul '13

24 Jul '13

> > Hi Stefan and Daniel, > @Stefan i think unrar is not available in Pakfire, but i compile it at this time. If the build process is finished, i upload it to my home directory. I will go then also for some tests. > > Feedback will come soon. > > Greetings > > > Erik > > Am 29.05.2013 um 21:53 schrieb Stefan Schantl: > >> Hello Daniel, >> >> thanks for testing the packages, are they also affected by the "/etc/init.d/" bug ? >> >> All mailing list followers, please join the team and test the pyload package and it's dependencies. >> >> The installation of the packages is pretty easy: >> >> * Install sqlite, pycurl and unrar by using pakfire. "pakfire install sqlite pycurl unrar" or do it over the WUI. >> >> * Download pyload and the dependecies from here: http://people.ipfire.org/~stevee/testing/ >> >> * Put them on your IPFire into the "/opt/pakfire/tmp" directory. >> >> * Unextract the downloaded files with tar - "tar -xvf file.ipfire" and install it with "./install.sh" >> >> * Be sure to install the pyload package at the end - pyload automatically will be started. >> >> The GUI, as Daniel already documented will be available at "http://<ip-of-your-ipfire>:8086", the default credentials are "pyload" with the password "secret". >> >> Please report any problems or errors, to get rid of them and to speed up the final merge into the main distribution. >> >> A big thanks, >> >> - Stefan >> >>> Yesterday I've tested the pyload packages from Stevee. >>> http://people.ipfire.org/~stevee/testing/ >>> >>> Installationorder: leptonica, tesseract-ocr, python-pyOpenSSL, >>> python-Jinja2, python-Beaker, python-thrift, python-simplejson, >>> python-pycrypto, python-pytesser, python-PIL, python-BeautifulSoup, >>> spidermonkey, sqlite, pycurl, unrar, pyload >>> >>> sqlite and pycurl you find in the pakfire. >>> >>> After I've installed everything the pyload webinterface was reachable on >>> ipfire:8086. >>> >>> username: pyload >>> password: secret >>> >>> At first pyload seems to work fine. Also automatic unrar and unzip of >>> compressed files work fine. >>> >>> The only thing is that every one minute there is the following entry in >>> the logfile. >>> >>> 149 28.05.2013 08:49:34 ERROR Error executing hooks: 'NoneType' object >>> has no attribute '__getitem__' >>> 150 28.05.2013 08:50:34 ERROR Error executing hooks: 'NoneType' object >>> has no attribute '__getitem__' >>> 151 28.05.2013 08:51:34 ERROR Error executing hooks: 'NoneType' object >>> has no attribute '__getitem__' >>> 152 28.05.2013 08:52:34 ERROR Error executing hooks: 'NoneType' object >>> has no attribute '__getitem__' >>> >>> Maybe someone could verify it. >>> >>> - Daniel >>> >>> _______________________________________________ >>> Development mailing list >>> Development(a)lists.ipfire.org >>> http://lists.ipfire.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development(a)lists.ipfire.org >> http://lists.ipfire.org/mailman/listinfo/development >

5 9

Strongswan 5 issues in IPFire 2.13
by Michael Tremer 14 Jul '13

14 Jul '13

Hey, when IPFire 2.13 was released, the latest version of strongswan was shipped with it. Apparently, some people have problems operating their VPN connections with it. This is a brief summary from my point of view: The first version with these changes that might cause trouble has been released in August 2012 with a big headline which said: Testers needed. * http://planet.ipfire.org/post/testers-needed-strongswan-5-0-0 * http://lists.ipfire.org/pipermail/development/2012-August/000039.html My mail on the mailing list states: > It should not require any manual interaction at all. Please install > and give me feedback about the connection stability and the > interoperability with other (proprietary) implementations. It's as if someone had known... If you think, we didn't have people who actually tested this, you are wrong. There were a lot of people and the reports I got of them were all like: "Yeah, this made my VPN tunnels more stable". Especially when the configuration of one connection has been edited, the other connections remained established all the time. A big advantage over the implementation in IPFire 2.11! Eight days before the final version of IPFire 2.13 was released, people started complaining. It was not a real bug report, but just a shout out "something went wrong, I could not be bothered, so I downgraded!". No technical details, no logs, no what-so-ever. Since the release, a bunch of more people complained about similar problems. Again, no one provided (or was willing to provide) information that helps to solve the problem. Nobody was even bothered to create a proper bug report in bugzilla. My VPN connections run for more than six months with strongswan 5 and I never had any problems since then. If someone really has interest in solving this, maybe it is time that you start the action and help the developers. This is not a project where you can tell people what they should do (for you). This is an Open Source project - so everyone is able to read the source code, check what changes have been made and to provide a fix. -Michael

4 5

connections.cgi: iptables connection tracking.
by Kay-Michael Köhler 05 Jul '13

05 Jul '13

Hello everyone i'm going to start development on connections.cgi to have some kind of sorting at "iptables connection tracking" (status->connections) I think it is a good idea to have the following (asc/desc) sort options: "Protocol" "Source IP:Port" "Destination IP Port" "Connection status" If you guys agree it would be a please for me to share and post the patch here when i'm done. Regards Kay-Michael

2 12

Core 69 working on Xen HVM
by R. W. Rodolico 12 Jun '13

12 Jun '13

I'm not sure where to report this to, but I have Core 69 running on a Xen HVM, using Debian Wheezy, Xen 4.1 and the xl toolstack. It is doing a site-to-site vpn, some road warriors, and runs dhcp and NAT. This was an upgrade from Core 68. Please let me know where reports should be made in the future as I have a couple of other routers to upgrade. Rod -- R. W. "Rod" Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 http://www.dailydata.net 214.827.2170

2 1

Core69 problems with the connect to blue acl
by Daniel Weismüller 10 Jun '13

10 Jun '13

Hi I've updated to testing core69 and added a new mac to the connect to blue acl on the webif. If I look at the webif everything seems to work correctly but the new mac could not connect to the internet. I checked iptables on the cli and I found the the new mac neither in the wirelessinput nor in the wirelessforward acl. May someone check it before I open a bug? - Daniel

2 2

Problem with boot.ipfire.org on Core 69 development build
by embp 09 Jun '13

09 Jun '13

Hi all, i want to report a problem with the Development Build: next/b3acd7b8-dirty of Core 69. I have tried the boot.ipfire.org section but the following error appears. IPXE initialising devices... OK IPFire boot server (boot.ipfire.org) IPXE 1.0.0+ --open source Network Boot firmware - http://ipxe.org Waiting for link -up on net to... failed Permission denied (http://ipxe.org/o227603x) Could not configure net0: permission denied (http://ipxe.org/o227603x) Reboot and Select proper boot device..... Greetings Erik

5 6

OpenVPN problems since Core 68
by Erik K. 02 Jun '13

02 Jun '13

Hi all, i want to report a problem with OpenVPN. The last significant changes where the update to Core 68, so i think this problem may have something to do with this changes but i´am not sure about the exact date. Since free dyndns expires i have tried to enter my IP address to the "global settings" but an Error occures which tell me something like error messages: Source port in use: 1197 so i have tested some other changes in the global section but the same error message appears. After enabling the debbugger in ovpnmain.cgi the httpd error_log gives me the following output. [Thu May 30 10:15:27 2013] [error] [client 192.168.75.2] [Thu May 30 10:15:27 2013] ovpnmain.cgi: Use of uninitialized value $cgiparams{"TYPE"} in string eq at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 962., referer: https://192.168.75.1:444/cgi-bin/ovpnmain.cgi [Thu May 30 10:15:27 2013] [error] [client 192.168.75.2] [Thu May 30 10:15:27 2013] ovpnmain.cgi: Use of uninitialized value $cgiparams{"TYPE"} in string eq at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 1052., referer: https://192.168.75.1:444/cgi-bin/ovpnmain.cgi [Thu May 30 10:15:27 2013] [error] [client 192.168.75.2] [Thu May 30 10:15:27 2013] ovpnmain.cgi: Use of uninitialized value $cgiparams{"TYPE"} in string eq at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 1141., referer: https://192.168.75.1:444/cgi-bin/ovpnmain.cgi [Thu May 30 10:15:27 2013] [error] [client 192.168.75.2] [Thu May 30 10:15:27 2013] ovpnmain.cgi: Use of uninitialized value $cgiparams{"KEY"} in string eq at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 1141., referer: https://192.168.75.1:444/cgi-bin/ovpnmain.cgi [Thu May 30 10:15:27 2013] [error] [client 192.168.75.2] [Thu May 30 10:15:27 2013] ovpnmain.cgi: Use of uninitialized value in concatenation (.) or string at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 4853., referer: https://192.168.75.1:444/cgi-bin/ovpnmain.cgi so my question does someone have equal problems since Core 68 ? Greetings Erik

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development June 2013