**** BEGIN LOGGING AT Sun Dec 05 02:59:58 2010
Dec 05 03:42:46 <builder> build #34 of ixp4xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/34
Dec 05 06:14:25 <builder> build #32 of xburst is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/32
Dec 05 06:59:22 <builder> build #33 of iop32x is complete: Failure [failed shell_4 compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/33
Dec 05 09:10:02 <builder> build #37 of ar71xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ar71xx/builds/37
Dec 05 09:16:44 <builder> build #33 of au1000 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/33
Dec 05 09:35:25 <Kaloz> cshore: that's hardly something solid to base things on. ppl reported issues with ath9k all the time when they got OOM because of running too many processes
Dec 05 10:18:51 <builder> build #39 of ubicom32 is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/39
Dec 05 10:39:07 <russell--> what is the right way to set the MTU on one of the vap's in madwifi, i want ath1 to use 1527, for example
Dec 05 10:39:24 <russell--> (in this case, for batman-adv)
Dec 05 10:46:37 <OutBackDingo> russell--: with a firewall rule
Dec 05 10:49:15 <russell--> that sounds unlikely
Dec 05 10:49:26 <russell--> there are no firewall rules on these things
Dec 05 10:49:31 <russell--> just bridging
Dec 05 10:50:09 <russell--> ip link set ath1 mtu 1527 seems to do it, but where in /etc/config-land does that belong
Dec 05 11:08:58 <EqUaTe> OutBackDingo: you don't set the MTU with iptables...
Dec 05 11:09:05 <EqUaTe> it's an interface setting
Dec 05 11:09:17 <EqUaTe> i don't know where you would set it though
Dec 05 11:31:56 <CIA-42> florian * r24258 /trunk/package/base-files/ (Makefile files/sbin/wifi):
Dec 05 11:31:56 <CIA-42> [package] adds a --help option to /sbin/wifi
Dec 05 11:31:56 <CIA-42> Signed-off-by: Sebastian Philipp <sebastian@spawnhost.de>
Dec 05 11:42:14 <Acinonyx> hello
Dec 05 11:47:57 <CIA-42> kaloz * r24259 /trunk/ (7 files in 4 dirs): [target/mpc85xx]: preliminary support for Freescale MPC85xx based boards
Dec 05 11:57:34 <OutBackDingo> EqUaTe: well no not specifically the interface but it is stil feasible to do with iptabe to resolv MTU problems
Dec 05 12:47:38 <EqUaTe> OutBackDingo: that's called an ugly hack
Dec 05 12:47:59 <EqUaTe> plus you can't use iptables to increase the interface mtu
Dec 05 12:48:10 <OutBackDingo> nope thats not doable
Dec 05 12:50:25 <EqUaTe> that's what russell-- was wanting to do
Dec 05 14:17:59 <CIA-42> jow * r24260 /packages/net/polipo/ (Makefile files/polipo.init): [packages] polipo: solve a bunch of "sh: bad number" errors in init script, always allow 127.0.0.1
Dec 05 16:35:38 <CIA-42> nbd * r24261 /trunk/package/mac80211/patches/520-ath9k_reset_fix.patch: ath9k: fix a DMA related race condition at hw reset time
Dec 05 16:45:19 <CIA-42> nbd * r24262 /branches/backfire/package/mac80211/patches/593-ath9k_reset_dma_fix.patch: ath9k: backport dma fix from r24261
Dec 05 17:35:28 <CIA-42> jow * r24263 /packages/utils/collectd/Makefile: [packages] collectd: make it depend on libltdl
Dec 05 18:43:58 <CIA-42> hauke * r24264 /trunk/target/linux/brcm47xx/ (files/ files-2.6.34/ files-2.6.36/ files-2.6.37/): brcm47xx: use on common files dir
Dec 05 18:50:15 <CIA-42> jow * r24265 /packages/net/olsrd/ (3 files in 2 dirs): [packages] olsrd: bring txtinfo/gateways formatting in line with the other output modes
Dec 05 19:21:22 <builder> build #33 of ep93xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/33
Dec 05 19:26:36 <crow> is there something wrong with phy0 ? http://openwrt.pastebin.com/J0iHu2U0 (KAMIKAZE (bleeding edge, r24129) kernel 2.6.36.1))
Dec 05 19:28:51 <CIA-42> hauke * r24266 /trunk/target/linux/brcm47xx/patches-2.6.36/ (12 files):
Dec 05 19:28:52 <CIA-42> brcm47xx: backport patch from kernel 2.6.37
Dec 05 19:28:52 <CIA-42> Backport patches from r24162
Dec 05 19:28:52 <CIA-42> brcm47xx: reorder patches like they were commitet upstream
Dec 05 19:29:05 <crow> seem problem was in wireless config file "option hwmode 11gn" -n and problem solwed. (ath5k card) think this card cant do n..
Dec 05 19:29:26 <CIA-42> hauke * r24267 /trunk/target/linux/brcm47xx/files/drivers/mtd/maps/bcm47xx-flash.c: brcm47xx: do not read from CFE
Dec 05 19:29:45 <xMff> 11gn -> 11ng
Dec 05 19:30:41 <framer99> that error looks like hostapd does not support that option
Dec 05 19:30:43 <crow> got same error with "option hwmode 11ng"
Dec 05 19:30:55 <xMff> yes indeed, quite uncommon
Dec 05 19:30:58 <framer99> this looks simliar http://bugs.gentoo.org/259866
Dec 05 19:31:06 <crow> https://dev.openwrt.org/ticket/7930
Dec 05 19:32:16 <crow> ath5k can do n ?
Dec 05 19:33:06 <xMff> no but hostapd should fail with "cannot set n bla bla" instead of complaining about an unknown opt
Dec 05 19:33:29 <framer99> is it possibly an issue with wpad/mini/full hostapd-full mini or something.. (not sure how all those versions of wpad/hostapd work)
Dec 05 19:33:50 <xMff> they should all support 11n
Dec 05 19:34:04 <xMff> mini is default for ath9k stuff too
Dec 05 19:35:15 <cshore_> ping nbd
Dec 05 19:35:58 <nbd> pong
Dec 05 19:36:40 <framer99> http://pastebin.com/mh2sJXww shows that wpad-full and both hostapd packages do
Dec 05 19:37:20 <framer99> well, hostap-full and whatever both hostapd-supplicant pkgs are
Dec 05 19:56:56 <cshore_> nbd: have you had a chance to look at the patches I'm proposing for mtd?
Dec 05 19:58:05 <cshore_> sorry for not being here when you ponged btw - had an interruption....seems to happen a lot the past week
Dec 05 19:58:09 <nbd> not yet
Dec 05 20:00:40 <cshore_> nbd: I'm asking for input because I can't test 47xx because I don't have one
Dec 05 20:01:03 <nbd> please ask somebody actively working on that platform
Dec 05 20:01:04 <cshore_> nbd: and it's your baby IIRC
Dec 05 20:01:16 <nbd> i haven't really done much with brcm47xx in a while
Dec 05 20:01:20 <cshore_> oh, ok
Dec 05 20:01:30 <cshore_> nbd: what about mtd?
Dec 05 20:04:04 <nbd> the changes look ok to me
Dec 05 20:06:58 <crow> i have one brcm47xx here but no serial, will try to setup serial these days and can try changset.
Dec 05 20:07:24 <framer99> crow: can you try with "wpad" installed instead of wpad-mini
Dec 05 20:08:00 <crow> framer99 will need to build it first as i am using with brcm47xx kernel 2.6.36.1 isntead default one..
Dec 05 20:08:28 <framer99> ok, well, i'm no expert but that's what i'd do based on what I saw
Dec 05 20:11:05 <cshore_> crow: thanks
Dec 05 20:15:03 <danage> blogic: ping
Dec 05 20:16:54 <framer99> cshore: i have a brcm47xx with serial for testing.. where would i find the patches you need tested?
Dec 05 20:17:47 <philipp64|laptop> [florian]: ping
Dec 05 20:18:16 <philipp64|laptop> actually, maybe felix knows...  nbd you still there?
Dec 05 20:18:32 <nbd> yes
Dec 05 20:19:16 <philipp64|laptop> was wondering if there's a standard netlink message for INTF's to communicate information about their status: carrier, bandwidth, signal quality, error rate, etc.
Dec 05 20:20:09 <philipp64|laptop> I was thinking it would be useful for both Wifi and DSL.
Dec 05 20:20:18 <nbd> no
Dec 05 20:20:33 <philipp64|laptop> there isn't one?
Dec 05 20:20:36 <nbd> right
Dec 05 20:20:46 <philipp64|laptop> ok. how much work would it be to add it?
Dec 05 20:20:59 <nbd> i don't think such a thing would have a chance upstream
Dec 05 20:21:23 <nbd> for AP mode interfaces, a global status for signal strength, quality, etc. is completely useless
Dec 05 20:21:26 <philipp64|laptop> it would be handy to have a way to get such messages into user-space too... either via multicast or a DBus proxy.
Dec 05 20:21:58 <philipp64|laptop> that's probably true... but for DSL the metrics are a lot more standardized.
Dec 05 20:22:05 <philipp64|laptop> or rather, normalized.
Dec 05 20:22:16 <philipp64|laptop> there are agreed ways of measuring signal quality.
Dec 05 20:22:21 <nbd> then dsl should have its own interface for that
Dec 05 20:22:32 <nbd> but unifying wifi and dsl does not make much sense to me here
Dec 05 20:23:26 <philipp64|laptop> well, the message could have several fields, and only the ones that make sense for a given medium would be populated.
Dec 05 20:23:33 <CIA-42> juhosg * r24268 /trunk/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-f5d8235-v2.c: ramips: use tabs instead of spaces in mach-f5d8235-v2.c
Dec 05 20:23:34 <philipp64|laptop> how much work do you think this would be?
Dec 05 20:23:36 <CIA-42> juhosg * r24269 /trunk/target/linux/ramips/ (rt288x/profiles/00-default.mk rt305x/profiles/00-default.mk):
Dec 05 20:23:36 <CIA-42> ramips: default profile fix
Dec 05 20:23:36 <CIA-42> Fix package names in default profiles.
Dec 05 20:23:36 <CIA-42> Signed-off-by: Roman Yeryomin <roman@advem.lv>
Dec 05 20:23:39 <CIA-42> juhosg * r24270 /trunk/target/linux/ramips/ (9 files in 3 dirs): ramips: add support for 2.6.36
Dec 05 20:23:52 <nbd> philipp64|laptop: i think this would be shot down on linux-netdev immediately
Dec 05 20:24:06 <philipp64|laptop> any particular reason?
Dec 05 20:24:26 <nbd> because the overlap is only useful in some specific corner cases, but useless for all other cases
Dec 05 20:24:36 <nbd> it mixes things together that do not really belong together
Dec 05 20:24:53 <philipp64|laptop> then we could use typed messages, with a common part, and a media-specific tail.
Dec 05 20:25:06 <nbd> but what's the point of trying to unify it then?
Dec 05 20:25:14 <nbd> cfg80211 already reports all necessary information for 802.11
Dec 05 20:25:15 <philipp64|laptop> things like "carrier on/off" should be globally useful.
Dec 05 20:25:20 <nbd> carrier on/off is already global
Dec 05 20:25:27 <nbd> it's reflected in the interface flags
Dec 05 20:25:33 <nbd> howver for dsl you cannot even assume that you have a netdfev
Dec 05 20:25:35 <nbd> netdev
Dec 05 20:26:06 <philipp64|laptop> yeah... and that's a problem.  I've been trying to convince the linux-atm group that we need a netdev.
Dec 05 20:26:15 <nbd> what for?
Dec 05 20:26:24 <philipp64|laptop> oddly, we have one if we're using 2684... but not otherwise.
Dec 05 20:26:36 <philipp64|laptop> well, so we can get interface stats and state for one thing.
Dec 05 20:26:37 <nbd> well, 2684 transports ethernet frames
Dec 05 20:26:38 <nbd> ATM does not
Dec 05 20:27:06 <philipp64|laptop> yes.  but linux supports more than just Ethernet-ish netdev's.
Dec 05 20:27:11 <nbd> adding a netdev just for the stats seems pointless
Dec 05 20:27:32 <nbd> and making atm a protocol to work on top of netdevs would probably require some significant rework
Dec 05 20:27:44 <nbd> and what for?
Dec 05 20:27:45 <philipp64|laptop> why?
Dec 05 20:28:21 <nbd> since it changes the way the data path works
Dec 05 20:28:30 <philipp64|laptop> how do you instrument ATM otherwise?  how do you get a IfIndex assigned to it for SNMP, for instance, without a netdev?
Dec 05 20:29:04 <nbd> why do you need an ifindex there?
Dec 05 20:29:37 <philipp64|laptop> so you can monitor the state of the NIC.
Dec 05 20:30:02 <philipp64|laptop> if you want to get SNMP traps sent on carrier state changes, you need an IfIndex.
Dec 05 20:30:10 <nbd> why should the kernel be changed to work around SNMP protocol issues?
Dec 05 20:30:16 <nbd> that doesn't make any sense to me at all
Dec 05 20:30:17 <philipp64|laptop> otherwise, you don't know what the trap corresponds to.
Dec 05 20:30:49 <philipp64|laptop> well, I'm just thinking about using what's there already, rather than reinventing the wheel N times over.
Dec 05 20:31:11 <nbd> and i'm convinced that such a change would be for the wrong reasons
Dec 05 20:31:17 <philipp64|laptop> ok, let me ask a different question... how would you do this?
Dec 05 20:31:20 <nbd> and you probably wouldn't get far trying to convince upstream
Dec 05 20:31:29 <nbd> fake an ifindex for atm devices
Dec 05 20:31:36 <nbd> in a way that does not produce overlap
Dec 05 20:31:42 <philipp64|laptop> why not just fake a netdev?
Dec 05 20:32:04 <nbd> because nobody wants workarounds for conceptually broken user space in the kernel
Dec 05 20:32:05 <philipp64|laptop> that is, use it for control messages, but communicate data out-of-band?
Dec 05 20:32:29 <philipp64|laptop> "conceptually broken user space"?
Dec 05 20:32:54 <nbd> well, if snmp depends on having a real ifindex for something that does not have one, then that's broken
Dec 05 20:32:59 <nbd> it's a leaky abstraction
Dec 05 20:33:33 <philipp64|laptop> you could argue the opposite too: that it doesn't have one reflects that something is broken.
Dec 05 20:33:41 <nbd> huh?
Dec 05 20:33:49 <nbd> ifindex is for netdevs
Dec 05 20:33:52 <nbd> atm works without netdevs
Dec 05 20:33:58 <nbd> => it makes sense for atm not to have an ifindex
Dec 05 20:34:22 <philipp64|laptop> why does it make sense for ATM to not have an ifindex?
Dec 05 20:34:36 <nbd> because it does not need one
Dec 05 20:35:27 <philipp64|laptop> I just made the point it did: if it can have carrier state changes, then it can generate traps.  if it can generate traps, then the interface needs to have a meaningful notation.  in SNMP, that's the IfIndex.
Dec 05 20:35:50 <nbd> having a carrier state reporting mechanism does not depend on having an ifindex
Dec 05 20:35:50 <philipp64|laptop> same with bytes sent, frames sent, etc.
Dec 05 20:36:07 <nbd> ATM also needs different statistics than an netdev
Dec 05 20:36:07 <philipp64|laptop> it does in the SNMP interface spec.
Dec 05 20:36:16 <nbd> the netdev statistics cannot be arbitrarily changed anyway
Dec 05 20:36:21 <nbd> because the user space ABI needs to be stable
Dec 05 20:36:43 <nbd> the kernel does not care about what the SNMP spec says, nor should it!
Dec 05 20:36:52 <nbd> it's up to user space to manage such protocols
Dec 05 20:36:57 <philipp64|laptop> yeah... it seemed broken to me that all netdev statistics get shoehorned into looking Ethernet-ish.
Dec 05 20:37:37 <philipp64|laptop> the protocol gets done in user-space, yes, but the instrumentation gets done by the driver.
Dec 05 20:37:42 <philipp64|laptop> they have to cooperate.
Dec 05 20:38:03 <nbd> user space can take care of this via decent abstractions
Dec 05 20:38:12 <nbd> it does not depend on the kernel doing things in such a specific way
Dec 05 20:38:38 <nbd> and just because it's easier for user space to do it this way does not mean that it's a good idea to shape the kernel based on weird protocol corner cases
Dec 05 20:38:55 <philipp64|laptop> well, if you try hard enough, you can workaround a lot of shortcomings in the kernel.  but should you have to?
Dec 05 20:39:06 <nbd> it's not a shortcoming of the kernel
Dec 05 20:39:13 <nbd> it's the lack of a proper abstraction in user space
Dec 05 20:39:35 <nbd> the kerne has had its fair share of legacy API baggage
Dec 05 20:39:42 <philipp64|laptop> just because it doesn't look like Ethernet doesn't make it "weird" or a "corner case".
Dec 05 20:39:44 <nbd> adding more to that is not going to be popular with kernel devs
Dec 05 20:40:46 <philipp64|laptop> ok. simpler question: how would you make ATM/DSL interfaces indicate to user-space their instrumentation then?
Dec 05 20:41:28 <nbd> not sure, i haven't looked the ATM API in detail
Dec 05 20:41:41 <nbd> but i'd probably add an ATM netlink interface if there isn't such a thing already
Dec 05 20:46:08 <KanjiMonster> afaik broadcom does add netdevs just for their stats (of atm/dsl), but one can argue about broadcom being a good reference ;)
Dec 05 20:46:30 <nbd> well, it may just be a good example of how NOT to do it ;)
Dec 05 20:46:50 <nbd> the broadcom ATM/DSL drivers are pretty nasty after all
Dec 05 20:52:50 <CIA-42> hauke * r24271 /trunk/package/kernel/modules/usb.mk:
Dec 05 20:52:50 <CIA-42> kernel: add kmod-usb-serial-wwan
Dec 05 20:52:50 <CIA-42> This package is needed by kmod-usb-serial-option
Dec 05 20:52:50 <CIA-42> Thank you raver (closes #7731)
Dec 05 21:08:09 <russell--> Equate: i added an interface for the vap in /etc/config/network, with proto=none and mtu=1527 and that worked
Dec 05 21:09:03 <EqUaTe> cool
Dec 05 21:32:23 <CIA-42> hauke * r24272 /trunk/package/kernel/modules/netdevices.mk:
Dec 05 21:32:23 <CIA-42> kernel: add dummy net device
Dec 05 21:32:23 <CIA-42> Thank you Thomas Jansen.
Dec 05 21:32:23 <CIA-42> (partly closes #5849)
Dec 05 22:22:19 <swalker> updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/uscan.shtml
Dec 05 22:25:45 <philipp64|laptop> KanjiMonster: you talking about bnx2 or tg3?
Dec 05 22:26:24 <KanjiMonster> philipp64|laptop: I'm talking about the bcm63xx dsl/atm drivers
Dec 05 22:29:57 <philipp64|laptop> arch/mips/bcm63xx/ ?
Dec 05 22:32:04 <KanjiMonster> yes
Dec 06 01:38:52 <tripolar> hi
Dec 06 01:39:34 <tripolar> i build openwrt for brcm47xx and it doesnt boot - im on the latest rev - i cant use serial output because i have no serial connected to the router
Dec 06 01:39:40 <tripolar> its a wl500gp v1
Dec 06 01:42:50 <soma_> you could try failsafe. but if possible i would suggest serial
Dec 06 01:44:11 <tripolar> the device doesnt come up after the first flash so no failsave at all
Dec 06 01:44:19 <tripolar> it just refuses my network connections
Dec 06 01:45:02 <roh>  
Dec 06 01:45:27 <tripolar> but 2.6.34.7 boots fine
Dec 06 02:10:11 <CIA-42> cshore * r24273 /trunk/target/linux/brcm63xx/base-files/etc/defconfig/CPVA642/ (. network): [bcm63xx] base-files: Added network defconfig because board only has one ethernet (4-port switch)
Dec 06 02:50:22 <tripolar_> roh: are you still here
Dec 06 02:50:30 <tripolar_> i have a kernel dump
Dec 06 02:53:09 <tripolar_> http://nopaste.info/9393ed1fa9.html
**** ENDING LOGGING AT Mon Dec 06 02:59:57 2010