**** BEGIN LOGGING AT Tue Jul 06 02:59:58 2010 **** BEGIN LOGGING AT Tue Jul 06 08:26:14 2010 Jul 06 11:17:43 acoul * r22074 /trunk/package/busybox/Makefile: package/busybox: fix sed issue with gcc-4.5.0 (closes #7566) Jul 06 12:40:09 nbd * r22075 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_main.c: ar71xx: only reinit the ethernet MAC at .open() on ar724x for now, until we've figured out what part of it causes the issue described in #7563 Jul 06 12:42:01 nbd * r22076 /branches/backfire/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_main.c: [backfire] ar71xx: backport ethernet regression fix from r22075 Jul 06 14:10:43 hi, has anyone tried editing a wireless network with the current version of luci (trunk)? "Administration -> Network -> Wifi" i'm getting the following error: http://pastebin.com/WJpYPN2d Jul 06 15:18:25 problem had to do with mac80211 see: https://lists.openwrt.org/pipermail/openwrt-devel/2010-July/007455.html Jul 06 15:19:58 the net:wlan0 vs wlan0 may make sense Jul 06 15:20:08 however the radio0 -> wlan0 part is completely wrong Jul 06 15:20:47 radio0 is just a placeholder name for assigning virtual interfaces to radio interfaces Jul 06 15:20:52 it has no basis in sysfs or anything else Jul 06 15:21:25 and it was intentionally named differently, so that it would not be confused with phy0 or wlan0 Jul 06 15:21:48 nbd: hmm but when i'm using radio0 in /etc/config/wireless luci doesn't work Jul 06 15:21:57 then maybe there's a bug in luci Jul 06 15:22:03 but radio0 is definitely correct Jul 06 15:23:07 are there any luci developers in this irc channel? Jul 06 15:23:16 yes Jul 06 15:23:17 xMff is Jul 06 15:31:18 ah, there already seems to be a bugreport for this problem: http://luci.subsignal.org/trac/ticket/125 jow_laptop, are you the owner of this ticket? Jul 06 15:40:37 acoul * r22077 /packages/utils/psmisc/Makefile: utils/psmisc: fix fownload site (thanks faulpelz) Jul 06 15:49:04 qecko: could you please try this patch? http://nbd.name/mac80211-sh-fix.patch Jul 06 15:49:19 it should fix the net:wlan0 vs wlan0 issue without breaking older kernels Jul 06 15:56:49 nbd: i'm currently recompiling but i can test your patch manually after the device rebooted Jul 06 16:15:05 nbd: seems working but i think you can omit the "grep" and instead using only sed, even if its slightly slower, alternatively: "grep net: | cut -d':' -f2" ;) Jul 06 16:59:29 nbd: i have to revert my statement... your patch doesn't work... just found a new interface "wlan1" Jul 06 17:00:49 any idea what's wrong with it? Jul 06 17:02:12 nbd: hmm it looked fine, but i gotta go now... i can fix this in the next days Jul 06 17:44:50 nbd: even my old version doesn't work... the wireless network is shown on my laptop but i cannot connect anymore... there must have been several changes cz it worked with kernel 2.6.32 Jul 06 17:45:42 nbd: do you know a point where i can start debugging? ifconfig shows TX bytes but zero RX bytes Jul 06 17:48:47 well, first we need to make sure that the interface create/destroy stuff works properly Jul 06 17:48:53 then we'll debug the other issue Jul 06 17:54:13 build #70 of ep93xx is complete: Failure [failed compile] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/70 Jul 06 17:55:12 nbd: this part seems to work but i get this error: "command failed: Too many open files in system (-23)" when executing "wifi restart" Jul 06 17:55:35 right after "br-lan: port 2(wlan0) entering disabled state" Jul 06 17:55:44 try to find out which command produces this error Jul 06 17:55:46 using sh -x Jul 06 18:05:34 nbd: i had wlan1 in sysfs, but no wlan0.. i restarted and the errors are gone Jul 06 18:06:00 iteration seems to work: phy phy0, wlan0 ($phy $wdev) Jul 06 18:06:54 nbd: but its not possible to connect to the wlan Jul 06 18:09:16 ok Jul 06 18:11:58 changing the ssid of the wlan works... i selected no encryption now, but wlan0 has zero RX... seems if there are no packets received Jul 06 18:20:08 nbd: client mode, even with wpa2-psk works fine Jul 06 18:20:23 interesting Jul 06 18:23:56 plus - ap mode was working with kernel 2.6.32... but you got no idea nbd, ain't ya? Jul 06 18:25:39 qecko: what device are you using? Jul 06 18:26:42 Hauke: OpenRISC Alekto with Atheros AR2413 (ath5k), but i think the wireless card is more important than the actual device ;) Jul 06 18:27:32 qecko: I have not read your full conversation but this looks like the similar to the problem I have on my device Jul 06 18:27:59 qecko: does AP mode work with kernel 2.6.32 but with 2.6.33 and later ist does not any more Jul 06 18:28:01 ? Jul 06 18:28:31 yep... i guess its a problem with mac80211 introduced in 2.6.33 Jul 06 18:28:51 but it may have something to do with hostapd too Jul 06 18:29:12 qecko: the ssid is broadcasted, so the clients are able to see the AP, but thes are unsable to connect? Jul 06 18:29:27 s/unsable/unable Jul 06 18:29:32 Hauke: exactly Jul 06 18:30:00 qecko: om then it is the same problem I have on a Asus wl-500GP with b43 driver Jul 06 18:30:08 weird stuff Jul 06 18:30:18 nbd: is ath9k working? Jul 06 18:30:27 i haven't tested it with newer kernels yet Jul 06 18:31:17 qecko: so are you guys going to submit the openrisc alekto support to openwrt? Jul 06 18:31:22 I tried hostapd with the b43 driver on my laptop and there it worked Jul 06 18:31:30 you're from a company that makes boards with this SoC, right? Jul 06 18:32:09 nbd: yep :) i already submitted all patches for 2.6.32 and it was working stable but now i'm working on AlektoLAN which has basically more lan ports Jul 06 18:33:16 ah, right. just found it on the list Jul 06 18:33:42 maybe i'll take a closer look at that stuff once i'm done with my mac80211 ampdu rewrite Jul 06 18:34:46 ok, fine... i think i'll be back at friday Jul 06 18:35:00 with 'that stuff' i meant the platform port Jul 06 18:35:10 i would like to get the other bug fixed earlier than that Jul 06 18:35:10 ;) Jul 06 18:35:26 okay :) Jul 06 18:35:59 so, my wild guess is that something broke the cooked monitor interface Jul 06 18:36:16 that would explain the difference between ap and client mode Jul 06 18:36:38 Hauke: can you try if b43 also works in client mode on your wl-500gp? Jul 06 18:36:46 or did you try that already? Jul 06 18:36:49 hm, i never had a clue what the wlan0.mon interface is good for ;) Jul 06 18:37:27 nbd: I tried but the devices is quiet far away from the access poit Jul 06 18:37:31 i will retry Jul 06 18:38:29 qecko: probe requests and stuff like that is not handled in mac80211 Jul 06 18:38:34 qecko: hostapd handles this Jul 06 18:38:47 mac80211 will forward any frames that it did not handle into the cooked monitor interface Jul 06 18:38:50 so that hostapd can process it Jul 06 18:41:25 nbd: I added a printk into the handler for tx requests and it was calle only one time at the beginning Jul 06 18:41:38 s/calle/called Jul 06 18:41:47 when running hostapd Jul 06 18:41:51 since it works on a pc, let's see if any of the openwrt patches break it Jul 06 18:42:00 the most likely candidate would be 240-packet_socket.patch Jul 06 18:42:09 i mean 240-packet_socket_type.patch Jul 06 18:42:13 try reverting that in your kernel tree Jul 06 18:42:32 just patch -p1 -R < patches/generic/240-* in build_dir/linux-* Jul 06 18:42:42 ok, then it really may have something to do with that... but i finally gotta go now... thank you a lot, nbd :) Jul 06 18:42:56 you're welcome Jul 06 18:43:07 hope i'm back at friday... if not cu next week :) Jul 06 18:43:21 Hauke: do you have time to try this? Jul 06 18:43:34 nbd: yes I wil try this Jul 06 18:43:37 ok, thx Jul 06 18:45:06 heh Jul 06 18:45:23 it looks like somebody may have broken this particular patch while forward porting it to 2.6.33 Jul 06 18:46:49 oh yes Jul 06 18:46:55 looking at the long it was a collective effort Jul 06 18:47:12 matteo committed the updated patch, but left out one chunk that didn't apply Jul 06 18:47:26 then florian tried to fix it and optimize it at the same time Jul 06 18:47:31 but the optimization was wrong Jul 06 18:47:40 and most likely led to this particular issue Jul 06 18:47:56 yes, it makes sense to me now Jul 06 18:49:07 nbd: what is wrong with the patch? Jul 06 18:49:35 when florian added back the pkt_type field to the struct packet_sock, he added it like this: Jul 06 18:49:38 + __u8 pkt_type:3; Jul 06 18:49:49 while in the previous version it was: Jul 06 18:49:49 + unsigned int pkt_type; Jul 06 18:50:20 and a 3-bit bitmask is not enough to cover all possible packet types that one wants to filter Jul 06 18:50:35 i think specifically mac80211 uses its own packet types Jul 06 18:50:43 which go beyond the standard kernel packet types Jul 06 18:50:52 so it makes sense that mac80211 is affected, while other stuff works fine Jul 06 18:51:35 * nbd repairs the damage... Jul 06 18:52:03 nbd: ah Jul 06 18:53:51 nbd * r22078 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: mac80211: fix interface teardown for kernels >= 2.6.33 Jul 06 18:53:57 nbd * r22079 /trunk/target/linux/generic/ (3 files in 3 dirs): Jul 06 18:53:57 repair the damage that was done to the packet socket type filter patch when it was forward ported to 2.6.33 Jul 06 18:53:57 this should fix the mac80211 problems in 2.6.33 and later versions Jul 06 18:54:20 should work now ;) Jul 06 19:02:57 nbd: after removing patch 240-... the tx callback gets called more often, but I am not able to connect Jul 06 19:03:13 nbd: But taht could also be a result of some of my other changes Jul 06 19:03:26 nbd: I will try with a refresh kernel Jul 06 19:16:12 nbd: now it works for me with kernel 2.6.34 Jul 06 19:25:35 cool Jul 06 20:13:35 build #67 of mpc52xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/67 Jul 06 20:50:50 hauke * r22080 /trunk/target/linux/generic/ (config-2.6.30 config-2.6.34): kernel: add missing config option found by buildbot Jul 06 21:24:22 build #5 of at91 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/5 Jul 07 01:09:47 jow * r22081 /packages/net/tcpdump/ (3 files in 2 dirs): [packages] tcpdump: properly handle iface names with leading digits (#7572) **** ENDING LOGGING AT Wed Jul 07 02:59:56 2010