**** BEGIN LOGGING AT Wed Nov 21 02:59:58 2018 Nov 21 04:09:16 hi Nov 21 04:09:51 is it possible that the for wrt* v1 devices no power table for wifi is provided in the dts file(s)? Nov 21 04:15:45 https://github.com/kaloz/mwlwifi/issues/211 Nov 21 04:15:54 The driver doesn't support user to change power level. Nov 21 04:16:01 lol Nov 21 04:17:51 But i have the feeling, changing the power level worked some time ago Nov 21 04:18:19 shm0: are you trying to increase or decrease Tx power? Nov 21 04:18:49 decrease Nov 21 04:19:06 ok, good :-) Nov 21 04:19:12 i have the feeling the device is sending way over the allowed limit of 100mw Nov 21 04:19:51 if your regdomain is set correctly, in theory the driver will operate at the maximum the hardware supports, within the limits of the regulatory domain Nov 21 04:20:30 i hope you shouldn't have to do more than that, and that's a different question from "how to change tx power" Nov 21 04:21:00 all other devices around here that are set to 100% tx power giving me 2-3 bars. while the wrt1200ac always giving me full bars Nov 21 04:21:05 but perhaps you should mention which actual devices you're using, and someone smarter than me can help ;-) Nov 21 04:21:40 so i come to the conclusion that the device is sending with more then 100mw Nov 21 04:22:13 also when you switch antennas and use antenna_gain option to adjust the power levels accordlingly Nov 21 04:22:23 i find most devices "bars" to be a horrible indicator of signal level or quality Nov 21 04:22:32 that doesn't work either cause its not possible to lower the tx power Nov 21 04:23:30 i have the feeling Nov 21 04:23:39 mwlwifi will never work correctly Nov 21 04:24:58 how to get the old behaviour back? loading the power table from file instead from dts? Nov 21 04:26:43 i looked through some dts files and can't find any power tables there Nov 21 04:27:17 and i can't find any info online, how the layout has to be Nov 21 04:27:53 i need a fix cause this high power levels give me headaches Nov 21 04:28:10 literally Nov 21 04:30:32 shm0: find a better way to verify actual tx power (borrow a spectrum analyzer, use an android-based wifi scanner that shows actual power levels, ANYTHING beyond "bars"), confirm your selected regdomain is correct, and report a bug if EIRP is above your jurisdiction's limits Nov 21 04:34:14 even when i had a spectrum analyzer, it doesn't change the fact that it isn't possible to adjust the power levels down Nov 21 04:34:39 i can tell you that the device is sending way over 100mw cause i get this squeaking noise in my head Nov 21 04:35:39 https://pastebin.com/u6Sp3Vcu Nov 21 04:36:19 the mwlwifi dev commented it is normal that the channels are not displayed when the power table is loaded from dts Nov 21 04:36:34 shm0: ok, just ignore me. Nov 21 04:36:38 * Fishman wanders off Nov 21 04:36:40 :| Nov 21 04:37:17 how can the power table be loaded from dts file when there are no powertables in the dts files Nov 21 04:38:20 and the best part is when you v2 device with eeprom locked power table. Yeah sry it is not possible to adjust power (down). Nov 21 04:38:43 this is ridiculous Nov 21 04:38:47 marvell Nov 21 04:38:48 lmao Nov 21 04:45:04 Tx-Power: 13dBm Nov 21 04:45:04 -> Signal: -54 dBm | Noise: -90 dBm Tx-Power: 0 dBm Nov 21 04:45:04 -> Signal: -55 dBm | Noise: -89 dBm Nov 21 04:45:14 i dont know Nov 21 04:45:19 but seems broken to me Nov 21 04:46:29 stintel: they are just 5 LED's that light up to indicate RSRP signal strength which I am getting from a modem Nov 21 04:47:31 i read in the kernel docs that it's not possible to create a trigger for a specific LED, so would i need to create a LED trigger for 5 discrete ranges of values and assign each led to one? Nov 21 04:49:13 source under "future development" at the end: https://www.kernel.org/doc/Documentation/leds/leds-class.txt Nov 21 04:51:19 Squeaking noises, a highly precise measurement of radiated RF energy. Nov 21 04:52:19 shm0: are you sure it's not just singing capacitors or resistors? very common and the fix is to use a bigger resistor or cap Nov 21 04:52:54 the noise is in my ear/head Nov 21 04:53:49 when i turn the wifi off it goes away Nov 21 04:55:40 https://www.nanomotion.com/piezo-ceramic-motor-technology/piezoelectric-effect/ Nov 21 04:56:23 does it sound like a fizzy sound or a high pitched whine? Nov 21 04:57:58 the sound doesn't come from the device Nov 21 04:58:23 it is like having a tinnitus Nov 21 04:58:28 ringing in the ear Nov 21 04:58:33 and a bit of headache Nov 21 05:00:21 can someone provide info how the power table in the dts file has to look like please? Nov 21 05:02:56 ok, sounds like a royal pain but i don't have any info that might be helpful i'm afraid. but if anyone wants to check their devices one way is by recording a video and playing it back. mine definitely showed up on video, and the fab shop fixed it by putting in a bigger resistor on the wifi circuit Nov 21 05:52:42 i found a power table here Nov 21 05:52:43 https://svn.dd-wrt.com/browser/src/linux/universal/linux-4.14/arch/arm/boot/dts/armada-385-linksys-caiman.dts Nov 21 06:03:47 also here https://git.openwrt.org/?p=openwrt/svn-archive/archive.git;a=blob;f=target/linux/mvebu/files/arch/arm/boot/dts/armada-385-linksys-caiman.dts;h=2c3b77f77d0c513c8c96f79f9d1e3bde08815766;hb=0d04dc4d622617886cc4beafa606de2f68416965 Nov 21 06:05:43 current branch? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mvebu/patches-4.14/002-add_powertables.patch;h=c5a211dd40428996e2f50338338c279f4012038e;hb=HEAD Nov 21 06:06:54 ty Nov 21 06:07:11 so the power table(s) already get patched into the dts Nov 21 06:19:52 hmm must be mwlwifi driver bug ? Nov 21 07:36:44 shm0: does OpenWrt have DTS files with power info too? Nov 21 07:37:10 also, that may be only for country switching Nov 21 07:38:30 seems like openwrt has a patch that applies the powertables to the dts files Nov 21 07:39:53 i can't find any info about the marvell,powertable device tree layout Nov 21 07:40:33 shm0: that driver isn't upstream, so it's likely Imre didn't care about documentation Nov 21 07:40:47 it's probably just a set of values for some hw registers Nov 21 07:40:50 okay Nov 21 08:17:28 rmilecki: there was an attempt at upstreaming mwlwifi, but they took being asked to not continue adding new features during resubmissions as it being unwanted or so Nov 21 08:17:53 that makes sense Nov 21 08:18:11 it's probably hard to review properly when a lot changes between submitted versions Nov 21 08:18:48 solution is also pretty trivial: get a branch where you sort out everything without adding new features there Nov 21 08:18:52 rmilecki: you even commented on the v7 submission ;) Nov 21 08:18:57 oh, maybe Nov 21 08:19:13 ah, v9 it was Nov 21 08:19:16 too bad they gave up Nov 21 08:20:33 actually I wonder if there was something else Nov 21 08:20:59 last message on v9 was "All right. I will check and let patch v10 to use it. For previous parameters, they will only be used by previous OpenWrt projects.", but there was never a v10 Nov 21 08:21:08 might be worth a ping Nov 21 08:24:02 writing now Nov 21 08:26:01 thanks Nov 21 08:48:58 https://www.mall.cz/vypinace-zasuvky/webhiddenbrand-revogi-smart-power-strip-2-6x-bezdr-zasuvka-wifi Nov 21 08:49:03 reckon I can install openwrt on that? :D Nov 21 08:51:04 http://marex-hnd.blogspot.com/2018/04/revogi-smart-power-strip-sow323-iot.html Nov 21 08:51:07 heh Nov 21 08:53:53 ldir: currently bumping kernels .. Nov 21 09:01:32 :) Nov 21 09:01:54 I can't even find any useful google hits for that cpu Nov 21 09:06:38 xback: great balls of multicore fire :-) Nov 21 09:51:52 ldir: stintel: bumps available in my staging tree. (master and 18.06) not compile-tested yet .. but the changes where minor .. low-risk Nov 21 09:52:37 changelog shows a lot of ext4 changes, so testing x86_64 using ext4 as FS will be recommended here Nov 21 09:53:25 * ldir building - slowly Nov 21 09:58:00 ldir: keep in mind I have a patch which bumps musl in there. intended for early testing currently Nov 21 09:58:42 * ldir likes living on the edge :-) Nov 21 10:09:48 what's the defined way of wiping the overlayfs part, when using squashfs + $rw-fs? Nov 21 10:10:02 is it, despite the name, jffs2reset? Nov 21 10:11:18 xback: well it rebooted - and routes packets - and the ext4/2 partition mounted at least Nov 21 10:16:50 mirko: "firstboot" Nov 21 10:21:26 grepping for "firstboot" in my build_dir/target-*/root-* folder doesn't show anything executing it Nov 21 10:21:45 why should there be? Nov 21 10:21:46 ah, it might be executed from a binary executable Nov 21 10:22:06 because firstboot i suppose it being called at first boot at some time Nov 21 10:22:08 it deletes overlays and sthings, why would you do that from scratch? Nov 21 10:22:16 it's a "restore to firstboot" command Nov 21 10:22:49 when you build the image, you just build things, you don't need to delete overlays or anything. Nov 21 10:23:08 karlp: because i figure it will also create the rw-filesystem after an squashfs image of arbitrary size is flashed Nov 21 10:23:25 karlp: of course, it's part of the factory reset part Nov 21 10:23:53 it would has to be called after every upgrade Nov 21 10:24:02 no, it does recreate things, it just deletes overlays. Nov 21 10:24:10 you then reboot, and the normal boot handling does the right thing Nov 21 10:24:17 why would it be called after every upgrdae? Nov 21 10:24:36 because - as said - th RW-fs needs to be recreated Nov 21 10:25:00 and firstboot doesn't do that. Nov 21 10:25:05 firstboot && reboot does that. Nov 21 10:25:08 which essentially is a factory reset Nov 21 10:25:11 hm Nov 21 10:25:32 you can just try this out if you don't ebelive me, I won't feel bad :) Nov 21 10:25:38 firstboot appears to only be a wraper for jffs2reset anyway Nov 21 10:29:34 found it - libfstools/rootdisk.c calls mkfs.ext4 / mkfs.f2fs to create the overlay Nov 21 10:29:44 presumably it "does the right thing" when it's not a jffs system **** BEGIN LOGGING AT Wed Nov 21 13:20:27 2018 Nov 21 13:45:41 hello all Nov 21 13:47:37 I want to use Build/pad-offset in image-commands.mk, but I am not very good at shell scripts. and I have found no description about this, could someone help Nov 21 14:08:49 hrm, so yeah, again, "ntpdate -q" can ask busybox's ntpd, but ntpclient and ntpq and ntpdc all fail to connect. Nov 21 14:09:19 I can use a hotplug event to save the most recent event I guess, but would be nice to get something more uptodate, without having to wait for ntpdate -q to work. Nov 21 14:13:25 ntpq and friends are isc ntpd only, no? Nov 21 14:13:40 uh Nov 21 14:13:42 ntp.rg Nov 21 14:13:47 sigh, you know what I mean Nov 21 14:47:00 q Nov 21 15:06:33 have we ever discussed idea of rootfs appended to the kernel with upstream guys? mtd guys? Nov 21 15:06:45 that's related to our parsers as well Nov 21 15:07:51 e.g. "mtdsplit_seama.c" which splits "firmware" partition into "kernel" and "rootfs" by looking for a magics Nov 21 15:33:18 Wed Nov 21 15:32:04 2018 daemon.crit bird: I found another BIRD running. Nov 21 15:33:18 sigh Nov 21 15:33:34 I can't see why its broken Nov 21 15:33:45 surely its just a copy/paste of the old oen Nov 21 15:33:48 one* Nov 21 16:04:26 nbd: MT7628 still dying as WDS client. Gets stuck in TX hang resets instead of MCU hang now. Nov 21 16:16:33 ok, thanks for the info Nov 21 16:16:47 haven't worked on wds yet, will do so next Nov 21 16:24:18 are you using only wds client or ap+sta? Nov 21 16:26:59 nbd: Just client in this case Nov 21 16:44:25 jow: I'm trying to use uhttpd-mod-ubus, and am a bit curious about the acls are applied. I'm copying chunks of the attended-sysupgrade code, and reading https://openwrt.org/docs/techref/ubus and there's a note there that talks about unauthenticated vs "superuser" but as best I can tell from experiments, you _must_ have a valid login to get a session anyway, Nov 21 16:45:33 so the rpc acl.d files might be a way of applying acls for different users, but if you're logged in already, via luci.dispatcher.context.authsession, why do I still need to add access? Nov 21 16:46:50 or, if I _do_ add an acl file that grants me the rights, like: https://zerobin.net/?a773f9d3b96cdd09#V0kQHSq8+Ki4R0Qwz24w+2lEOPwwBTOQ2mRkCyj1fsI= have I opened up any security holes? You still need to be a valid user right? Nov 21 16:47:12 (I mean, ubus "read" access on the file module is.... a lot more than "read" but that's a different question) Nov 21 16:49:43 xback: just booted 4.14.82 on my odroid-c2 (target isn't upstream yet) Nov 21 16:50:39 fixed my broken nut configs, and added checks for UPSes in icinga2 Nov 21 17:02:34 eh, ubus -t doesn't do anything (on 18.06?) it just seems hardcoded to 3? Nov 21 17:02:46 or could that be inside the rpcd-file module? Nov 21 17:34:05 heh, there we go, "d2fac3: Increase exec command timeout to 30 seconds" Nov 21 17:34:08 was 3 secs. Nov 21 17:35:16 but that's from 2013, /me wonders why they still have timeouts at 3 secs. Nov 21 17:43:01 ok, that's for exec, but RPC_FILE_MAX_RUNTIME is still 3 :) Nov 21 18:05:06 Monkeh: i can reproduce the issue Nov 21 18:05:15 no idea where it is coming from or if it's fixable Nov 21 18:05:21 might just be a hardware quirk in mt7628 Nov 21 18:14:10 nbd: I am hopeful it can be fixed, but.. :) Nov 21 19:29:44 Goodevening Nov 21 19:31:54 got a question..I am playing around with an Cisco EPC3925 for some time. While i already extracted a lot of information from it, the device itself is EOL for a few years already. is OpenWRT still intrested to make it run openwrt or does it not care anymore because of the EOL Nov 21 19:33:29 ThijsNL: EOL or not doesn't matter for OpenWrt Nov 21 19:33:49 if it only supported devices on the shelves the list would be rather short. Nov 21 19:36:09 Ok thanks,, then i will update the wiki with some findings Nov 21 19:36:20 dug quite deep into the firststage and secondstage bootloader Nov 21 19:37:13 this 'SA BootLoader Version: 2.3.0_R1(S)' Nov 21 23:09:32 alright Nov 21 23:09:47 some setting in dnsmasq is breaking aws resolution Nov 21 23:46:54 seems like. removing the power tables from the dts files makes no difference **** ENDING LOGGING AT Thu Nov 22 02:59:58 2018