**** BEGIN LOGGING AT Sat Apr 27 02:59:58 2013 Apr 27 03:07:29 playing here with an rt3072 based radio Apr 27 03:07:41 should 4addr style wds work with this one ? Apr 27 03:08:08 I seem to be having issues with client and ap interface at the same time Apr 27 03:08:19 I can bring you two aps, or ap and mesh Apr 27 03:08:27 but, can't seem to get ap + client to start Apr 27 03:09:05 wondering if that's a limitation of the hardware, or, just something busted in mac80211 + ralink Apr 27 03:09:18 same configuration works fine on my ath9k stuff Apr 27 07:47:47 build #261 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/261 Apr 27 07:50:35 build #234 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/234 Apr 27 07:53:24 build #234 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/234 Apr 27 09:29:38 jow r36463 trunk/package/network/config/netifd/Makefile * netifd: update to git head - disables multicast snooping by default on bridges Apr 27 09:43:24 jow r36464 branches/attitude_adjustment/package/uci/Makefile * AA: uci: merge r36377 Apr 27 09:46:03 jow r36465 branches/attitude_adjustment/package/iwinfo/ (7 files in 3 dirs) Apr 27 09:46:03 AA: iwinfo: merge r34982, r35005, r35007, r35471, r36292, r36339, r36417, r36449, r36450 Apr 27 09:57:27 nbd r36466 trunk/package/mac80211/patches/605-rt2x00-pci-eeprom.patch * mac80211: refresh patch Apr 27 09:57:27 nbd r36467 trunk/package/mac80211/patches/300-pending_work.patch * ath9k: fix keycache handling with many connected clients Apr 27 10:00:54 build #224 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/224 Apr 27 10:19:38 build #234 of avr32 is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/234 Apr 27 10:23:03 build #229 of xburst is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/229 Apr 27 10:47:20 build #238 of ar7 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/238 Apr 27 11:54:36 build #203 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/203 Apr 27 16:34:20 Had a power outage last nite, so, lost the scrollback here, don't know if my question yesterday evening was answered or not Apr 27 16:34:37 but, I've got an RT3072 based wifi gadget usb attached to an arm board Apr 27 16:35:32 I can get it up and running as an ap, client, or mesh point no problem Apr 27 16:35:56 but, trying to get a wds going with it, I can't seem to get the client going with 4addr additions Apr 27 16:36:03 at the same time as an access point is also running Apr 27 16:36:08 seems to be either or, but not both Apr 27 16:36:20 is this expected behaviour from the RT line of stuff ? Apr 27 16:36:36 ie, is this a hardware limitation, or a possible driver issue ? Apr 27 19:43:45 build #270 of at91 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/270 Apr 27 20:12:04 jow_laptop: are there any other plans to jettison things from packages/ that aren't maintained? Apr 27 20:29:13 swalker: https://github.com/openwrt/packages-abandoned Apr 27 20:56:26 KanjiMonster: what's the criteria for being deemed as abandoned? Apr 27 20:59:34 swalker: brokenness which no one cares to fix Apr 27 20:59:39 old stuff Apr 27 20:59:54 and packages that we agree on that we dont want to maintain and for which there is no volunteerr Apr 27 21:00:09 and most likely other reasons that we make up as we go along Apr 27 21:03:40 80-90% of packages/ then? Apr 27 21:08:46 how you came up that number is most likely only known to you Apr 27 21:09:02 last time i checked ~10 packages were foobared Apr 27 21:09:14 out of ~1000 that would be 1% Apr 27 21:09:56 stuff with several critical CVEs Apr 27 21:10:07 KanjiMonster: like apache Apr 27 21:10:09 ;) Apr 27 21:13:17 well, ~90% of packages/ has no stated maintainer; a few have stepped up only to not be given access to maintain the package(s) they cared about Apr 27 21:13:49 * swalker was actually just looking at apache, no commits in years Apr 27 21:15:20 pffff Apr 27 21:54:28 I need to make a change here, and struggling to figure out the 'right' way to do it Apr 27 21:54:37 I want to build an image, that comes up as per normal, fresh flash Apr 27 21:54:48 but, instead of making the wireless an ap in network lan Apr 27 21:54:58 I want it to set up client mode interface, in network wan Apr 27 21:55:09 so, just two changes to the default setup, mode and network Apr 27 21:55:19 but, not sure how to get the defaults set differently Apr 27 21:55:30 so it fleshes out the rest of the /etc/wireless correctly Apr 27 21:55:33 but with those changes Apr 27 21:55:40 is there a way to do that with uci-defaults Apr 27 21:55:50 or, do I have to hack in /sbin/wifi for this ? Apr 27 22:01:43 if your device uses mac80211, you could try hacking trunk/package/mac80211/files/lib/wifi/mac80211.sh Apr 27 22:02:11 groz: you can also see from that file how the first time initialization currently happens Apr 27 22:07:17 yah, I was thinking that route was probably where I have to go Apr 27 22:07:27 was just hoping there was a magic way of playing with uci-defaults Apr 27 22:07:46 I'm trying to get a little arm board 'finished' so I can send off an image Apr 27 22:08:02 then I gotta step back and set up a big patch set for submission Apr 27 22:08:19 it's a new arm based thingy not currently supported in trunk, but I have all the basic stuff working fine on it now Apr 27 22:08:50 but this usb attach wifi has been probematic to say the least, until I figured out what the problems were Apr 27 22:08:52 and fixed them Apr 27 22:08:52 lol Apr 27 22:08:54 groz: uci-defaults should work (somewhat), they are run after wifi was detected Apr 27 22:10:33 ok, looks like those are just plain shell scripts, so, should be easy to make a couple changes at that point Apr 27 22:10:41 I'll try that, that's easiest route if it work Apr 27 22:21:44 hehe, kanji, that seems to have worked just nice Apr 27 22:21:46 thanks Apr 27 22:47:07 groz: the only gotcha is that uci-defaults scripts are executed after every flash even when keeping config, so they might modify existing configs after sysupgrade (openwrt's usually don't since they create the config if there isn't one, but don't modify any existing ones) Apr 27 22:51:45 hmm, ok, I'll figure out a way to deal with that Apr 27 22:51:52 thanks for the heads up Apr 27 22:54:24 I'll make my uci-default first check, that it's chaning the 'stock out of the box default' Apr 27 22:54:34 and do nothing if it's not set to OpenWrt as the ssid Apr 27 22:54:38 solves that problem nicely Apr 27 22:56:49 this is just a one-off hack I need to get done today Apr 27 22:56:52 and this will work Apr 27 23:38:58 i just updated my build root to the latest trunk and mostly got everything working again. There's one new problem, though: when booting, I get this: [ 0.580000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only Apr 27 23:39:27 i've looked around and lots of people seem to just ignore that warning. however, my file system is, in fact, read only. Apr 27 23:40:35 i don't think it's from the image being too large and not having enough erase blocks (fw = 3.3 MB, flash = 4MB; previously worked fine with 3.4MB image) Apr 27 23:45:17 is that warning really OK to ignore? is there something else that can cause mounting the root fs read-only? Apr 27 23:48:22 brnt: that's normal and expected for squashfs images (squashfs is a readonly filesystem). jffs2 images have their rootfs aligned to the erase block size, so with those images there should be no warning Apr 27 23:49:59 kanjimonster: thx. does anything else come to mind that could be causing changes to files to not persist across reboots? (which i assumed was due to RO file system) Apr 27 23:51:03 brnt: if the image is too large, you should get an error in dmesg ("Too few erase blocks"), you should maybe check that first Apr 27 23:51:20 do you have a rootfs_data? Apr 27 23:51:56 kanjimonster: i've seen that in the past when my image was too large. no erase block messages this time. Apr 27 23:52:07 okay Apr 27 23:52:08 yes on rootfs_data Apr 27 23:53:47 what does mount say? Apr 27 23:54:26 you should see a jffs2 partition mounted to /overlay Apr 27 23:55:44 / dev/mtdblock6 on /tmp/overlay type jffs2 (rw,noatime) Apr 27 23:56:07 seems to think it's RW Apr 27 23:56:23 yes Apr 27 23:56:49 are you using trunk? AA? Apr 27 23:57:02 trunk Apr 27 23:57:35 selfbuilt? snapshot? Apr 27 23:58:01 self Apr 27 23:59:01 hrm Apr 27 23:59:23 being mounted on /tmp/overlay means it thinks mounting the jffs2 didn't finish yet Apr 28 00:00:03 here's something interesting…i can create a new file (/etc/config/foo) and it persists across reboot, but no changes to existing files stick Apr 28 00:01:57 what device is this? Apr 28 00:02:07 do you have any local modifications? Apr 28 00:02:35 ralink 3052-based; yes, several :-) Apr 28 00:03:06 after this most recent reboot, i now have two mounts of the same device: Apr 28 00:03:16 /dev/mtdblock6 on /tmp/overlay type jffs2 (rw,noatime) Apr 28 00:03:24 /dev/mtdblock6 on /overlay type jffs2 (rw,noatime) Apr 28 00:03:30 hrm Apr 28 00:03:36 the latter is the expected one Apr 28 00:06:59 is there something that happens during init that is supposed to unmount /tmp/overlay and mount /overlay? Apr 28 00:07:08 yes Apr 28 00:07:11 well Apr 28 00:07:16 no idea about the unmount part Apr 28 00:07:21 but I think so Apr 28 00:09:32 yeah, just checked an identical device running AA and it only has /overlay Apr 28 00:25:12 brnt, what is the device ? Apr 28 00:27:47 with the two mounts showing, its like firstboot stuff is not completed Apr 28 01:56:20 build #198 of gemini is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/198 Apr 28 01:59:15 build #235 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/235 Apr 28 02:01:59 build #235 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/235 Apr 28 02:39:36 groz: /dev/mtdblock5 (different device than registers in trunk) **** ENDING LOGGING AT Sun Apr 28 02:59:58 2013