**** BEGIN LOGGING AT Fri Feb 05 02:59:56 2010 Feb 05 03:04:52 How is your serial cable connected? Feb 05 03:58:27 anyone know whats wrong with the iptables multiport match in 2.4? I havent' had much luck with it since https://dev.openwrt.org/ticket/5141 Feb 05 03:58:56 sorta puts a cramp in qos Feb 05 06:21:03 ping [florian] Feb 05 07:57:08 jow * r19530 /trunk/package/base-files/ (Makefile files/usr/share/udhcpc/default.script): [package] base-files: fix udhcpc address acquisition on network restart (patch by Scott Dudley) Feb 05 08:06:28 ping xMff Feb 05 08:06:40 pong Feb 05 08:07:49 I noticed that the coldplug of existing devices is never done Feb 05 08:08:37 preinit has the coldplug to get device names, but there is never a coldplug that creates events for existing devices Feb 05 08:09:41 well only thin I remember is that the old preinit did: /sbin/hotplug2 --coldplug --set-rules-file /etc/hotplug2-init.rules Feb 05 08:10:02 right, but that only creates device names Feb 05 08:10:46 the hotplug that generates events (i.e. the full, after preinit hotplug) never does a coldplug Feb 05 08:11:27 what do you mean with "only creates device names" ? Feb 05 08:11:38 You mean /dev nodes ? Feb 05 08:11:40 right Feb 05 08:12:53 and what should a real coldplug do? Feb 05 08:14:05 generate events for detected devices so that the same thing that is done for hotplugged devices is done for existing devices....i.e. hotplug.rules (not -init) should be activated for existing devices not only new ones Feb 05 08:15:27 like mount partitions not in /etc/config/fstab even if the usb modules were already loaded and the device in place before preinit Feb 05 08:15:50 or start up network interfaces Feb 05 08:16:07 well then you just need to call coldplug again at the end of preinit Feb 05 08:16:15 with full rules Feb 05 08:16:22 but without network interfaces Feb 05 08:17:20 why is that? Feb 05 08:18:08 they're treated separately iirc Feb 05 08:19:18 is that because it needs some init.d processing first? Feb 05 08:19:36 that too yes Feb 05 08:20:24 maybe hotplug should be deferred until /etc/init.d/done Feb 05 08:36:37 hmmm....I see a problem with that approach....it looks like the network hotplug takes a device down (or at a bridge) down when the device has an 'add' event Feb 05 08:36:54 or at least bridge, I meant to say Feb 05 08:38:28 it's probably the fault of ifup, which does an ifdown first Feb 05 08:39:58 ifdown before ifup is okay imo Feb 05 08:43:01 then add should only do ifup if it's not already up... Feb 05 08:47:13 or maybe we need special hotplug coldplug rules set, since it seems to be a problem Feb 05 08:49:31 ... Feb 05 08:49:41 you're about to open a big can of worms Feb 05 08:52:23 we experienced another funny thing yesterday with openwrt as xen domu Feb 05 08:52:51 it booted too fast, some services started by init failed because the network wasn't ready at the time they were started Feb 05 08:52:57 well the problem is that there is no dependencies for hotplug events, imo Feb 05 08:52:59 right Feb 05 08:53:25 and init depends on hotplug events Feb 05 08:53:27 they failed because they were configured to bind to a specific ip Feb 05 08:54:10 well I think at one point everything must be converted to hotplug Feb 05 08:54:14 yes Feb 05 08:54:23 and preinit just kicks it into operation Feb 05 08:54:25 and dependencies need to be added Feb 05 08:54:27 yes Feb 05 08:55:17 or there must be a facility to synchronize (certain) init scripts with hotplug, for example to defer network services until the network setup is fully complete Feb 05 08:55:40 that's what I meant by dependencies Feb 05 08:55:53 but this is complex work Feb 05 08:55:57 yes Feb 05 08:57:08 ubuntu workstation has this problem with dhcp-server on a desktop Feb 05 08:57:32 dhcp-server is trying to bind before the network is ready Feb 05 08:57:48 because it's still init.d based Feb 05 08:57:56 while the network is upstart Feb 05 08:58:45 the service we had trouble with was haproxy, I just told me colleague to make boot() empty and fire it up with hotplug, but we kinda missed a hotplug event that only fires once, when the whole network is complete Feb 05 08:59:27 no we just tied it to net/add but this will fire once for each interface Feb 05 08:59:31 *now Feb 05 09:04:33 I'm going to have to think about it somewhat...I don't think this is something that you can just hack a good solution for Feb 05 09:05:03 but for now I think it would be sufficient to block /e/i/network boot until the network is complete, but I see other problems, for example a dhcp client that never returns, or a 3g dialup that takes ages to complete Feb 05 09:07:21 what you really need is to be able to depend on the part of the network you actually care about...e.g. base firewall and interface-specific (or interfaces, .e.g lan and wan, if that's what you need) Feb 05 09:09:42 in case of haproxy that would require: parsing the native config, look for "bind" directives, map the ip to an interface, map the interface to a network, wait for the particular network(s) Feb 05 09:10:16 hmmmm..... Feb 05 09:11:42 the problem is probably no so much creating a solution but dealing with all the packages Feb 05 09:12:28 right Feb 05 09:12:31 init.d is easy Feb 05 09:12:45 but with hotplug you have problems Feb 05 09:13:01 things aren't serial any more Feb 05 09:13:08 well, some programs like ntp-client already use hotplug for init-on-boot Feb 05 09:13:43 I think each network-config-dependant service should be initialized via hotplug Feb 05 09:13:58 that makes sense Feb 05 09:14:30 for example /etc/hotplug.d/net, ACTION=add Feb 05 09:14:42 there you can check the uci state to see which interfaces are up Feb 05 09:14:54 right Feb 05 09:14:57 or maybe even route -n | grep required-ip Feb 05 09:15:57 however, what's actually missing is a good set of helper functions Feb 05 09:16:15 like ip2iface, iface2network, ip2network etc. Feb 05 09:16:41 because the reverse mapping can be quite complex Feb 05 09:17:45 definitely Feb 05 09:19:23 for example, I know I need to bind to 89.56.34.24, so I need to know which network it belongs to to be able to check its "up" state Feb 05 09:21:10 now imagine that would be the wan interface and it has not received dhcp yet Feb 05 09:21:45 I could either schedule some kind of "waitfor wan" event which we have no infrastructure for Feb 05 09:22:04 or I could move the startup operation into a hotplug addif event Feb 05 09:23:38 now if I have a single service binding on different interfaces I have a problem Feb 05 09:23:53 because the hotplug events are delivered per-interface Feb 05 09:24:18 I'd need to build some list of required candidates and iterate that on each addif event until all required interfaces are up Feb 05 09:24:27 right Feb 05 09:25:32 I think the approach is correct but thats what we need the helper functions for to make it easy to implement Feb 05 09:25:38 yes Feb 05 09:26:11 so that I can call something like "if is_up 192.168.5.3 89.56.34.24 10.11.34.56; then start; fi" in each addif Feb 05 09:28:35 kind of like an if-pool-x-up.d directory (like if-up.d, but for collections of interfaces) Feb 05 09:29:08 a dynamic queue mechanism, yes but I think that would be too complex Feb 05 09:29:44 a hotplug even is initiated with each interface going up anyway Feb 05 09:30:07 so I can decide within the event handler whether the environment is complete enough Feb 05 09:31:06 using a kind of queue would introduce another level of indirection Feb 05 09:31:18 hmmm... Feb 05 09:31:50 on the other hand... Feb 05 09:32:47 I could do echo on_ip start_foo 192.168.5.3 89.56.34.24 10.11.34.56 > /var/run/foo/serivce.task Feb 05 09:33:08 and then some processing code that runs with each addif and executes the queue in /var/run Feb 05 09:33:41 this could be easily done in boot() Feb 05 09:34:20 then one must make sure that this "task setup" stuff is run before any network init Feb 05 09:35:29 basically add /etc/boot.d which is run from /etc/init.d/boot, or some such Feb 05 09:35:39 instead of tempfile with taskinfo one could use a volatile uci config Feb 05 09:35:49 before the hotplugging/coldpluggin Feb 05 09:35:54 with one section / task Feb 05 09:38:41 or maybe /etc/task.d ... I like that better Feb 05 09:39:05 it's not yet another init.d, it's specifically for defining tasks Feb 05 09:39:21 well keep in mind that there might be a need to generate tasks dynamically Feb 05 09:39:42 depending on the confguration of the particular service Feb 05 09:40:22 nevermind, I think we talk about different things - you mean the "init script" that sets up the task, right? Feb 05 09:40:26 make use /etc/task.d as an alternate UCI config dir, an combine it with /var/state/task Feb 05 09:40:28 yes Feb 05 09:40:30 ok Feb 05 09:40:39 make=maybe Feb 05 09:40:57 basically so it doesn't affect regular uci Feb 05 09:41:01 right Feb 05 09:41:22 some library with a few shell functions like add_task, run_task etc. Feb 05 09:41:34 right Feb 05 09:41:59 and we need a format to specify an action if the requirements are fullfilled and the requirements itself, like depends_on_ip, depends_on_mounted_jffs2, etc. Feb 05 09:44:32 maybe a failure action as well, if the requirements were not met when the booting is finished Feb 05 09:44:42 right Feb 05 09:44:52 but there's no clear "end of booting" Feb 05 09:44:59 maybe just a timeout Feb 05 09:45:14 hotplug actions could be triggered way later, for example if a usbnet adapter is plugged in days later Feb 05 09:51:56 well you could have a fail-condition...basically it's another task, that if it's conditions are met before the original tasks, kills the other task and does the fail action Feb 05 09:52:39 it could be simple timeout Feb 05 09:56:59 I think the requirements should just be names of shell functions, which are found by 'including' some directory...easily extensible, and we provide a library of common ones Feb 05 09:57:30 yes Feb 05 09:57:53 we should make a draft / rfc somewhere to sort out the rough cases Feb 05 10:00:52 if public, we could just use the wiki...although I'm not sure what namespace....maybe just in the inbox Feb 05 10:01:42 http://wiki.openwrt.org/inbox/techref/taskinit_discussion Feb 05 10:49:45 ok, I have an initial text up there now Feb 05 10:58:22 swalker * r19531 /packages/lang/luafilesystem/Makefile: [packages] luafilesystem: update to 1.5.0 Feb 05 11:19:22 swalker * r19532 /packages/utils/dosfstools/ (Makefile patches/002-linux_26_headers.patch): [packages] dosfstools: update to 3.0.9 Feb 05 11:25:08 hi Feb 05 11:25:10 ping nbd Feb 05 17:52:53 hello guy I need help to build a package, the problem is my package should be created after other, but it's created just before, and I don't understand why, here is my makefile, postinstall and result of buildroot http://pastebin.ca/1787234, any one can help me please? Feb 05 17:54:06 ping xMff Feb 05 17:55:10 xMff: I'm not sure about 19530 Feb 05 17:56:06 we re-wrote the script to avoid reconfiguring the interface just because udhcp says its up Feb 05 17:56:24 wont this bring is back to where we started? Feb 05 17:56:43 s/is/us Feb 05 17:57:49 my original re-write worked with the interfaces directly so as to avoid the case corrected by this patch Feb 05 18:08:01 netprince_: it is intended for /etc/init.d/network restart wich leaves the uci state intact but removes the ip configuration Feb 05 18:08:33 netprince_: but I'll check again later Feb 05 18:09:09 yeah, I haven't had a chance to try it yet either, but it looks like dhcp clients with short lease times might get the interfaces reconfigured each renew? Feb 05 18:09:40 hm yeah, ifdown should probably just revert te uci state Feb 05 18:10:45 yeah, that would work better I think Feb 05 18:12:29 build #4 of adm5120 is complete: Failure [failed compile_15] Build details are at http://tksite.gotdns.org:8010/builders/adm5120/builds/4 Feb 05 18:13:15 xMff: May you check It http://pastebin.ca/1787234 and tellme what i'm doing wrong? Feb 05 18:38:56 ping nbd Feb 05 20:22:40 oing nbd Feb 05 20:50:16 florian * r19533 /trunk/target/linux/generic-2.6/patches-2.6.32/270-scci_sd_section_fix.patch: [kernel] fix mips linking failure on bad section (#6635) Feb 05 22:11:12 <|KanjiMonster|> [florian]: where can I set parameters for lzma? (regarding ticket #6627) Feb 05 23:57:29 nbd: ping Feb 06 01:49:37 ping xMff Feb 06 02:00:15 build #4 of iop32x is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/4 Feb 06 02:30:21 ping thepeople **** ENDING LOGGING AT Sat Feb 06 02:59:56 2010