[00:03] <florian__> ah that's what is causing strcpy linking error ?
[00:03] <[mbm]> yep
[00:03] <[mbm]> but it looks like I have other issues
[00:09] <[mbm]> ah
[00:09] <[mbm]> seems they moved -ffreestanding out of the toplevel makefile and added it to some specific archs
[00:10] <nbd> and not for mips, right?
[00:10] <nbd> :/
[00:10] <[mbm]> yeah, just for uml
[00:10] <[mbm]> and i386
[00:10] <[mbm]> ...
[00:10] <[mbm]> bastards.
[00:10] <nbd> hmz
[00:10] <[mbm]> # temporary until string.h is fixed
[00:10] <[mbm]> cflags-y += -ffreestanding
[00:11] <nbd> btw. i'll try to make the /sbin/wifi script generic. do you think i should put 'plugins' in /lib/wifi/*.sh?
[00:12] <[mbm]> plugins?
[00:12] <nbd> shell includes for different drivers
[00:13] <nbd> so that wlc or kmod-broadcom-wl would come with /lib/wifi/broadcom.sh that contains all the instructions for setting up the driver from /etc/config/wireless
[00:15] <nbd> so /lib/wifi/broadcom.sh only registers a handler function for the wifi interface type 'broadcom-wl', which only gets called when the config file specifies such an interface
[00:15] <nbd> so that in the future it'll work with multiple different wifi interfaces containing different virtual interfaces
[00:16] <[mbm]> so is that for config parsing or talking to the driver?
[00:17] <nbd> the parsing is done by stuff in /etc/functions.sh
[00:17] <nbd> the script collects all the config values and applies them to the driver
[00:17] <[mbm]> and you're using a shell script for that?
[00:17] <nbd> for broadcom it's a shell script plus the new wlc util
[00:18] <nbd> which is similar to wl, but can do all the required parameters and can also read from stdin for better shell scripting performance
[00:18] <nbd> the main logic of the driver setup process in the shell stuff
[00:18] <[mbm]> ok, but what was the point of the shell script then?
[00:19] <[mbm]> why aren't we interfacing wlc directly?
[00:19] <nbd> the shell script converts the config into driver parameters for broadcom
[00:19] <nbd> because wlc is pretty close to the wl option names
[00:19] <[mbm]> not to be annoying or anything, but "why?"
[00:20] <nbd> because i don't want to parse the config in c
[00:20] <[mbm]> seems like we could abstract things at the wlc layer and avoid a shell script
[00:20] <nbd> and i don't want to do the driver abstraction in c either
[00:20] <nbd> and wlc is useful, because it's really small and replaces wl at the same time
[00:20] <[mbm]> ok
[00:21] <nbd> and the source code is much much cleaner than the previous wificonf stuff
[00:21] <nbd> because it just uses a large table that points to generic ioctl functions for most calls
[00:21] <nbd> so a lot less code duplication
[00:22] <nbd> and for the config i'll implement it so that you can even specify the virtual interfaces in an arbitrary order and the shell script makes sure that everything gets sent to the driver in the correct order
[00:23] <nbd> so the config is going to be very intuitive
[00:24] <[mbm]> I'm still trying to hold on to the idea that the drivers can use a common ioctl scheme or that there would be a single arch specific binary
[00:25] <nbd> it's too much work to really abstract away all the unique properties of the driver
[00:25] <[mbm]> this whole concept of a generic wifi uril that calls an arch specific script which calls an arch specific binaries .. just seems like a mess
[00:25] <nbd> because the broadcom driver is really a lot less flexible than madwifi
[00:25] <[mbm]> yeah I know
[00:25] <nbd> and you have to be really careful to specify everything in the right order
[00:25] <nbd> even more than with the older driver
[00:25] <nbd> so the abstraction really happens at the shell code level
[00:26] <[mbm]> I'm not saying I have any better ideas, I'm just saying that it's still a hack
[00:26] <nbd> and why arch specific scripts?
[00:26] <nbd> driver specific scripts are much better
[00:26] <[mbm]> er, whatever .. meant the same thing
[00:26] <nbd> waht i don't see is why it has to be binary?
[00:27] <[mbm]> I don't, I just want to see less layers
[00:27] <nbd> there aren't that many layers. for most drivers the shell code interfaces directly with the native setup utilities
[00:27] <nbd> only on broadcom there is the need of an extra binary utility to set things up
[00:28] <[mbm]> ok
[00:28] <nbd> for wifi itself we can also define common shell functions that handle iwconfig based stuff and reuse them from the madwifi/whatever-specific stuff
[00:28] <nbd> so everything that can be shared, will be
[00:29] <CIA-4> mbm * r4015 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/patches/202-mips-freestanding.patch: reintroduce the -ffreestanding to avoid gcc inline errors
[00:32] <[mbm]> hmm no responses to the firewall thread .. that's disapointing
[00:36] <h3sp4wn> florian: http://openwrt.vcp-springe.de/experimental/yafc-sdk.tar.bz2 - that should build on normal white russian and kamikaze I will update it for buildroot-ng once I can get a build to complete
[00:37] <[mbm]> http://seclists.org/lists/nmap-dev/2006/Jan-Mar/0111.html
[00:38] <nbd> :)
[00:39] <[mbm]> I'm still amused at how popular that tip is .. it only appeared once on an old linux.com article and now everyone is using it
[00:40] <nbd> hmm... if i continue at this rate, i might actually get the broadcom stuff running today
[00:52] <{Nico}> MODULE_PARM is gone in 2.6.17, how do we deal with that for external kernel drivers?
[00:52] <{Nico}> should we patch-em-all?
[00:52] <{Nico}> or re-add MODULE_PARM until all drivers have been updated?
[00:52] <nbd> patch-em-all
[00:52] <nbd> imho
[00:52] <nbd> we can send the patches to the authors then
[00:53] <nbd> we don't have that many externally compiled drivers, do we?
[00:54] <{Nico}> nbd: did you see what i did for kmod-switch?
[00:54] <nbd> yeah
[00:54] <{Nico}> is this the way to go?
[00:55] <nbd> i think the kernel version to check for could be changed a bit
[00:56] <nbd> iirc module_parm was added a bit earlier
[00:56] <nbd> i mean module_param
[00:56] <{Nico}> btw, ipsec-tools and fuse are broken too but for other api changes i guess
[00:56] Action: nbd is currently trying to get the broadcom wifi stuff for 2.4 up and running
[00:57] <{Nico}> nbd: imho, what's important there is more MODULE_PARM death
[00:58] <nbd> yeah
[00:58] <nbd> looks good
[00:58] <{Nico}> ok, back to the dirty job
[01:11] <h3sp4wn> Is there any of the current archs which can compile at this moment or should I just wait until tommorow (buildroot-ng) I am going to try and convert some packages to the new format
[01:15] <[mbm]> you should be able to compile buildroot-ng for the brcm-2.4 platform
[01:16] <h3sp4wn> Thanks
[01:17] <h3sp4wn> mbm: appologies for the stupid question - obviously 2.6.17 only affects the 2.6 kernel
[01:18] <[mbm]> yeah, the 2.6.17 stuff is broken on many platforms
[01:18] <[mbm]> cleaning up the mess now
[01:19] <nbd> btw. i'll drop support for non-standard configurations like wpa1 with aes or mixed wpa1+wpa2
[01:19] <nbd> stuff like that is asking for trouble, anyway
[01:22] <[mbm]> ok
[01:43] <[mbm]> lmao
[01:43] <[mbm]> nice quit message, but the quotes give it away
[01:47] <nbd> yeah
[01:51] <{Nico}> [mbm], nbd: do you want the variables in "define Package/foo" indented or not?
[01:51] <nbd> yeah, let's indent them
[01:51] <nbd> with 2 spaces
[01:52] <[mbm]> yeah makes it easier to read
[01:52] <{Nico}> 'k
[01:55] <CIA-4> nico * r4016 /branches/buildroot-ng/openwrt/package/openswan/patches/102-new_module_param.patch: fix MODULE_PARM removal in 2.6.17.
[02:24] <CIA-4> mbm * r4017 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/patches/ (000-aruba.patch 002-irq.patch): fix irq handling on 2.6.17
[06:48] <CIA-4> nbd * r4018 /branches/buildroot-ng/openwrt/package/broadcom-wl/Makefile: add libbcmcrypto to the nas package
[10:28] <CIA-4> kaloz * r4019 /branches/buildroot-ng/openwrt/ (4 files in 3 dirs): be politically correct
[11:57] <CIA-4> florian * r4020 /branches/buildroot-ng/openwrt/target/linux/au1000-2.6/config: Update alchemy kernel configuration
[12:02] <CIA-4> florian * r4021 /branches/whiterussian/openwrt/package/webif/files/usr/lib/webif/form.awk: Add upload template for webif, closes #590 and definitively #525
[13:10] <florian__> Kaloz: can you resend me your brcm63xx patch against 2.6.8.1 ?
[13:20] <florian__> by mail preferably :)
[13:52] <florian__> Kaloz: ?
[13:55] <Kaloz> florian__: will send it later
[14:09] <florian__> Kaloz: ok, thank you very much
[14:10] <florian__> someone here with a buffalo WLA2-G54L can confirm that #536 can be closed ?
[14:23] <ang-st> just al ittle question about how are handled kernel patches
[14:24] <florian__> go ahead
[14:24] <ang-st> is there a kind of package to build to add one ?
[14:25] <ang-st> i mean for the buildroot script
[14:31] <florian__> no, just put your new patch into target/linux/<sub arch>/patches/
[14:34] <ang-st> ok in fact the originals patch are shipped with the buildroot script ?
[14:39] <florian__> not with the buildroot script, but they are shiped in the svn snapshot
[14:42] <florian__> I am not sure I answered your question, right ?
[14:42] <florian__> Kaloz: did you had a look at the rtl865x tarballs ?
[14:43] <ang-st> hmm the fact is if i want to automate the fecth and patch of the kernel automatically ....
[14:43] <ang-st> where should i have a look
[14:43] <ang-st> (sorry i speak english as martian cow :))
[14:44] <florian__> lol
[14:44] <florian__> I think fetching and patching of the kernel is already automatic ?
[14:45] <ang-st> yep but imagine that i would add another patch
[14:45] <ang-st> and even make it available for some friends:p
[14:46] <ang-st> moreover this patch is situated on a repository
[14:46] <ang-st> how should i do this ? :)
[14:47] <ang-st> cause i saw http://forum.openwrt.org/viewtopic.php?pid=26438 that's ok but
[14:48] <ang-st> it only work if you manually put it in /patches/ subdirs right ,
[14:48] <ang-st> ?
[14:49] <florian__> ah I see
[14:50] <florian__> why can't you put the patch in patches/ ?
[14:55] <ang-st> i can but in fact the question is how it is done for other patch
[14:56] <florian__> there is no download of patches actually
[14:57] <florian__> everything is in the buildroot
[14:57] <ang-st> ok
[14:57] <florian__> if you want to put a custom patch, you have to do it by hand
[14:57] <florian__> I know it's not really convenient, and it should not be that hard to add download functionnality before patching
[15:00] <ang-st> ok it's clear for me so now i can stop to browse source to find this :)
[15:23] <jr-> florian. about ticket 536. wla2-g54l doesn't have wan port. only 4 lan ports + wlan. switch settings are forced to defaults by cfe on every boot. i don't think openwrt should randomly change one of lan ports to wan port. especially since all ports are bridged together until S05nvram temporarily changes it.
[15:26] <florian__> jr-: ok, so what to do ?
[15:28] <jr-> depends what openwrt wishes to offer sor wla2-g54l. treat it as wan-less device that it really is or try to turn it device with wan-port with problems it causes unless you also patch cfe.
[15:30] <florian__> ok, I see what you mean
[15:36] <jr-> i have wla2-g54l in somewhere. i'll check current status of openwrt on it. nbd fixed some minor problem i had with it before rc5. i think only problems were in diag.o not controlling leds and buttons and unknown flash type that was fixed earlier.
[17:40] <CIA-4> nbd * r4022 /branches/buildroot-ng/openwrt/package/base-files/ (au1000-2.6/sbin/mount_root default/sbin/mount_root): mount /proc earlier in /sbin/mount_root
[19:50] <CIA-4> nbd * r4023 /branches/buildroot-ng/openwrt/scripts/gen_menuconfig.pl: fix for multiple dependency flags
[19:54] <CIA-4> nbd * r4024 /branches/buildroot-ng/openwrt/scripts/gen_deps.pl: more dependency fixes
[19:54] <CIA-4> nbd * r4025 /packages/net/ (5 files in 3 dirs): add chillispot
[20:13] <CIA-4> nbd * r4026 /packages/net/chillispot/Makefile: reverse the order of + and @ in chillispot depends, because package/rules.mk requires it
[20:57] <CIA-4> mbm * r4027 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/patches/203-fix_initrd_duplication.patch: annoying initrd bug introduced by 2.6.17
[22:11] <tziOm> nbd, know why portmap segfaults here (rc5)
[22:11] <nbd> no
[22:14] <[mbm]> trace it and see :P
[22:14] <tziOm> strace doesnt really give me anything useful I think...
[22:14] <tziOm> svr4_syscall() = -1 ERRNO_4090 (Unknown error 4090)
[22:15] <[mbm]> you might need gdb
[22:16] <tziOm> does it work other places?
[22:17] Action: [mbm] hasn't tried; I only run nfs as a client and I don't use portmap
[22:17] <tziOm> type portmap and check if it segfaults...
[22:18] <[mbm]> didn't I just say I don't use portmap?
[22:18] <[mbm]> I don't even have it on any of my systems
[22:25] <tziOm> yeah?
[22:32] <[mbm]> no?
[22:52] <nbd> i really need to learn more about fixing endianness bugs
[22:52] <nbd> fscking chillispot doesn't work on big-endian
[22:53] <[mbm]> lmao
[22:53] <nbd> i found a mention of two 4-bit ip headers being reversed
[22:53] <nbd> and i fixed that
[22:53] <nbd> but i have no clue about what needs to be done to the ip checksum
[22:54] <[mbm]> crc routines change depending on endian
[22:54] <[mbm]> you can't just byteswap the end result
[22:55] <nbd> i know
[22:55] <nbd> but i don't know what needs to be changed
[22:56] <[mbm]> is it a table based crc?
[22:56] <[mbm]> or did they include the polynomial?
[22:56] <nbd> no
[22:56] <nbd> let me check...
[22:57] <nbd> they just sum it up and then negate it
[22:57] <nbd> i mean invert it
[22:57] <[mbm]> ok, that's not a true crc32
[22:57] <nbd> i'll paste it
[22:58] <nbd> http://pastebin.ca/67970
[22:58] <nbd> a little bit different
[22:59] <[mbm]> ok, they're summing words at a time
[22:59] <nbd> can i just swap the words
[22:59] <nbd> and later swap the result?
[23:01] <[mbm]> well, the problem is slightly more complex than that
[23:01] <[mbm]> little endian looks like this: 1234
[23:01] <[mbm]> big endian looks like this: 4321
[23:02] <nbd> i know
[23:02] <[mbm]> that routine is adding 16bit works
[23:02] <[mbm]> so 12+34 isn't the same as 43+21
[23:02] <[mbm]> and no byteswapping of the result will fix that
[23:02] <nbd> that's why i wanted to byteswap the individual words _and_ the result
[23:02] <[mbm]> right
[23:03] <[mbm]> but before you do that check to see what it does with the results
[23:03] <[mbm]> since it would be a waste to byteswapp the crc only to byteswap it back later
[23:06] <nbd> hmm... weird... i don't get any packets from chillispot for some reason
[23:06] <nbd> it receives my dhcp request
[23:06] <nbd> and prints it on the log
[23:06] <nbd> but i don't get the reply in ethereal
[23:07] <nbd> could it be that the raw socket is dropping invalid packets?
[23:13] <florian__> nbd: probable
[23:14] <nbd> i hate this software
[23:14] <nbd> it's buggy, it's bloated
[23:14] <florian__> yeah, it's chillispot
[23:15] <nbd> i'll tell them that it's not worth fixing it
[23:15] <nbd> they should switch to a different software
[23:15] <florian__> wifidog is far better
[23:15] <nbd> is it fully compatible?
[23:15] <florian__> no, it's using a different authentication server
[23:15] <nbd> hmz
[23:15] <florian__> but it remains a captive portal
[23:18] <[mbm]> I've thought of doing one of those multiple times
[23:18] <[mbm]> (there really isn't much to it)
[23:20] <florian__> there is a lot of things where are handling that needs rewriting ;)
[23:22] <florian__> in fact, the real project we should work on
[23:23] <florian__> is the time machine
[00:00] --- Wed Jun 21 2006
[00:03] <[mbm]> yep
[00:03] <[mbm]> but it looks like I have other issues
[00:09] <[mbm]> ah
[00:09] <[mbm]> seems they moved -ffreestanding out of the toplevel makefile and added it to some specific archs
[00:10] <nbd> and not for mips, right?
[00:10] <nbd> :/
[00:10] <[mbm]> yeah, just for uml
[00:10] <[mbm]> and i386
[00:10] <[mbm]> ...
[00:10] <[mbm]> bastards.
[00:10] <nbd> hmz
[00:10] <[mbm]> # temporary until string.h is fixed
[00:10] <[mbm]> cflags-y += -ffreestanding
[00:11] <nbd> btw. i'll try to make the /sbin/wifi script generic. do you think i should put 'plugins' in /lib/wifi/*.sh?
[00:12] <[mbm]> plugins?
[00:12] <nbd> shell includes for different drivers
[00:13] <nbd> so that wlc or kmod-broadcom-wl would come with /lib/wifi/broadcom.sh that contains all the instructions for setting up the driver from /etc/config/wireless
[00:15] <nbd> so /lib/wifi/broadcom.sh only registers a handler function for the wifi interface type 'broadcom-wl', which only gets called when the config file specifies such an interface
[00:15] <nbd> so that in the future it'll work with multiple different wifi interfaces containing different virtual interfaces
[00:16] <[mbm]> so is that for config parsing or talking to the driver?
[00:17] <nbd> the parsing is done by stuff in /etc/functions.sh
[00:17] <nbd> the script collects all the config values and applies them to the driver
[00:17] <[mbm]> and you're using a shell script for that?
[00:17] <nbd> for broadcom it's a shell script plus the new wlc util
[00:18] <nbd> which is similar to wl, but can do all the required parameters and can also read from stdin for better shell scripting performance
[00:18] <nbd> the main logic of the driver setup process in the shell stuff
[00:18] <[mbm]> ok, but what was the point of the shell script then?
[00:19] <[mbm]> why aren't we interfacing wlc directly?
[00:19] <nbd> the shell script converts the config into driver parameters for broadcom
[00:19] <nbd> because wlc is pretty close to the wl option names
[00:19] <[mbm]> not to be annoying or anything, but "why?"
[00:20] <nbd> because i don't want to parse the config in c
[00:20] <[mbm]> seems like we could abstract things at the wlc layer and avoid a shell script
[00:20] <nbd> and i don't want to do the driver abstraction in c either
[00:20] <nbd> and wlc is useful, because it's really small and replaces wl at the same time
[00:20] <[mbm]> ok
[00:21] <nbd> and the source code is much much cleaner than the previous wificonf stuff
[00:21] <nbd> because it just uses a large table that points to generic ioctl functions for most calls
[00:21] <nbd> so a lot less code duplication
[00:22] <nbd> and for the config i'll implement it so that you can even specify the virtual interfaces in an arbitrary order and the shell script makes sure that everything gets sent to the driver in the correct order
[00:23] <nbd> so the config is going to be very intuitive
[00:24] <[mbm]> I'm still trying to hold on to the idea that the drivers can use a common ioctl scheme or that there would be a single arch specific binary
[00:25] <nbd> it's too much work to really abstract away all the unique properties of the driver
[00:25] <[mbm]> this whole concept of a generic wifi uril that calls an arch specific script which calls an arch specific binaries .. just seems like a mess
[00:25] <nbd> because the broadcom driver is really a lot less flexible than madwifi
[00:25] <[mbm]> yeah I know
[00:25] <nbd> and you have to be really careful to specify everything in the right order
[00:25] <nbd> even more than with the older driver
[00:25] <nbd> so the abstraction really happens at the shell code level
[00:26] <[mbm]> I'm not saying I have any better ideas, I'm just saying that it's still a hack
[00:26] <nbd> and why arch specific scripts?
[00:26] <nbd> driver specific scripts are much better
[00:26] <[mbm]> er, whatever .. meant the same thing
[00:26] <nbd> waht i don't see is why it has to be binary?
[00:27] <[mbm]> I don't, I just want to see less layers
[00:27] <nbd> there aren't that many layers. for most drivers the shell code interfaces directly with the native setup utilities
[00:27] <nbd> only on broadcom there is the need of an extra binary utility to set things up
[00:28] <[mbm]> ok
[00:28] <nbd> for wifi itself we can also define common shell functions that handle iwconfig based stuff and reuse them from the madwifi/whatever-specific stuff
[00:28] <nbd> so everything that can be shared, will be
[00:29] <CIA-4> mbm * r4015 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/patches/202-mips-freestanding.patch: reintroduce the -ffreestanding to avoid gcc inline errors
[00:32] <[mbm]> hmm no responses to the firewall thread .. that's disapointing
[00:36] <h3sp4wn> florian: http://openwrt.vcp-springe.de/experimental/yafc-sdk.tar.bz2 - that should build on normal white russian and kamikaze I will update it for buildroot-ng once I can get a build to complete
[00:37] <[mbm]> http://seclists.org/lists/nmap-dev/2006/Jan-Mar/0111.html
[00:38] <nbd> :)
[00:39] <[mbm]> I'm still amused at how popular that tip is .. it only appeared once on an old linux.com article and now everyone is using it
[00:40] <nbd> hmm... if i continue at this rate, i might actually get the broadcom stuff running today
[00:52] <{Nico}> MODULE_PARM is gone in 2.6.17, how do we deal with that for external kernel drivers?
[00:52] <{Nico}> should we patch-em-all?
[00:52] <{Nico}> or re-add MODULE_PARM until all drivers have been updated?
[00:52] <nbd> patch-em-all
[00:52] <nbd> imho
[00:52] <nbd> we can send the patches to the authors then
[00:53] <nbd> we don't have that many externally compiled drivers, do we?
[00:54] <{Nico}> nbd: did you see what i did for kmod-switch?
[00:54] <nbd> yeah
[00:54] <{Nico}> is this the way to go?
[00:55] <nbd> i think the kernel version to check for could be changed a bit
[00:56] <nbd> iirc module_parm was added a bit earlier
[00:56] <nbd> i mean module_param
[00:56] <{Nico}> btw, ipsec-tools and fuse are broken too but for other api changes i guess
[00:56] Action: nbd is currently trying to get the broadcom wifi stuff for 2.4 up and running
[00:57] <{Nico}> nbd: imho, what's important there is more MODULE_PARM death
[00:58] <nbd> yeah
[00:58] <nbd> looks good
[00:58] <{Nico}> ok, back to the dirty job
[01:11] <h3sp4wn> Is there any of the current archs which can compile at this moment or should I just wait until tommorow (buildroot-ng) I am going to try and convert some packages to the new format
[01:15] <[mbm]> you should be able to compile buildroot-ng for the brcm-2.4 platform
[01:16] <h3sp4wn> Thanks
[01:17] <h3sp4wn> mbm: appologies for the stupid question - obviously 2.6.17 only affects the 2.6 kernel
[01:18] <[mbm]> yeah, the 2.6.17 stuff is broken on many platforms
[01:18] <[mbm]> cleaning up the mess now
[01:19] <nbd> btw. i'll drop support for non-standard configurations like wpa1 with aes or mixed wpa1+wpa2
[01:19] <nbd> stuff like that is asking for trouble, anyway
[01:22] <[mbm]> ok
[01:43] <[mbm]> lmao
[01:43] <[mbm]> nice quit message, but the quotes give it away
[01:47] <nbd> yeah
[01:51] <{Nico}> [mbm], nbd: do you want the variables in "define Package/foo" indented or not?
[01:51] <nbd> yeah, let's indent them
[01:51] <nbd> with 2 spaces
[01:52] <[mbm]> yeah makes it easier to read
[01:52] <{Nico}> 'k
[01:55] <CIA-4> nico * r4016 /branches/buildroot-ng/openwrt/package/openswan/patches/102-new_module_param.patch: fix MODULE_PARM removal in 2.6.17.
[02:24] <CIA-4> mbm * r4017 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/patches/ (000-aruba.patch 002-irq.patch): fix irq handling on 2.6.17
[06:48] <CIA-4> nbd * r4018 /branches/buildroot-ng/openwrt/package/broadcom-wl/Makefile: add libbcmcrypto to the nas package
[10:28] <CIA-4> kaloz * r4019 /branches/buildroot-ng/openwrt/ (4 files in 3 dirs): be politically correct
[11:57] <CIA-4> florian * r4020 /branches/buildroot-ng/openwrt/target/linux/au1000-2.6/config: Update alchemy kernel configuration
[12:02] <CIA-4> florian * r4021 /branches/whiterussian/openwrt/package/webif/files/usr/lib/webif/form.awk: Add upload template for webif, closes #590 and definitively #525
[13:10] <florian__> Kaloz: can you resend me your brcm63xx patch against 2.6.8.1 ?
[13:20] <florian__> by mail preferably :)
[13:52] <florian__> Kaloz: ?
[13:55] <Kaloz> florian__: will send it later
[14:09] <florian__> Kaloz: ok, thank you very much
[14:10] <florian__> someone here with a buffalo WLA2-G54L can confirm that #536 can be closed ?
[14:23] <ang-st> just al ittle question about how are handled kernel patches
[14:24] <florian__> go ahead
[14:24] <ang-st> is there a kind of package to build to add one ?
[14:25] <ang-st> i mean for the buildroot script
[14:31] <florian__> no, just put your new patch into target/linux/<sub arch>/patches/
[14:34] <ang-st> ok in fact the originals patch are shipped with the buildroot script ?
[14:39] <florian__> not with the buildroot script, but they are shiped in the svn snapshot
[14:42] <florian__> I am not sure I answered your question, right ?
[14:42] <florian__> Kaloz: did you had a look at the rtl865x tarballs ?
[14:43] <ang-st> hmm the fact is if i want to automate the fecth and patch of the kernel automatically ....
[14:43] <ang-st> where should i have a look
[14:43] <ang-st> (sorry i speak english as martian cow :))
[14:44] <florian__> lol
[14:44] <florian__> I think fetching and patching of the kernel is already automatic ?
[14:45] <ang-st> yep but imagine that i would add another patch
[14:45] <ang-st> and even make it available for some friends:p
[14:46] <ang-st> moreover this patch is situated on a repository
[14:46] <ang-st> how should i do this ? :)
[14:47] <ang-st> cause i saw http://forum.openwrt.org/viewtopic.php?pid=26438 that's ok but
[14:48] <ang-st> it only work if you manually put it in /patches/ subdirs right ,
[14:48] <ang-st> ?
[14:49] <florian__> ah I see
[14:50] <florian__> why can't you put the patch in patches/ ?
[14:55] <ang-st> i can but in fact the question is how it is done for other patch
[14:56] <florian__> there is no download of patches actually
[14:57] <florian__> everything is in the buildroot
[14:57] <ang-st> ok
[14:57] <florian__> if you want to put a custom patch, you have to do it by hand
[14:57] <florian__> I know it's not really convenient, and it should not be that hard to add download functionnality before patching
[15:00] <ang-st> ok it's clear for me so now i can stop to browse source to find this :)
[15:23] <jr-> florian. about ticket 536. wla2-g54l doesn't have wan port. only 4 lan ports + wlan. switch settings are forced to defaults by cfe on every boot. i don't think openwrt should randomly change one of lan ports to wan port. especially since all ports are bridged together until S05nvram temporarily changes it.
[15:26] <florian__> jr-: ok, so what to do ?
[15:28] <jr-> depends what openwrt wishes to offer sor wla2-g54l. treat it as wan-less device that it really is or try to turn it device with wan-port with problems it causes unless you also patch cfe.
[15:30] <florian__> ok, I see what you mean
[15:36] <jr-> i have wla2-g54l in somewhere. i'll check current status of openwrt on it. nbd fixed some minor problem i had with it before rc5. i think only problems were in diag.o not controlling leds and buttons and unknown flash type that was fixed earlier.
[17:40] <CIA-4> nbd * r4022 /branches/buildroot-ng/openwrt/package/base-files/ (au1000-2.6/sbin/mount_root default/sbin/mount_root): mount /proc earlier in /sbin/mount_root
[19:50] <CIA-4> nbd * r4023 /branches/buildroot-ng/openwrt/scripts/gen_menuconfig.pl: fix for multiple dependency flags
[19:54] <CIA-4> nbd * r4024 /branches/buildroot-ng/openwrt/scripts/gen_deps.pl: more dependency fixes
[19:54] <CIA-4> nbd * r4025 /packages/net/ (5 files in 3 dirs): add chillispot
[20:13] <CIA-4> nbd * r4026 /packages/net/chillispot/Makefile: reverse the order of + and @ in chillispot depends, because package/rules.mk requires it
[20:57] <CIA-4> mbm * r4027 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/patches/203-fix_initrd_duplication.patch: annoying initrd bug introduced by 2.6.17
[22:11] <tziOm> nbd, know why portmap segfaults here (rc5)
[22:11] <nbd> no
[22:14] <[mbm]> trace it and see :P
[22:14] <tziOm> strace doesnt really give me anything useful I think...
[22:14] <tziOm> svr4_syscall() = -1 ERRNO_4090 (Unknown error 4090)
[22:15] <[mbm]> you might need gdb
[22:16] <tziOm> does it work other places?
[22:17] Action: [mbm] hasn't tried; I only run nfs as a client and I don't use portmap
[22:17] <tziOm> type portmap and check if it segfaults...
[22:18] <[mbm]> didn't I just say I don't use portmap?
[22:18] <[mbm]> I don't even have it on any of my systems
[22:25] <tziOm> yeah?
[22:32] <[mbm]> no?
[22:52] <nbd> i really need to learn more about fixing endianness bugs
[22:52] <nbd> fscking chillispot doesn't work on big-endian
[22:53] <[mbm]> lmao
[22:53] <nbd> i found a mention of two 4-bit ip headers being reversed
[22:53] <nbd> and i fixed that
[22:53] <nbd> but i have no clue about what needs to be done to the ip checksum
[22:54] <[mbm]> crc routines change depending on endian
[22:54] <[mbm]> you can't just byteswap the end result
[22:55] <nbd> i know
[22:55] <nbd> but i don't know what needs to be changed
[22:56] <[mbm]> is it a table based crc?
[22:56] <[mbm]> or did they include the polynomial?
[22:56] <nbd> no
[22:56] <nbd> let me check...
[22:57] <nbd> they just sum it up and then negate it
[22:57] <nbd> i mean invert it
[22:57] <[mbm]> ok, that's not a true crc32
[22:57] <nbd> i'll paste it
[22:58] <nbd> http://pastebin.ca/67970
[22:58] <nbd> a little bit different
[22:59] <[mbm]> ok, they're summing words at a time
[22:59] <nbd> can i just swap the words
[22:59] <nbd> and later swap the result?
[23:01] <[mbm]> well, the problem is slightly more complex than that
[23:01] <[mbm]> little endian looks like this: 1234
[23:01] <[mbm]> big endian looks like this: 4321
[23:02] <nbd> i know
[23:02] <[mbm]> that routine is adding 16bit works
[23:02] <[mbm]> so 12+34 isn't the same as 43+21
[23:02] <[mbm]> and no byteswapping of the result will fix that
[23:02] <nbd> that's why i wanted to byteswap the individual words _and_ the result
[23:02] <[mbm]> right
[23:03] <[mbm]> but before you do that check to see what it does with the results
[23:03] <[mbm]> since it would be a waste to byteswapp the crc only to byteswap it back later
[23:06] <nbd> hmm... weird... i don't get any packets from chillispot for some reason
[23:06] <nbd> it receives my dhcp request
[23:06] <nbd> and prints it on the log
[23:06] <nbd> but i don't get the reply in ethereal
[23:07] <nbd> could it be that the raw socket is dropping invalid packets?
[23:13] <florian__> nbd: probable
[23:14] <nbd> i hate this software
[23:14] <nbd> it's buggy, it's bloated
[23:14] <florian__> yeah, it's chillispot
[23:15] <nbd> i'll tell them that it's not worth fixing it
[23:15] <nbd> they should switch to a different software
[23:15] <florian__> wifidog is far better
[23:15] <nbd> is it fully compatible?
[23:15] <florian__> no, it's using a different authentication server
[23:15] <nbd> hmz
[23:15] <florian__> but it remains a captive portal
[23:18] <[mbm]> I've thought of doing one of those multiple times
[23:18] <[mbm]> (there really isn't much to it)
[23:20] <florian__> there is a lot of things where are handling that needs rewriting ;)
[23:22] <florian__> in fact, the real project we should work on
[23:23] <florian__> is the time machine
[00:00] --- Wed Jun 21 2006