**** BEGIN LOGGING AT Sun Jan 13 02:59:59 2013
Jan 13 10:36:01 <stintel> dwmw2_gone: I have one more suggestion, start upsdrvctl before upsd in the init script, as upsd relies on the driver
Jan 13 10:47:26 <stintel> nbd: fyi, with r34912 reverted the problem is even worse, ~10MB/s download from wan to lan (wired), and I see load average of 9.5
Jan 13 10:47:47 <stintel> and the router becomes laggy
Jan 13 10:48:46 <stintel> and on my router, the unaligned instructions number is crazy high, 5747533 after only 23min uptime
Jan 13 10:49:06 <stintel> on my 2nd rspro with the same image, that doesn't happen
Jan 13 10:49:21 <stintel> but that isn't routing or nat, it's just a bridged AP
Jan 13 10:51:17 <nbd> ok
Jan 13 10:52:16 <stintel> and even when there is almost no traffic the number of unaligned instructions keeps increasing, about 500/s
Jan 13 10:53:22 <stintel> fyi, panic_on_oops=1 is a workaround for not rebooting after sysupgrade :)
Jan 13 10:59:32 <stintel> nbd: not sure if this helps, but when I echo 2 > unaligned_action (on the 2nd rspro), I get this: http://pastebin.com/kw7VNd4W
Jan 13 11:10:53 <builder> build #138 of rb532 is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/138
Jan 13 11:11:55 <builder> build #138 of ppc44x is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/138
Jan 13 11:13:35 <stintel> nbd: this could be related: http://www.bufferbloat.net/issues/360
Jan 13 11:18:52 <nbd> yeah, i know some bufferbloat guys have worked on more comprehensive fixes for the unaligned stuff, but they haven't produced a patch suitable for merging yet
Jan 13 11:19:06 <nbd> i think i found the critical place that kills performance
Jan 13 11:34:45 <OpenWrt-Commits> nbd r35123 trunk/Config.in * kernel: fix enabling coredump support on 3.7+
Jan 13 11:34:49 <OpenWrt-Commits> nbd r35124 trunk/target/linux/ar71xx/patches-3.7/902-unaligned_access_hacks.patch
Jan 13 11:34:49 <OpenWrt-Commits> ar71xx: extend the unaligned access hacks to a few more places that showed up in the new kernel
Jan 13 11:34:53 <OpenWrt-Commits> nbd r35125 trunk/target/linux/ar71xx/patches-3.7/220-add_cpu_feature_overrides.patch * ar71xx: add more cpu feature overrides, slightly reduces kernel size
Jan 13 11:35:00 <nbd> stintel: there, performance should be good now
Jan 13 11:35:18 <stintel> nbd: awesome, thanks
Jan 13 11:57:43 <stintel> nbd: awesome, thanks
Jan 13 12:24:46 <OpenWrt-Commits> nbd r35126 trunk/target/linux/generic/patches-3.7/305-mips_module_reloc.patch * kernel: add back the mips module relocation patch
Jan 13 12:31:53 <stintel> heh already 505922 unaligned instructions after only 5 minutes uptime, wtf is up with this box
Jan 13 12:32:18 <stintel> gonna test the performance soon, but I experienced it when downloading via steam in windows, need to reboot
Jan 13 12:34:36 <nbd> i didn't test routing, there are probably some more places to fix unaligned instructions in
Jan 13 12:35:16 <nbd> got some stack traces?
Jan 13 12:35:38 <builder> build #148 of ramips is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/148
Jan 13 12:50:14 <stintel> nbd: my router didn't like echo 2 > unaligned_action , and I have no easy way to use it's serial console
Jan 13 12:50:58 <nbd> ok
Jan 13 12:51:04 <stintel> I have some more from my AP, related to ipv6 multicast
Jan 13 12:51:31 <stintel> they are here http://stewie.be.tintel.eu/openwrt/dmesg_rspro_ap.txt
Jan 13 13:07:13 <OpenWrt-Commits> nbd r35127 trunk/target/linux/ar71xx/patches-3.7/902-unaligned_access_hacks.patch
Jan 13 13:07:13 <OpenWrt-Commits> ar71xx: avoid __packed define in the unaligned access hack patch, make the ipv6 address struct also 2-byte-aligned/packed
Jan 13 13:07:15 <nbd> try now
Jan 13 13:33:35 <dape> make target/linux/clean should be enough?
Jan 13 13:35:10 <nbd> yes
Jan 13 13:36:11 <stintel> nbd: a few more now, mostly in rawv6_rcv
Jan 13 13:36:24 <stintel> you can refresh http://stewie.be.tintel.eu/openwrt/dmesg_rspro_ap.txt to see
Jan 13 13:38:42 <stintel> and seems to go up together with the ipv6 multicast packets on my network, I am running ospf6
Jan 13 13:39:04 <stintel> 2 devices, 2 packets every 10 seconds only for that
Jan 13 13:52:24 <builder> build #128 of sibyte is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/128
Jan 13 13:59:41 <strasidlo> luka: Hello Luka, after days of fighting with asterisk11 package it finally works on mips and x86 :-)
Jan 13 14:17:05 <dape> uhm, cannot figure out where are the Makefiles for the luci-apps in my trunk
Jan 13 14:19:49 <strasidlo> luka: if you're interested, there's a patch in patchwork/mailing list :)
Jan 13 14:29:31 <stintel> nbd: next to the ones in that dmesg, on my router the unaligned instructions increase still very high when downloading anything from the internet at high speed. seen it increase by 20000 on 1-2 seconds
Jan 13 14:29:41 <stintel> and that was downloading on v4
Jan 13 14:30:07 <stintel> guess I'll have to get this usb serial thing working under os x
Jan 13 14:30:12 <stintel> and find a decent terminal app
Jan 13 14:32:32 <OpenWrt-Commits> nbd r35128 trunk/package/libs/libubox/Makefile
Jan 13 14:32:32 <OpenWrt-Commits> libubox: update to latest version, adds small blobmsg enhancements and license fixes - package is now ISC/BSD-3c
Jan 13 14:35:22 <nbd> stintel: i found quite a few more unaligned accesses and a better way to fix them
Jan 13 14:35:51 <stintel> that sounds good
Jan 13 14:55:44 <OpenWrt-Commits> nbd r35129 trunk/target/linux/ar71xx/patches-3.7/902-unaligned_access_hacks.patch
Jan 13 14:55:44 <OpenWrt-Commits> ar71xx: improve unaligned access patches, add a net_hdr_word() macro which assumes 2-byte aligned access and generates better code than {get,put}_unaligned_cpu32
Jan 13 14:55:51 <nbd> stintel: please test with that one
Jan 13 14:56:08 <stintel> nbd: on it, thanks again
Jan 13 14:56:23 <stintel> ah, waiting till 16:00 for the git sync :)
Jan 13 14:56:45 <stintel> hmm could just wget the patch too
Jan 13 15:08:40 <dangole> somehow ppp doesn't set the link-local address of an ipv6 ppp interface any longer
Jan 13 15:08:46 <dangole> i guess this was introduced with ipv6-support
Jan 13 15:08:52 <dangole> or netifd changes
Jan 13 15:09:01 <dangole> it still shows in the logs
Jan 13 15:09:42 <dangole> and after setting it with ip addr add [...] or ifconfig [...], the dhcp-client also get's the global address from my isp
Jan 13 15:11:23 <stintel> hmmm, is this something to worry about in the future? [    2.860000] ath79-spi ath79-spi: master is unqueued, this is deprecated
Jan 13 15:14:58 <stintel> nbd: fyi, this is on the AP now: http://stewie.be.tintel.eu/openwrt/dmesg_rspro_ap.txt
Jan 13 15:15:03 <stintel> I believe I see a few new ones
Jan 13 15:15:25 <stintel> in igmp_rcv and br_multicast_rcv
Jan 13 15:15:52 <stintel> might be that they were already there but not visible in dmesg because the log buffer isn't large enough
Jan 13 15:16:02 <stintel> I'll flash it on my router too now
Jan 13 15:23:24 <stintel> nbd: on the router I can still see the number increase by 20000 on 1s when downloading at ~100Mbps
Jan 13 15:24:53 <nbd> yeah, i just found an assembly checksum function in the mips include dir that is causing this
Jan 13 15:25:56 <stintel> aha
Jan 13 15:26:11 <stintel> I also have some dmesg output from my router now, with echo 2 > unaligned_action
Jan 13 15:28:05 <stintel> nbd: here is the dmesg from the router
Jan 13 15:28:11 <stintel> ehr, http://stewie.be.tintel.eu/openwrt/dmesg_rspro_router.txt
Jan 13 15:28:17 <stintel> adding the link can help :)
Jan 13 15:28:53 <stintel> or this is all invalid when the checksum function is fixed ?
Jan 13 15:29:49 <nbd> some new ones in there
Jan 13 15:30:19 <dape> weird, sometimes this happens on a pppoe wan connection (dual stack) "daemon.err pppd[8140]: Couldn’t rename ppp1 to pppoe-wan"
Jan 13 15:30:53 <dape> got it on few wr740n routers, reboot solves it
Jan 13 15:30:57 <stintel> nbd: yeah, well with all the layers and features, each of them might add to the number, explains why there are so many
Jan 13 15:32:56 <jow_laptop> dangole: anything in the logs with pppd_debug enabled?
Jan 13 15:33:20 <jow_laptop> dangole: and is the LLADDR info passed to /etc/ppp/ip-up ?
Jan 13 15:38:51 <dangole> jow_laptop: i'll go find out, brb
Jan 13 15:39:03 <OpenWrt-Commits> nbd r35130 trunk/target/linux/ar71xx/patches-3.7/902-unaligned_access_hacks.patch * ar71xx: fix unaligned access in a few more places
Jan 13 15:50:21 <stintel> nbd: looking good on the AP at least, have 89 unaligned instructions on 4 min uptime
Jan 13 15:50:29 <stintel> before it was about 100 /min there
Jan 13 15:51:01 <stintel> and now 1 min later still 89
Jan 13 15:51:14 <nbd> ok, so i guess i don't need to make any further changes
Jan 13 15:51:20 <nbd> unaligned accesses are only problematic if they're in a hotpath
Jan 13 15:51:44 <stintel> I'll flash it on the router now and see what it gives there
Jan 13 15:58:10 <OpenWrt-Commits> nbd r35131 trunk/package/libs/ ustream-ssl ustream-ssl/Makefile * add ustream-ssl, an ustream abstraction library for SSL stream sockets
Jan 13 16:03:46 <stintel> nbd: http://stewie.be.tintel.eu/openwrt/dmesg_rspro_router.txt
Jan 13 16:03:55 <stintel> tc_classify_compat
Jan 13 16:04:41 <stintel> dmesg | grep "ra    :" gives only those
Jan 13 16:05:06 <stintel> (for now, I did echo 0 > unaligned_action already to not crash the router)
Jan 13 16:34:42 <dangole> jow_laptop: wow, this whole 6relayd, 6distributed, ipv6-support story is a mess
Jan 13 16:34:59 <dangole> jow_laptop: i've been using wide-dhcp6c and radvd. worked really nce
Jan 13 16:35:21 <dangole> now this stuff polutes my network with site-local prefixes, though i have never asked it to do so
Jan 13 16:35:41 <dangole> next step will probably be to introduce NAT in ipv6, so the site-local prefix can be static
Jan 13 16:35:49 <dangole> </complain mode>
Jan 13 16:36:02 <dangole> anyway
Jan 13 16:36:53 <dangole> so /lib/netifd/ppp-up does receive correct $LLLOCAL $LLREMOTE, i added some logging to it and it gets them right
Jan 13 16:36:56 <dangole> so does pppd
Jan 13 16:37:23 <dangole> just that the ppp-interface ends up without any ipv6 LL address set, therefore dhcpv6 fails
Jan 13 16:39:23 <jow_laptop> dangole: you can disable the site local prefixes
Jan 13 16:39:44 <jow_laptop> dangole: and yes, next step will be net :)
Jan 13 16:39:47 <jow_laptop> *nat
Jan 13 16:40:03 <jow_laptop> optional of course
Jan 13 16:40:25 <jow_laptop> if you insist on using wide + radvd then don't install ipv6-support
Jan 13 16:40:34 <jow_laptop> they conflict with each other
Jan 13 16:40:47 <dangole> i installed neither of them now, wanted to try ipv6-support
Jan 13 16:41:32 <dangole> anyway, let's leave the nat66-yes-or-no discussion a side for now
Jan 13 16:41:38 <jow_laptop> so to get rid of the ula prefix, simply comment it out in /etc/config/network6
Jan 13 16:41:57 <dangole> i did that, i commented the whole global section there
Jan 13 16:42:09 <stintel> nbd: fyi, just tested download at ~100Mbps again, load still goes to ~4 on the router, but monitoring agent seems to respond a bit better than before
Jan 13 16:42:29 <dangole> still resulting in different fd29:: and fd27:: prefix being assigned to my lan interface
Jan 13 16:42:45 <jow_laptop> dangole: you need to restart 6distributed, 6relayd
Jan 13 16:42:49 <nbd> stintel: what happens to the unaligned instructions counter?
Jan 13 16:42:57 <dangole> jow_laptop: i did reboot
Jan 13 16:43:19 <stintel> nbd: on the Ap is still on 89, on the router still goes up during download
Jan 13 16:43:30 <jow_laptop> dangole: I left the global section and commented out the ula option, don't get any such addresses in my network
Jan 13 16:43:35 <dangole> and i wouldn't mind an additional site-prefix network to run there, also as a way to reach the openwrt box through local ipv6 if my wan interface is down
Jan 13 16:43:41 <nbd> stintel: ok, so probably a few more things to fix on the router
Jan 13 16:43:48 <stintel> nbd: did you refresh http://stewie.be.tintel.eu/openwrt/dmesg_rspro_router.txt ?
Jan 13 16:43:56 <stintel> there is 1 more: tc_classify_compat
Jan 13 16:44:06 <stintel> it's the only one I see
Jan 13 16:44:29 <nbd> please show me /proc/modules from that router
Jan 13 16:44:41 <dangole> jow_laptop: but it should be done with multi-homing, so once the ipv6 wan is up, local machines also get a global address
Jan 13 16:45:18 <stintel> nbd: http://pastebin.com/2FuZVTTQ
Jan 13 16:45:26 <jow_laptop> dangole: whats reported by ifstatus wan?
Jan 13 16:45:37 <jow_laptop> dangole: it does that here
Jan 13 16:45:57 <nbd> stintel: ah, seems to be cls_u32 match
Jan 13 16:46:16 <stintel> I guess it's used by qos-scripts
Jan 13 16:48:14 <stintel> exactly, /etc/init.d/qos stop and the number no longer goes up
Jan 13 16:48:41 <dangole> jow_laptop: ifstatus wan got the $LLLOCAL address and also the default route with next-hop $LLREMOTE
Jan 13 16:48:54 <dangole> maybe netifd should assign it to the interface?
Jan 13 16:49:00 <jow_laptop> dangole: it does
Jan 13 16:49:21 <jow_laptop> dangole: I suppose ipv6-support interfered, whats your current /etc/config/network6 ?
Jan 13 16:49:24 <dangole> i remember there was a transition from pppd setting up it's interface settings by itself to netifd doing that
Jan 13 16:49:28 <OpenWrt-Commits> nbd r35132 trunk/target/linux/ar71xx/patches-3.7/902-unaligned_access_hacks.patch * ar71xx: fix unaligned access in cls_u32
Jan 13 16:49:31 <nbd> stintel: there ;)
Jan 13 16:49:42 <stintel> nbd: awesome, thanks a lot
Jan 13 16:49:48 <dangole> jow_laptop:
Jan 13 16:49:48 <dangole> config interface 'wan'
Jan 13 16:49:48 <dangole> 	option mode 'dhcpv6'
Jan 13 16:49:48 <dangole> 	option request_prefix 'auto'
Jan 13 16:49:48 <dangole> 	option prefix_fallback 'relay'
Jan 13 16:49:48 <dangole> 	option peerdns '1'
Jan 13 16:49:50 <dangole> 	option site_border '1'
Jan 13 16:49:50 <stintel> keep up the good work ;-)
Jan 13 16:49:52 <dangole> config interface 'lan'
Jan 13 16:49:54 <dangole> 	option mode 'router'
Jan 13 16:49:58 <dangole> 	option advertise_prefix '64'
Jan 13 16:50:02 <dangole> 	option relay_master 'wan'
Jan 13 16:51:58 <dangole> jow_laptop: dnsmasq also doesn't get the ipv6 nameserver which should be acquired by odhcp6c
Jan 13 16:53:40 <jow_laptop> dangole: in dhcpv6.sh, comment out conf_set "$device" disable_ipv6 1 / conf_set "$device" disable_ipv6 0
Jan 13 16:53:40 <cyrusff> dangole: we will get rid of the mess soon though i havent heard of any problems like yours until now
Jan 13 16:54:08 <jow_laptop> cyrusff: I believe the disable_ipv6 will strip pppoe ipv6 ll addreses from the underlying iface
Jan 13 16:54:27 <cyrusff> ah ok can be
Jan 13 16:54:35 <stintel> cyrusff: how can I prevent 6relayd from starting ?
Jan 13 16:54:55 <cyrusff> dont use ipv6-support
Jan 13 16:55:02 <stintel> ok :)
Jan 13 16:55:02 <cyrusff> then it wont start
Jan 13 16:56:04 <cyrusff> anyway once nbd merges the prefix stuff to netifd there will be no 6distributed etc. any more
Jan 13 16:56:35 <cyrusff> wide and radvd are even more messy though
Jan 13 16:57:38 <stintel> not using either of them here
Jan 13 16:57:50 <dangole> cyrusff: i agree, given that netifd should manage all interfaces, wide-dhcp6c creates even more of a mess
Jan 13 16:57:54 <stintel> but I tried dnsmasq6 and it couldnt start because 6relayd bound the dhcpv6s port
Jan 13 16:58:39 <jow_laptop> cyrusff: we need a less invasive way of triggering a router solicitation than disable/enable of ipv6
Jan 13 16:58:54 <jow_laptop> cyrusff: that will mess up any non-ethernet/slaac iface underneath
Jan 13 16:59:15 <cyrusff> yes i will just make a 6relayd flag that just sends a RS
Jan 13 16:59:21 <dangole> jow_laptop and cyrusff: i'll give it try with the lines commented, if everything goes fine i'll be right back
Jan 13 17:00:55 <nbd> stintel: btw. can you still crash your device by unloading ath9k in the current version?
Jan 13 17:01:57 <stintel> nbd: I think so, let me test, the AP is rebooting with my last build
Jan 13 17:02:21 <stintel> as well as oops during sysupgrade
Jan 13 17:03:39 <stintel> nbd: http://pastebin.com/WX8HBuZw
Jan 13 17:04:10 <dangole> jow_laptop: didn't do the trick :(
Jan 13 17:04:54 <jow_laptop> still no ll?
Jan 13 17:05:02 <dangole> still, my l2tp-wan interface ends up without the IPv6 LL address set
Jan 13 17:05:30 <jow_laptop> can you place an "ifconfig l2tp-wan" call there and see if the addrs are still set at this stage?
Jan 13 17:05:51 <jow_laptop> cyrusff: does 6relayd / odhcp6c anything with the ll addrs?
Jan 13 17:05:59 <nbd> stintel: odd, i can't seem to reproduce it here
Jan 13 17:06:13 <cyrusff> nope
Jan 13 17:06:46 <cyrusff> but i'll remove the disable_ipv6 stuff anyway
Jan 13 17:06:48 <nbd> stintel: what kind of wifi card do you have in there?
Jan 13 17:06:59 <dangole> jow_laptop: where to add it? in /etc/netifd/ppp-up ?
Jan 13 17:07:20 <jow_laptop> dangole: there and in dhcpv6.sh, pipe the output to logger or something
Jan 13 17:11:41 <stintel> nbd: 2x ath9k, Ubiquiti SR71a and Mikrotik r52n
Jan 13 17:12:00 <stintel> btw, root@wrt0:~# cat /sys/kernel/debug/mips/unaligned_instructions
Jan 13 17:12:00 <stintel> 45
Jan 13 17:12:06 <stintel> that's on the router :)
Jan 13 17:12:37 <stintel> sweet, just did speedtest and it's still 45, nice work!
Jan 13 17:15:30 <cyrusff> jow_laptop: can it be that with L2tp the ppp doesn't enable ipv6?
Jan 13 17:16:30 <nbd> stintel: please try this patch: http://nbd.name/ini-fix.patch
Jan 13 17:17:26 <nbd> (for package/mac80211/patches)
Jan 13 17:18:16 <jow_laptop> cyrusff: unlikely, it uses the same ppp ip-up infrastructure which offloads the address setting to netifd
Jan 13 17:18:21 <stintel> then I guessed it well ;)
Jan 13 17:19:26 <cyrusff> hmm no i rather meant the pppd parameters
Jan 13 17:19:32 <cyrusff> used when doing l2tp
Jan 13 17:26:03 <stintel> nbd: now I get more: http://pastebin.com/ZqZKquNN
Jan 13 17:26:18 <stintel> if this helps : 00:11.0 Network controller: Atheros Communications Inc. AR9160 Wireless Network Adapter [AR9001 802.11(a)bgn] (rev 01)
Jan 13 17:26:21 <stintel> 00:12.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01)
Jan 13 17:26:38 <nbd> this was after reinstalling and rebooting?
Jan 13 17:26:43 <OpenWrt-Commits> cyrus r35133 trunk/package/network/ipv6/ 6relayd/files/6relayd.init 6relayd/files/6relayd.config 6relayd/Makefile 6relayd/files/6relayd.hotplug * 6relayd: Rewrite init-script logic
Jan 13 17:26:48 <OpenWrt-Commits> cyrus r35134 trunk/package/network/ipv6/ipv6-support/ Makefile files/dhcpv6.sh * ipv6-support: don't use disable_ipv6
Jan 13 17:26:49 <nbd> reflash or module reinstall?
Jan 13 17:26:49 <stintel> nbd: oh wait
Jan 13 17:27:21 <stintel> nbd: yes
Jan 13 17:27:58 <nbd> which one?
Jan 13 17:28:11 <stintel> reflash
Jan 13 17:28:15 <nbd> ok
Jan 13 17:28:26 <stintel> and  make target/linux/clean package/kernel/clean package/mac80211/clean world -j12
Jan 13 17:28:35 <nbd> ok
Jan 13 17:28:51 <nbd> can you try if it also happens if you remove the SR71a?
Jan 13 17:30:04 <stintel> I'll have a hard time getting it back in afterwards because the pigtails are too short :P
Jan 13 17:30:12 <nbd> ok
Jan 13 17:30:14 <stintel> but let me get to it
Jan 13 17:32:58 <strasidlo> Hello, in latest revisions my x86 builds won't boot. It fails on  SQUASHFS error: xz_dec_run error, data probably corrupt, on Unable to read data cache entry.
Jan 13 17:33:23 <strasidlo> even on default config
Jan 13 17:34:25 <stintel> nbd: root@wrt1:/# rmmod ath9k
Jan 13 17:34:25 <stintel> [   98.260000] ath9k: ath9k: Driver unloaded
Jan 13 17:34:38 <stintel> nbd: seems to work fine without the sr71a
Jan 13 17:35:31 <nbd> ok
Jan 13 17:35:35 <nbd> that narrows it down
Jan 13 17:35:50 <stintel> but is it the sr71a, or is it the fact that it are two cards
Jan 13 17:36:02 <nbd> i think it's more likely that it's sr71a specific
Jan 13 17:36:14 <OpenWrt-Commits> cyrus r35135 trunk/package/network/ipv6/odhcp6c/ files/dhcpv6.sh files files/dhcpv6.script Makefile * odhcp6c: Add preliminary proto-handler
Jan 13 17:36:16 <stintel> I dont think I have another ath9k lying around :)
Jan 13 17:36:27 <nbd> because for AR9160 there is some pretty nasty code that has resisted quite a few cleanup attempts so far ;)
Jan 13 17:36:38 <nbd> but i'll dig through it again
Jan 13 17:37:03 <nbd> AR913x might be affected as well
Jan 13 17:37:13 <stintel> let me test if I also get the error on sysupgrade now (it's a different one)
Jan 13 17:38:35 <stintel> but it's not critical now that I know panic_on_oops=1 is a workaround
Jan 13 17:40:35 <stintel> nope, no error now
Jan 13 17:55:31 <nbd> ok, i think i finally found the bug
Jan 13 17:56:40 <stintel> alright, getting the sr71a back in wasn't that hard
Jan 13 17:57:10 <stintel> I just need to connect the sr71a to the pigtails, and then to the board
Jan 13 17:57:31 <stintel> that stationbox has proven to be handy
Jan 13 17:58:22 <stintel> hmmm, or not, lspci doesn't detect it, meh
Jan 13 18:02:38 <toketin> Hi, have anyone tried to use the usb dongle wifi Alfa Awus036h under openwrt?
Jan 13 18:04:31 <OpenWrt-Commits> jow r35136 packages/net/ miniupnpd/files/upnpd.config miniupnpd/Makefile * miniupnpd: update to v1.7.20121005 (#9811, #10694, #10829)
Jan 13 18:07:28 <OpenWrt-Commits> cyrus r35137 trunk/package/network/ipv6/odhcp6c/ files/dhcpv6.script Makefile * odhcp6c: Send RS on start
Jan 13 18:09:35 <nbd> stintel: new patch, same location
Jan 13 18:09:48 <OpenWrt-Commits> jow r35138 branches/packages_12.09/net/ miniupnpd/files/upnpd.config miniupnpd/Makefile * AA: miniupnpd: merge r35136
Jan 13 18:18:39 <strasidlo> mirko, luka: ping :-)
Jan 13 18:24:20 <toketin> Hi, i get this error trying to start rtl8187 module: insmod: can't insert 'rtl8187': unknown symbol in module, or unknown parameter
Jan 13 18:27:50 <toketin> what should i do?
Jan 13 18:28:11 <nbd> check dmesg
Jan 13 18:28:47 <stintel> nbd: cool, I just rmmod ath9k with 2 cards in, and it doesn't seem to crash
Jan 13 18:29:36 <nbd> please also test if the sr71a is still working properly
Jan 13 18:30:13 <stintel> ok, good point
Jan 13 18:30:24 <stintel> I have 4x the same ssid, I might never notice that it doesn't work :P
Jan 13 18:30:47 <toketin> nbd: the two lines where rtl8187 appears in dmesg are these two:
Jan 13 18:30:49 <toketin> [   12.116000] rtl8187: Unknown symbol eeprom_93cx6_multiread (err 0)
Jan 13 18:30:51 <toketin> [   12.120000] rtl8187: Unknown symbol eeprom_93cx6_read (err 0)
Jan 13 18:31:36 <toketin> the problem is that during the boot the module rtl8187 isn't loaded by default (with lsmod i can't see it)
Jan 13 18:33:10 <nbd> hm, the module has a dependency on the eeprom module
Jan 13 18:33:14 <nbd> and it's supposed to load that one
Jan 13 18:34:56 <toketin> is it a package?
Jan 13 18:35:11 <nbd> yes
Jan 13 18:35:20 <nbd> kmod-eeprom-93cx6
Jan 13 18:35:45 <toketin> ok i don't have it installed
Jan 13 18:36:48 <toketin> ok i try see you soon :D
Jan 13 18:38:11 <stintel> nbd: I disabled the 5GHz radio in the AP so my macbook connected on the 2.4 (the sr71a), I got around 50Mbps download fromt internet, so seems to work still
Jan 13 18:38:54 <nbd> great
Jan 13 18:38:57 <stintel> iperf gives 88.6Mbps
Jan 13 18:38:59 <stintel> so looks good
Jan 13 18:39:06 <stintel> it's 130Mbps max for some reason
Jan 13 18:39:19 <stintel> I guess that's OS X and 2.4 --> no 40MHz channel
Jan 13 18:39:37 <nbd> right
Jan 13 18:46:52 <stintel> Noltari: and the patch also seems to fix the kernel error after sysupgrade
Jan 13 18:46:55 <stintel> ehr
Jan 13 18:46:59 <stintel> nbd: ^
Jan 13 18:56:36 <toketin> nbd: thanks now the router recognise the usb dongle buti can't connect to the wifi
Jan 13 18:56:44 <OpenWrt-Commits> nbd r35139 trunk/package/mac80211/ (7 files) * ath9k: fix memory corruption issues on ar5416/ar91xx
Jan 13 18:56:58 <nbd> toketin: well, rtl8187 is a crappy chipset
Jan 13 18:56:59 <nbd> ;)
Jan 13 18:57:02 <toketin> wpa_supplicant tells me wlan1: SME: Authentication request to the driver failed
Jan 13 18:57:21 <toketin> nbd: yes i know that under linux it's ugly
Jan 13 18:57:43 <toketin> but i've read users able to use it
Jan 13 18:58:55 <toketin> nbd: with my archlinux i can connect using the alfa awus036h
Jan 13 18:59:13 <nbd> which openwrt version are you using
Jan 13 18:59:22 <toketin> r34388
Jan 13 18:59:37 <toketin> root@OpenWrt:~# wifi up radio1
Jan 13 18:59:38 <nbd> hm
Jan 13 18:59:39 <toketin> command failed: Operation not supported (-122)
Jan 13 19:00:11 <toketin> i had a similar problem with another usb dongle that uses the driver ath9k_htc, i've fixed with this: iw dev wlan1 del; iw phy1 interface add wlan1 type station; ifconfig wlan1 up;
Jan 13 19:00:23 <toketin> i've tried now with this rtl8187 but nothing
Jan 13 19:00:29 <toketin> same error
Jan 13 19:02:12 <swalker> updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html
Jan 13 19:16:29 <toketin> nothing it doesn't work :/
Jan 13 19:17:40 <jow_laptop> afaik that driver still uses wext so the openwrt scripts will not work
Jan 13 19:18:04 <jow_laptop> you need to set it up manually with iwconfig and wpa_supplicant -Dwext ...
Jan 13 19:20:14 <nbd> it's a mac80211 driver
Jan 13 19:20:46 <jow_laptop> ah ok, might have confused it then
Jan 13 19:21:23 <toketin> nothing also with -D wext, the output http://dpaste.com/876008/
Jan 13 19:23:45 <toketin> what can i try jow_laptop?
Jan 13 19:27:04 <jow_laptop> find out why its busy, looks like some other process is using wlan1 already
Jan 13 19:28:23 <toketin> killall hostapd?
Jan 13 19:31:45 <toketin> jow_laptop: i've tried also with these commands: iw dev wlan1 del; iw phy1 interface add wlan1 type station; ifconfig wlan1 up;
Jan 13 19:33:56 <toketin> how can i see what is using the wlan1?
Jan 13 19:37:57 <jow_laptop> in ps probably
Jan 13 19:39:03 <toketin> just "ps" as command?
Jan 13 19:39:18 <jow_laptop> ps ww
Jan 13 19:40:16 <toketin> http://dpaste.com/876015/
Jan 13 19:41:27 <jow_laptop> now look for wlan1...
Jan 13 19:41:39 <toketin> yes i've seen
Jan 13 19:41:49 <toketin>  3903 root      1724 S    wpa_supplicant -B -P /var/run/wifi-wlan1.pid -D nl80211 -i wlan1 -c /var/run/wpa_supplicant-wlan1.conf
Jan 13 19:41:51 <toketin>  3925 root      1500 S    udhcpc -p /var/run/udhcpc-wlan1.pid -s /lib/netifd/dhcp.script -f -t 0 -i wlan1 -C
Jan 13 19:42:11 <toketin> it's right because i've set "wifi up radio1"
Jan 13 19:42:44 <toketin> the same configuration is working with another usb dongle (ath9k_htc chipset)
Jan 13 19:44:34 <jow_laptop> then something is probably broken with the driver
Jan 13 19:45:01 <toketin> strange, it's working under archlinux
Jan 13 19:48:28 <builder> build #115 of iop32x is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/115
Jan 13 19:49:57 <OpenWrt-Commits> jow r35140 trunk/package/network/config/netifd/Makefile * netifd: update to git head, adds 64bit counters
Jan 13 19:50:06 <OpenWrt-Commits> jow r35141 trunk/package/ubus/Makefile * ubus: update to git head, passes u64 blob types as doubles to Lua
Jan 13 19:50:11 <OpenWrt-Commits> jow r35142 trunk/package/libs/libnfnetlink/Makefile * libnfnetlink: update to v1.0.1
Jan 13 19:54:14 <builder> build #112 of gemini is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/112
Jan 13 20:45:19 <OpenWrt-Commits> juhosg r35143 trunk/package/mac80211/patches/605-rt2x00-pci-eeprom.patch * mac80211: rt2x00: fix PCI eeprom patch
Jan 13 21:00:56 <OpenWrt-Commits> jow r35144 trunk/rules.mk * rules.mk: only select latest libgcc.a with wildcard match (#12798)
Jan 13 22:11:20 <OpenWrt-Commits> nbd r35145 trunk/package/mac80211/patches/300-pending_work.patch * mac80211: fix monitor mode injection
Jan 14 00:16:29 <OpenWrt-Commits> mazilo r35146 packages/net/ freeswitch/patches/001-build-modules_conf_in.patch freeswitch/Makefile freeswitch/files/etc.packages
Jan 14 00:16:29 <OpenWrt-Commits> Added an option to compile with latest git HEAD (default disabled). Please use this option with care. It may break he compilation.
Jan 14 00:57:55 <dangole> cyrusff, jow_laptop: doing some more logging now, I can see that pppd sets the LL addresses and they shortly after disappear. sometimes odhcp6c had already acquired an address by that time and 6distributed did it's job, but the missing LL address still prevents the interface from routing
**** ENDING LOGGING AT Mon Jan 14 02:59:59 2013