[10:02] <groz> nbd, are you areound ?
[10:02] <groz> i finally got things going here on a wrt with the newest stuff
[10:02] <groz> and got a chance to try a few things
[10:02] <groz> in particular that new wl driver
[10:02] <groz> a) I cannot load google when connected to that wrt
[10:03] <groz> b) centrino will not associate with it
[10:04] <groz> the first one is kind of funny, cuz no other sites i have bookmarked on that computer give me any trouble
[10:04] <groz> it's a reasonable selection of places, mostly stuff i use when i'm on the road flying
[10:04] <db90h> the google issue is a known one
[10:04] <groz> but www.google.ca just sits there spinning
[10:04] <db90h> u'd think they'd have discovered it during testing..but
[10:04] <groz> ya, and the svn commit records show the new one he put in the other day
[10:04] <[mbm]> the google thing as been reported before and nbd supposedly fixed it in a commit earlier this week
[10:04] <groz> supposedly fixed that
[10:05] <groz> but it's still there, unless my scratch checkout didn't get the new one
[10:05] <groz> which i will go validate
[10:05] <db90h> i thought i vaguely remembered someone saying something about a fix ;p
[10:05] Action: [mbm] wonders what's so special that causes google to fail
[10:05] <db90h> vague hazy memory says: seems like i heard something about vlan tags being in the packets form google
[10:05] Action: groz wonders what broadcom developer has a mad on for google
[10:07] <groz> vlan tags will travers switches, will be stripped at the first router
[10:07] <db90h> yea, i figured they would
[10:08] <groz> ok, let me rephrase
[10:08] <db90h> as i thought about that
[10:08] <groz> they _should_ be stripped at the first router
[10:08] <groz> and guaranteed they are here
[10:08] <[mbm]> if a vlan flag is leaking in, it wouldn't be from wl -- no vlans used in the driver
[10:08] <groz> because i'm running over vlans
[10:08] <groz> to reach the wrt
[10:08] <db90h> i just heard someone say that in dd-wrt forums
[10:08] <db90h> i have no idea of its accuracy
[10:08] <db90h> or even feasibility
[10:08] <groz> if that is the case
[10:08] <[mbm]> db90h: if you heard it in the dd-wrt forums then I very much doubt it
[10:09] <groz> it should be trivial to strip them
[10:09] <groz> before going into wl
[10:09] <groz> but, like i said
[10:09] <groz> that data travels over vlan segments here
[10:09] <groz> before it gets to my wrt
[10:09] <groz> and if i plug in with a wire
[10:09] <groz> google loads fine
[10:09] <groz> it's ONLY over the wireless
[10:13] <[mbm]> sniff the wan link and get some packet dumps
[10:13] <db90h> yea, i really need to not repeat random shit i hear on dd-wrt forums
[10:14] <db90h> that said, some people there reported enabling WMM and No acknowledgement works
[10:14] <db90h> which doesn't make any sense either
[10:14] <db90h> yea, let me just quit repeating shit from there, sorry about that
[10:14] <[mbm]> forums are the worst place to get information
[10:15] <[mbm]> even the openwrt forums have people that post total crap
[10:15] <groz> if the openwrt forums are an example, i have to agree with ya mbm
[10:15] Action: [mbm] usually moderates or flames the hell out of such posters
[10:16] <db90h> hehe, my mind may have already suffered catastrophic corruption from reading so much forum shit then ;p
[10:20] <florian__> ola
[10:46] <db90h> can anyone tell me a little about how the /tmp partition's RAM allocation is managed?
[10:47] <groz> i beleive tmpfs allocates a swack of virtual memory, then, pages real memory in as required
[10:47] <groz> to back it
[10:48] <db90h> ah, makes sense, thanks
[10:55] <nbd> .
[10:55] <nbd> if you want info on the google problem, there are tcpdump captures that you can compare
[10:55] <nbd> in our forum
[10:55] <groz> I'll get to it in a bit, but, your commit said it was intended to fix
[10:56] <groz> just wanted to let you know, it's still there
[10:56] <nbd> the linksys changelog mentioned fixing certain websites over wireless
[10:56] <groz> is that driver from linksys, or asus ?
[10:57] <wigyori> nbd: so that 'google is unreachable' problem was their fsckup?
[10:57] <nbd> linksys
[10:57] <nbd> wigyori: broadcom fscked it up
[10:57] <nbd> wigyori: because a similar driver from a netgear gpl tarball has exactly the same problem
[10:57] <wigyori> i see
[10:58] <groz> either broadcom doesn't test things, or, somebody at broadcom has a real mad on for google
[10:58] <nbd> linuxquestions is affected as well
[11:00] <nbd> the tcpdump captures are here: http://forum.openwrt.org/viewtopic.php?pid=30594#p30594
[11:00] <groz> I'm curious how they can expect to sell router hardware if units built with it wont load google
[11:00] <nbd> no idea
[11:01] <nbd> but it doesn't seem to affect everybody
[11:03] <groz> interesting
[11:12] <db90h> downright weird it seems
[11:12] <florian__> that's completely weird anyway
[11:12] <db90h> if linksys's latest attempted fix also didn't work on the 300n, then surely they will eventually get it fixed for real
[11:13] <florian__> nbd: I think we can close #518, right ?
[11:13] <murb> nbd: this "google" problem also seems to bne an ssh problem.
[11:16] <nbd> florian__: right
[11:16] <nbd> murb: how?
[11:29] <murb> ok might i've seen problems very much like that whilst trying to use tkip, i could ssh to some places and not others. From madwifi sta to hostap /d AP
[11:30] <murb> so completely different drivers just very simular behaviour
[11:35] <groz> florian, questin on 'protocol' with these tickets
[11:35] <groz> i see one, trivial thing, i've already bumped into it myself, #591
[11:35] <groz> is it ok to just 'claim the ticket' and plug in the fix
[11:35] <groz> the close it ?
[11:35] <groz> or is there a more formal process ?
[11:57] <florian__> groz: I think I am not the best person who will answer you regarding any protocol we have, I have already "stolen" {Nico}'s tickets some times ;)
[11:57] <groz> lol ok
[11:58] <groz> so i'll assume that means it's not a strictly controlled thing
[11:58] <florian__> but usually this is how I do : if I see a ticket I think I can solve, I assign it to me, commit the fix, if I am sure (by testing) it works, I close it, with the changeset number, if it *may* fix it, I post a comment
[11:59] <groz> ok, just wondering, see a trivial one in there, and, it's something i want fixed in my own work here
[11:59] <groz> so i scooped it
[12:04] <db90h> i'm working with an openwrt build on a WRT54Gv5 as a reversion firmware.. for some reason OpenWrt keeps setting sdram_init to an empty value "sdram_init=", thus bricking the box .. maybe the default nvram params i'm using are one of openwrt's init scripts
[12:04] <db90h> why is openwrt messing with sdram_init?
[12:05] <db90h> err i meant to say maybe the default nvram params i'm using are CONFUSING one of openwrt's init scripts
[12:06] <db90h> S05nvram
[12:07] <db90h> yea, the boardflags i happen to be using on this CFE are confusing this script
[12:08] <db90h> fortunately i have adjusted them on plug vxworks_killer firmwares, but the first versions did use this boardflag (the same as the WAP54Gv3)
[12:09] <db90h> regardless, it seems there should be some check to prevent sdram_init from being set to an empty value, unless this is intentional...
[12:10] <db90h> and i would still like to know why this workaround is necessary for 'braindead CFE defaults'.. are the sdram defaults really undesirable on any unit? surely the manufacture set them correctly
[12:15] <{Nico}> florian__, groz: when working on an assigned ticket, you should try to contact the owner first
[12:15] <groz> i believe there were a few revs of the wrt54g that were set to use 16 meg, but actually had 32
[12:15] <groz> nico, i took one that was not assigned to anybody
[12:15] <groz> but was just wondering if 'just take it' if its not assigned is 'acceptable'
[12:19] <dbcch> fucking video adaptor crashes
[12:21] <dbcch> wait, i think i just thought of why i saw that sdram_init errata
[12:21] <dbcch> it's not the default nvram parameters confusing the script, i bet it's something i've omitted from busybox..
[12:21] <dbcch> tho i haven't omitted much, i'll have to check
[12:34] <dbcch> printf.. duh
[14:02] <florian__> {Nico}: yes next time I will contact the ticket owner, rather than just fixing the ticket without warning him
[14:02] <florian__> groz: wrt54g v2 rev XH have 32 Mb ram, I got one and am pretty happy with it :)
[14:29] <{Nico}> florian__: np
[14:30] <florian__> {Nico}: etienne told me he was going to buy 2 models of this : http://www.airlink101.com/products/ar525w.html
[14:37] <{Nico}> for us?
[14:38] <florian__> {Nico}: I think so
[14:40] <CIA-17> nico * r4302 /packages/net/kismet/Makefile: fix depencencies on uclibc++
[14:44] <CIA-17> nico * r4303 /packages/ (libs/net-snmp/Makefile net/freeradius/Makefile): fix build in WhiteRussian SDK
[14:45] <CIA-17> nico * r4304 /branches/buildroot-ng/openwrt/package/mtd/Makefile: fix CATEGORY
[15:10] <florian__> we need to make something to handle properly the ipkg upgrades and things like that
[15:19] <nbd> .
[15:20] <florian__> ..
[18:26] <florian__> re
[18:59] <florian__> anyone tried hacking the wrt54gx2 ?
[20:23] <CIA-17> groz * r4305 /branches/buildroot-ng/openwrt/target/linux/generic-2.4/patches/228-bridge-preferred.patch: Add bridge preferred mac patch
[20:35] <CIA-17> groz * r4306 /branches/buildroot-ng/openwrt/target/linux/generic-2.4/patches/228-bridge-preferred.patch: oooops, bridge patch was broken
[21:22] <CIA-17> groz * r4307 /branches/buildroot-ng/openwrt/package/base-files/brcm-2.4/bin/firstboot: Minor change to firstboot, closes #591
[23:41] <[mbm]> groz: 4307 is mostly irrelevent as we've switched to mini_fo
[00:00] --- Fri Jul 28 2006
[10:02] <groz> i finally got things going here on a wrt with the newest stuff
[10:02] <groz> and got a chance to try a few things
[10:02] <groz> in particular that new wl driver
[10:02] <groz> a) I cannot load google when connected to that wrt
[10:03] <groz> b) centrino will not associate with it
[10:04] <groz> the first one is kind of funny, cuz no other sites i have bookmarked on that computer give me any trouble
[10:04] <groz> it's a reasonable selection of places, mostly stuff i use when i'm on the road flying
[10:04] <db90h> the google issue is a known one
[10:04] <groz> but www.google.ca just sits there spinning
[10:04] <db90h> u'd think they'd have discovered it during testing..but
[10:04] <groz> ya, and the svn commit records show the new one he put in the other day
[10:04] <[mbm]> the google thing as been reported before and nbd supposedly fixed it in a commit earlier this week
[10:04] <groz> supposedly fixed that
[10:05] <groz> but it's still there, unless my scratch checkout didn't get the new one
[10:05] <groz> which i will go validate
[10:05] <db90h> i thought i vaguely remembered someone saying something about a fix ;p
[10:05] Action: [mbm] wonders what's so special that causes google to fail
[10:05] <db90h> vague hazy memory says: seems like i heard something about vlan tags being in the packets form google
[10:05] Action: groz wonders what broadcom developer has a mad on for google
[10:07] <groz> vlan tags will travers switches, will be stripped at the first router
[10:07] <db90h> yea, i figured they would
[10:08] <groz> ok, let me rephrase
[10:08] <db90h> as i thought about that
[10:08] <groz> they _should_ be stripped at the first router
[10:08] <groz> and guaranteed they are here
[10:08] <[mbm]> if a vlan flag is leaking in, it wouldn't be from wl -- no vlans used in the driver
[10:08] <groz> because i'm running over vlans
[10:08] <groz> to reach the wrt
[10:08] <db90h> i just heard someone say that in dd-wrt forums
[10:08] <db90h> i have no idea of its accuracy
[10:08] <db90h> or even feasibility
[10:08] <groz> if that is the case
[10:08] <[mbm]> db90h: if you heard it in the dd-wrt forums then I very much doubt it
[10:09] <groz> it should be trivial to strip them
[10:09] <groz> before going into wl
[10:09] <groz> but, like i said
[10:09] <groz> that data travels over vlan segments here
[10:09] <groz> before it gets to my wrt
[10:09] <groz> and if i plug in with a wire
[10:09] <groz> google loads fine
[10:09] <groz> it's ONLY over the wireless
[10:13] <[mbm]> sniff the wan link and get some packet dumps
[10:13] <db90h> yea, i really need to not repeat random shit i hear on dd-wrt forums
[10:14] <db90h> that said, some people there reported enabling WMM and No acknowledgement works
[10:14] <db90h> which doesn't make any sense either
[10:14] <db90h> yea, let me just quit repeating shit from there, sorry about that
[10:14] <[mbm]> forums are the worst place to get information
[10:15] <[mbm]> even the openwrt forums have people that post total crap
[10:15] <groz> if the openwrt forums are an example, i have to agree with ya mbm
[10:15] Action: [mbm] usually moderates or flames the hell out of such posters
[10:16] <db90h> hehe, my mind may have already suffered catastrophic corruption from reading so much forum shit then ;p
[10:20] <florian__> ola
[10:46] <db90h> can anyone tell me a little about how the /tmp partition's RAM allocation is managed?
[10:47] <groz> i beleive tmpfs allocates a swack of virtual memory, then, pages real memory in as required
[10:47] <groz> to back it
[10:48] <db90h> ah, makes sense, thanks
[10:55] <nbd> .
[10:55] <nbd> if you want info on the google problem, there are tcpdump captures that you can compare
[10:55] <nbd> in our forum
[10:55] <groz> I'll get to it in a bit, but, your commit said it was intended to fix
[10:56] <groz> just wanted to let you know, it's still there
[10:56] <nbd> the linksys changelog mentioned fixing certain websites over wireless
[10:56] <groz> is that driver from linksys, or asus ?
[10:57] <wigyori> nbd: so that 'google is unreachable' problem was their fsckup?
[10:57] <nbd> linksys
[10:57] <nbd> wigyori: broadcom fscked it up
[10:57] <nbd> wigyori: because a similar driver from a netgear gpl tarball has exactly the same problem
[10:57] <wigyori> i see
[10:58] <groz> either broadcom doesn't test things, or, somebody at broadcom has a real mad on for google
[10:58] <nbd> linuxquestions is affected as well
[11:00] <nbd> the tcpdump captures are here: http://forum.openwrt.org/viewtopic.php?pid=30594#p30594
[11:00] <groz> I'm curious how they can expect to sell router hardware if units built with it wont load google
[11:00] <nbd> no idea
[11:01] <nbd> but it doesn't seem to affect everybody
[11:03] <groz> interesting
[11:12] <db90h> downright weird it seems
[11:12] <florian__> that's completely weird anyway
[11:12] <db90h> if linksys's latest attempted fix also didn't work on the 300n, then surely they will eventually get it fixed for real
[11:13] <florian__> nbd: I think we can close #518, right ?
[11:13] <murb> nbd: this "google" problem also seems to bne an ssh problem.
[11:16] <nbd> florian__: right
[11:16] <nbd> murb: how?
[11:29] <murb> ok might i've seen problems very much like that whilst trying to use tkip, i could ssh to some places and not others. From madwifi sta to hostap /d AP
[11:30] <murb> so completely different drivers just very simular behaviour
[11:35] <groz> florian, questin on 'protocol' with these tickets
[11:35] <groz> i see one, trivial thing, i've already bumped into it myself, #591
[11:35] <groz> is it ok to just 'claim the ticket' and plug in the fix
[11:35] <groz> the close it ?
[11:35] <groz> or is there a more formal process ?
[11:57] <florian__> groz: I think I am not the best person who will answer you regarding any protocol we have, I have already "stolen" {Nico}'s tickets some times ;)
[11:57] <groz> lol ok
[11:58] <groz> so i'll assume that means it's not a strictly controlled thing
[11:58] <florian__> but usually this is how I do : if I see a ticket I think I can solve, I assign it to me, commit the fix, if I am sure (by testing) it works, I close it, with the changeset number, if it *may* fix it, I post a comment
[11:59] <groz> ok, just wondering, see a trivial one in there, and, it's something i want fixed in my own work here
[11:59] <groz> so i scooped it
[12:04] <db90h> i'm working with an openwrt build on a WRT54Gv5 as a reversion firmware.. for some reason OpenWrt keeps setting sdram_init to an empty value "sdram_init=", thus bricking the box .. maybe the default nvram params i'm using are one of openwrt's init scripts
[12:04] <db90h> why is openwrt messing with sdram_init?
[12:05] <db90h> err i meant to say maybe the default nvram params i'm using are CONFUSING one of openwrt's init scripts
[12:06] <db90h> S05nvram
[12:07] <db90h> yea, the boardflags i happen to be using on this CFE are confusing this script
[12:08] <db90h> fortunately i have adjusted them on plug vxworks_killer firmwares, but the first versions did use this boardflag (the same as the WAP54Gv3)
[12:09] <db90h> regardless, it seems there should be some check to prevent sdram_init from being set to an empty value, unless this is intentional...
[12:10] <db90h> and i would still like to know why this workaround is necessary for 'braindead CFE defaults'.. are the sdram defaults really undesirable on any unit? surely the manufacture set them correctly
[12:15] <{Nico}> florian__, groz: when working on an assigned ticket, you should try to contact the owner first
[12:15] <groz> i believe there were a few revs of the wrt54g that were set to use 16 meg, but actually had 32
[12:15] <groz> nico, i took one that was not assigned to anybody
[12:15] <groz> but was just wondering if 'just take it' if its not assigned is 'acceptable'
[12:19] <dbcch> fucking video adaptor crashes
[12:21] <dbcch> wait, i think i just thought of why i saw that sdram_init errata
[12:21] <dbcch> it's not the default nvram parameters confusing the script, i bet it's something i've omitted from busybox..
[12:21] <dbcch> tho i haven't omitted much, i'll have to check
[12:34] <dbcch> printf.. duh
[14:02] <florian__> {Nico}: yes next time I will contact the ticket owner, rather than just fixing the ticket without warning him
[14:02] <florian__> groz: wrt54g v2 rev XH have 32 Mb ram, I got one and am pretty happy with it :)
[14:29] <{Nico}> florian__: np
[14:30] <florian__> {Nico}: etienne told me he was going to buy 2 models of this : http://www.airlink101.com/products/ar525w.html
[14:37] <{Nico}> for us?
[14:38] <florian__> {Nico}: I think so
[14:40] <CIA-17> nico * r4302 /packages/net/kismet/Makefile: fix depencencies on uclibc++
[14:44] <CIA-17> nico * r4303 /packages/ (libs/net-snmp/Makefile net/freeradius/Makefile): fix build in WhiteRussian SDK
[14:45] <CIA-17> nico * r4304 /branches/buildroot-ng/openwrt/package/mtd/Makefile: fix CATEGORY
[15:10] <florian__> we need to make something to handle properly the ipkg upgrades and things like that
[15:19] <nbd> .
[15:20] <florian__> ..
[18:26] <florian__> re
[18:59] <florian__> anyone tried hacking the wrt54gx2 ?
[20:23] <CIA-17> groz * r4305 /branches/buildroot-ng/openwrt/target/linux/generic-2.4/patches/228-bridge-preferred.patch: Add bridge preferred mac patch
[20:35] <CIA-17> groz * r4306 /branches/buildroot-ng/openwrt/target/linux/generic-2.4/patches/228-bridge-preferred.patch: oooops, bridge patch was broken
[21:22] <CIA-17> groz * r4307 /branches/buildroot-ng/openwrt/package/base-files/brcm-2.4/bin/firstboot: Minor change to firstboot, closes #591
[23:41] <[mbm]> groz: 4307 is mostly irrelevent as we've switched to mini_fo
[00:00] --- Fri Jul 28 2006