[00:00] <groz> db, what part of the word 'open' is unclear
[00:00] <db90h> course, i just neutered the prereq checks
[00:00] <groz> feel free to change whatever you want
[00:00] <db90h> well it still seems silly to make me go to the trouble
[00:01] <[mbm]> db90h: no, ours actually work
[00:01] <db90h> i think i made a reasonable complaint.. but feel free to make things tedious on me if u want ;p
[00:01] <db90h> [mbm]: yea, i never had any issues with openwrt..builds as easy as pie without me working my ass off
[00:02] <db90h> course freewrt is in state of flux, so maybe it was a temporary condition
[00:02] <[mbm]> I won't say what I really think of them
[00:03] <florian__> why because this is publically logged ?
[00:03] <groz> i dont understand why folks go to all the trouble of copying something
[00:03] <groz> all they have to do, is build a 'look and feel' they want in a web interface module
[00:03] <groz> and slap it on top of openwrt
[00:03] <groz> and end up miles ahead of where they are starting with a monolithic setup
[00:03] <florian__> then we could steal there webif, and start a new project: free-webif
[00:03] <florian__> :p
[00:04] <db90h> they are actually diverging from openwrt a lot, and, trust me, a webif is not their primary concern
[00:04] <florian__> what is the primary concern ?
[00:04] <db90h> i actually bitched them out for not making webif a higher priority ;p
[00:04] <[mbm]> groz: yeah, but then it's openwrt, and not $something_else
[00:04] <[mbm]> remember the whole linux vs gnu/linux fiasco?
[00:04] <db90h> from what i have seen, they are converting a lot of the buid system to BSD style stuff.. tho I'm not a BSD person and wouldn't know BSD style stuff if I saw it
[00:05] <[mbm]> db90h: try to downplay the fact that it's a linux kernel
[00:06] <groz> mbm, the part i find interesting, most of the dev work today on openwrt is targeting 'anything but the wrt'
[00:06] <florian__> groz: that's right actually ;)
[00:07] <[mbm]> no, most of the work is done building a cross platform framework
[00:07] <florian__> I don't really think so
[00:07] <groz> yes, the framework is nicely cross platform
[00:07] <groz> and the wrt platform is 'well supported'
[00:07] <groz> so the real low level work is 'more platforms'
[00:07] <florian__> [mbm]: ah you meant cross platform system as a unique system for all devices ?
[00:08] <florian__> I thought you were talking about a cross embedded developpment system
[00:08] <[mbm]> florian__: I meant a framework which can be used to build for multiple devices
[00:08] <[mbm]> build system itself only really runs on linux
[00:09] <florian__> right, but independently from the archs I have tested : x86, amd64, ppc, sparc64, it just works great on linux
[00:09] <florian__> I would like to make it run on osx anyway ;)
[00:09] <groz> not sure it would be terribly useful targetting a non linux setup either
[00:09] <florian__> bsd/osx is interesting
[00:09] <groz> i may be wrong
[00:09] <[mbm]> groz: I have a feeling that if anyone actually cared they'd have either filed a bug report or sent in a patch
[00:10] <florian__> I remember seeing almost 2 years ago a freebsd patch
[00:10] <[mbm]> I have yet to recieve either
[00:10] <groz> i have (for now) no interest/need to go non linux
[00:10] <groz> but it's an interesting possibility
[00:10] <groz> maybe some day
[00:10] <florian__> yes, when we will have time ;)
[00:10] <florian__> I just wonder if I won't take a year doing oss stuff
[00:11] <[mbm]> really I figured by now that openwrt would be established as a platform and some other party would have put a ancy webif on it
[00:11] <[mbm]> I'm surprised that hasn't happened
[00:11] <groz> i think most that are interested in the fancy webif
[00:11] <groz> are drag and drop gui types
[00:12] <groz> and totally intimidated by the raw nature of the basic platform
[00:12] <groz> or
[00:12] <groz> off in thier own little world trying to build '$proprietary system
[00:12] <florian__> maybe we should port webmin to openwrt ?
[00:12] <[mbm]> well, I mean my plan for openwrt was basically to build the basic framework and then let everyone else handle the porting and packaging
[00:12] <florian__> we even received patches for qt3 on openwrt !
[00:13] <groz> i dont think webmin would fit, it's got to many dependancies
[00:13] <db90h> well i find a web UI easier to use, and I don't think its something that should be frowned upon
[00:13] <[mbm]> but these days it seems like almost the entire process is handled by us
[00:13] <florian__> groz: I was joking ;)
[00:13] <[mbm]> what happened to external development?
[00:14] <db90h> i would haev also expected someone to put a cool webif on openwrt
[00:14] <db90h> i wonder why nobody has
[00:14] <florian__> too complicated
[00:14] <[mbm]> there were several false starts
[00:14] <[mbm]> I've lost track of the exact number
[00:14] <florian__> if webif was written in php, you could have seen more contributions
[00:14] <db90h> yea
[00:14] <florian__> because awk is not exactly a web language ;)
[00:15] <[mbm]> some wanted to write a c program, others wanted to do it in things like php where the scripting language ate almost the entire flash
[00:15] <db90h> but hell, they can forget webif if they want
[00:15] <florian__> there are not perfect languages for interfaces
[00:15] <[mbm]> well, the closest thing to perfect would be a c app
[00:16] <[mbm]> but that makes it really hard to extend
[00:16] <florian__> yeah, fast enough
[00:16] <db90h> this is the approach of dd-wrt from what i've seen
[00:16] <florian__> but it's one of the worst languages when it comes to parsing
[00:16] <groz> how about a c app with a plug in architecture
[00:16] <groz> so folks can install modules into it
[00:16] <[mbm]> groz: was wondering about that
[00:16] <db90h> that's a good idea
[00:16] <groz> then the webif module for a package, becomes part of the package
[00:16] <[mbm]> dlsym is easy enough
[00:16] <florian__> dlsym ?
[00:17] <groz> that's included only if webif is actually isntalled
[00:17] <[mbm]> florian__: man dlopen
[00:17] <florian__> ok
[00:17] <groz> and then the default for everything to downgrade to
[00:17] <groz> is just running ash scrips
[00:17] <florian__> [mbm]: thanks, I see, this is very powerful
[00:17] <[mbm]> groz: I don't think I'd go so far as to force webif modules in every package .. what if they don't have webif installed?
[00:18] <groz> part of the install process mbm, dont actually pull the webif module out and into flash, if webif isn't there
[00:18] <groz> but it can ride along in the ipk
[00:18] <florian__> also we have to take something into account, if we always change developpment tools, webif module writing, this will discourage people from writing and porting applications
[00:18] <[mbm]> much easier to start a new set of webif-foobar packages that will depend on foobar
[00:18] <groz> just not end up installed
[00:18] <groz> well, that would work too
[00:19] <groz> so installing the webif module, drags along the package
[00:19] <[mbm]> right
[00:19] <db90h> i like it
[00:19] <[mbm]> (with the exception that ipkg is horribly broken and you can't expect it to work quite that easily)
[00:20] <florian__> we can use busybox's dpkg if needed
[00:20] <[mbm]> somebody is going to have to walk through the ipkg code at some point and fix the dependancy handling
[00:20] <[mbm]> florian__: more overhead
[00:20] <[mbm]> .. ipkg chokes when multiple versions of the same package are available
[00:20] <groz> mbm what would you consider a reasonable flash budget for the core of a webif, sans any modules plugged in
[00:20] <db90h> ipkg's dependency handling is broken or insufficient?
[00:21] <db90h> oh, i see
[00:21] <florian__> db90h: insufficient and broken
[00:21] <[mbm]> db90h: let's say I get clever and I make packages model-* and preinstall them in the firmware
[00:21] <db90h> he answered before i asked
[00:21] <[mbm]> so I make a model-linksys and a model-asus
[00:22] <[mbm]> package doesn't actually contain anything, it's just there as a meta package -- for the sake of being a dependancy
[00:22] <[mbm]> now, I go and I make a new package called foobar
[00:22] <[mbm]> I make multiple versions of the foobar package, one which depends on model-linksys and one that depends on model-asus
[00:23] <[mbm]> the idea being that if I say "ipkg install foobar" I get the correct one for my machine
[00:23] <db90h> makes sense
[00:23] <[mbm]> sounds great in theory, but ipkg just absolutely chokes on it
[00:23] <groz> with the current ipkg you would have to make foobar-linksys and foobar-asus
[00:23] <db90h> hmm
[00:23] <[mbm]> it can't handle the fact that there are two conflicting packages that have the same name
[00:24] <[mbm]> another similar example -
[00:24] <[mbm]> I make a package called kernel and preinstall it in the firmware
[00:24] <[mbm]> the kernel package has it's version set to things like 2.4.30 and 2.6.17
[00:25] <[mbm]> now, I want to make multiple packages with kmod-foobar
[00:25] <[mbm]> which depend on kernel=2.4.30 and kernel=2.6.17
[00:25] <[mbm]> again, ipkg breaks
[00:25] <[mbm]> it can't handle dependancies with version numbers
[00:25] <groz> here is a way around that, that i've used before
[00:25] <[mbm]> and it can't handle packages with overlapping names
[00:25] <groz> keep multiple package trees available
[00:25] <groz> one for each kernel setup etc
[00:26] <groz> then you actually switch the package source
[00:26] <groz> depending on the setup you want
[00:26] <groz> sooooo
[00:26] <[mbm]> groz: yeah, I know there are ways around it .. but that's dismissing the fact that there are bugs in ipkg
[00:26] <groz> one package tree for kernel 2.6
[00:26] <groz> another for 2.4
[00:26] <groz> not dismissing, it's working with it
[00:26] <[mbm]> we shouldn't need workarounds
[00:26] <groz> and finding a way to get the job done
[00:26] <[mbm]> and the more effort you invest in a workaround the less inclined anyone is to actually fix the original bug
[00:27] <db90h> hehe, 'working with it' is the best spin i've ever heard for 'work around' ;)
[00:27] <groz> welll db, take for example broken radio drivers, and no way to fix them
[00:27] <groz> you find work arounds
[00:27] <groz> it's working with what you got
[00:27] <groz> to find a solution
[00:28] <[mbm]> groz: yeah, but that was when we couldn't do anything but .. in the case of ipkg we actually have sources and we can fix it
[00:28] <db90h> oh yea, i do it all the time, the question is always which is the best thing to do in your particular situation: fix the problem or work around it
[00:28] <[mbm]> provided we get someone with a big ass knife to cut through the crap that's the ipkg source
[00:28] <groz> that answer is trivial db90, when you dont have sources, and cant fix it , you work around
[00:30] <db90h> well there's time, difficulty, and cost questions too.. in some worlds anyway ;p
[00:30] <db90h> oh, and don't forget laziness ;p
[00:35] <florian__> lol
[00:58] <florian__> humm, I am about to make the flash being detected by the brcm63xx ...
[01:01] <db90h> mbm: i'm reading these broadcom reference docs, in relation to our micro library stripping discussion yesterdy.. it's not just symbol name, apparently the optimal way is to scan for what objects are actually used in uclibc and relink the library
[01:01] <db90h> this is a great idea for static configurations
[01:01] <db90h> i'm going to try to implement it for openwrt, just for my own static micro builds
[01:02] <db90h> it shouldn't take too long, i think i've got the best way to integrate it mapped out
[01:02] <db90h> i just didn't know until now people who i heard 'unused symbol stripping' from were talking about the actual objects from the runtime lib (or maybe they weren't)
[03:31] <db90h> does anyone have a CFE image for Belkin 723x-4?
[10:33] <florian__> wrt: my friend
[10:59] <florian__> nbd: how did you manage to put rb532 support in openwrt ?
[11:04] <nbd> florian__: ?
[11:04] <florian__> nbd: forget my question :)
[11:04] <florian__> I ignored there was full sources for the board
[11:04] <florian__> I thought it was like broadcom boards where you have to grab parts from tarballs and tarballs
[11:05] <nbd> well, we grabbed parts of the generic idt board support for linux 2.6 and parts of the very hackish routerboard patch for linux 2.4
[11:07] <florian__> how stable is it ?
[11:08] <nbd> well, at the moment it has a weird problem with the block2mtd hacks that i wrote
[11:08] <nbd> but before it had that problem, everything except for ethernet ports on the rb564 daughterboard was stable
[11:10] <florian__> and what about wifi ?
[11:11] <nbd> it doesn't come with wifi cards. i tried atheros and it worked well
[11:15] <florian__> ah great
[11:19] <florian__> I found interesting code to handle both CFE/Redboot on the brcm63xx
[11:19] <florian__> I even wonder how it booted before :)
[11:31] <florian__> nbd: do you know when argc, argv are passed to a board specific prom_init code ?
[11:31] <florian__> usually it is prom_init(void)
[11:31] <florian__> but for the brcm63xx, I need a way to find which bootloader it is
[11:32] <nbd> i think it depends on the boot loader
[11:32] <nbd> i don't know
[11:33] <florian__> ok
[11:35] <florian__> nbd: the physmap code crashes here : http://pastebin.ca/104873
[11:35] <nbd> simple null pointer dereference
[11:36] <nbd> add some printk stuff to see in which line it crashes, then it's easy
[11:36] <nbd> " mymtd is : 00000000"
[11:36] <nbd> what's that?
[11:37] <florian__> I don't know
[11:37] <florian__> should be a pointer address
[11:37] <nbd> look into this one
[11:37] <nbd> it might be the bad pointer
[11:37] <florian__> ok, In fact, the "probing for .." is what I added
[11:39] <florian__> I have to go, will see that later
[11:40] <malbon> florian__: did you look at the sa1100-flash driver?
[11:40] <florian__> malbon: yes I did, but it did not help
[11:41] <florian__> I prefer trying to use the existing flash implementation for the livebox because it is able to distinct the bootloaders
[11:41] <malbon> that's fair enough.
[11:42] <florian__> later I think we could clean up the brcm63xx specific code in order to add it to the existing bcm47xx with some specific part
[11:42] <florian__> for the moment, it's crappy, I know it, but I rather would like to make things working, before cleaning
[11:51] <nbd> i don't think we should add bcm63xx to bcm47xx
[11:51] <nbd> imho bcm63xx is not similar to bcm47xx at all
[11:53] <florian__> maybe some code can be shared ?
[11:53] <nbd> which parts?
[11:53] <florian__> flash mapping maybe ?
[11:53] <florian__> or everything that is dependant from CFE, but maybe not
[11:54] <nbd> flash mapping can't be shared
[11:54] <nbd> since bcm47xx uses trx and bcm63xx is device specific
[11:54] <florian__> right
[11:54] <florian__> then, I really don't know
[11:55] <florian__> board init is different by nature
[11:55] <florian__> maybe b44
[13:30] <CIA-17> nbd * r4318 /branches/buildroot-ng/openwrt/ (6 files in 4 dirs): add support for per-package prereq checks, run global prereq checks before (menu-)config
[13:30] <CIA-17> nbd * r4319 /packages/libs/popt/Makefile: check for gettext in the popt package
[13:36] <nbd> hmm... that's nice. i just noticed how easy it is to add extensions to the buildroot-ng package format without breaking compatibility
[13:37] <wbx> fetching some nice ideas from us ;)
[13:37] <nbd> yeah, but implementing them in a less hackish way
[13:38] <nbd> but actually the prereq check idea was being discussed even before freewrt started
[13:39] <wbx> idea sharing is good, i don't see any hackish way.
[13:39] <nbd> the thing i didn't like is that you keep all the package prereqs in a single file
[13:39] <nbd> instead of in the package makefile
[13:40] <nbd> and you have a bit of redundant shell code that you might want to get rid of
[13:40] <nbd> but i agree. idea sharing is useful
[13:51] <groz> idea sharing is useful, but, if you have stuff to contribute, would be a heck of a lot more useful to just contribute it back into the build system rather than squirel it away somewhere else
[13:54] <nbd> groz: but that's a bit problematic if there are lots of issues with (lack of) communication between certain developers combined with disagreements on what should be in the repository
[13:54] <wbx> groz: we have different design goals.
[13:55] Action: nbd admits that he still doesn't know much about what exactly the design goals of freewrt are except for 'builds on bsd'
[13:55] <groz> i just took a look at it nbd, doesn't build on bsd
[13:55] <groz> it's a reconfigured openwrt
[13:56] <nbd> it builds on some bsd variants
[13:56] <groz> it 'builds on bsd' when it's booting a bsd kernel on the target device
[13:57] <nbd> ok, then: s/builds on bsd/compiles on bsd/
[13:57] <groz> lol
[14:01] <wbx> nbd: yeah, because you are very ignorant ;P
[14:01] <nbd> thank you for your insight
[14:01] <wbx> nbd: i have no idea what openwrt is for.
[14:02] <nbd> are you serious or do you want to flame us?
[14:03] <wbx> may be both. i can't use openwrt for a system where I need high security, because I can not update it remotely without configuration loss.
[14:03] <wbx> do you ever had customers in costa rica and south africa? you want be able to remotely update 10 or more routers..
[14:04] <nbd> well, it's obviously not done yet
[14:04] <groz> wbx, I have 1800 of them out there, and no problem updating without configuration losses
[14:05] <groz> later next week i've got an upgrade gonna go on about a thousand
[14:05] <nbd> wbx: please don't interpret everything that i say as a trolling attempt, just because i disagree with the way freewrt got started
[14:07] <wbx> groz: with OpenWrt? without local hacks? i don't think so.
[14:08] <groz> obviusly i've put some effort into making it wok
[14:08] <groz> work
[14:08] <wbx> and why you do not integrate it back to openrt, so that others can use it?
[14:08] <wbx> 13:43 < groz> idea sharing is useful, but, if you have stuff to contribute, would
[14:09] <wbx> be a heck of a lot more useful to just contribute it back into the
[14:09] <groz> i disappeared from this project for over a year for a number of reasons
[14:09] <wbx> build system rather than squirel it away somewhere else
[14:09] <groz> but if you take a look at the current status
[14:09] <groz> you'll see i am putting the stuff back
[14:10] <groz> one of the main reasons i found other thigns to do, got kinda tired of watching other folks check all the hard work out of cvs
[14:10] <groz> change a few scripts
[14:10] <groz> put a different look on a couple things
[14:10] <groz> and call it thier own work
[14:10] <groz> some even have the audacity to sell it
[14:10] <groz> and contribute nothing back
[14:11] <wbx> i think you did not understand open source.
[14:12] <groz> open source works when it's a 2 way street
[14:14] <wbx> do you think openwrt and fon is 2 way?
[14:14] <nbd> actually it is
[14:14] <groz> time will tell
[14:15] <groz> but it is my understanding that there is a significant amount of exchange
[14:16] <wbx> strange that no QoS scripts are integrated into OpenWrt.
[14:16] <nbd> quite a few things that i wrote for openwrt were actually paid for by fon
[14:16] <nbd> and appeared in openwrt first
[14:17] <nbd> the scripts are there, they're just not in the repository yet
[14:17] <nbd> because i don't consider them 'done' yet
[14:17] <nbd> but anyone can install and test them
[14:21] <wbx> anyone who is able too. i don't think there are a lot people out there are able to do it.
[14:22] <nbd> it's just one ipkg install line
[14:22] <nbd> and it's even documented in the wiki
[14:22] <nbd> and usually it's as simple as running that ipkg install line, editing the config file and setting the linespeed
[14:23] <groz> and if you need to deploy 'preconfigured' its as easy as incorporating that into the setup for image builder
[14:23] <nbd> yes
[14:23] <nbd> well, almost
[14:24] <nbd> at the moment you still need to manually resolve the dependencies
[14:24] <nbd> i'm still thinking about ways to fix this properly
[14:24] <nbd> not that easy
[15:50] <db90h> nbd, i've been reading this broadcom reference manual and i think i've misunderstood what brainslayer and you said by 'symbol stripping' all this time.. it suggests actually relinking the runtime library (usually uclibc) so that unused objects are removed. Is this seperate from the symbol stripping you guys have talked about, or is this what you were referring to?
[15:51] <db90h> i plan to implement this for openwrt, since i have a need to build small static configurations of it.. i plan to delay sstrip calls until the end of the process, probably lamely through creating an sstrip proxy that records calls to sstrip and invokes them prior to compressing/packaging the filesystem
[15:54] <db90h> either that or i'll just sstrip every ELF in the filesystem, same deal as doing a proxy probably.. tho if there are any that shouldn't be sstrip'd for some reason, i'll have to exclude them of course
[15:58] <db90h> i'm not sure if there are any cases that might complicate this procedure, i.e. an one function of uclibc depending on another exposed function of uclibc, and how easily this can be detected.. but it can be done for sure
[18:37] <nbd> groz: ping
[18:45] <nbd> db90h: i think the building process can be changed so that it will both remove unused functions and sstrip the binaries before creating the packages
[18:46] <nbd> db90h: with buildroot-ng
[18:46] <nbd> in whiterussian or trunk it's probably a lot more difficult to implement in a clean way
[18:46] <nbd> at least if you don't want to modify every single package :)
[18:55] <db90h> nbd: i had the thought of doing it simply by replacing sstrip with a tool that records every attempt.. then at the end of build, after we've pruned the runtime lib, then go and sstrip all the queued requests (with path adjustments, we'll find them in the fs)
[18:57] <db90h> it's kinda cheating, but it should work i think ;)
[18:58] <db90h> i gotta get up to speed on my shell scripting to mess with this tho.. i'm more inclined to write tools in C to do everything as it's more famliar to me ;p
[19:03] <db90h> should be all sriptable tho, sstrip-queue easy script, then i'll just tweak these existing optimize_lib.sh scripts to avoid any real work getting more into shell scripting ;p
[19:07] <db90h> does buildroot-ng currently produce builds usable and stable? cuz i'd love to start working with it, but i am being selfish in that i want whatever i do to be immediately useful to me
[19:08] <db90h> it's a shame the stable bran and the trunk, nevermind build-root ng are so different, it makes it difficult to develop for both
[19:09] <db90h> tho in this case this change should be portable to trunk with ease
[19:23] <malbon> db90h: why don't you just develop for buildroot-ng which is the future? the other trees are limited life.
[19:23] <db90h> are current buildroot-ng produced builds stable enough for me to actually put into use?
[19:24] <db90h> i mean, home use.. i don't need them rock solid.. just fully functional
[19:28] <db90h> ?
[19:28] <nbd> usually buildroot-ng works
[19:28] <nbd> sometimes it breaks
[19:28] <nbd> but most of the time it should work
[19:30] <db90h> i'll give it a try
[19:30] <db90h> i missed webif
[19:31] <db90h> but i should be able to port it easily, right?
[19:31] <db90h> just move the package will work?
[19:31] <nbd> it's not that wasy
[19:31] <nbd> easy
[19:31] <db90h> shit
[19:31] <nbd> because buildroot-ng does not use nvram
[19:33] <db90h> white russian is just closer to what i want i think.. there are a lot of updates it needs (squashfs 3.0, newest lzma, and much more).. but it procduces images more useful to me atm.. when buildroot-ng progresses enough, i'll work with it
[19:34] <db90h> i have too much left to learn to make any great contributions to openwrt anyway i think, best i just fool around with whatever
[19:57] <CIA-17> nbd * r4320 /branches/buildroot-ng/openwrt/target/linux/rb532-2.6/patches/100-rb5xx_support.patch: bugfix for the rb532 block2mtd code
[20:08] <groz> nbd ping
[20:08] <nbd> pong
[20:08] <groz> you pinged earlier, after i went to bed
[20:08] <nbd> groz: can you test broadcom-wl again? i have a potential workaround
[20:08] <groz> i can, it'll be an hour or two
[20:08] <db90h> for the google issue?
[20:08] <nbd> groz: try wlc wme 0 after the thing is up
[20:09] <nbd> yes
[20:09] <groz> i have a couple little things i need to do this morning before i can rebuild/reflash a wrt
[20:09] <nbd> ok
[20:09] <groz> lemme make a call, maybe i can put it off an hour or two
[20:09] <groz> do the wrt right now
[20:09] <nbd> there were some reports that said disabling wmm 'fixes' the google issue
[20:09] <groz> hang on
[20:17] <groz> nbd, do i need to svn up to get some changes/patches, or just do the wlc wme 0 to what i've got from a couple days ago ?
[20:17] <nbd> just use the old one
[20:20] <groz> that would be very nice if that works
[20:21] <groz> got a build running, will be flashing in a few minutes
[20:27] <groz> nbd, got another question for ya, also another wl issue
[20:27] <groz> but a different one
[20:27] <groz> i've got a test setup works like this
[20:28] <groz> 4 wrts set up, all wds to each other, so each has 3 wds connections, all bridged
[20:28] <groz> one of them has an internet connection
[20:28] <groz> i run a test program on all fo them, basically it sends a raw eithernet packet out specific wds connections
[20:28] <groz> then it's listening for raw packets of that protocol as well
[20:29] <groz> I compare the source address in the ethernet header with the actual source which is placed in the raw packet
[20:29] <groz> and about 5% of the packets traversing wds links actually pop out of the bridge on the wrong unit
[20:29] <groz> the source address in the ethernet frame does not match that in the packet itself
[20:30] <groz> I repeat this test with cables in place, so all the data skips passing thru the wireless
[20:30] <groz> and it runs flawlessly
[20:30] <groz> so it seems wl is messing with ethernet source address on wds frames
[20:30] <groz> but it's definitely random, and 'occaisional'
[20:30] <groz> so far, every variant of wl i've messed with has this problem
[20:31] <groz> does this ring any bells or would you have any unique insight on that ?
[20:40] <nbd> groz: i've never seen this before
[20:41] <groz> ok, just curious, i've tested it with wl drivers from various sources
[20:41] <groz> and always the same result
[20:42] <groz> i haven't actually done a lot of testing with the current wl in -ng because the google issue was a show stopper
[20:47] <murb> i'm curious if anyone has tried the new bcm43xx reverse engineered driver?
[20:48] <groz> it's in my plan murb, but i haven't gotten there
[21:59] <CIA-17> nbd * r4321 /branches/buildroot-ng/openwrt/package/base-files/default/etc/functions.sh: fix unnamed config sections
[22:25] <CIA-17> nbd * r4322 /branches/buildroot-ng/openwrt/package/base-files/default/etc/functions.sh: avoid using a reserved word as a variable name
[22:29] <groz> nbd ping
[22:30] <nbd> pong
[22:30] <groz> ok, i build a stock image from scratch
[22:30] <groz> got it so it'll come up, access point, and i can go anywhere but google
[22:30] <nbd> now try wlc wme 0
[22:30] <groz> then wlc wme 0 fails, so i wlc down
[22:30] <groz> then wlc wme 0
[22:30] <groz> wlc up
[22:31] <groz> iwconfig wl0 mode master essid xxxx
[22:31] <groz> is this correct ?
[22:31] <groz> it's now showing beacons again
[22:31] <nbd> don't use iwconfig
[22:31] <groz> well if i go wlc up at that point
[22:31] <nbd> just wlc down wme 0 up
[22:31] <groz> it's not beaconging anymore
[22:31] <nbd> oh
[22:31] <groz> actually
[22:31] <groz> when it starts up
[22:31] <nbd> then try wlc down wme 0 up ssid xxxx
[22:31] <groz> if i dont do iwconfg up
[22:31] <groz> then i dont get beacons either
[22:32] <groz> ok, i'll try using _just_ wlc
[22:32] <groz> he real issue i got, after i wme 0
[22:32] <groz> then iwconfig
[22:32] <groz> shortly after it resets
[22:33] <nbd> wlcompat hasn't been updated for the new driver yet
[22:33] <groz> ok up ssid with wlc seems to bring it back
[22:33] <groz> so i'll just use wlc
[22:33] <groz> stand by
[22:34] <groz> using nokia 770 as the client, doing before and after tests now
[22:41] <groz> ok, still no joy
[22:42] <groz> wme is zero
[22:42] <groz> loading other sites
[22:42] <groz> not loading google
[22:46] <murb> do ssled http connections also not work?
[22:47] <groz> you mean any old ssl
[22:47] <groz> or some site specifically ?
[22:47] <murb> yeah.
[22:47] <groz> lemme check
[22:47] <murb> i had can't ssh or ssl to some sites issue with wireless some time ago
[22:47] <murb> but it wasn't a wl based thing.
[22:48] <groz> just got the login https page fine from my bank
[22:49] <groz> so ssl does appear to work
[22:51] <groz> ok, here's an interesting one
[22:51] <groz> https://www.google.com sends a redirect to http
[22:51] <groz> i got the redirect
[22:52] <groz> typed in https, now it's stuck trying to load http
[23:01] <murb> does http://www.google.de work?
[23:02] <groz> no, neither does .ca
[23:02] <groz> BUT
[23:02] <groz> if i got to google.com here
[23:02] <groz> they do redirect me to google.ca
[00:00] --- Sun Jul 30 2006
[00:00] <db90h> course, i just neutered the prereq checks
[00:00] <groz> feel free to change whatever you want
[00:00] <db90h> well it still seems silly to make me go to the trouble
[00:01] <[mbm]> db90h: no, ours actually work
[00:01] <db90h> i think i made a reasonable complaint.. but feel free to make things tedious on me if u want ;p
[00:01] <db90h> [mbm]: yea, i never had any issues with openwrt..builds as easy as pie without me working my ass off
[00:02] <db90h> course freewrt is in state of flux, so maybe it was a temporary condition
[00:02] <[mbm]> I won't say what I really think of them
[00:03] <florian__> why because this is publically logged ?
[00:03] <groz> i dont understand why folks go to all the trouble of copying something
[00:03] <groz> all they have to do, is build a 'look and feel' they want in a web interface module
[00:03] <groz> and slap it on top of openwrt
[00:03] <groz> and end up miles ahead of where they are starting with a monolithic setup
[00:03] <florian__> then we could steal there webif, and start a new project: free-webif
[00:03] <florian__> :p
[00:04] <db90h> they are actually diverging from openwrt a lot, and, trust me, a webif is not their primary concern
[00:04] <florian__> what is the primary concern ?
[00:04] <db90h> i actually bitched them out for not making webif a higher priority ;p
[00:04] <[mbm]> groz: yeah, but then it's openwrt, and not $something_else
[00:04] <[mbm]> remember the whole linux vs gnu/linux fiasco?
[00:04] <db90h> from what i have seen, they are converting a lot of the buid system to BSD style stuff.. tho I'm not a BSD person and wouldn't know BSD style stuff if I saw it
[00:05] <[mbm]> db90h: try to downplay the fact that it's a linux kernel
[00:06] <groz> mbm, the part i find interesting, most of the dev work today on openwrt is targeting 'anything but the wrt'
[00:06] <florian__> groz: that's right actually ;)
[00:07] <[mbm]> no, most of the work is done building a cross platform framework
[00:07] <florian__> I don't really think so
[00:07] <groz> yes, the framework is nicely cross platform
[00:07] <groz> and the wrt platform is 'well supported'
[00:07] <groz> so the real low level work is 'more platforms'
[00:07] <florian__> [mbm]: ah you meant cross platform system as a unique system for all devices ?
[00:08] <florian__> I thought you were talking about a cross embedded developpment system
[00:08] <[mbm]> florian__: I meant a framework which can be used to build for multiple devices
[00:08] <[mbm]> build system itself only really runs on linux
[00:09] <florian__> right, but independently from the archs I have tested : x86, amd64, ppc, sparc64, it just works great on linux
[00:09] <florian__> I would like to make it run on osx anyway ;)
[00:09] <groz> not sure it would be terribly useful targetting a non linux setup either
[00:09] <florian__> bsd/osx is interesting
[00:09] <groz> i may be wrong
[00:09] <[mbm]> groz: I have a feeling that if anyone actually cared they'd have either filed a bug report or sent in a patch
[00:10] <florian__> I remember seeing almost 2 years ago a freebsd patch
[00:10] <[mbm]> I have yet to recieve either
[00:10] <groz> i have (for now) no interest/need to go non linux
[00:10] <groz> but it's an interesting possibility
[00:10] <groz> maybe some day
[00:10] <florian__> yes, when we will have time ;)
[00:10] <florian__> I just wonder if I won't take a year doing oss stuff
[00:11] <[mbm]> really I figured by now that openwrt would be established as a platform and some other party would have put a ancy webif on it
[00:11] <[mbm]> I'm surprised that hasn't happened
[00:11] <groz> i think most that are interested in the fancy webif
[00:11] <groz> are drag and drop gui types
[00:12] <groz> and totally intimidated by the raw nature of the basic platform
[00:12] <groz> or
[00:12] <groz> off in thier own little world trying to build '$proprietary system
[00:12] <florian__> maybe we should port webmin to openwrt ?
[00:12] <[mbm]> well, I mean my plan for openwrt was basically to build the basic framework and then let everyone else handle the porting and packaging
[00:12] <florian__> we even received patches for qt3 on openwrt !
[00:13] <groz> i dont think webmin would fit, it's got to many dependancies
[00:13] <db90h> well i find a web UI easier to use, and I don't think its something that should be frowned upon
[00:13] <[mbm]> but these days it seems like almost the entire process is handled by us
[00:13] <florian__> groz: I was joking ;)
[00:13] <[mbm]> what happened to external development?
[00:14] <db90h> i would haev also expected someone to put a cool webif on openwrt
[00:14] <db90h> i wonder why nobody has
[00:14] <florian__> too complicated
[00:14] <[mbm]> there were several false starts
[00:14] <[mbm]> I've lost track of the exact number
[00:14] <florian__> if webif was written in php, you could have seen more contributions
[00:14] <db90h> yea
[00:14] <florian__> because awk is not exactly a web language ;)
[00:15] <[mbm]> some wanted to write a c program, others wanted to do it in things like php where the scripting language ate almost the entire flash
[00:15] <db90h> but hell, they can forget webif if they want
[00:15] <florian__> there are not perfect languages for interfaces
[00:15] <[mbm]> well, the closest thing to perfect would be a c app
[00:16] <[mbm]> but that makes it really hard to extend
[00:16] <florian__> yeah, fast enough
[00:16] <db90h> this is the approach of dd-wrt from what i've seen
[00:16] <florian__> but it's one of the worst languages when it comes to parsing
[00:16] <groz> how about a c app with a plug in architecture
[00:16] <groz> so folks can install modules into it
[00:16] <[mbm]> groz: was wondering about that
[00:16] <db90h> that's a good idea
[00:16] <groz> then the webif module for a package, becomes part of the package
[00:16] <[mbm]> dlsym is easy enough
[00:16] <florian__> dlsym ?
[00:17] <groz> that's included only if webif is actually isntalled
[00:17] <[mbm]> florian__: man dlopen
[00:17] <florian__> ok
[00:17] <groz> and then the default for everything to downgrade to
[00:17] <groz> is just running ash scrips
[00:17] <florian__> [mbm]: thanks, I see, this is very powerful
[00:17] <[mbm]> groz: I don't think I'd go so far as to force webif modules in every package .. what if they don't have webif installed?
[00:18] <groz> part of the install process mbm, dont actually pull the webif module out and into flash, if webif isn't there
[00:18] <groz> but it can ride along in the ipk
[00:18] <florian__> also we have to take something into account, if we always change developpment tools, webif module writing, this will discourage people from writing and porting applications
[00:18] <[mbm]> much easier to start a new set of webif-foobar packages that will depend on foobar
[00:18] <groz> just not end up installed
[00:18] <groz> well, that would work too
[00:19] <groz> so installing the webif module, drags along the package
[00:19] <[mbm]> right
[00:19] <db90h> i like it
[00:19] <[mbm]> (with the exception that ipkg is horribly broken and you can't expect it to work quite that easily)
[00:20] <florian__> we can use busybox's dpkg if needed
[00:20] <[mbm]> somebody is going to have to walk through the ipkg code at some point and fix the dependancy handling
[00:20] <[mbm]> florian__: more overhead
[00:20] <[mbm]> .. ipkg chokes when multiple versions of the same package are available
[00:20] <groz> mbm what would you consider a reasonable flash budget for the core of a webif, sans any modules plugged in
[00:20] <db90h> ipkg's dependency handling is broken or insufficient?
[00:21] <db90h> oh, i see
[00:21] <florian__> db90h: insufficient and broken
[00:21] <[mbm]> db90h: let's say I get clever and I make packages model-* and preinstall them in the firmware
[00:21] <db90h> he answered before i asked
[00:21] <[mbm]> so I make a model-linksys and a model-asus
[00:22] <[mbm]> package doesn't actually contain anything, it's just there as a meta package -- for the sake of being a dependancy
[00:22] <[mbm]> now, I go and I make a new package called foobar
[00:22] <[mbm]> I make multiple versions of the foobar package, one which depends on model-linksys and one that depends on model-asus
[00:23] <[mbm]> the idea being that if I say "ipkg install foobar" I get the correct one for my machine
[00:23] <db90h> makes sense
[00:23] <[mbm]> sounds great in theory, but ipkg just absolutely chokes on it
[00:23] <groz> with the current ipkg you would have to make foobar-linksys and foobar-asus
[00:23] <db90h> hmm
[00:23] <[mbm]> it can't handle the fact that there are two conflicting packages that have the same name
[00:24] <[mbm]> another similar example -
[00:24] <[mbm]> I make a package called kernel and preinstall it in the firmware
[00:24] <[mbm]> the kernel package has it's version set to things like 2.4.30 and 2.6.17
[00:25] <[mbm]> now, I want to make multiple packages with kmod-foobar
[00:25] <[mbm]> which depend on kernel=2.4.30 and kernel=2.6.17
[00:25] <[mbm]> again, ipkg breaks
[00:25] <[mbm]> it can't handle dependancies with version numbers
[00:25] <groz> here is a way around that, that i've used before
[00:25] <[mbm]> and it can't handle packages with overlapping names
[00:25] <groz> keep multiple package trees available
[00:25] <groz> one for each kernel setup etc
[00:26] <groz> then you actually switch the package source
[00:26] <groz> depending on the setup you want
[00:26] <groz> sooooo
[00:26] <[mbm]> groz: yeah, I know there are ways around it .. but that's dismissing the fact that there are bugs in ipkg
[00:26] <groz> one package tree for kernel 2.6
[00:26] <groz> another for 2.4
[00:26] <groz> not dismissing, it's working with it
[00:26] <[mbm]> we shouldn't need workarounds
[00:26] <groz> and finding a way to get the job done
[00:26] <[mbm]> and the more effort you invest in a workaround the less inclined anyone is to actually fix the original bug
[00:27] <db90h> hehe, 'working with it' is the best spin i've ever heard for 'work around' ;)
[00:27] <groz> welll db, take for example broken radio drivers, and no way to fix them
[00:27] <groz> you find work arounds
[00:27] <groz> it's working with what you got
[00:27] <groz> to find a solution
[00:28] <[mbm]> groz: yeah, but that was when we couldn't do anything but .. in the case of ipkg we actually have sources and we can fix it
[00:28] <db90h> oh yea, i do it all the time, the question is always which is the best thing to do in your particular situation: fix the problem or work around it
[00:28] <[mbm]> provided we get someone with a big ass knife to cut through the crap that's the ipkg source
[00:28] <groz> that answer is trivial db90, when you dont have sources, and cant fix it , you work around
[00:30] <db90h> well there's time, difficulty, and cost questions too.. in some worlds anyway ;p
[00:30] <db90h> oh, and don't forget laziness ;p
[00:35] <florian__> lol
[00:58] <florian__> humm, I am about to make the flash being detected by the brcm63xx ...
[01:01] <db90h> mbm: i'm reading these broadcom reference docs, in relation to our micro library stripping discussion yesterdy.. it's not just symbol name, apparently the optimal way is to scan for what objects are actually used in uclibc and relink the library
[01:01] <db90h> this is a great idea for static configurations
[01:01] <db90h> i'm going to try to implement it for openwrt, just for my own static micro builds
[01:02] <db90h> it shouldn't take too long, i think i've got the best way to integrate it mapped out
[01:02] <db90h> i just didn't know until now people who i heard 'unused symbol stripping' from were talking about the actual objects from the runtime lib (or maybe they weren't)
[03:31] <db90h> does anyone have a CFE image for Belkin 723x-4?
[10:33] <florian__> wrt: my friend
[10:59] <florian__> nbd: how did you manage to put rb532 support in openwrt ?
[11:04] <nbd> florian__: ?
[11:04] <florian__> nbd: forget my question :)
[11:04] <florian__> I ignored there was full sources for the board
[11:04] <florian__> I thought it was like broadcom boards where you have to grab parts from tarballs and tarballs
[11:05] <nbd> well, we grabbed parts of the generic idt board support for linux 2.6 and parts of the very hackish routerboard patch for linux 2.4
[11:07] <florian__> how stable is it ?
[11:08] <nbd> well, at the moment it has a weird problem with the block2mtd hacks that i wrote
[11:08] <nbd> but before it had that problem, everything except for ethernet ports on the rb564 daughterboard was stable
[11:10] <florian__> and what about wifi ?
[11:11] <nbd> it doesn't come with wifi cards. i tried atheros and it worked well
[11:15] <florian__> ah great
[11:19] <florian__> I found interesting code to handle both CFE/Redboot on the brcm63xx
[11:19] <florian__> I even wonder how it booted before :)
[11:31] <florian__> nbd: do you know when argc, argv are passed to a board specific prom_init code ?
[11:31] <florian__> usually it is prom_init(void)
[11:31] <florian__> but for the brcm63xx, I need a way to find which bootloader it is
[11:32] <nbd> i think it depends on the boot loader
[11:32] <nbd> i don't know
[11:33] <florian__> ok
[11:35] <florian__> nbd: the physmap code crashes here : http://pastebin.ca/104873
[11:35] <nbd> simple null pointer dereference
[11:36] <nbd> add some printk stuff to see in which line it crashes, then it's easy
[11:36] <nbd> " mymtd is : 00000000"
[11:36] <nbd> what's that?
[11:37] <florian__> I don't know
[11:37] <florian__> should be a pointer address
[11:37] <nbd> look into this one
[11:37] <nbd> it might be the bad pointer
[11:37] <florian__> ok, In fact, the "probing for .." is what I added
[11:39] <florian__> I have to go, will see that later
[11:40] <malbon> florian__: did you look at the sa1100-flash driver?
[11:40] <florian__> malbon: yes I did, but it did not help
[11:41] <florian__> I prefer trying to use the existing flash implementation for the livebox because it is able to distinct the bootloaders
[11:41] <malbon> that's fair enough.
[11:42] <florian__> later I think we could clean up the brcm63xx specific code in order to add it to the existing bcm47xx with some specific part
[11:42] <florian__> for the moment, it's crappy, I know it, but I rather would like to make things working, before cleaning
[11:51] <nbd> i don't think we should add bcm63xx to bcm47xx
[11:51] <nbd> imho bcm63xx is not similar to bcm47xx at all
[11:53] <florian__> maybe some code can be shared ?
[11:53] <nbd> which parts?
[11:53] <florian__> flash mapping maybe ?
[11:53] <florian__> or everything that is dependant from CFE, but maybe not
[11:54] <nbd> flash mapping can't be shared
[11:54] <nbd> since bcm47xx uses trx and bcm63xx is device specific
[11:54] <florian__> right
[11:54] <florian__> then, I really don't know
[11:55] <florian__> board init is different by nature
[11:55] <florian__> maybe b44
[13:30] <CIA-17> nbd * r4318 /branches/buildroot-ng/openwrt/ (6 files in 4 dirs): add support for per-package prereq checks, run global prereq checks before (menu-)config
[13:30] <CIA-17> nbd * r4319 /packages/libs/popt/Makefile: check for gettext in the popt package
[13:36] <nbd> hmm... that's nice. i just noticed how easy it is to add extensions to the buildroot-ng package format without breaking compatibility
[13:37] <wbx> fetching some nice ideas from us ;)
[13:37] <nbd> yeah, but implementing them in a less hackish way
[13:38] <nbd> but actually the prereq check idea was being discussed even before freewrt started
[13:39] <wbx> idea sharing is good, i don't see any hackish way.
[13:39] <nbd> the thing i didn't like is that you keep all the package prereqs in a single file
[13:39] <nbd> instead of in the package makefile
[13:40] <nbd> and you have a bit of redundant shell code that you might want to get rid of
[13:40] <nbd> but i agree. idea sharing is useful
[13:51] <groz> idea sharing is useful, but, if you have stuff to contribute, would be a heck of a lot more useful to just contribute it back into the build system rather than squirel it away somewhere else
[13:54] <nbd> groz: but that's a bit problematic if there are lots of issues with (lack of) communication between certain developers combined with disagreements on what should be in the repository
[13:54] <wbx> groz: we have different design goals.
[13:55] Action: nbd admits that he still doesn't know much about what exactly the design goals of freewrt are except for 'builds on bsd'
[13:55] <groz> i just took a look at it nbd, doesn't build on bsd
[13:55] <groz> it's a reconfigured openwrt
[13:56] <nbd> it builds on some bsd variants
[13:56] <groz> it 'builds on bsd' when it's booting a bsd kernel on the target device
[13:57] <nbd> ok, then: s/builds on bsd/compiles on bsd/
[13:57] <groz> lol
[14:01] <wbx> nbd: yeah, because you are very ignorant ;P
[14:01] <nbd> thank you for your insight
[14:01] <wbx> nbd: i have no idea what openwrt is for.
[14:02] <nbd> are you serious or do you want to flame us?
[14:03] <wbx> may be both. i can't use openwrt for a system where I need high security, because I can not update it remotely without configuration loss.
[14:03] <wbx> do you ever had customers in costa rica and south africa? you want be able to remotely update 10 or more routers..
[14:04] <nbd> well, it's obviously not done yet
[14:04] <groz> wbx, I have 1800 of them out there, and no problem updating without configuration losses
[14:05] <groz> later next week i've got an upgrade gonna go on about a thousand
[14:05] <nbd> wbx: please don't interpret everything that i say as a trolling attempt, just because i disagree with the way freewrt got started
[14:07] <wbx> groz: with OpenWrt? without local hacks? i don't think so.
[14:08] <groz> obviusly i've put some effort into making it wok
[14:08] <groz> work
[14:08] <wbx> and why you do not integrate it back to openrt, so that others can use it?
[14:08] <wbx> 13:43 < groz> idea sharing is useful, but, if you have stuff to contribute, would
[14:09] <wbx> be a heck of a lot more useful to just contribute it back into the
[14:09] <groz> i disappeared from this project for over a year for a number of reasons
[14:09] <wbx> build system rather than squirel it away somewhere else
[14:09] <groz> but if you take a look at the current status
[14:09] <groz> you'll see i am putting the stuff back
[14:10] <groz> one of the main reasons i found other thigns to do, got kinda tired of watching other folks check all the hard work out of cvs
[14:10] <groz> change a few scripts
[14:10] <groz> put a different look on a couple things
[14:10] <groz> and call it thier own work
[14:10] <groz> some even have the audacity to sell it
[14:10] <groz> and contribute nothing back
[14:11] <wbx> i think you did not understand open source.
[14:12] <groz> open source works when it's a 2 way street
[14:14] <wbx> do you think openwrt and fon is 2 way?
[14:14] <nbd> actually it is
[14:14] <groz> time will tell
[14:15] <groz> but it is my understanding that there is a significant amount of exchange
[14:16] <wbx> strange that no QoS scripts are integrated into OpenWrt.
[14:16] <nbd> quite a few things that i wrote for openwrt were actually paid for by fon
[14:16] <nbd> and appeared in openwrt first
[14:17] <nbd> the scripts are there, they're just not in the repository yet
[14:17] <nbd> because i don't consider them 'done' yet
[14:17] <nbd> but anyone can install and test them
[14:21] <wbx> anyone who is able too. i don't think there are a lot people out there are able to do it.
[14:22] <nbd> it's just one ipkg install line
[14:22] <nbd> and it's even documented in the wiki
[14:22] <nbd> and usually it's as simple as running that ipkg install line, editing the config file and setting the linespeed
[14:23] <groz> and if you need to deploy 'preconfigured' its as easy as incorporating that into the setup for image builder
[14:23] <nbd> yes
[14:23] <nbd> well, almost
[14:24] <nbd> at the moment you still need to manually resolve the dependencies
[14:24] <nbd> i'm still thinking about ways to fix this properly
[14:24] <nbd> not that easy
[15:50] <db90h> nbd, i've been reading this broadcom reference manual and i think i've misunderstood what brainslayer and you said by 'symbol stripping' all this time.. it suggests actually relinking the runtime library (usually uclibc) so that unused objects are removed. Is this seperate from the symbol stripping you guys have talked about, or is this what you were referring to?
[15:51] <db90h> i plan to implement this for openwrt, since i have a need to build small static configurations of it.. i plan to delay sstrip calls until the end of the process, probably lamely through creating an sstrip proxy that records calls to sstrip and invokes them prior to compressing/packaging the filesystem
[15:54] <db90h> either that or i'll just sstrip every ELF in the filesystem, same deal as doing a proxy probably.. tho if there are any that shouldn't be sstrip'd for some reason, i'll have to exclude them of course
[15:58] <db90h> i'm not sure if there are any cases that might complicate this procedure, i.e. an one function of uclibc depending on another exposed function of uclibc, and how easily this can be detected.. but it can be done for sure
[18:37] <nbd> groz: ping
[18:45] <nbd> db90h: i think the building process can be changed so that it will both remove unused functions and sstrip the binaries before creating the packages
[18:46] <nbd> db90h: with buildroot-ng
[18:46] <nbd> in whiterussian or trunk it's probably a lot more difficult to implement in a clean way
[18:46] <nbd> at least if you don't want to modify every single package :)
[18:55] <db90h> nbd: i had the thought of doing it simply by replacing sstrip with a tool that records every attempt.. then at the end of build, after we've pruned the runtime lib, then go and sstrip all the queued requests (with path adjustments, we'll find them in the fs)
[18:57] <db90h> it's kinda cheating, but it should work i think ;)
[18:58] <db90h> i gotta get up to speed on my shell scripting to mess with this tho.. i'm more inclined to write tools in C to do everything as it's more famliar to me ;p
[19:03] <db90h> should be all sriptable tho, sstrip-queue easy script, then i'll just tweak these existing optimize_lib.sh scripts to avoid any real work getting more into shell scripting ;p
[19:07] <db90h> does buildroot-ng currently produce builds usable and stable? cuz i'd love to start working with it, but i am being selfish in that i want whatever i do to be immediately useful to me
[19:08] <db90h> it's a shame the stable bran and the trunk, nevermind build-root ng are so different, it makes it difficult to develop for both
[19:09] <db90h> tho in this case this change should be portable to trunk with ease
[19:23] <malbon> db90h: why don't you just develop for buildroot-ng which is the future? the other trees are limited life.
[19:23] <db90h> are current buildroot-ng produced builds stable enough for me to actually put into use?
[19:24] <db90h> i mean, home use.. i don't need them rock solid.. just fully functional
[19:28] <db90h> ?
[19:28] <nbd> usually buildroot-ng works
[19:28] <nbd> sometimes it breaks
[19:28] <nbd> but most of the time it should work
[19:30] <db90h> i'll give it a try
[19:30] <db90h> i missed webif
[19:31] <db90h> but i should be able to port it easily, right?
[19:31] <db90h> just move the package will work?
[19:31] <nbd> it's not that wasy
[19:31] <nbd> easy
[19:31] <db90h> shit
[19:31] <nbd> because buildroot-ng does not use nvram
[19:33] <db90h> white russian is just closer to what i want i think.. there are a lot of updates it needs (squashfs 3.0, newest lzma, and much more).. but it procduces images more useful to me atm.. when buildroot-ng progresses enough, i'll work with it
[19:34] <db90h> i have too much left to learn to make any great contributions to openwrt anyway i think, best i just fool around with whatever
[19:57] <CIA-17> nbd * r4320 /branches/buildroot-ng/openwrt/target/linux/rb532-2.6/patches/100-rb5xx_support.patch: bugfix for the rb532 block2mtd code
[20:08] <groz> nbd ping
[20:08] <nbd> pong
[20:08] <groz> you pinged earlier, after i went to bed
[20:08] <nbd> groz: can you test broadcom-wl again? i have a potential workaround
[20:08] <groz> i can, it'll be an hour or two
[20:08] <db90h> for the google issue?
[20:08] <nbd> groz: try wlc wme 0 after the thing is up
[20:09] <nbd> yes
[20:09] <groz> i have a couple little things i need to do this morning before i can rebuild/reflash a wrt
[20:09] <nbd> ok
[20:09] <groz> lemme make a call, maybe i can put it off an hour or two
[20:09] <groz> do the wrt right now
[20:09] <nbd> there were some reports that said disabling wmm 'fixes' the google issue
[20:09] <groz> hang on
[20:17] <groz> nbd, do i need to svn up to get some changes/patches, or just do the wlc wme 0 to what i've got from a couple days ago ?
[20:17] <nbd> just use the old one
[20:20] <groz> that would be very nice if that works
[20:21] <groz> got a build running, will be flashing in a few minutes
[20:27] <groz> nbd, got another question for ya, also another wl issue
[20:27] <groz> but a different one
[20:27] <groz> i've got a test setup works like this
[20:28] <groz> 4 wrts set up, all wds to each other, so each has 3 wds connections, all bridged
[20:28] <groz> one of them has an internet connection
[20:28] <groz> i run a test program on all fo them, basically it sends a raw eithernet packet out specific wds connections
[20:28] <groz> then it's listening for raw packets of that protocol as well
[20:29] <groz> I compare the source address in the ethernet header with the actual source which is placed in the raw packet
[20:29] <groz> and about 5% of the packets traversing wds links actually pop out of the bridge on the wrong unit
[20:29] <groz> the source address in the ethernet frame does not match that in the packet itself
[20:30] <groz> I repeat this test with cables in place, so all the data skips passing thru the wireless
[20:30] <groz> and it runs flawlessly
[20:30] <groz> so it seems wl is messing with ethernet source address on wds frames
[20:30] <groz> but it's definitely random, and 'occaisional'
[20:30] <groz> so far, every variant of wl i've messed with has this problem
[20:31] <groz> does this ring any bells or would you have any unique insight on that ?
[20:40] <nbd> groz: i've never seen this before
[20:41] <groz> ok, just curious, i've tested it with wl drivers from various sources
[20:41] <groz> and always the same result
[20:42] <groz> i haven't actually done a lot of testing with the current wl in -ng because the google issue was a show stopper
[20:47] <murb> i'm curious if anyone has tried the new bcm43xx reverse engineered driver?
[20:48] <groz> it's in my plan murb, but i haven't gotten there
[21:59] <CIA-17> nbd * r4321 /branches/buildroot-ng/openwrt/package/base-files/default/etc/functions.sh: fix unnamed config sections
[22:25] <CIA-17> nbd * r4322 /branches/buildroot-ng/openwrt/package/base-files/default/etc/functions.sh: avoid using a reserved word as a variable name
[22:29] <groz> nbd ping
[22:30] <nbd> pong
[22:30] <groz> ok, i build a stock image from scratch
[22:30] <groz> got it so it'll come up, access point, and i can go anywhere but google
[22:30] <nbd> now try wlc wme 0
[22:30] <groz> then wlc wme 0 fails, so i wlc down
[22:30] <groz> then wlc wme 0
[22:30] <groz> wlc up
[22:31] <groz> iwconfig wl0 mode master essid xxxx
[22:31] <groz> is this correct ?
[22:31] <groz> it's now showing beacons again
[22:31] <nbd> don't use iwconfig
[22:31] <groz> well if i go wlc up at that point
[22:31] <nbd> just wlc down wme 0 up
[22:31] <groz> it's not beaconging anymore
[22:31] <nbd> oh
[22:31] <groz> actually
[22:31] <groz> when it starts up
[22:31] <nbd> then try wlc down wme 0 up ssid xxxx
[22:31] <groz> if i dont do iwconfg up
[22:31] <groz> then i dont get beacons either
[22:32] <groz> ok, i'll try using _just_ wlc
[22:32] <groz> he real issue i got, after i wme 0
[22:32] <groz> then iwconfig
[22:32] <groz> shortly after it resets
[22:33] <nbd> wlcompat hasn't been updated for the new driver yet
[22:33] <groz> ok up ssid with wlc seems to bring it back
[22:33] <groz> so i'll just use wlc
[22:33] <groz> stand by
[22:34] <groz> using nokia 770 as the client, doing before and after tests now
[22:41] <groz> ok, still no joy
[22:42] <groz> wme is zero
[22:42] <groz> loading other sites
[22:42] <groz> not loading google
[22:46] <murb> do ssled http connections also not work?
[22:47] <groz> you mean any old ssl
[22:47] <groz> or some site specifically ?
[22:47] <murb> yeah.
[22:47] <groz> lemme check
[22:47] <murb> i had can't ssh or ssl to some sites issue with wireless some time ago
[22:47] <murb> but it wasn't a wl based thing.
[22:48] <groz> just got the login https page fine from my bank
[22:49] <groz> so ssl does appear to work
[22:51] <groz> ok, here's an interesting one
[22:51] <groz> https://www.google.com sends a redirect to http
[22:51] <groz> i got the redirect
[22:52] <groz> typed in https, now it's stuck trying to load http
[23:01] <murb> does http://www.google.de work?
[23:02] <groz> no, neither does .ca
[23:02] <groz> BUT
[23:02] <groz> if i got to google.com here
[23:02] <groz> they do redirect me to google.ca
[00:00] --- Sun Jul 30 2006