**** BEGIN LOGGING AT Thu Sep 15 02:59:57 2011
Sep 15 09:28:29 <CIA-73> acoul * r28243 /packages/net/bird/Makefile: net/bird: update to version 1.3.3
Sep 15 09:38:33 <acoul> http://paste.pocoo.org/show/476368/
Sep 15 11:42:43 <CIA-73> loswillios * r28244 /packages/sound/pulseaudio/Makefile: [packages] pulseaudio: update to 1.0-rc4
Sep 15 12:34:31 <kerneis> hi
Sep 15 12:35:06 <kerneis> I suspect there is an issue with the firewall in current trunk, about FORWARD in a zone
Sep 15 12:36:46 <kerneis> setting up option forward ACCEPT in a zone, forwarded packets jump to the zone_whatever_accept rule
Sep 15 12:37:07 <kerneis> which accepts only output packets
Sep 15 12:37:31 <kerneis> so forwarded packets are dropped, despite the ACCEPT option
Sep 15 12:41:54 <jow_laptop> zone_whatever_ACCEPT contains  -i whatever -j ACCEPT and -o whatever -j ACCEPT here
Sep 15 12:42:29 <kerneis> let me check, I wrote that from my memories
Sep 15 12:43:08 <kerneis> (anyway, what is sure is that my packets are not forwarded as a result, unless I chose an ACCEPT policy in the defaults)
Sep 15 12:43:21 <jow_laptop> forwarded from where to where?
Sep 15 12:43:37 <kerneis> this is an adhoc mesh network
Sep 15 12:43:42 <jow_laptop> the forward policy in zone options is mainly intended for traffic between hosts within the zone
Sep 15 12:43:44 <kerneis> so forwarded from wifi to the same wifi
Sep 15 12:44:40 <jow_laptop> we use that same stuff for olsr meshes and it works as expceted there
Sep 15 12:45:12 <jow_laptop> did you rule out that the INVALID rule is catching your connections?
Sep 15 12:47:38 <kerneis> jow_laptop: http://pastebin.com/iPzYbCdu
Sep 15 12:48:02 <kerneis> notice the wlan zone
Sep 15 12:48:39 <jow_laptop> that paste does not tell me anything
Sep 15 12:49:04 <jow_laptop> whats in zone_wlan_accept ?
Sep 15 12:50:22 <kerneis> hmm, nothing?
Sep 15 12:50:32 <kerneis> how to do I figure it out?
Sep 15 12:50:44 <jow_laptop> iptables -nvL zone_wlan_ACCEPT
Sep 15 12:50:54 <kerneis> iptables -L shows only "Chain zone_wlan_ACCEPT (3 references)
Sep 15 12:51:01 <kerneis> target     prot opt source               destination "
Sep 15 12:51:39 <kerneis> root@OpenWrt:~# iptables -nvL zone_wlan_ACCEPT
Sep 15 12:51:40 <jow_laptop> is wifi even brought up?
Sep 15 12:51:40 <kerneis> Chain zone_wlan_ACCEPT (3 references) pkts bytes target     prot opt in     out     source               destination
Sep 15 12:51:50 <jow_laptop> looks like it was never added to the firewall
Sep 15 12:51:52 <kerneis> I think so, otherwise I wouldn't be able to connect to it
Sep 15 12:52:14 <jow_laptop> whats your wireless config?
Sep 15 12:52:19 <jow_laptop> and network config?
Sep 15 12:52:59 <kerneis> http://pastebin.com/guvRp66r
Sep 15 12:53:05 <kerneis> hmm, I have an idea
Sep 15 12:53:24 <kerneis> it might be related to the fact that I use a "static" proto without providing an IP?
Sep 15 12:53:38 <jow_laptop> yes
Sep 15 12:53:54 <jow_laptop> try none instead
Sep 15 12:54:00 <kerneis> okay, thanks
Sep 15 12:54:10 <jow_laptop> you should see something like "adding interface wlan (wlan0) to zone wlan" in logread
Sep 15 12:55:04 <jow_laptop> only then rules are applied to it. unless that happens its only covered by the default policy which is obviously drop
Sep 15 12:57:55 <kerneis> it worked, many thanks
Sep 15 13:54:03 <jow_laptop> kerneis: great
Sep 15 17:06:36 <Syburg> What is the difference between the CFE commands "flashimage" and "f"? For flashimage it says "flash an image behind the bootloader" and for "f" it says "flash an image". Also is "flashimage" only a temporary flash? Because my device wont hold the firmware...
Sep 15 17:08:44 <jow_laptop> f might happily overwrite the running loader
Sep 15 17:10:16 <jow_laptop> while flashimage also does integrity checks  I think
Sep 15 17:12:07 <Syburg> jow_laptop: Thats why I didn't attempt to use it, because I can't JTAG. The integrity check fails for the second boot. It's strange, I flash openwrt with the flashimage command and it boots. I can use it like everything is alright. But after a reboot - POW Checksum error of the image...
Sep 15 17:13:20 <jow_laptop> Syburg: thats not uncommon
Sep 15 17:14:52 <jow_laptop> Syburg: the bootloader calculates a chacksum over some flash areas which is invalidated once openwrt replaces its deadc0de marker with a jffs2 filesystem header
Sep 15 17:15:47 <jow_laptop> Syburg: there is even special code to mitigate that problem by applying certain offset fixups on the tr header
Sep 15 17:16:42 <jow_laptop> Syburg: apparently your case/model is not handled (correctly)
Sep 15 17:17:01 <Syburg> jow_laptop: Of couse not, im currently "porting" OpenWRT to it.
Sep 15 17:17:33 <Syburg> jow_laptop: To be honest I'm adding new board support for an brcm63xx platform
Sep 15 17:18:14 <jow_laptop> https://dev.openwrt.org/browser/trunk/target/linux/brcm47xx/files/drivers/mtd/maps/bcm47xx-flash.c see line 245 and below
Sep 15 17:19:09 <jow_laptop> sorry, 345
Sep 15 17:19:56 <jow_laptop> it might have a very similar issue then
Sep 15 17:22:03 <KanjiMonster> Syburg: there's a fixmtd command for that; there are already a few boards needing it; try adding your boardname to https://dev.openwrt.org/browser/trunk/target/linux/brcm63xx/base-files/etc/uci-defaults/brcm63xx_fixcrc.sh
Sep 15 17:24:42 <Syburg> KanjiMonster: would be awesome if i can solve that so easily :D
Sep 15 17:27:34 <Olipro> ugh, I hate it when a dirclean doesn't fix build failures >_<
Sep 15 17:33:01 <Syburg> jow_laptop and KanjiMonster: Tank you for your help, I'm building a new firmware right now and i'll tell you if it worked or not :)
Sep 15 17:49:28 <Syburg> KanjiMonster: i edited the file, but this didn't work. Do I have to execute it by myself? It isn't in the directory "/etc/uci-defaults" on the router, btw
Sep 15 17:52:52 <KanjiMonster> Syburg: iirc it gets deleted after execution; check /rom/etc/uci-defaults/
Sep 15 17:55:34 <CIA-73> nbd * r28245 /trunk/package/mac80211/ (49 files in 2 dirs): mac80211: update to wireless-testing 2011-09-14
Sep 15 17:56:16 <Syburg> KanjiMonster: /rom does only contain the file "note"... but in my other tries it contained what it should...
Sep 15 17:56:48 <KanjiMonster> Syburg: are you using a jffs2 image instead of a squashfs one?
Sep 15 17:58:41 <Syburg> KanjiMonster: yes
Sep 15 17:59:07 <Syburg> KanjiMonster: would take me 20 secs to flash squashfs if you want me to ;)
Sep 15 17:59:08 <KanjiMonster> okay, then there's no rom-part of the image; everything is writable
Sep 15 17:59:47 <KanjiMonster> Syburg: it shouldn't matter; but it would allow you to check whether your changes actually made it into the image
Sep 15 18:00:27 <Syburg> KanjiMonster: Sounds like a good idea.. give me a sec
Sep 15 18:05:55 <Syburg> KanjiMonster: the changes took effect. I guess i have to try it again; case sensitive this time... :D
Sep 15 18:06:10 <KanjiMonster> heh
Sep 15 18:21:48 <Syburg> KanjiMonster: okay... i cant find the script in the folder but reboot works for now...
Sep 15 18:23:46 <jow_laptop> Syburg: did you look in /rom/etc/uci-defaults / ?
Sep 15 18:25:34 <Syburg> jow_laptop: how embarrassing, you're right... i think i'll get me some coffee :D
Sep 15 19:16:13 <Syburg> jow_laptop and KanjiMonster: I wanted to thank you again for your help! It was a big step for me to get a "stable" patch. Good night to you guys and everyone else, of course! :)
Sep 15 21:45:37 <Delboy> nbd: ping
Sep 15 21:45:40 <nbd> Delboy: pong
Sep 15 21:45:45 <Delboy> hi
Sep 15 21:46:00 <Delboy> got a question/problem in ath5k
Sep 15 21:46:43 <Delboy> there is that code which should use eeprom data from flash on those devices
Sep 15 21:46:46 <Delboy> without eeprom
Sep 15 21:46:56 <nbd> yes
Sep 15 21:47:54 <Delboy> and i tried to make that work for my board, but it looks like that the code for that got somehow removed few months ago
Sep 15 21:48:31 <Delboy> one patch is there /mac80211/patches/450-add-ath5k-platform.patch
Sep 15 21:49:26 <Delboy> but code inside the driver looks to me missing and i tried to get it working from that old patch but no luck
Sep 15 21:49:40 <nbd> hm, no idea why that got removed
Sep 15 21:49:57 <nbd> i'll look into it
Sep 15 21:50:07 <Delboy> aha here it is
Sep 15 21:50:07 <Delboy> https://dev.openwrt.org/changeset/26744/trunk/package/mac80211/patches
Sep 15 21:50:30 <Delboy> 473-ath5k_read_mac_addr.patch             and 451-add-platform-eeprom-support-to-ath5k.patch
Sep 15 21:51:29 <nbd> i'll look into merging that code back soon
Sep 15 21:51:45 <Delboy> ok thx
Sep 15 21:54:12 <rektide> i have some Marvell Kirkwood boards i'm starting to play with;
Sep 15 21:54:22 <rektide> if any devs are interested i'll be idling
Sep 15 21:54:36 <rektide> there's some options among the stack
Sep 15 22:37:11 <gotnone> is there an atheros specific devel channel?
Sep 15 22:37:22 <nbd> nope
Sep 15 22:37:52 <gotnone> anyone still working on AR531x boards?
Sep 16 01:24:52 <CIA-73> mazilo * r28246 /packages/net/freeswitch/ (2 files in 2 dirs): Added missing net/freeswitch/files/etc.minimal/autoload_configs/dingaling.conf.xml and bumped up to latest git commit
Sep 16 02:26:44 <xiangfu> Hi
Sep 16 02:26:55 <xiangfu> the IGNORE_ERRORS=m can not ignore the kmod right?
Sep 16 02:27:24 <xiangfu> I do have IGNORE_ERRORS in make parameters. but I still get some error: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-09162011-0324/BUILD_LOG.09162011-0422.last100
**** ENDING LOGGING AT Fri Sep 16 02:59:56 2011