**** BEGIN LOGGING AT Fri Sep 14 03:00:11 2018 Sep 14 07:23:50 Hi, in UCI, is it possible to convert an anonymous section into a named section with the UCI lua bindings? Sep 14 07:26:25 morning Sep 14 07:30:37 hey wigyori o/ Sep 14 07:37:53 hey okraits :-) Sep 14 07:38:10 that's a good question, I'm also interested in that Sep 14 07:39:20 Hey nemesis-ninux ;-) Sep 14 07:40:34 At the moment, I'm trying to modify the hidden options '.name' and '.anonymous' with the set function, but not successful so far. Sep 14 07:43:48 I don't remember: is it possible to add a specific UCI block with a certain order? Sep 14 07:44:52 I'm thinking that in the worst case we could make a copy of all the configurations, retaining their order in a list (lua table), remove all the unnamed/anonymous configurations, add the named copies in the exact order they were before Sep 14 07:46:34 that's probably why I'm deleting the unnamed sections: https://github.com/openwisp/openwisp-config/blob/master/openwisp-config/files/sbin/openwisp-uci-autoname.lua Sep 14 07:46:45 I couldn't find a way to add a name to them Sep 14 07:46:48 nemesis-ninux: It is at least possible to change the order of sections Sep 14 07:46:51 maybe here somene could help Sep 14 07:47:02 nemesis-ninux: Yeah, that is the crucial point Sep 14 07:47:03 to point out a simpler solution Sep 14 07:52:17 * russell-- has developed a simpler solution ... stop caring about the order! ;-) Sep 14 07:53:01 russell--: That will end in trouble in the case of firewall rules Sep 14 07:53:05 ;) Sep 14 07:53:54 nemesis-ninux: We could use the foreach function to iterate over sections, but only of a specific type, not over all sections... Sep 14 07:54:18 And I don't know if that function returns the section in the real order Sep 14 07:55:34 okraits: get_all Sep 14 07:57:11 nemesis-ninux: that's what we're using now - returns the sections in an arbitrary order Sep 14 07:57:58 let me try something out Sep 14 08:02:10 nemesis-ninux: foreach seems to return the correct order - let me adapt the script Sep 14 10:02:24 why do you need to name existing unnamed sections? Sep 14 10:02:52 I imagine if you really needed this you'd delete the section and readd it with your name. Sep 14 10:03:11 ordering has never been guaranteed in anyform anyway, so that doesn't matter. Sep 14 10:03:20 but you'd lose any comments in the section. Sep 14 10:04:13 you should use a key within the section if you want to order them, trying to force or assume some sort of ordering from arbitraty sections _will_ get you int rouble sooner or later. Sep 14 10:46:37 karlp: agreed Sep 14 10:46:49 karlp: well put :-) Sep 14 10:57:55 Hey. Anyone using a DGA4132? I bricked it and dont know if its recoverable Sep 14 11:42:38 anyone familiar with netifd except for nbd? ;) Sep 14 11:42:41 i'll need a help Sep 14 11:42:48 i'm describing my problem right now, will post in a minute Sep 14 11:48:44 just sent "Custom init.d script switching LAN static -> dhcp triggers reload <-> hostapd race" e-mail Sep 14 13:22:36 moe1: unless you wiped the cfe, should be, without much fuss Sep 14 13:26:56 DonkeyHotei: i have faulty data in jffs, system will not boot, kernel panics. How i can enter cfe for this device? the only thing i could do is flash a firmware over tftp, but this will cause the same error, because theres a problem in data Sep 14 13:28:13 jffs is typically wiped with a factory reset Sep 14 13:30:57 thats also a problem: factory reset works with 30sec holding reset button. But after 22secs the kernel panics :D Sep 14 13:32:06 bootloader hast no other function, cfe seems locked, bootloader accepts only signed new firmware. But its cheap, so perhaps i buy another one Sep 14 13:37:50 there has to be a way to wipe jffs from cfe Sep 14 13:44:46 i found nothing to enter cfe or any other open way to do stuff on this router Sep 14 13:44:56 bootloader is hell Sep 14 14:16:21 moe1: can't you tftp an initramfs? Sep 14 14:17:50 jwh: no, just signed full img. but thanks for help Sep 14 14:18:01 ah, doh Sep 14 14:42:14 rmiliecki:netifd has no locking mechanism as the different proto shell scripts are loosely coupled Sep 14 14:43:04 rmilecki:can't you just start your custom script befor network is started which is 20 Sep 14 15:12:35 moe1: CTRL+C to access CFE prompt Sep 14 15:12:49 moe1: https://wiki.openwrt.org/doc/techref/bootloader/cfe Sep 14 15:14:10 rmilecki: i did try that, doesnt work ;( also tried rs232 escape and some other things. Sep 14 15:14:22 moe1: maybe your TX doesn't work Sep 14 15:14:36 it does, i can enter tftp mode by pressing b Sep 14 15:14:38 moe1: i've never seeen CFE that doesn't allow interrupting with CTRL+C Sep 14 15:14:53 moe1: ok, so maybe it's some weird CFE Sep 14 15:15:04 anyway, having tftpd is all you need i guess Sep 14 15:15:10 moe1: enter tftpd and flash a new firmware Sep 14 15:15:52 this device is so great in hardware and openwrt (cc) is running. vdsl2 with 35b. But Flashing is hell Sep 14 15:16:09 rmilecki: only the signed versions are accepted. and this one doesnt boot Sep 14 15:16:30 oh crap Sep 14 15:16:40 so... flash an original image I guess? Sep 14 15:16:46 and then if possible try OpenWrt again? Sep 14 15:16:49 i think, theres a problem with faulty data in jffs, there are also crc errors in kernel berfore panic Sep 14 15:17:05 yeah, original does not boot anymore :D Sep 14 15:20:33 never had something unruly like this. i want an easy u boot back :D Sep 14 16:54:42 are warnings like this all over the bootlog normal? [ 8.609020] random: ubusd: uninitialized urandom read (4 bytes read) Sep 14 16:55:44 DonkeyHotei: yeah, most embedded boards don't have enough entropy, especially at boot Sep 14 16:56:45 then reading urandom on boot at all would be a bug, no? Sep 14 16:57:33 depends on what you need it for Sep 14 16:57:54 there's always /dev/random, which blocks until it has enough entropy Sep 14 16:57:58 DonkeyHotei: there is a kernel option to force it to block, but it could delay boot, or even freeze it Sep 14 16:58:57 DonkeyHotei: I think most openwrt devices are going to get their entropy from the wifi card, so until those are initialized, probably not much randomness is available Sep 14 16:58:58 hmm Sep 14 16:59:40 yeah, all the warnings are before wifi init Sep 14 17:00:18 isn't that mostly atheros based wlan chipsets (whose hwrng isn't that good either), afaik at least Marvell doesn't generated entropy from wlan Sep 14 17:01:05 yeah, atheros for sure, I thought others do it too Sep 14 17:03:03 that netgear thing seems to work a lot better as ath79 than trying as ar71xx: https://github.com/openwrt/openwrt/pull/1379 Sep 14 17:04:24 I've switched all my previously-ar71xx devices to ath79, without noticing any problems so far Sep 14 17:06:42 imho it would be possible to remove source-only for it soon (and to start removing corresponding/ tested devices from ar71xx) Sep 14 17:21:23 pkgadd: I have v2 and v4 for Archer C7. should I be testing ar79 builds? if so, um, why? :-) Sep 14 17:21:31 ath70* Sep 14 17:21:35 ath79** Sep 14 17:23:01 Got a question about the ipq4019… getting errors about "Unhandled fault: imprecise external abort (0xc06) at 0x004cf6a6" … is the MMU less than full-featured? Or am I building things wrong? Seems to be lacking detail… Sep 14 17:23:04 Zero_Chaos: why not? ;) works pretty well for me on the tl-wdr3600/ tl-wdr4300 (and tl-wr1043ndv1/ tl-wr941ndv2) Sep 14 17:23:33 pkgadd: I'm curious what the difference is, like why is ath79 better than ar71xx? Sep 14 17:24:06 Zero_Chaos: it's moving from mach files to device tree - and with that it's starting to be submitted mainline Sep 14 17:25:08 pkgadd: cool. who do I poke to get archer c7 v4 in there so I can test both? Sep 14 17:25:13 as a side effect images might get a little smaller (only having to include one fdt, instead of statically building in all mach files) - and with (at least the prospect of-) mainlining, drivers also get revised/ reviewed and fixed) Sep 14 17:26:45 there's not really anyone to poke, it happens when/if it happens (quite likely for all revisions of the c7 though, at one point or another) - unless you want to dabble into it yourself (the major steps should be done already) Sep 14 17:28:28 pkgadd: I suspect I won't be making those changes myself. but I'll do a test build of v2 for fun Sep 14 17:30:13 it's quite surprising to see quite active device porting to ath79 happening already, from many different contributors Sep 14 17:31:32 pkgadd: I'd love it if someone cared that much about my netifd bug Sep 14 17:32:30 pkgadd: why surprising? it's the way forward for all of them. Sep 14 17:35:04 karlp: sure, I'm just pleasantly surprised to see quite a few and rather active porting efforts going on (even though ath79 images aren't even prebuilt yet) from many (semi-external) contributors, rather than taking it easy and relying on ar71xx to support their devices; ath79 didn't have that much of publicity/ exposure, so it's refreshing to see the influx of pull requests for existing devices Sep 14 17:35:10 (and not just new ones that weren't supported by ar71xx so far) Sep 14 17:36:45 and not just the easy ones either, but also the slightly trickier things - like mtd concat for those buffalo routers Sep 14 17:57:02 hi quick question, is there a quick way to duplicate incoming UDP packages before they are sent over Wifi? Sep 14 18:03:32 yes, you can do this in iptables with ipt_TEE Sep 14 18:04:10 alex_: http://www.persianov.net/tutorials/how-to-setup-openwrt-traffic-mirroring-and-snort-ids/ Sep 14 18:05:20 sweet thx philip Sep 14 18:12:18 alex_: enjoy. Sep 14 18:28:46 sooooo same machine: 1) compiling toolchain + building img from a VM Ubuntu 18.04 @ 12 threadripper threads= success 2) Building toolchain + Building img in naitive Arch Linux @ 32 threads = Fail Sep 14 18:28:50 maybe Sep 14 18:28:53 just maybe Sep 14 18:29:45 some packets are trying to compile while their pre-requisite packages have yet to be compiled?? Sep 14 18:30:08 I know building base with no add-on builds fine in the Arch machine Sep 14 18:35:28 yes, dont use -j Sep 14 18:35:38 ummmm Sep 14 18:35:42 ummmmmmmm Sep 14 18:35:47 there are still some cases where it goes wrong Sep 14 18:35:59 more j the more likely it is Sep 14 18:36:06 havent figured out where yet Sep 14 18:36:20 right but it seems <12 threads is working just fine Sep 14 18:36:36 I will look into what # of cores the build failes Sep 14 18:36:38 fails Sep 14 18:36:45 its just coincidence Sep 14 18:37:11 I narrowed it down to to either kernel modules or luci Sep 14 18:37:22 I literally turned off everything else Sep 14 18:37:31 as in, the order isnt sufficiently screwed, or the step built in time Sep 14 18:37:49 yes Sep 14 18:38:03 whereas with higher jobs it may exec it early enough to break Sep 14 18:38:18 make will usually pick up where it failed, as an ugly workaround Sep 14 18:38:20 is there a way to make a package that links to others wait to be compiled until the other package is already compiled? Sep 14 18:38:58 yes, by adding the according dependencies into the makefiles Sep 14 18:41:16 the build system should support -j, otherwise this is a bug Sep 14 18:41:39 it is possible to activte logs in the advanced menu, then you can easiyl find the error Sep 14 18:43:15 ah many thats why i couldnt find the error log last time Sep 14 20:06:00 lynxis: ping Sep 14 20:06:16 Hauke: pong Sep 14 20:15:18 lynxis: since you were just active, and I happen to be staring at some commits from you in netifd... is there a way I can PR a bug fix? Sep 14 20:17:50 Zero_Chaos: i'm drinking beer right now together with others devs. don't expect much. Do you have a link for lazy people? Sep 14 20:18:36 lynxis: https://bugs.openwrt.org/index.php?do=details&task_id=1840 Sep 14 20:18:53 lynxis: basically *mixed is over-zealous and breaks wep+mixed Sep 14 20:19:27 lynxis: should be like {wpa,psk}*mixed* or something slightly less greedy Sep 14 20:25:47 Zero_Chaos: I did not knew there is wep-mixed. Sep 14 20:27:42 lynxis: there is, it is documented, and by commenting out that line it is also functional https://openwrt.org/docs/guide-user/network/wifi/basic?s[]=wireless&s[]=configuration Sep 14 20:28:08 lynxis: thanks a lot for responding while enjoying your beer btw :-) Sep 14 20:30:52 lynxis: basically it's right below where I'm complaining about. the wep one is protected until a *wep* line, while the wpa one is just straight *mixed* Sep 14 20:32:55 lynxis: s/until/under/ Sep 14 20:33:06 Zero_Chaos: out of curiosity, do you still need wep? Sep 14 20:33:36 lynxis: I help run the Wireless Capture the Flag, so yes, extensively, as a target for people to attack :-) Sep 14 20:33:46 Zero_Chaos: ok, you got me! Sep 14 20:34:09 lynxis: it is honestly super fun to watch a room full of "hackers" fail to break wep Sep 14 20:34:35 :D Sep 14 20:36:03 isn't that more an issue of knowing and being familiar with the right tools, rather than a particular difficulty? (I know it should be easy, but I've never even thought about attempting it) Sep 14 20:36:32 pkgadd: that's pretty much what most people think, but it's surprising how often hacker tools either suck, or are surprisingly hard to use Sep 14 20:36:35 I just opt to use a secure protocol instead ;) Sep 14 20:36:56 pkgadd: so actually breaking wep can be harder than most people expect. still 2 minutes if you are experienced Sep 14 20:37:07 pkgadd: lol, what secure protocol? I don't know any Sep 14 20:37:29 to cover my bases, I'll just lie and go with ipsec ;) Sep 14 20:37:51 but to be honest, wpa2psk/ ccmp Sep 14 20:38:31 pkgadd: password crackers are really good, and people are very bad at picking psk. and to talk about businesses, etc, you can normally find the psk on a sheet of paper in the conference room Sep 14 20:39:33 Zero_Chaos: my wlan password are generated by pwgen -s 63 1 Sep 14 20:40:26 so at least guessing or dictionary attacks won't help you (and yes, it does suck big time to enter those on smartphones or similar) Sep 14 20:41:03 pkgadd: yeah it's certainly possible to pick a good psk, just statistically improbable, comparing you to your neighbours Sep 14 20:41:31 pkgadd: and the whole cycling psk thing, that really sucks so no one does it Sep 14 20:42:03 lynxis: so, aside from letting you finish your beer, how can I get wep+mixed fixed in netifd? How can I help? Sep 14 20:42:04 admitted, I don't change my psks often (unless moving to different hardware) Sep 14 23:54:07 What would be the correct way to have a service restart when the wan interface comes up (i.e. when PPPoE negotiation has finished and the link is active) ? Sep 14 23:54:28 procd_add_interface_trigger seems to be what's used in a few services Sep 14 23:55:29 but this page suggests procd_add_network_trigger instead. https://wiki.openwrt.org/inbox/procd-init-scripts#procd_triggers_on_config_filenetwork_interface_changes **** ENDING LOGGING AT Sat Sep 15 03:00:25 2018