**** BEGIN LOGGING AT Sat Dec 03 02:59:57 2011
Dec 03 03:12:43 <builder_> build #104 of pxcab is complete: Failure [failed compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/104
Dec 03 06:42:18 <builder_> build #98 of ppc44x is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/98
Dec 03 12:18:07 <CIA-77> nico * r29400 /packages/net/pyload/ (. Makefile files/ files/pyload.init): packages: add pyload (a fast, lightweight and full featured download manager)
Dec 03 12:18:09 <CIA-77> nico * r29401 /packages/net/pyrit/ (. Makefile): packages: add pyrit (a GPGPU-driven WPA/WPA2-PSK key cracker)
Dec 03 12:21:20 <CIA-77> nico * r29402 /packages/lang/pyrrd/ (. Makefile patches/ patches/101-cross.patch):
Dec 03 12:21:20 <CIA-77> ackages: add pyrrd (an Object-Oriented Python Interface for RRDTool)
Dec 03 12:21:20 <CIA-77> This patch is a port of the PyRRD package to openwrt. PyRRD is a wrapper
Dec 03 12:21:20 <CIA-77> for rrdtool for python. The API is so much better than the python
Dec 03 12:21:20 <CIA-77> bindings for rrd.
Dec 03 12:21:20 <CIA-77> Signed-off-by: Roberto Riggio <roberto.riggio@create-net.org>
Dec 03 12:52:34 <karlp> I'm trying to fix up whitespace in a diff I submitted, what whitespace should I be using? actual tabs, instead of spaces, tabstop=8?
Dec 03 12:52:49 <karlp> anyone got some vim settings that will do the right thing?
Dec 03 12:53:12 <karlp> I'm guess noexpandtab, ts=8, sw=8, softtabstop=8 ?
Dec 03 14:01:16 <CIA-77> jow * r29403 /trunk/package/iwinfo/ (29 files in 5 dirs): [package] add libiwinfo (moved from LuCI trunk)
Dec 03 14:03:35 <CIA-77> jow * r29404 /packages/utils/collectd/ (Makefile patches/900-add-iwinfo-plugin.patch): [packages] collectd: add iwinfo plugin, similar to wireless but compatible to madwifi and mac80211 drivers
Dec 03 14:13:25 <CIA-77> jow * r29405 /branches/backfire/package/iwinfo/: [backfire] merge r29403
Dec 03 16:37:16 <CIA-77> juhosg * r29406 /trunk/target/linux/ar71xx/image/Makefile:
Dec 03 16:37:16 <CIA-77> ar71xx: reclaim unused space in WNDR3700/3800 images
Dec 03 16:37:16 <CIA-77> Patch by: Mark Mentovai <mark@moxienet.com>
Dec 03 16:37:17 <CIA-77> juhosg * r29407 /trunk/target/linux/ar71xx/Makefile: ar71xx: add uboot-envtools to the default package list
Dec 03 16:37:19 <CIA-77> juhosg * r29408 /trunk/target/linux/ar71xx/ (5 files in 2 dirs): ar71xx: remove swconfig and wpad-mini from custom profiles
Dec 03 17:00:59 <CIA-77> juhosg * r29409 /trunk/tools/firmware-utils/src/mktplinkfw.c: firmware-utils/mktplinkfw: fix combined image creation
Dec 03 17:01:01 <CIA-77> juhosg * r29410 /trunk/target/linux/ar71xx/image/Makefile: ar71xx: create initramfs images for the newer TP-Link boards
Dec 03 18:12:56 <Olipro> jow_laptop: does the firewall init always skip interfaces that don't appear to be up, or is there an option you can set to disable hotplug detection?
Dec 03 18:13:48 <jow_laptop> yes, no
Dec 03 18:15:38 <Olipro> well, I'm currently having a pour through anyway since I want to add a UCI option that'll allow you to have it utilise iptables-save/restore
Dec 03 18:15:52 <Olipro> is there any sort of overview anywhere of how the various firewall script files interact with eachother?
Dec 03 18:16:12 <Olipro> or if you can, just give me a general overview of the function call chain
Dec 03 18:16:57 <CIA-77> juhosg * r29411 /trunk/target/linux/ar71xx/patches-2.6.39/ (4 files): ar71xx: allow to pass part_probe types to the m25p80 driver
Dec 03 18:17:00 <CIA-77> juhosg * r29412 /trunk/target/linux/ar71xx/ (2 files in 2 dirs):
Dec 03 18:17:00 <CIA-77> ar71xx: run the wrt160nl parser only on the WRT160NL board
Dec 03 18:17:00 <CIA-77> Also remove static mtd partition definitions.
Dec 03 18:17:02 <CIA-77> juhosg * r29413 /trunk/target/linux/ar71xx/ (3 files in 2 dirs): ar71xx: run the MyLoader parser only on the WP543 board
Dec 03 18:17:03 <CIA-77> juhosg * r29414 /trunk/target/linux/ar71xx/ (7 files in 2 dirs): ar71xx: run the RedBoot parser only on the RedBoot based boards
Dec 03 18:17:07 <CIA-77> juhosg * r29415 /trunk/target/linux/ar71xx/ (3 files in 3 dirs): ar71xx: add mtd partition parser for the TP-Link boards
Dec 03 18:17:10 <CIA-77> juhosg * r29416 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/ (8 files):
Dec 03 18:17:10 <CIA-77> ar71xx: use the tp-link parser on the tp-link boards
Dec 03 18:17:11 <CIA-77> Also remove static partition maps.
Dec 03 18:17:21 <CIA-77> jow * r29417 /trunk/package/iwinfo/src/iwinfo_wext.c: [package] libiwinfo: fix hw mode detection
Dec 03 18:17:36 * Olipro prods jow_laptop
Dec 03 18:18:14 <jow_laptop> the overview is in the code :)
Dec 03 18:18:21 <jow_laptop> interaction, not much
Dec 03 18:18:34 <jow_laptop> main init establishes base rules plus rules or ifaces which are up
Dec 03 18:18:51 <jow_laptop> hotplug.d/iface/*-firewall triggers rules for ifaces which appear later
Dec 03 18:19:17 <jow_laptop> and I still think that iptables add/restore will not gain much
Dec 03 18:19:55 <Olipro> well, in terms of performance, probably not
Dec 03 18:20:11 <Olipro> but it will make it much more flexible for customisation
Dec 03 18:20:34 <jow_laptop> more flexible than firewall.user ?
Dec 03 18:21:14 <Olipro> in cases where you're manipulating existing rules generated by the script, sure
Dec 03 18:21:46 <jow_laptop> well, big can of worms imo
Dec 03 18:21:52 <jow_laptop> the uci firewall assumes a certain structure
Dec 03 18:22:00 <jow_laptop> having users messing around within it breaks it
Dec 03 18:22:40 <jow_laptop> and for precompiled firewall rulesets there is shorewall-lite, fwbuilder etc.
Dec 03 18:23:12 <Olipro> I know, hence why you can instead just offer a save/restore option; people can get a ready-to-go ruleset from the script, and henceforth just toy with it themselves without ever having to worry about any changes or updates made to the firewall script when they get around to flashing a new firmware
Dec 03 18:23:22 <jow_laptop> then the problem with interfaces, you'll not know in advance how ifaces will be called. downing/renaming/deleting/joining interfaces will not be properly reflected
Dec 03 18:24:28 <Olipro> sure, the point of the save/restore thing is purely for people who will know what they're doing
Dec 03 18:25:33 <Olipro> I'm not terribly fond of the interface hotplug anyway; iptables doesn't care if an interface is up or down, it'll just sit there in your ruleset doing nothing
Dec 03 18:25:35 <jow_laptop> those will probably not have firewall isntalled in the first place
Dec 03 18:25:57 <Olipro> if you're adding interfaces as a hotplug action, you do essentially have a very small window where the default firewall policy is going to apply
Dec 03 18:26:11 <jow_laptop> well you don't know if $wanif is going to be eth0.1, eth0, br-wan, pppoe-wan, pptp-wan, 3g-wan, tap0, ...
Dec 03 18:26:24 <jow_laptop> there is a reason for interface hotplugging
Dec 03 18:27:09 <jow_laptop> and if your router is booting so often that the minimal time window is going to be a thread to your network security then you have a problem anyway
Dec 03 18:27:33 <Olipro> heh, I see your point
Dec 03 18:28:38 <Olipro> yeah, I think the smarter thing to do will be to just port my netfilter initscript to OpenWRT
Dec 03 18:29:39 <jow_laptop> if one really wants to improve the firewall then the way to go would be conntrack marks / firewall marks
Dec 03 18:29:49 <jow_laptop> this would drastically cut down the amount of needed rules
Dec 03 18:30:05 <jow_laptop> while retaining the current flaxibility
Dec 03 18:30:47 <jow_laptop> you'd basically just set up the zone-to-zone base rules and later simply add mark rules per iface which select and route streams through the appropraite zone chains
Dec 03 18:31:13 <jow_laptop> and since no actual iface names are involved anymore you don't need all those extra chains
Dec 03 18:32:17 <Olipro> mmm, that's a nice way of doing it, although the QoS script would presumably need some tweaking to remain compatible
Dec 03 18:32:25 <jow_laptop> the only holdback for that was qos-scripts
Dec 03 18:32:40 <jow_laptop> but that got now changed to only use the lower 8 bit of firewall marks
Dec 03 18:32:51 <jow_laptop> so the high bits are free for something else
Dec 03 18:33:08 <Olipro> hm, so you've got the top 24bits of the packet mark to play with
Dec 03 18:34:08 <jow_laptop> yeah
Dec 03 18:34:35 <Olipro> actually, you could probably simplify qos-scripts not to use packet marks at all
Dec 03 18:34:47 <Olipro> if you us -j CLASSIFY instead, you can assign it to a qdisc directly
Dec 03 18:34:50 <Olipro> *use
Dec 03 18:35:03 <jow_laptop> probably
Dec 03 18:49:45 <CIA-77> jow * r29418 /branches/backfire/package/iwinfo/src/iwinfo_wext.c: [backfire] iwinfo: merge r29417
Dec 03 18:50:15 <Olipro> jow_laptop: hmm, if you did use marks, you'd only be able to apply marks based on the incoming interface, in PREROUTING
Dec 03 18:50:38 <Olipro> the filter/FORWARD chain is visited before mangle/FORWARD
Dec 03 19:40:27 <CIA-77> nico * r29419 /branches/backfire/target/linux/ (6 files in 6 dirs): [backfire] targets: rename "files-2.6.x" directories to "files"
Dec 03 19:41:03 <jow_laptop> Olipro: don't see the problem yet, the current fw framework is source bound as well
Dec 03 19:41:13 <CIA-77> nico * r29420 /branches/backfire/toolchain/ (8 files in 8 dirs): [backfire] toolchain: prune empty directories
Dec 03 23:01:38 <swalker> {Nico}: more windows line endings, this time in the pyrit Makefile
Dec 03 23:01:59 <philipp64|laptop> hi all. I was wondering if anyone else was interested in "tag" and "set" support in dnsmasq? I find it useful to be able to match against a MAC address like 00:0e:08:*:*:* and "tag" it for receiving extra DHCP options... like IP addresses for a TFTP and SIP server, etc.
Dec 03 23:02:44 <philipp64|laptop> I'd like to add UCI support to handle this, but if it risks making the configs overly complicated for little benefit (ie. no one else using it) it might not be worth the trouble.
Dec 03 23:03:10 <jow_laptop> thats the reward for buckling under written's nagging
Dec 03 23:03:15 <jow_laptop> (windows newlines)
Dec 03 23:04:31 <jow_laptop> philipp64|laptop: http://wiki.openwrt.org/doc/uci/dhcp#classifying.clients.and.assigning.individual.options ?
Dec 03 23:05:33 <philipp64|laptop> jow_laptop: yeah, like that, but with an extra level of indirection.
Dec 03 23:05:47 <philipp64|laptop> let me dig out an example...
Dec 03 23:05:49 <swalker> well, I think it's better than rotting attached to a ticket and/or mailing list thread
Dec 03 23:06:48 <philipp64|laptop> one or more instances of: dhcp-mac=set:SIP,00:0e:08:*:*:* (for each ethernet vendor prefix)
Dec 03 23:07:26 <philipp64|laptop> and then for all devices which match the tag "SIP", you then specify: dhcp-option=tag:SIP,option:141,192.168.1.1
Dec 03 23:08:03 <philipp64|laptop> the nice thing about tagging is you can match against the vendor string, the MAC address, the address range, the subnet...
Dec 03 23:08:39 * swalker wonders if any of the pseudo-maintainers have gotten commit access to their package(s) yet
Dec 03 23:11:43 <jow_laptop> philipp64|laptop: I got what you mean and the wiki page explains exactly that
Dec 03 23:12:31 <jow_laptop> this fore example is only applied to my desktop: http://pastebin.com/nAqn0WvN
Dec 03 23:13:17 <jow_laptop> it results in  --dhcp-mac=lan,00:1b:fc:89:97:5a -O lan,6,141.1.1.
Dec 03 23:13:58 <philipp64|laptop> right... the problem is that if I have 4 patterns matching MAC prefixes... and 5 options that I want to send... that's 20 permutations.
Dec 03 23:14:21 <philipp64|laptop> the way I'm proposing it's N+M, not N*M.
Dec 03 23:14:28 <jow_laptop> actually its only 5
Dec 03 23:14:36 <jow_laptop> dhcp_options can be multiple
Dec 03 23:14:41 <jow_laptop> in one section
Dec 03 23:15:06 <jow_laptop> so its down to four sections using four mac patterns with 5 options each
Dec 03 23:15:39 <jow_laptop> if you want to optimize this further you can make the init script loop over the classifier values
Dec 03 23:15:42 <philipp64|laptop> you're just counting it differently. :-)
Dec 03 23:15:54 <jow_laptop> then its one section with 4 patterns and 5 options
Dec 03 23:16:09 <philipp64|laptop> right, the same 5 options repeated in each.
Dec 03 23:16:49 <philipp64|laptop> I like being able to "macro-ize" or "templatize" or "indirect" or whatever you want to call it to come up with a generic definition for "SIP" device.
Dec 03 23:17:18 <philipp64|laptop> but it's not specific to SIP, of course....
Dec 03 23:17:43 <philipp64|laptop> you could come up with restrictions for Kindle/Fire/iPad rules that restrict the devices to a "lounge", etc.
Dec 03 23:19:10 <philipp64|laptop> anyway, in addition to the "vendorid" keyword, I'll try to add handling for "tag" and "set".
Dec 03 23:19:30 <jow_laptop> I blieve you're reinventing the wheel
Dec 03 23:19:41 <philipp64|laptop> (to the respective "options" and "mac" sections, of course.)
Dec 03 23:20:17 <philipp64|laptop> ok, so how else can "templates" or macros be specified?
Dec 03 23:22:07 <jow_laptop> http://pastebin.com/FFTK783n
Dec 03 23:22:22 <jow_laptop> results in -O SIP,6,141.1.1.1 --dhcp-mac=SIP,00:11:*:*:*:* --dhcp-mac=SIP,00:22:*:*:*:* --dhcp-mac=SIP,00:33:*:*:*:*
Dec 03 23:23:14 <jow_laptop> and one could extend the classifier handling to accept multiple classifer values
Dec 03 23:23:23 <jow_laptop> then it would boil down to only two sections
Dec 03 23:24:26 <jow_laptop> like this: http://pastebin.com/8ScBTpFZ
Dec 03 23:28:44 <jow_laptop> patch: http://pastebin.com/dGZRxvrc
Dec 03 23:29:12 <jow_laptop> thinking about it one could combine all classifiers into one too
Dec 03 23:29:34 <jow_laptop> config classifier which then would accept multiple macs, userclasses, circuitids etc.
Dec 03 23:30:02 <jow_laptop> its probably easier to understand than "config mac", "config userclass", etc.
Dec 03 23:37:11 <philipp64|laptop> hmmm.... so you could use "set:SIP" as the RHS in the "mac" section, and "tag:SIP" as the RHS in the "option" section...
Dec 03 23:38:08 <jow_laptop> yes
Dec 03 23:38:48 <philipp64|laptop> ok... would be nice to have a little window-dressing on that so users don't need to be dnsmasq experts...
Dec 03 23:39:09 <philipp64|laptop> maybe a prefix character that gets rewritten?  like '@' ?
Dec 03 23:39:26 <jow_laptop> or simply implement an option "set" in addition to "networkid"
Dec 03 23:39:53 <jow_laptop> and a complementary "tag" option in potential user sections
Dec 03 23:40:27 <jow_laptop> like "option set SIP" in mac and "option tag SIP" in host
Dec 03 23:40:34 <philipp64|laptop> ${networkid/#@/tag:}
Dec 03 23:40:49 <jow_laptop> but option tag sounds like tagging something, not matching a tag
Dec 03 23:41:04 <philipp64|laptop> ok, "class"
Dec 03 23:41:05 <jow_laptop> so maybe "option match tag" or "option for tag"
Dec 03 23:41:57 <jow_laptop> your substitution sounds nice too
Dec 03 23:42:42 <jow_laptop> however it looks like my example is essentially the same as set: and tag:
Dec 03 23:42:45 <philipp64|laptop> I agree with your other suggestion of introducing an additional keyword... i.e. "classifier".
Dec 03 23:42:53 <jow_laptop> just can't figure out which notation is deprecated
Dec 03 23:42:58 <jow_laptop> I recall that there are two
Dec 03 23:43:48 <philipp64|laptop> or the "set" option in addition to "networkid" as you say... though maybe "class" not "set"... but either way is good.
Dec 03 23:43:53 <philipp64|laptop> whatever is most intuitive.
Dec 03 23:50:56 <jow_laptop> http://pastebin.com/AFmRKxYw
Dec 03 23:58:54 <philipp64|laptop> looks promising.... I can build an image and try it...
Dec 04 00:29:24 <jow_laptop> yes please, I've no clear overview over where tags can be set and matched
Dec 04 00:47:00 <Olipro> I think the patches to python borked it
Dec 04 00:50:44 <Olipro> (python for the host)
Dec 04 02:25:59 <philipp64|laptop> jow_laptop: built an image...  I'll install it and configure it after dinner...
**** ENDING LOGGING AT Sun Dec 04 02:59:58 2011