[OpenWrt-Devel] RFC: Adding IPv6 support to uci_firewall
Hi folks,
in the context of my diploma thesis I'm currently working on an IPv6 gateway
based on OpenWrt. I wrote quite a lengthy synopsis but later found out that
my idea is already well summarized in RFC 4864 [1], chapter 4.2:
To implement simple security for IPv6 in, for example, a DSL or cable
modem-connected home network, the broadband gateway/router should be
equipped with stateful firewall capabilities. These should provide a
default configuration where incoming traffic is limited to return
traffic resulting from outgoing packets (sometimes known as
reflective session state). There should also be an easy interface
that allows users to create inbound 'pinholes' for specific purposes
such as online gaming.
That's it (plus some nifty features) because I don't buy (and got some counter
arguments to) the security-by-obscurity arguments behind the the three bullet
points previously in the same chapter :)
After fighting with and taming buildroot for some time, I hit my next
obstacle: Quite obviously uci_firewall is not IPv6 capable.
So I guess I've got to change that.
[2] suggests to discuss the ideas in advance so double work can be avoided. I
like that idea, so here's my proposal to add IPv6 support to uci_firewall:
* uci_firewall will automagically detect if IPv6 rules are needed, based on
the availability of ip6tables and kmod-ipv6. There will probably be some
corner cases, like when kmod-ipv6 is loaded after the firewall was already
set up, but these should be fixable.
* All rules which don't explicitly state a $src or $dst will be generated for
both. (The same is true for chains.) If one of those is given, the script
will look at the address format and generate the proper rules.
* This will be done by replacing $IPTABLES with an iptables() funtion which
does the magic (guess this will be easier once nftables [3] is around but
I've got to work with the stuff we have).
* Seems like the uci_firewall needs some general love, there seem to be some
non-local or even variables with undefined values hanging around.
* Maybe I'll additionally add an explicit src_ipv4 and src_ipv6 (and
dst_ipv{4,6} respectively) if that makes sense.
* I also thought about introducing host aliases which bundle the IPvX
addresses of a host and are then referenced in the rules (if you used
m0n0wall, you know what I mean). But that would be a later feature.
* Contrary to m0n0wall the host aliases should be accompanied by net aliases
so renumbering a net becomes trivial.
Any comments, ideas, flames? I'm also hanging around on #openwrt as moonflux.
Cheers,
Malte
[1]http://tools.ietf.org/rfc/rfc4864.txt
[2]https://dev.openwrt.org/wiki/SubmittingPatches
[3]http://marc.info/?l=linux-netdevm=123735060618579
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] aiccu: fix heatbeat typo in init script
Signed-off-by: Malte S. Stretz m...@apache.org
---
ipv6/aiccu/files/aiccu.init |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ipv6/aiccu/files/aiccu.init b/ipv6/aiccu/files/aiccu.init
index 40c3bc6..56de87d 100644
--- a/ipv6/aiccu/files/aiccu.init
+++ b/ipv6/aiccu/files/aiccu.init
@@ -25,7 +25,7 @@ start() {
config_get_bool requiretls $cfgs_section requiretls 0
config_get_bool defaultroute $cfgs_section defaultroute 1
config_get_bool nat $cfgs_section nat 1
- config_get_bool heartbeat $cfgs_section heatbeat 1
+ config_get_bool heartbeat $cfgs_section heartbeat 1
mkdir -p /tmp/run
echo username $username /tmp/run/aiccu-${cfgs_section}.conf
echo password $password /tmp/run/aiccu-${cfgs_section}.conf
--
1.5.4.3
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] aiccu: revamp the init script
This patch:
* Replaces the mess the config file generation was with a bunch of helper
routines.
* Makes absent boolean config options use the aiccu internal defaults like for
the strings. These options are commented out in the config per default.
* Ensures that the generated config file has mode 600. I know that OpenWrt is
normally not a multiuser system but we've got passwords in there, better safe
than sorry.
* Records for each (probably only one) running aiccu the state in /var/state
and stops the tunnels based on that. This avoids weird errors when you
change your config and then try to restart aiccu.
* Replaces config_cb with config_foreach which makes the file a lot better to
understand for non-pros like me.
* Adds a name to the section in the default config file so the files
in /var/run have a nicer name. Maybe the files should be named based on the
interface name instead but I didn't find a clean way to implement this.
Signed-off-by: Malte S. Stretz m...@apache.org
---
ipv6/aiccu/files/aiccu.conf | 10 ++--
ipv6/aiccu/files/aiccu.init | 93 +-
2 files changed, 60 insertions(+), 43 deletions(-)
diff --git a/ipv6/aiccu/files/aiccu.conf b/ipv6/aiccu/files/aiccu.conf
index 671fd16..b088992 100755
--- a/ipv6/aiccu/files/aiccu.conf
+++ b/ipv6/aiccu/files/aiccu.conf
@@ -1,11 +1,11 @@
-config aiccu
+config aiccu tunnel
option username ''
option password ''
option protocol ''
option server ''
option interface''
option tunnel_id''
- option requiretls ''
- option defaultroute '1'
- option nat '1'
- option heartbeat'1'
+# option requiretls 'true'
+# option defaultroute 'true'
+# option nat 'true'
+# option heartbeat'true'
diff --git a/ipv6/aiccu/files/aiccu.init b/ipv6/aiccu/files/aiccu.init
index 56de87d..6567bcd 100644
--- a/ipv6/aiccu/files/aiccu.init
+++ b/ipv6/aiccu/files/aiccu.init
@@ -1,52 +1,69 @@
#!/bin/sh /etc/rc.common
-# Copyright (C) 2006 OpenWrt.org
+# Copyright (C) 2006-2009 OpenWrt.org
START=50
-config_cb() {
- local cfg_type=$1
- local cfg_name=$2
+aiccu_set() {
+ local config=$1
+ local option=$2
+ local value=$3
+ echo $option $value /var/run/aiccu-${config}.conf
+}
+
+aiccu_set_string() {
+ local config=$1
+ local option=$2
+ local setting=$3
+ config_get dummy $config ${setting:-$option}
+ [ -n $dummy ] aiccu_set $config $option $dummy
+}
- case $cfg_type in
- aiccu)
- append cfgs_sections $cfg_name $N
- ;;
+aiccu_set_bool() {
+ local config=$1
+ local option=$2
+ local setting=$3
+ config_get_bool dummy $config ${setting:-$option} undef
+ case $dummy in
+ 0) aiccu_set $config $option false ;;
+ 1) aiccu_set $config $option true ;;
esac
}
start() {
config_load aiccu
- for cfgs_section in $cfgs_sections; do
- config_get username $cfgs_section username
- config_get password $cfgs_section password
- config_get server $cfgs_section server
- config_get protocol $cfgs_section protocol
- config_get interface $cfgs_section interface
- config_get tunnel_id $cfgs_section tunnel_id
- config_get_bool requiretls $cfgs_section requiretls 0
- config_get_bool defaultroute $cfgs_section defaultroute 1
- config_get_bool nat $cfgs_section nat 1
- config_get_bool heartbeat $cfgs_section heartbeat 1
- mkdir -p /tmp/run
- echo username $username /tmp/run/aiccu-${cfgs_section}.conf
- echo password $password /tmp/run/aiccu-${cfgs_section}.conf
- [ -n $server ] echo server $server
/tmp/run/aiccu-${cfgs_section}.conf
- [ -n $protocol ] echo protocol $protocol
/tmp/run/aiccu-${cfgs_section}.conf
- [ -n $interface ] echo ipv6_interface $interface
/tmp/run/aiccu-${cfgs_section}.conf
- [ -n $tunnel_id ] echo tunnel_id $tunnel_id
/tmp/run/aiccu-${cfgs_section}.conf
- [ $requiretls = 1 ] echo requiretls true
/tmp/run/aiccu-${cfgs_section}.conf
- [ $defaultroute != 1 ] echo defaultroute false
/tmp/run/aiccu-${cfgs_section}.conf
- [ $nat = 1 ] echo behindnat true
/tmp/run/aiccu-${cfgs_section}.conf
- [ $heartbeat != 1 ] echo makebeats false
/tmp/run/aiccu-${cfgs_section}.conf
- echo 'daemonize true' /tmp/run/aiccu-${cfgs_section}.conf
- echo pidfile /var/run/aiccu-${cfgs_section}.pid
/tmp/run/aiccu-${cfgs_section}.conf
-
- aiccu start /tmp/run/aiccu-$cfgs_section.conf
- done
Re: [OpenWrt-Devel] [PATCH] aiccu: revamp the init script
On Monday 08 June 2009 22:10:27 I wrote: This patch: ... is wordwrapped. Grmf, it did look good before I sent it out, seems like KMail wordwraps after closing the composer window :-/ Any comments, shall I send again? The patch is the base for other stuff I'm working on, coming soon. Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Homepage: Current Wiki redirection is useless
On Tuesday 09 June 2009 10:22:27 Matthias Buecher / Germany wrote: As it seems that the new Wiki won't be available soon, could someone please fix the redirection for the old Wiki. Instead of just replacing the domain, at least add .html add the end of the redirection and replace all slashes / with (2f). Then all the wiki links in the forum and from external pages would work and help the user to find information. If Apache either by mod_alias (AliasMatch, RedirectMatch): http://httpd.apache.org/docs/2.2/mod/mod_alias.html Or by mod_rewrite (see guides): http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html The server is nginx, the following (recursive) rules should work (but aren't tested, I just had a quick look at [1]): rewrite ^([^/]+)/(.*)$ $1(2f)$2 rewrite ^/(.*)$ http://oldwiki.openwrt.org/$1.html permanent Cheers, Malte [1]http://wiki.nginx.org/NginxHttpRewriteModule -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ping Re: RFC: LuCI Web Interface Image Format
Hi, On Wednesday 17 June 2009 03:38:01 Daniel Dickinson wrote: No one seems to have responded to this, and I'd like to start working on it next week. If developers could think about this and comment, it would be appreciated. I'm not a core OpenWrt developer but was thinking about implementing sysupgrade for the RouterBoard 411. That board has two mtd partitions, one for the kernel and one for the rootfs, so the default way of flashing it with sysupgrade doesn't work. I think most of what you wrote isn't needed, especially the logic on how to write the image. Because that stuff is already included in the platform specific part of sysupgrade and is already included in the old firmware. But if it is neded (like for a new platform), it could be included in my idea as well. The ideas I had for implementing it for the RB411 were quite simple: The firmware image can be a standard .tar.gz; nothing fancy, no own format. A tar would be enough but that one doesn't have a recognizable magic number. The tarball contains a folder named firmware with a bunch of files. Each file is an image which has the same name as the corresponding mtd partition. To introduce md5sums, each file could be accompanied by an optional .md5 file, ie. on the RB411 we'd have /firmware/kernel /firmware/kernel.md5 /firmware/rootfs /firmware/rootfs.md5 A broken tgz header will be recognized by these tools already. If we need any logic for flashing, we can also introduce a sysupgrade dir. Anything in there will go to /lib/upgrade before flashing. For even more flexibility, the root could contain an optional (executable) sysupgrade.sh which called instead of the system sysupgrade. Those were the ideas I had. Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFC: Adding IPv6 support to uci_firewall
Moin, On Monday 08 June 2009 14:22:32 I wrote: [stuff] If anybody's interested, my current work (including history) is available on GitHub [1]. Current state: * Works on 8.09.1, should work on trunk as well. * Moved some stuff around. Only refactoring, not a single firewall rule changed (until now). Except... * I introduced an iptables wrapper, see files/lib/iptables.sh and [2] to get an idea. * It applies all rules both to iptables and ip6tables, but only if the needed table is available. Ie. no NAT for IPv6 (if not installed), but broken rules if IP addresses are used in a rule. Next step: * Look at the IP addresses and apply the rules to the correct tables only. And again: Any comments, ideas, flames? I'm also hanging around on #openwrt as moonflux. Cheers, Malte [1]http://github.com/mss/sixwrt-packages/tree/firewall-hack/package/firewall [2]http://github.com/mss/sixwrt- packages/commit/4094d813a1562562761381e05f21d61d09b9dff6 -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ping Re: RFC: LuCI Web Interface Image Format
Hi JoW, On Wednesday 17 June 2009 16:14:37 Jo-Philipp Wich wrote: I like that .tar.gz idea, it would also cover devices like the Fonera where you have two separate images too. However, it's planned to introduce a unified image format for OpenWrt which would solve most of this issues so I haven't started working on it. Is this planned for some time or do you mean Daniel's proposal (which sounds like a new idea but I'm not subscribed to this list very long). There's no reason why the unified format couldn't be a tgz (or some other, maybe uncompressed, format which carries a magic number) with some meta informations :) Daniel's proposal sounded quite complicated to me. But imho it would be great to have such a capability for the stable 8.09 series since it can be added as package on top of the normal code. The question is whether config-keeping is doable in such a way, have you already tried this (with mtd's -j option) ? No, I haven't. The RB411 is just a testbed for my hacks so I don't care about recreating the config (and switched to 8.09 with backported packages anyway). Also, the wget2nand script from the ar71xx platform (which I used for reflashing) uses the default yffs formatted partition, so I don't think the mtd -j switch would work anyway (haven't tried it though). But if the rootfs is a jffs, I don't see while config-keeping shouldn't work (ok, so the tarball would need a symlink or something pointing to the rootfs). Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ping Re: RFC: LuCI Web Interface Image Format
Hi, On Wednesday 17 June 2009 22:01:24 Peter Korsgaard wrote: Malte A broken tgz header will be recognized by these tools already. Malte If we need any logic for flashing, we can also introduce a Malte sysupgrade dir. Anything in there will go to /lib/upgrade Malte before flashing. For even more flexibility, the root could Malte contain an optional (executable) sysupgrade.sh which called Malte instead of the system sysupgrade. Why not just use a standard format like the Debian .deb instead of inventing a custom format? [...] Alternatively you could use ipkg/opkg. Indeed, I think this is an even better idea. M -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
On Thursday 18 June 2009 16:22:54 Jo-Philipp Wich wrote: today I've written a proof-of-concept for getting rid of oldstyle networking aka 'ifconfig'. You do realize that this oldstyle networking stuff uses busybox internals while switching to ip will introduce yet another few kilobytes of bloat? busybox also has a builtin ip; I don't know if it has all the features needed but if it has, the images could get even smaller without the external ip and without the builtin ifconfig. Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New OpenWrt Community Wiki
On Thursday 18 June 2009 21:44:17 kloschi wrote: On Thu, 2009-06-18 at 21:34 +0200, Matthias Buecher / Germany wrote: doesn't work for me: #1 http://wiki.openwrt.org/DropbearPublicKeyAuthenticationHowto should result in http://oldwiki.openwrt.org/DropbearPublicKeyAuthenticationHowto.html so .html is missing ooops, please check with nuwiki.openwrt.org, because DNS is not switched yet and will take some time. http://nuwiki.openwrt.org/DropbearPublicKeyAuthenticationHowto works for me. The more complicated http://nuwiki.openwrt.org/OpenWrtDocs/Development/SetupBuildEnvironmentHowTo works as well. Nice. Didn't know the DokuWiki was case-insensitive. The pages should have a rel-canonical but I couldn't find a DokuWiki plugin to do this. You should replace the string redirect in the rewrite line with a permanent (ie code 301 instead of 302) though :) #2 slashes have to be converted to (2f) Can you confirm that with the nuwiki tld? That would only be needed on oldwiki, if the few links to the oldwiki should be kept alive. Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
On Friday 19 June 2009 09:31:59 Bastian Bittorf wrote: * Vasilis Tsiligiannis b_tsiligian...@silverton.gr [18.06.2009 21:15]: Try removing 'route' too (-ifconfig-route+ip). 'route' can be replaced by 'ip' also, if this function is implemented in busybox. -ifconfig -route -arp +ip arp is already a oneliner in /etc/profile and not compiled into busybox per default. busybox+ip-ipconfig-route: -rwxr-xr-x 1 mss mss 543796 2009-06-19 09:46 busybox -rwxr-xr-x 1 mss mss 632750 2009-06-19 09:46 busybox_unstripped That's only 12k more than busybox-ip+ipconfig+route. I still don't know if busybox' ip can do everything the real one can do. Somebody should test all packages depending on the ip package to see if they work with the busybox variant. I agree that ip is the nicer command, so the ipconfig/route wrapper could go into an own package on which unported packages have to depend and the default image could just have another oneliner in /etc/profile a la arp. Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] A revamped firewall with IPv6 support
Hi folks, last month I wrote to this list [1] with a suggestion on how to extend the current firewall package (aka uci_firewall) to support IPv6 rules. I got a bit side tracked in between but after a lot of trying around and refactoring I've got a working (and I think nice) solution. I dubbed it firewall2, ie. bumped the PKG_VERSION (the PKG_RELEASE is currently at 0b1, I call that beta1 :). I wrote [PATCH] in the subject but didn't really attach a patch but a tarball containing the files. You can also get and browser the files from my Git repository at Gitorious [2]. A real patch didn't make much sense because I moved the code around and refactored it a lot. The original code felt like spaghetti code (and had some small bugs obviously caused by that) so to truly grok what it does and glue in my iptables wrapper I started with some splitted the monolithic uci_firewall.sh into a bunch of separate files. Here's a diffstat anyway: package/firewall/Makefile | 10 +- package/firewall/files/20-firewall| 35 -- package/firewall/files/bin/fw | 47 +++ package/firewall/files/firewall.config| 28 +- package/firewall/files/firewall.hotplug | 18 + package/firewall/files/firewall.init | 18 +- package/firewall/files/lib/config.sh | 79 + package/firewall/files/lib/core.sh| 216 package/firewall/files/lib/core_forwarding.sh | 40 +++ package/firewall/files/lib/core_interface.sh | 70 package/firewall/files/lib/core_redirect.sh | 54 +++ package/firewall/files/lib/core_rule.sh | 56 +++ package/firewall/files/lib/core_zone.sh | 72 package/firewall/files/lib/fw.sh | 164 + package/firewall/files/lib/uci_firewall.sh|5 + package/firewall/files/uci_firewall.sh| 457 - 16 files changed, 855 insertions(+), 514 deletions(-) The files in lib are installed to /lib/firewall as they are. It would be trivial to merge/compile them into a single file to save space, but I checked and installed on JFFS, the split version takes up 20 kB while a merged version needs 18.5 kB. Not sure its worth it. So, let me try to summarize what I changed and the further plans I have: To start, I prefixed all functions with fw_, all global variables with FW_ and made sure that all variables are either localized or named in a way they won't clash with other globals, like stuff from /lib/network. Stuff like calling a variable interfaces and have stuff breaking at weird places really made my head hurt. Second, I didn't change any (IPv4) behaviour, just added things (like the IPv6 stuff). I tried to verify this by tracing the iptable calls and make sure they are the same in the same order. But typos are possible, so it would be great if somebody with a complex setup could verify this. From the user's perspective there is only one change: You can now specify both IPv4 and IPv6 addresses as src_ip and dest_ip in your firewall rules and everything works as expected, at least if ip6tables is installed (if not, the IPv6 rules are silently skipped). Even better, if you don't specify a src_ip or dest_ip, the rules are applied to both rulesets. This is based on my assumption that if you generally want to block access to a certain port, you probably don't want to have a gaping hole in your firewall just because you accidently enabled IPv6. So the new firewall should work exactly as before, just better :) Behind the scenes there's the obvious split into separate files. uci_firewall.sh is only a placeholder for backwards compatibility and to cope with opkg not removing old files when updating a package (or does it?). The rest can be categorized in three types of files: config.sh -- Here I introduced a function fw_config_get_section. I hoped to have something like this (ie. config_get_section) moved into /lib/config because it should be useful at other places/packages as well. I'll explain it in detail in a separate mail. core*.sh -- These bundle the firewall logic formerly found in the uci_firewall.sh. My plan is to make the firewall pluggable (more on this later), so the prefix core in /lib/firewall is reserved for the firewall itself. * core.sh contains more or less the public API and the init script is just a very thin wrapper around the start, stop, reload and restart functions found here. Also, here the defaults are loaded, includes are handled, general stuff like that. * The files core_rule.sh, core_forwarding.sh and core_redirect.sh represent these three types of firewall rules/sections in the config files. These are called in a config_foreach in core.sh. This is also true for core_zone.sh contains the setup of the helper tables and jumps for each zone definition. * Finally the stuff in core_interface.sh is called when interfaces come and go. That code was previously split between the hotplug file
Re: [OpenWrt-Devel] etherwake configuration, not working on eth0
On Sunday 19 July 2009 13:27:47 Matthias Buecher / Germany wrote: [...] I'm done creating the patches for etherwake and busybox's ether-wake to use br-lan as a default. But can somebody confirm that br-lan is also a working interface for other devices or Kamikaze 8.09 in general? Kamikaze sets up the lan interface as a bridge per default, so your patch should work. But it will probably break as soon as somebody changes the interface config. And even if eth0 is bridged, etherwake should work on the base device eth0 as well if I'm not mistaken. Anyway, if it doesn't work for you, I guess the best way to handle this is by doing something like this in the scripts which use etherwake: . /etc/functions.sh include /lib/network DEFAULT_IFACE=lan scan_interfaces config_get iface $DEFAULT_IFACE ifname etherwake -i $iface $@ The $DEFAULT_IFACE could be made configurable. Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] etherwake configuration, not working on eth0
On Sunday 19 July 2009 14:22:38 Matthias Buecher / Germany wrote: On 19.07.2009 13:52, Malte S. Stretz wrote: On Sunday 19 July 2009 13:27:47 Matthias Buecher / Germany wrote: [...] And even if eth0 is bridged, etherwake should work on the base device eth0 as well if I'm not mistaken. Anyway, if it doesn't work for you, I guess the best way to handle this is by doing something like this in the scripts which use etherwake: . /etc/functions.sh include /lib/network DEFAULT_IFACE=lan scan_interfaces config_get iface $DEFAULT_IFACE ifname etherwake -i $iface $@ The $DEFAULT_IFACE could be made configurable. For my private script I currently use the following code, which works great. As I'm the only user of the script, a simple env var is good enough. [...] Try the attached script :) Cheers, Malte -- uciwol Description: application/shellscript ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [legal] Compatibility of GPL with Apache
On Tuesday 21 July 2009 10:58:28 paolo del bene wrote: [quoted mail] Well, somebody should pay a lawyer to find out about GPL/ASL compatibility :) Short: OpenWrt is a distribution, the build environment is GPLv2 (unless otherwise stated), LuCI is a third party project like dnsmasq or the Linux kernel. At least the brcm-2.4 images use even at least one proprietary binary. No difference to any other Linux (or BSD or ...) distribution. Nevertheless I added a paragraph to [1] which might clear this up a bit. BTW, there is one gray area in OpenWrt: Any patches in the source tree should be delivered under the license the patched application is under. Maybe this needs some clarification somehow. Cheers, Malte [1]http://nuwiki.openwrt.org/doc/license -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] sdk: do not exclude share directory or bison and friends break
For some reason the share (ie. /usr/share) directory is not included in the SDK tarball, see bug 5629 [1] for details, a patch is attached to the bug [2]. Maybe somebody familiar with the SDK could also have a quick glance at bug 5417 [3]. Cheers, Malte [1]https://dev.openwrt.org/ticket/5629 [2]https://dev.openwrt.org/attachment/ticket/5629/sdk-include-share.patch [3]https://dev.openwrt.org/ticket/5417 -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: set default value for config_get via 4th parameter plus some more (#5636)
The command config_get_bool allows a fourth parameter which defines a default value. At many places it would be very useful if the plain three-parameter version of config get supported such a parameter as well, that saves a bunch of [ -z $foo ] checks in my scripts. In bug 5636 [0] you can find some patches: The first [1] introduces an optional fourth parameter to config_get. That patch could be backported to 8.09 branch. The next four patches [2,3,4,5] apply this four-parameter version in functions.sh, init.d/boot, init.d/led and init.d/fstab. Finally there's another patch [6] to /lib/network/config.sh which also includes some refactoring moving around some code and localizes a lot of variables which weren't so before. The changes don't spread over more than two hunks per refactoring. Cheers, Malte [0]https://dev.openwrt.org/ticket/5636 [1]https://dev.openwrt.org/attachment/ticket/5636/0001--package-base-files- allow-default-value-for-config.patch [2]https://dev.openwrt.org/attachment/ticket/5636/0002--package-base-files- port-functions.sh-to-new-confi.patch [3]https://dev.openwrt.org/attachment/ticket/5636/0003--package-base-files- port-init.d-boot-to-new-config.patch [4]https://dev.openwrt.org/attachment/ticket/5636/0004--package-base-files- port-init.d-led-to-new-config_.patch [5]https://dev.openwrt.org/attachment/ticket/5636/0005--package-base-files- clean-up-init.d-fstab-and-port.patch [6]https://dev.openwrt.org/attachment/ticket/5636/0006--package-base-files- some-lib-network-config.sh-re.patch -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: set default value for config_get via 4th parameter plus some more (#5636)
On Friday 07 August 2009 14:59:37 I wrote: On Friday 07 August 2009 04:12:00 Jo-Philipp Wich wrote: Applied in r17155-r17160. Yay, I didn't expect this one to be applied that quick :) I added a 7th patch to the ticket [7] which updates the tex docs accordingly. I attached another doc patch [8] plus a little tiny refactoring [9]. Cheers, Malte [7]https://dev.openwrt.org/attachment/ticket/5636/0007-docs-update- documentation-to-explain-the-four-param.patch [8]https://dev.openwrt.org/attachment/ticket/5636/0008-doc-some-talk-about- named-sections-and-stuff.patch [9]https://dev.openwrt.org/attachment/ticket/5636/0009--package-base-files- small-refactoring-to-use-alrea.patch -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] firewall/iptables
On Tuesday 20 October 2009 14:58:49 Ugur DOGRU wrote: This patch is for firewall/iptables. Most of it is to fix some hush script problems. [...] As most other init/hotplug scripts don't work with hush as well, I wonder why you went for the firewall only :) What you fixed are actually not problems in the scripts, but workarounds for hush-limitations and un-localizing variables is prone to breaking some stuff (I fixed one such issue earlier this year). The eval-code you used for assigning variables looks fishy as well but I never worked with hush so maybe PITAresque stuff like this is needed. Maybe you should just add the 50k and use ash instead? Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Disable IPv6 autoconfiguration
Moin, On Wednesday 28 April 2010 16:45:58 Jo-Philipp Wich wrote: Therefore I believe that the /etc/sysctl.conf file should have net.ipv6.conf.all.forwarding=1 set by default. A default firewall solution is needed before it can be made the default. Even if you or me do not need a firewall it is not acceptable to do this without in release images. Last year I posted [1] a rewrite of the firewall script to add IPv6 support and judging from the replies (zero) it didn't look like anybody was interested. The most recent version is also available here [2]. It is probably far from perfect but a start. I've been AFK for the last few months and didn't track the recent development so I guess some patches are needed to make it work with Backfire and to incorporate the latest changes. But it did work quite well back then. Cheers, Malte [1]http://article.gmane.org/gmane.comp.embedded.openwrt.devel/3634 [2]http://gitorious.org/sixwrt/packages/trees/master/package/firewall -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New firewall (was: [PATCH] Disable IPv6 autoconfiguration)
Hi, On Thursday 29 April 2010 11:31:06 Andrew Byrne wrote: So I gave it a try now and it works well for me, will do some more ipv6 testing in the next days. I also ported several fixes from the trunk version of the uci firewall, added some compat code and hotplug events. Thanks! I tried to keep the firewall as backwards compatible as possible, eg. I changed almost no chain names and tried not to modify the packet flow through the chains. Even though I really liked to do so because some of the (I guess historically grown) flow doesn't really make sense (and seemed to be buggy). I'd love to go for a v3 with a completely new chain design, just got to find my notes from last year :) But some breakage with custom scripts hacking the chains was unavoidable I guess so thats where people have to watch out. Attached are two patches, one against package/firewall from current trunk (for users who want to try it) and one against the latest rev from your git repository. Maybe you want to review it. Thanks, I'll do so when I've got a spare moment. If testing reveals no further issues, I'll replace the default firewall was your improved version. I have also created an IPv6 firewall package, based directly off firewall. It's called firewall6. I wasn't sure if it would be better to add IPv6 into the existing package, or have a completely separate package. For consideration. http://nativev6.googlecode.com/svn/packages/firewall6/ I first went the same way you did but then came to the conclusion that this code duplication has two disadvantages: (a) Code duplication, has to be kept in sync and (b) it might (IMO) confuse the user if a (especially DENY) rule he set up in the firewall config isn't applied for firewall6 ie. IPv6. Or not really confused but annoyed once uses the hole in the firewall. That's why I went for the design described in the first RFC [3] and the later patch mail [1] which applies rules to both protocols if no protocol is specified. Cheers, Malte [3]http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/3387 P.S.: I lied in my last mail, I indeed got bit of (positive) feedback on my very first mail and I'm thankful for that. -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New firewall (was: [PATCH] Disable IPv6 autoconfiguration)
Hi, On Saturday 01 May 2010 21:12:45 Jo-Philipp Wich wrote: I merged the new firewall + my modifications into trunk now. thanks. I guess I'll have to write up the documentation now :) And buy a new device to keep hacking on my project and fix the firewall when it breaks... Are you also looking for (co-)maintainers for core packages like the firewall? Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
