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
Re: [OpenWrt-Devel] New firewall (was: [PATCH] Disable IPv6 autoconfiguration)
On Thursday 29 April 2010 17:00:55 Jo-Philipp Wich wrote: > > But some breakage with custom scripts hacking the chains was unavoidable > > I guess so thats where people have to watch out. > > If someone relied on firewall internals (e.g. me :P) he has to expect > that it could break at some point - imho. As long as firewall.user and > uci format semantics are not changed, everything should be fine. Jepp, IIRC that didn't change at all. I hope :) > > Thanks, I'll do so when I've got a spare moment. > > Good, thank you. > > I have some questions, since you modularized the firewall now, would it > be possible to make it extensible through plugins? > > For example a package adds /lib/firewall/core_foobar.sh which then is > responsible for all "config foobar" sections in /etc/config/firewall. > > That would be a great way to support more complicated "firewall macros" > in the future. Hehe, of course. Thats one of the reasons I went with the more complicated implementation in the first place. See the hooks called by fw_callback all over the place. It is all explained here [1], but you might want to have a look at one of the modules I wrote as part of my diploma thesis [4]. Or have a look at my thesis itself [5] (German), chapter 5.5 and appendix E talk about the implementation in detail (if the firewall gets included, I will update the wiki accordingly). Cheers, Malte [1]http://article.gmane.org/gmane.comp.embedded.openwrt.devel/3634 [4]http://gitorious.org/sixwrt/luci/blobs/master/package/sixwrt/files/lib/firewall/sixwrt.sh [5]http://msquadrat.de/pub/thesis/ -- ___ 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] [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] [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] 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] base-files: set default value for config_get via 4th parameter plus some more (#5636)
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. Cheers, Malte [7]https://dev.openwrt.org/attachment/ticket/5636/0007-docs-update- documentation-to-explain-the-four-param.patch -- ___ 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
[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
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
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] 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
[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 fil
Re: [OpenWrt-Devel] RFC: Adding IPv6 support to uci_firewall
On Friday 19 June 2009 18:43:36 ZioPRoTo (Saverio Proto) wrote: >[...] > However, before using an IPv6 firewall I'd like to be able to assign > IPv6 addresses to my router ! > > But how do you assign IPv6 addresses at boot ? I use tunnels, no static addresses. > Can you reproduce this bug ? > https://dev.openwrt.org/ticket/5356 Yes. My guess: The IPv6 module isn't loaded yet when the interfaces go up. It seems like /etc/init.d/boot does coldplugging of the interfaces first and then loads the modules, maybe thats part of the issue. You could add some debug logger calls in /lib/network/config.sh to narrow down the problem. 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 12:52:26 Bastian Bittorf wrote: > * elektra [19.06.2009 12:15]: > > doesn't connect to other Asterisk servers if 'route' is missing. > > therefore i implement a route() wrapper. > ATM i start at /etc/functions.sh but e.g. > asterisk does not use it. maybe it is a good > idea to make a symlink for /sbin/route|ifconfig|arp > to to wrapper at boottime, to avoid such things? > > other ideas? Maybe its just me, but the last few weeks I tried to grok the OpenWrt base- files scrips (and succeeded [1]) and my impression is that there is already a lot of stuff crammed into /etc/functions.sh which is sourced by almost everything but only used by a handful of scripts. Why not create just scripts in /sbin? If you're concerned about too much forking, you could put the functions in /lib/network instead. But as all calls to ifconfig etc. in base-files scripts should be replaced by calls to ip, I don't think its worth having that stuff sourced everytime the network scripts are run. Cheers, Malte [1] And it seems like there aren't many people around who did so, judging by all the code duplication and weird call chains I found. -- ___ 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 [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
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 Thursday 18 June 2009 18:07:49 bud.d...@suisse.org wrote: > On 18.06.2009 18:00, Malte S. Stretz wrote: > > 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. > > what are the size differences? did you try it out? Now I did :) busybox+ifconfig-ip: -rwxr-xr-x 1 mss mss 531500 2009-06-18 18:57 busybox -rwxr-xr-x 1 mss mss 618905 2009-06-18 18:57 busybox_unstripped busybox-ifconfig+ip: -rwxr-xr-x 1 mss mss 551168 2009-06-18 19:17 busybox -rwxr-xr-x 1 mss mss 640684 2009-06-18 19:17 busybox_unstripped Yes, it seems like the ip applet is definitely bigger. BTW: I previously talked about an ip package which is installed per default; not true, I guess the 6tunnel script I have installed pulled it in. 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 Thursday 18 June 2009 18:20:06 Ferenc Wagner wrote: > "Malte S. Stretz" writes: > > 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. > > The ip applet is not enabled currently, and I don't know if it's > smaller than the ifconfig applet. I know that its not enabled per default and don't know either if it is smaller (but I'm currently compiling to see what the difference is). But even if it is the same size as ifconfig, the per default installed ip package (the binary has about 200k) would become obsolete. If busybox can do all the stuff it does that means. So maybe $((script + (busybox + ip_applet - ifconfig_applet))) < $((ip + (busybox - ip_applet + ifconfig_applet))... we'll see. 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 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
Hi, On Wednesday 17 June 2009 20:06:29 Gregers Petersen wrote: > After long and hard gestation the new OpenWrt community wiki is now > ready and open for action :-) Thanks for the work on the shiny new wiki :) > The OpenWrt developer team is looking for a few individuals who would be > willing to help with moderation of the new wiki content and structure. > Individuals interested in this should contact me ;-) For now, just my old bugging to keep the old links working. My suggestion: Put the attached PHP script on oldwiki.openwrt.org and add a config line like rewrite ^/([A-Z].*)$ /oldwiki.php$1 Then add something along the lines of rewrite ^/([A-Z].*)$ http://oldwiki.openwrt.org$1 permanent into the config of nuwiki.openwrt.org. Then maybe rename nuwiki.openwrt.org to wiki.openwrt.org, just don't forget to update the $SERVER var in the PHP script :) This *should* work (the script I tested, the rewrites not). Of course instead of mod_rewrite you could also use mod_fastcgi. 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] 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] 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, 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] 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] [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
[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
---
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" ] &am
[OpenWrt-Devel] [PATCH] aiccu: fix heatbeat typo in init script
Signed-off-by: Malte S. Stretz
---
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] [package] dnsmasq: make sure dnsmasq has polled the resolv.conf generated by udhcpc (#5301)
When udhcpc (and maybe other tools) configures the wan interface, it updates update /tmp/resolv.conf.auto and dnsmasq has to read the new nameservers from there. Unfortunately dnsmasq uses polling so it can take up to a second until it refreshes; if any iface hotplug scripts (like ntpclient) need a working resolver on localhost, they will fail if hotplug is quicker than the dnsmasq poll interval. This patch simply introduces a one second delay before any 20+ hotplug scripts are started. Signed-off-by: Malte S. Stretz --- This patch (with less description) is also attached to ticket #5301, as recommended by Hamish Guthrie last week I hereby send it to the list as well. package/dnsmasq/Makefile |2 ++ package/dnsmasq/files/dnsmasq.hotplug |3 +++ 2 files changed, 5 insertions(+), 0 deletions(-) create mode 100644 package/dnsmasq/files/dnsmasq.hotplug diff --git a/package/dnsmasq/Makefile b/package/dnsmasq/Makefile index 1b030d1..77dd1df 100644 --- a/package/dnsmasq/Makefile +++ b/package/dnsmasq/Makefile @@ -48,6 +48,8 @@ define Package/dnsmasq/install $(INSTALL_DATA) ./files/dhcp.conf $(1)/etc/config/dhcp $(INSTALL_DIR) $(1)/etc/init.d $(INSTALL_BIN) ./files/dnsmasq.init $(1)/etc/init.d/dnsmasq + $(INSTALL_DIR) $(1)/etc/hotplug.d/iface + $(INSTALL_DATA) ./files/dnsmasq.hotplug $(1)/etc/hotplug.d/iface/15-dnsmasq endef $(eval $(call BuildPackage,dnsmasq)) diff --git a/package/dnsmasq/files/dnsmasq.hotplug b/package/dnsmasq/files/dnsmasq.hotplug new file mode 100644 index 000..96ed7a5 --- /dev/null +++ b/package/dnsmasq/files/dnsmasq.hotplug @@ -0,0 +1,3 @@ +#!/bin/sh +# Make sure dnsmasq had enough time to poll resolv.conf. +sleep 1 -- 1.5.4.3 -- ___ 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
On Sunday 07 June 2009 20:20:24 Florian Fainelli wrote:
> Le Sunday 07 June 2009 15:59:20 Malte S. Stretz, vous avez écrit :
>[...]
> > 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.
>
> Why not get ip6tables install its uci_firewall6 script for instance? Just
> like iptables installs its firewall script, since firewalling without
> ip6tables is not possible.
I thought about splitting the firewall package into a firewall4 and a
firewall6, both would put something into /lib/firewall and the main
iptables() wrapper would detect the existence of these scripts, a bit like
sysupgrade does it.
But after thinking about it I came to the conclusion that this would be some
overhead and the complexity might become hard to debug and I doubt its worth
the few bytes saved. In a few (1 <= $few <= 3) years we'll have native IPv6
anyway, so I don't think it makes much sense to split the script. But if you
think otherwise, I'm easy to be convinced :)
> > * 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.
>
> I am fine with this.
>
> > * 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).
>
> Last I tried, there was quite a lot of IPv4 specific cases which did make
> all rules apply, and those which were would not give a coherent firewall.
> This was with the old firewall though.
The current uci_firewall.sh doesn't look like there are many places where this
is still the case.
I'd love to be able to configure a single firewall and it just works for both
versions of IP. We'll see if it works out.
> > * 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.
>
> Ok
>
> > * 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.
>
> If it does not add that much overhead, I am ok with that. An user is most
> likely to know that computer with IPv4 a.b.c.d is named foo or bar on his
> local network
I tend to forget it, especially for some esotheric hosts on networks I only
see once in a while. And the last time I had to renumber a mid-sized IPv4
network (20 workstations, 6 servers, a bunch of print servers) it was a real
PITA fixing all those firewall rules etc. manually. Especially the point
below would make this almost trivial.
And once you've got both IPv4 and IPv6 on the net, you'd need to create each
rule twice. It would be a lot easier just to assign n IPvX addresses to each
alias and build the rules based on that. My next dream is that a host alias
can be tied to a MAC address (and/or some other identifying key) and the
firewall rules for this host are updated eg. when the DHCP lease changes
(this might of course be possible with dst_mac already, haven't checked yet).
> > * 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.
>
> I really like the idea, being an IPv6 user and enthousiast ;)
That's good to hear :)
Cheers,
Malte
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[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-netdev&m=123735060618579
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
