**** BEGIN LOGGING AT Sat May 12 02:59:58 2012 May 12 10:49:25 juhosg * r31679 /trunk/target/linux/ixp4xx/patches-3.3/900-ixp4xx-crypto-include-module.h.patch: ixp4xx: fix ixp4xx_crypto build error May 12 10:49:28 juhosg * r31680 /trunk/target/linux/sibyte/ (7 files in 2 dirs): sibyte: add 3.3 support May 12 10:49:30 juhosg * r31681 /trunk/target/linux/sibyte/Makefile: May 12 10:49:30 sibyte: switch to 3.3 May 12 10:49:30 It is compile tested only, so add a broken flag. May 12 10:49:31 juhosg * r31682 /trunk/target/linux/sibyte/ (config-default patches/): sibyte: remove 2.6.37 support May 12 10:49:34 juhosg * r31683 /trunk/target/linux/iop32x/ (5 files in 2 dirs): iop32x: add 3.3 support May 12 10:49:36 juhosg * r31684 /trunk/target/linux/iop32x/Makefile: May 12 10:49:36 iop32x: switch to 3.3 May 12 10:49:36 It is compile tested only, so add a broken flag. May 12 10:49:38 juhosg * r31685 /trunk/target/linux/iop32x/config-default: iop32x: remove 2.6.37 support May 12 12:05:19 juhosg * r31686 /trunk/target/linux/ (gemini/Makefile octeon/Makefile): linux: add broken flag to remaining targets which are using 2.6.37 May 12 12:05:20 juhosg * r31687 /trunk/target/linux/generic/ (config-2.6.37 patches-2.6.37/): linux/2.6.37: R.I.P. May 12 12:05:23 juhosg * r31688 /trunk/target/linux/generic/ (config-2.6.38 patches-2.6.38/): May 12 12:05:23 linux/2.6.38: R.I.P. May 12 12:05:23 It is used only by the broken coldfire target. May 12 17:40:50 nbd * r31689 /trunk/package/mac80211/patches/560-ath9k_fix_rx_tx_stop.patch: ath9k: stop rx before tx, should reduce the frequency of "Failed to stop Tx DMA" errors May 12 17:40:56 nbd * r31690 /trunk/package/mac80211/patches/561-ath9k_fix_tid_buffer_free.patch: ath9k: fix a rare use-after-free bug May 12 17:41:02 nbd * r31691 /trunk/package/mac80211/patches/562-ath9k_update_ar9330_initvals.patch: ath9k: update initvals for ar9330 to fix issues with high power designs May 12 17:41:07 nbd * r31692 /trunk/package/mac80211/patches/563-ath9k_fix_ar9330_internal_regulator.patch: ath9k: fix ar9330 internal regulator setup May 12 18:05:05 <_trine> nbd, which routers does this affect >> ar9330_internal_regulator May 12 18:06:07 some newer single stream routers based on the ar933x chipset May 12 18:06:19 not all of them though May 12 18:06:51 no idea which specific routers though May 12 18:07:12 <_trine> ok May 12 18:07:33 <_trine> I asked you a question this morning in PM but no reply from you May 12 18:08:03 maybe the first or second of those commits will help with that issue May 12 18:08:07 (the wifi stability one) May 12 18:08:13 <_trine> I see May 12 18:12:51 https://dev.openwrt.org/attachment/ticket/8729/000-upstream-fix-mpp9.patch May 12 18:13:00 look like important May 12 18:28:53 <_trine> nbd, in relation to connecting my nanostation to a BTFON hotspot I am not sure if dhcp is working properly May 12 18:29:48 <_trine> to be able to connect to the BTFON I have to manually set the nameservers on my netbook to 192.168.22.22 192.168.22.23 May 12 18:30:03 <_trine> then it will let me log on May 12 18:30:10 <_trine> and that works ok May 12 18:31:17 <_trine> but if I then start my vpn I cant access anything which requires a nameserver until I manually set the nameservers again to somethng like 141.1.1.1 4.2.2.2 May 12 18:31:57 <_trine> should it not be the case that my router when vpn is running supply the nameservers May 12 18:31:58 the part after starting vpn is normal May 12 18:32:17 since the vpn is probably overriding your route to that ip May 12 18:32:34 <_trine> I can ping the routers lan IP May 12 18:32:44 <_trine> from my remote netbook May 12 18:32:51 and did you put in the router's lan ip as dns? May 12 18:32:55 <_trine> yes May 12 18:33:00 and that didn't work? May 12 18:33:03 <_trine> no May 12 18:33:06 odd May 12 18:33:14 <_trine> thats my point May 12 18:33:56 <_trine> push "dhcp-option DNS 192.168.123.254" May 12 18:34:03 <_trine> is that what you mean May 12 18:34:19 no May 12 18:34:22 <_trine> 192.168.123.254 is my routers IP May 12 18:34:41 <_trine> please educate me :) May 12 18:35:02 you're giving me confusing info May 12 18:35:06 what's 192.168.22.22? May 12 18:35:32 <_trine> those are the nameservers which the BTFON system uses May 12 18:35:54 <_trine> the BTFON will only work with those and no others May 12 18:36:18 <_trine> the BTFON hotspot belongs to someoneelse May 12 18:36:23 ok, since i don't know anything about your network, i have to ask: May 12 18:36:29 you're using the nanostation as main router? May 12 18:36:34 <_trine> yes of course May 12 18:36:49 <_trine> opps that was out of sinc May 12 18:36:53 and if you set your dns manually to 192.168.123.254 before the BTFON login, what happens then? May 12 18:37:19 <_trine> in this case I am using the nanostation just to connect to the remote hotspot May 12 18:37:40 <_trine> and then I feed the link into my netbook May 12 18:37:48 <_trine> via rj45 May 12 18:37:51 ok, but you get dhcp from the nanostation? May 12 18:38:06 <_trine> my main router is at home its a wndr3700 May 12 18:38:23 <_trine> yes May 12 18:38:33 <_trine> dhcp from nano May 12 18:38:40 so 192.168.123.254 is the nano or the main router? May 12 18:39:22 <_trine> 192,168,123,254 is the main router(wndr3700) at home which is runnng the openvpn May 12 18:39:52 <_trine> and the netbook connected to the nano is the client May 12 18:40:18 and you tried putting in the dns server of the nano before bt login? May 12 18:40:45 <_trine> I dont understand you last sentence May 12 18:41:07 you can only log into the btfon hotspot if you are either directly or indirectly using its dns server May 12 18:41:18 <_trine> yes May 12 18:41:19 when getting dhcp from the nano, you should get the dns server pointed to the nano as well May 12 18:42:32 <_trine> it does not give me the BTFON naMeservers I have to echo them manually to /etc/resolv.conf on my netbook May 12 18:42:59 well, normally you shouldn't need to use the BTFON nameserver directly May 12 18:43:05 you should be able to just use the nano as dns server May 12 18:43:07 <_trine> its something odd about BTFONS May 12 18:43:13 and it should forward your dns requests to the BTFON May 12 18:43:24 have you tried using the nano as dns server? May 12 18:44:05 <_trine> it is a dns isnt it May 12 18:44:11 <_trine> the nano that is May 12 18:44:22 ? May 12 18:44:27 <_trine> I dont have ignore 1 on the lan May 12 18:44:34 ? May 12 18:44:48 <_trine> how do i use the nano as a dns then May 12 18:45:03 <_trine> isnt that just dnsmasc May 12 18:45:12 yes, it is just dnsmasq May 12 18:45:20 and it should act as a dns server in the default configuration May 12 18:45:25 <_trine> is that not running anyway May 12 18:45:32 my question is if you actually *used* it May 12 18:45:50 <_trine> you mean like udhcpc -i eth0 May 12 18:46:04 ? May 12 18:46:07 <_trine> or am I missing something May 12 18:46:11 i think you are May 12 18:46:17 <_trine> how do i use it May 12 18:46:34 resolv.conf... May 12 18:46:39 on your netbook... May 12 18:46:58 * danmackay laughs quietly May 12 18:47:22 <_trine> danmackay, feel free i dont mind May 12 18:48:14 <_trine> do you mean to put the ip address of the nano in the netbooks /etc/resolve.conf May 12 18:48:28 yes May 12 18:49:44 <_trine> I dont think it worked when i tried it but i will give it another try,, one of the problems I have been having is that these BTFON hotspots sometimes are not working although you can connect to them May 12 18:50:06 <_trine> it gets a bit confusing with them May 12 18:51:59 <_trine> I thought that push "dhcp-option DNS 192.168.123.254" should have worked when when i had the vpn working May 12 18:53:59 i need to be less of a moron an dput a vpn on my vps May 12 18:54:08 <_trine> I just checked I do have the nanos ip address in the /etc/resolv.conf and it does not work May 12 18:54:52 <_trine> something isnt working properly May 12 18:56:53 ahh it works finally :p after a full erase of flash May 12 18:57:12 uname -a May 12 18:57:12 Linux OpenWrt 3.3.5 #1 Sat May 12 20:43:26 CEST 2012 armv5tel GNU/Linux May 12 18:59:19 echo "timer" > /sys/class/leds/wan\:green/trigger May 12 18:59:22 :) May 12 19:03:38 <_trine> well nbd I was correct I just tried is again with echoing the namesevers manually I cannot resolve any names even though I have the nanos ip in /etc/resolv.conf May 12 19:03:59 could be nice to prevent the delete of .git in kernel build tree May 12 19:04:13 to save time May 12 19:04:19 <_trine> incidentally it does all work if i connect to any other type of wifi May 12 19:04:49 <_trine> this symptom is just peculiar to connecting to a BTFON May 12 19:05:45 <_trine> in the case of me connecting the nano to say your wifi on a normal AP it works May 12 19:06:04 <_trine> so why am I having this problem with a May 12 19:06:10 <_trine> BTFON May 12 19:07:03 <_trine> maybe danmackay has the answer or does he just continually laugh quietly in a corner before they come to take him away May 12 19:07:06 <_trine> ;) May 12 19:08:45 http://epsy.ath.cx:888/paste/?447 May 12 19:15:22 <_trine> nbd, do you have any ideas why this isnt working with BTFON's May 12 19:16:07 no May 12 19:16:22 <_trine> I can get it to wourk if i manually insert the nameservers but really i dont think I should have to do that if it was all working properly May 12 19:17:24 <_trine> when I am connected via vpn should not my main router (wndr3700) provide name resolving May 12 19:17:35 <_trine> and not the nano May 12 20:10:55 * swalker wonders who wants to bump openssl, https://www.openssl.org/news/secadv_20120510.txt May 12 20:27:53 and fix the -fpic flag for armv5t :p May 12 21:48:40 hmm have anyone heared something from the ubicom devs before they taken down theire dev portal ? May 12 21:49:14 ubicom has been bought by qualcomm May 12 21:49:16 * Willienl thinks about follow the company strategy.. open the bin and drop it. May 12 21:49:45 nbd: jup i have seen that last week.. also seen a kernel patch that possible fix the switch chip troughput bottle neck afther watching youtube May 12 21:50:02 but looks like from that point development stalls again May 12 21:50:24 last code kinda missing a lot compared to the sdk i have -> https://www.codeaurora.org/git/projects/ubicom?jump=repository May 12 21:50:26 i don't think there'll be any effort to add full support for the existing ubicom ip7k chips May 12 21:50:36 it's just not worth it May 12 21:50:38 no-mmu sucks May 12 21:50:42 nbd: i wondered why dlink replaced ip7k with ar7 ... May 12 21:50:56 then noticed ar7 atheros -> qualcomm May 12 21:51:17 thats mips i guess. unsure if all theire soc's are mips but those that i remember are May 12 21:52:41 nbd: also i can use a gpio host for abuseing but that was one of the problems i bumped in.. no clue how they have done it.. :) May 12 21:53:40 i think ubicom failed.. also this move fixed future dissapointments while they had a nice concept wich was lacking documentation May 12 21:55:02 nbd: going for a rb750 (same price) was a better move in the end.. May 12 21:55:09 or some tplink May 12 22:19:27 swalker * r31693 /packages/net/samba36/Makefile: [packages] samba36: add source url for old versions May 12 23:16:21 build #13 of kirkwood is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/13 May 12 23:59:14 hauke * r31694 /trunk/target/linux/brcm47xx/patches-3.3/ (2 files): May 12 23:59:14 brcm47xx: fix tg3 ssb patch May 12 23:59:14 Now tg3 works with the Ethernet core of the Linksys WRT610N v1 (again). May 13 00:08:14 hauke * r31695 /trunk/target/linux/generic/ (5 files in 5 dirs): May 13 00:08:14 kernel: ssb: add PCI IDs 0x4322 and 43222 May 13 00:08:14 The 0x4322 ID is found on the BCM4322 used on some SoCs like the May 13 00:08:14 Linksys WRT610N V1 connected to a BCM4705. The 43222 (0xa8d6) ID May 13 00:08:14 is found on the BCM43222 used on some other SoCs like the D-Link May 13 00:08:14 DSL-2760U connected to a BCM63xx. May 13 00:08:15 This fixes #10887. May 13 00:16:58 hauke * r31696 /trunk/target/linux/brcm47xx/image/Makefile: brcm47xx: generate image for Linksys WRT610N V1 May 13 00:36:20 ew linksys routers :P May 13 01:40:08 build #15 of iop32x is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/15 **** ENDING LOGGING AT Sun May 13 02:59:59 2012