**** BEGIN LOGGING AT Tue Jan 12 02:59:56 2010 Jan 12 03:10:05 nbd * r19110 /trunk/package/mac80211/ (13 files in 2 dirs): mac80211: upgrade to a new unofficial snapshot based on wireless-testing+wireless-2.6 Jan 12 03:10:14 nbd * r19111 /trunk/package/mac80211/patches/570-monitor_queue_select_fix.patch: mac80211: another minor fix to monitor mode queue selection Jan 12 03:50:27 xMff: and while at it I enhanced wpa_supplicant.sh so that it can handle WEP keys as well - https://dev.openwrt.org/ticket/6493 Jan 12 09:17:50 stintel: great Jan 12 12:16:40 hrrrmm, fun when gdb hard hangs your machine :/ Jan 12 14:40:41 swalker * r19112 /packages/mail/ssmtp/Makefile: [packages] ssmtp: update to 2.64 (#6467) Jan 12 22:12:55 stintel: ping Jan 12 22:14:37 stintel: currently reviewing your mac80211 wep patch, any particular reason why you don't quote keystring anymore? I think about keys with special chars like $, \ or ` Jan 12 23:14:32 xMff: I had to because otherwise iw wouldn't accept the keystring in case of multiple keys Jan 12 23:15:15 hmm Jan 12 23:15:41 since you have a test env around, can you test keys like "$foobar" etc. ? Jan 12 23:15:50 sure Jan 12 23:16:02 I'll fire up the machine Jan 12 23:16:07 no need to hurry Jan 12 23:18:46 hmm, I have to remove one of the cards in it again, phy0: POST failed Jan 12 23:18:51 I'll have to debug that issue as well Jan 12 23:19:40 maybe it would suffice to hex-escape the key Jan 12 23:20:10 ... if it starts with s: Jan 12 23:21:10 in iw it never starts with s: Jan 12 23:21:27 d:0:abcde or d:0:1234567890 are both fine Jan 12 23:21:36 the problem is, some users use option key 's:foobar' Jan 12 23:21:56 and the docs advice to always hex-encode Jan 12 23:22:03 ahh, so in case of iw, we just need to strip "s:" from it Jan 12 23:22:17 because iw will try to detect if you specified ascii vs hex key Jan 12 23:22:26 depending on the length? Jan 12 23:22:42 I haven't looked at the sources Jan 12 23:22:46 haven't read the code Jan 12 23:22:53 I see :) Jan 12 23:22:56 but it says so when giving wrong key Jan 12 23:26:57 right, if I didn't remove the quotes, sh -x wifi outputted an command "iw dev wlan0 connect ..." that failed when run from the script, but worked when pasting it. Jan 12 23:27:11 maybe I should've thought of a better way though ;-) Jan 12 23:30:49 if [ "${key:0:2}" = "s:" ]; then key="$(echo -n ${key#s:} | hexdump -e '"%02x" ""')"; fi Jan 12 23:31:05 something like that should be enough to support s:... and get rid of unsafe chars Jan 12 23:35:44 shouldn't it be echo -n "${key#s:}"? Jan 12 23:35:57 ah right Jan 12 23:36:06 the quotes again Jan 12 23:36:25 and is key:0:2 supported by busybox? Jan 12 23:36:29 yes Jan 12 23:36:31 ok Jan 12 23:36:32 just tested Jan 12 23:37:34 are you sure the hexdump command is correct? Jan 12 23:37:43 i'm seeing weird results with it when i test it on my host Jan 12 23:37:54 echo FOO | hexdump -e '"%02x" ""' Jan 12 23:37:58 a4f4f46 Jan 12 23:38:14 that looks completely wrong Jan 12 23:38:27 big endian? Jan 12 23:38:36 little endian Jan 12 23:39:28 what about this: echo -n FOO | hexdump -e '58/1 "%02x" ""' Jan 12 23:39:59 hm this creates padding Jan 12 23:40:21 and leaving out the numbers results in a trailing 00 Jan 12 23:40:30 at least in busybox Jan 12 23:42:18 hexdump -ve '1/1 "%02x"' Jan 12 23:42:21 that should work Jan 12 23:42:41 yep Jan 12 23:45:27 I'll try to update my patch with the suggestion above ;-) Jan 12 23:45:46 http://openwrt.pastebin.com/m4ef9fe77 Jan 12 23:47:47 ah, you convert it to hex right away and then pass it to iw Jan 12 23:48:37 if s:foo then it is converted to hex, else check whether it is hex and fail if it contains non-hex chars Jan 12 23:48:59 this should also be consistent with documentation and common usage Jan 12 23:49:19 ok. it shouldn't be necessary as iw accepts also the ascii string, but I guess this might be cleane Jan 12 23:49:36 ok Jan 12 23:49:37 ah hmm Jan 12 23:49:50 and I'm all in favour of consistency ;-) Jan 12 23:49:51 I still wonder how iw differentiates between ascii and hex Jan 12 23:50:07 must be based on length Jan 12 23:50:32 5 -> ascii, 10 -> hex, 13 -> ascii, 26 -> hex ... Jan 12 23:51:01 or does it accept three or four character strings as well? Jan 12 23:51:15 switch (strlen(keydata)) { Jan 12 23:51:24 allright Jan 12 23:51:44 then just add the s: thing and let iw handle the rest Jan 12 23:51:52 ok Jan 12 23:53:03 wep is strange :P Jan 12 23:53:08 it is ;-) Jan 12 23:54:56 but I need it sometimes, whenever I need to do presentations or trainings that involves more pc's than just my laptop, I like to simulate the network I used to build the demo setup. and at some places they only have a wan link with fugly wep encryption :-) Jan 12 23:55:28 s/with/accessible through/ Jan 12 23:59:06 yeah, the joy of legacy Jan 13 00:01:58 so I added two changes to handle keys if they start with s: Jan 13 00:02:32 but I'm not sure I understand how to fix the problem with the keystring without removing the quotes Jan 13 00:04:30 you could check the key length and the characters Jan 13 00:04:38 xMff: does http://openwrt.pastebin.ca/1749011 look alright for the s: part ? Jan 13 00:05:06 if it is 10 or 26 and does not contain characters other than a-f and 0-9 then leave it alone, else hex-encode it Jan 13 00:05:44 and maybe the key checking should be moved to a procedure Jan 13 00:05:57 then it can be shared between madwifi, broadcom and mac80211 Jan 13 00:06:20 almost Jan 13 00:06:25 ckey="${key#s:}" -> ckey="${ckey#s:}" Jan 13 00:06:46 indeed Jan 13 00:11:07 I'll just try with hex-encoding the individual keys before they're appended to $keystring, my test keys are hex anyway. but I fear that will not fix the problem with multiple keys Jan 13 00:13:50 http://openwrt.pastebin.com/m17c28d2a Jan 13 00:14:26 oops Jan 13 00:14:48 http://openwrt.pastebin.com/m59e126b4 Jan 13 00:18:40 test: http://openwrt.pastebin.com/m255c1b24 Jan 13 00:18:59 I guess that could go in /sbin/wifi ? Jan 13 00:19:12 I mean, that proc Jan 13 00:19:38 or /etc/functions.sh Jan 13 00:19:49 but /sbin/wifi sounds fine for wifi related stuff Jan 13 00:20:13 I'd vote for that too ;-) Jan 13 00:22:09 xMff: shall I create a new ticket just for the prepare_key enhancement ? Jan 13 00:22:20 stintel: put everything in one patch Jan 13 00:22:30 ok Jan 13 00:23:02 one minor issue, if one really wants s: in his key he now must specify "s:s:123" :) Jan 13 00:23:09 but that is okay imo Jan 13 00:23:12 or Jan 13 00:23:37 we could just check the length, and have the user never put s: in his key for ascii keys Jan 13 00:23:59 with iwconfig we could just add s: if lenght = 5 or the other ascii lenght Jan 13 00:24:09 s/ht/th/ Jan 13 00:24:33 but that would change the way it is currently, I understand Jan 13 00:24:37 and that might upset users ;-) Jan 13 00:25:22 users will do it wrong anyway Jan 13 00:25:25 :) Jan 13 00:25:35 no matter how much effort you put into it Jan 13 00:26:09 I mean we just advice to hex-encode anyway, this way nothing mangles they key Jan 13 00:26:27 -y Jan 13 00:27:07 hehe Jan 13 00:28:48 gee maybe I should actually plug my testbox into my switch and configure some static IP on an extra interface, coz going around desktop -> laptop (wifi) -> test machine (utp) sure isn't helping my productivity lol Jan 13 00:31:25 oh and rename the procedure to prepare_wep_key or so Jan 13 00:31:39 because I think I'll do the same for wpa later Jan 13 00:32:02 ok Jan 13 00:32:47 btw, what do you think of the patch for wpa_supplicant.sh ? I don't think it's actually needed, but since I saw that comment in mac80211.sh I guess it was somehow planned just not added Jan 13 00:33:23 and well while I was fooling around with WEP anyway, I was able to test if it would work :-) Jan 13 00:35:09 xMff: there will still be a problem when multiple wep keys are used Jan 13 00:35:09 it makes sense Jan 13 00:35:17 xMff: http://openwrt.pastebin.com/maf41886 Jan 13 00:35:25 look at the bottom Jan 13 00:35:41 the iw command key constructed there, works if I paste it in cli Jan 13 00:36:01 that's the reason why I removed those quotes Jan 13 00:36:07 but there has to be a better solution Jan 13 00:36:33 well now since the keys are escaped you need to quote the variable in the final command line Jan 13 00:36:40 erm Jan 13 00:36:47 I think it sees 2222222222 1:2222222222 2:3333333333 3:4444444444 as the whole entire key for 0: Jan 13 00:36:47 you do not need to quote anymore I meant Jan 13 00:36:55 ah Jan 13 00:37:08 so it should be save to just remove those quotes Jan 13 00:37:13 yes Jan 13 00:37:30 that was the whole point of the procedure (apart from s:) Jan 13 00:38:07 ah, yeah well, I'd have to say I never wrote bash scripts where I needed such "complexity", hence it all looks a bit strange Jan 13 00:38:20 yeah I understand that Jan 13 00:38:22 or uncomfortable, or what's the word I'm looking for ;-) Jan 13 00:38:45 (b)ash is pretty limited when it comes to string filtering Jan 13 00:39:12 and it is very easy to accidentally inject code Jan 13 00:39:50 the only thing I used several times is the ${var#something} to mass rename (or convert) files with a onliner ;-) Jan 13 00:39:53 one*liner Jan 13 00:41:20 the thing is, people are advised to pick secure passwords, then they end up including dollar sings and stuff and the shell tries to interpret that as code Jan 13 00:41:44 then one $ will eat up half of the key and they wonder why it does not work :) Jan 13 00:41:56 I can imagine Jan 13 00:42:21 there is also awk available in standard builds Jan 13 00:42:28 but people shouldn't bother try and find secure passwords for wep :-) Jan 13 00:42:33 but I do not really know it Jan 13 00:42:39 awk :] Jan 13 00:42:52 that's the most awesome part when giving linux training :D Jan 13 00:43:01 people go like "WTF?!!!" Jan 13 00:43:20 hehe or sed Jan 13 00:43:33 with real script files, not just some s/// Jan 13 00:43:37 yeah Jan 13 00:43:59 I'd need to consult a manual if I needed to write one right now ;-) Jan 13 00:44:34 don't try to Jan 13 00:44:55 any preference on where to put the proc in /sbin/wifi ? Jan 13 00:45:48 maybe after bridge_interface Jan 13 00:49:18 allright, I have to go to bed, will be around tomorrow again Jan 13 00:49:52 and thanks for your effort Jan 13 00:50:11 welcome Jan 13 00:50:20 thanks for the suggestions / assistance ;-) Jan 13 00:50:24 and have a good night Jan 13 00:52:18 one final thing, in the trace you posted earlier... the second key (222...) appears twice and 111... is missing Jan 13 00:52:20 a bug? Jan 13 00:53:25 hmm, likely. didn't ran into that the other day when testing Jan 13 00:54:00 probably caused by one of today's changes Jan 13 00:54:07 I'll verify before updating patch @ ticket Jan 13 00:54:47 okay. good night bbl Jan 13 00:57:33 lol Jan 13 00:57:36 I pressed ctrl-a Jan 13 00:57:37 damn vim Jan 13 00:57:38 for idx in 2 2 3 4; do Jan 13 01:00:09 now I understand where all these off-by-one errors come from *G* Jan 13 01:19:09 nbd: I had a nasty kernel panic with madwifi from openwrt trunk yesterday. afterwards, hal complained that hardware self-test failed (error 14, IIRC). ath5k errors with "phy0: POST failed". removing the card from the box for ~15m helped to fix it, however, after shutting down the machine and rebooting it few hours later, ath5k errored with "phy0: POST failed" again. you think this could be caused by the madwifi driver, or it's just the card Jan 13 01:20:56 maybe I should ask my question differently, should I bother debugging madwifi issues or just leave it alone and go ath5k instead Jan 13 01:29:46 what kind of hardware? Jan 13 01:40:26 nbd: D-link DWL-G520 h/w ver A1 f/w ver 2.23, lspci says AR5001X+ Jan 13 01:40:52 nbd: it's a pretty old card, actually. let me plug it back in and paste what dmesg says when ath_pci is loaded Jan 13 01:42:47 i mean in which device did you use this card? Jan 13 01:43:26 ahh. x86 testing box Jan 13 01:44:08 it's just a normal pc, the card is PCI. Jan 13 01:45:07 maybe it's simply an issue with the card Jan 13 01:47:00 pciids 168c:0013 , ath5k phy0: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41) Jan 13 02:49:54 ping [florian], kaloz **** ENDING LOGGING AT Wed Jan 13 02:59:57 2010