**** BEGIN LOGGING AT Sun Nov 17 02:59:57 2019 Nov 17 03:39:59 build #43 of lantiq/falcon is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Ffalcon/builds/43 blamelist: Jo-Philipp Wich , Christian Lamparter Nov 17 06:12:50 ynezz: please push something to master ;) I want to check my multi branch buildbot implementation Nov 17 10:04:46 KanjiMonster: thanks, will fix when i get home tonight Nov 17 12:51:38 pepe2k: no forma one, no. But I'd aim for next sunday (nov 25th), which would mean tagging on friday Nov 17 12:51:57 jow: ok, got it, thanks Nov 17 13:09:06 ynezz: since you labelled this pr: https://github.com/openwrt/openwrt/pull/2532 ... do you understand its purpose? Nov 17 13:23:47 jow: that looks like a huge bloat to me... Nov 17 13:24:55 disable/enable firewall, wifi... diag LED pulsing pattern Nov 17 13:28:44 well I was wondering about it as well... all that code ... to disable the firewall ... during preinit Nov 17 13:28:47 why? Nov 17 13:29:25 I'd approach it differently, build a nice cli script to implement configuration profiles, as optional package Nov 17 13:29:33 just burn it and don't waste time on fireworks Nov 17 13:30:16 call it "configure-as" - have it do things like "configure-as wifi-client ", then maybe add an optional preinit hook Nov 17 13:31:24 I suppose it came from the need of Wi-Fi enabled by default... it's a boomerang topic Nov 17 13:31:46 just have a look at related PRs Nov 17 13:31:57 "base-files: add support to configure oem values" Nov 17 13:32:14 "Enable wifi with oem or mac password" Nov 17 13:32:16 eh Nov 17 13:40:26 One can always compile one with own exact settings.. or imagebuild Nov 17 13:40:36 so I don't see the point in alleged PR, without loking it =) Nov 17 13:48:10 jow: I barely read the code when adding labels Nov 17 13:49:08 usually just looking at the modified files or just base it on the prefix: Nov 17 13:49:53 jow: as a case of making OpenWrt more userfriendly I think generating secure defaults for Wifi would be a good idea (like setting modern encryption settings with a randomly generated password, but still disabled - so a user only needs to enable it) - for wifi only devices maybe then enabling it and enabling wps-button support might be an option (which would allow you to connect without knowing the password, Nov 17 13:50:51 KanjiMonster: sounds like a nice approach Nov 17 13:52:45 Not all devices have WPS buttons, and WPS itself is a concern.. Nov 17 13:53:35 Monkeh: that's why it should only be enabled on devices that do not provide any other means of connection, not generally on all devices Nov 17 13:53:47 KanjiMonster: when that password would be generated, at a build stage? Nov 17 13:54:24 KanjiMonster: I have few devices which could be supported by OpenWrt _but_ there is only Wi-Fi, no button and no serial console access :) Nov 17 13:54:25 KanjiMonster: I'm all for eanbling wifi on devices without ethernet Nov 17 13:54:33 pepe2k: no, on (first)boot / wifi detection; on-device Nov 17 13:55:21 KanjiMonster: then this doesn't make much sense on devices without WPS-capability, user would still need to connect over serial/eth to get to know the password Nov 17 13:55:21 personally I find the proposed approach of an open wifi with minimal tx power and a conservative frequency guest the most sane Nov 17 13:55:40 *guess Nov 17 13:55:57 jow: minimal TX and open Wi-Fi for Ethernet-less devices would also work for me Nov 17 13:56:21 If you've installed OWRT, you know what you're doing Nov 17 13:56:29 All this sounds generally sane enough... enabling securest possible means in devices where better can't be done as default Nov 17 13:56:45 you're expected to have a level of knowledge since you installed custom firmware on a router Nov 17 13:56:58 pepe2k: could even be timed to shutoff after like 5 minutes Nov 17 13:57:02 or 15 minutes Nov 17 13:57:07 Red_M: not neccesarily, for example many tp-links eats openwrt just like that, among other vendors.. and I know peoples like openwrt even when they aren't such nerds as we are Nov 17 13:57:11 in case you accidentally forget about it Nov 17 13:57:12 Red_M: You'd think, but out there on the internet you see things. Nov 17 13:57:32 also, some devices won't take the most secure Nov 17 13:57:40 and there is no way to guess that Nov 17 13:57:53 so you leave them with a broken SSID Nov 17 13:58:00 pepe2k: those devices, so you would essentially brick them by accidentially disabling the wifi? Nov 17 13:58:07 Red_M: that's still kinda bollocks statement.. I don't say I specifically agree nor disagree in some fundamentals.. but you are implying "git guud" before you are allowed to install openwrt :P Nov 17 13:58:08 olmari: then that is TP-Link's issue, not OWRT's Nov 17 13:58:31 iirc, OWRT comes with no waranty Nov 17 13:58:37 Red_M: how is that tplinks issue when they deliberately doesn't hinder custom firmware install process? Nov 17 13:58:41 as stated in the license Nov 17 13:58:49 and that's also diffirent statement... Nov 17 13:59:07 fucking stay on one topic at a time then :) Nov 17 13:59:23 I'm not the one shooting statements :P Nov 17 13:59:40 please, calm down Nov 17 13:59:43 no warranty does not relate to that openwrt could still provide safest possible convenience on devices that can't have the safest possible Nov 17 13:59:45 As I read your statement containing TP-Link, you made it sound like TP-Link installs OWRT as default Nov 17 14:00:02 as in it ships with it Nov 17 14:00:09 jow: Is there any existing method to prevent more than one client connecting to that open AP at a time as well? Nov 17 14:00:13 *ships with OWRT Nov 17 14:00:50 Monkeh: probably, but wouldn't that mean that any auto-joining mobile device in range by accident would DoS the owner? Nov 17 14:00:52 I didn't say that, "eats openwrt" --> instlal just by giving openwrt bin to it :) Nov 17 14:01:07 Monkeh: you can just limit hostapd to one STA connected Nov 17 14:01:09 Most routers do that Nov 17 14:01:09 or rather lock the owner out Nov 17 14:01:20 jow: Ungh, I forgot about that stupid option. Nov 17 14:01:32 I prefer the to shut down the network 15 minutes after boot Nov 17 14:01:52 then people will notice and have to reboot Nov 17 14:02:26 ..and all I stil say is that I support the idea, exact implementation is.. well.. I like plenty of ideas thrown out here :) Nov 17 14:03:13 okay so 1) only for ethernet-less 2) with minimal tx power 3) not longer than 15 minutes 4) using OpenWrt as ssid without encryption? Nov 17 14:03:34 any modification / wifi command etc. would cancel the 15 minute timer Nov 17 14:03:42 jow: I agree Nov 17 14:03:57 Surely some degree of encryption would be sensible to prevent snagging your new settings straight off the air? Nov 17 14:03:57 who wants to implement this? Nov 17 14:04:13 jow: timeout sounds good, Xiaomi does that Nov 17 14:04:17 Monkeh: ssh :P Nov 17 14:04:26 point taken though Nov 17 14:04:41 if OWE would be supported by clients we could use that ;-) Nov 17 14:04:42 KanjiMonster: yes, in practice there is no 'easy' way to bring them back to life Nov 17 14:05:23 If there's any supported device (especially in this context) which can't do WPA2.. why is it supported again? :) Nov 17 14:05:47 assuming that 15 minute window would slip without the user taking action, the "disabledness" of the wifi would then be persisted Nov 17 14:05:58 to get it back, the user would have to perform a factory reset Nov 17 14:06:06 which would be a good enough compromise imho Nov 17 14:06:22 jow: ack on all pints Nov 17 14:06:27 points* Nov 17 14:06:59 still, no buttons and no eth devices could have a problem, maybe the timeout should be configurable per device? Nov 17 14:07:16 Just have a preset WPA2 password Nov 17 14:07:22 jow: I woulöd make a reboot sufficent to bring back wifi after 15 minutes Nov 17 14:07:23 for those device builds Nov 17 14:07:25 its probably simplest to checksum /etc/config/wireless when setting the 15 minute timer, then when it expires see if the checksum matches. If not, take no action, if yes, shutdown wifi Nov 17 14:07:51 like the device name or something Nov 17 14:07:52 Hauke: problem is you need to somehow persist the information that wifi has been configured Nov 17 14:08:22 you could run this script always 15 minutes after the bootup Nov 17 14:08:28 Hell, make the password the build target name Nov 17 14:08:41 Hauke: and how does it decide that it should not run because the device has been set up? Nov 17 14:09:04 if the chekcsum is the same as the initial configuration just call "wifi down" otherwiese do nothing Nov 17 14:09:56 hm Nov 17 14:10:19 Hauke: where do you take the checksum from? Nov 17 14:10:56 KanjiMonster: from /etc/config/wireless after the last wifi detect was running Nov 17 14:11:45 jow: wifi down and a way to have it enabled again after power cycle would cover all type of eth-less devices Nov 17 14:11:49 Hauke: how do you know the last wifi detect was run? there can be multiple wifis, how do you know you got all of them? Nov 17 14:12:50 we could check the checksum before each wifi detect if it still matches nothing was modified and then update the checksum and the timer after each detect Nov 17 14:13:16 normally these devices do not have a USB post port Nov 17 14:13:31 so you can not add a new wifi at runtime Nov 17 14:13:49 but this should still work, as this is only updated in case it was still "active" before Nov 17 14:14:56 what is an example of the devices we are talking about? Nov 17 14:15:10 SD cards with wifi Nov 17 14:16:02 Hauke: that creates a race between new wifi detected and new checksum generated Nov 17 14:16:12 KanjiMonster: ok Nov 17 14:16:23 I am not in the details of these scripts Nov 17 14:18:26 russell--: and this: https://forum.openwrt.org/t/supporting-zsun-wifi-card-reader-16mb-flash-64mb-ram-ar9331/2142 Nov 17 14:18:32 Hauke: I mean there is no atomic way to both update /etc/config/wifi *and* write the checksum into a file - if the "is the wifi unconfigured" check calculates the checksum before the updated uci config and then reads the updated checksum, or does the checksum check of the update uci config before the update checksum is written, it will think the config isn't at "defaults" Nov 17 14:18:32 wait Nov 17 14:18:38 its an SD card.... Nov 17 14:18:55 Just allow the user to edit the files on the SD card Nov 17 14:19:07 Just for first time boot Nov 17 14:19:16 then after that they can change it via luci Nov 17 14:19:24 Red_M: I do not know if it is only SD cards Nov 17 14:20:00 then I defer to my previous statement about preset WPA2 PSK being the build target name Nov 17 14:20:02 jow: how about a) provide sane default wifi password /encryption (e.g. wpa2), b) if all wifis are disabled, and no root password is set, create the low power ap Nov 17 14:21:33 KanjiMonster: the default secret would be fixed? Nov 17 14:21:40 like the target name Nov 17 14:22:24 I think that is what he means Nov 17 14:22:41 would work for me as well Nov 17 14:23:12 jow: the default password in /etc/config/wireless no, that should be be unguessable. the one used for the low power ap might be Nov 17 14:23:13 it would even provide some amount of security as a remote attacker does not necessarily know the target device Nov 17 14:23:27 its a bit of poor security Nov 17 14:23:27 KanjiMonster: that I meant Nov 17 14:23:38 but its just enough to allow you to configure the device Nov 17 14:23:45 Red_M: better than open and good enough to bridge the first time provisioning gap Nov 17 14:23:48 jow: and we might get inexperienced/new users asking for the password as well Nov 17 14:24:13 especially since what exactly the device name is might be up to where you look Nov 17 14:24:14 Should have read the ToH page Nov 17 14:24:18 pepe2k: then we ask them for the image name they flashed and infer it from that Nov 17 14:24:37 Make it a big red box on the hardware page Nov 17 14:24:42 first thing Nov 17 14:24:52 jow: images might work on multiple devices Nov 17 14:24:55 "Do not ask for the first time password, it is below" Nov 17 14:25:01 as this only affects devices without etherent I am fine Nov 17 14:25:29 when the document the first time password on each ToH wiki page it should be ok Nov 17 14:25:33 I would prefer some automatic mechanism without involving users knowledge which is always 0 at the begin Nov 17 14:25:39 someone else will take care of the user support anyway Nov 17 14:25:42 KanjiMonster: then users can still try all of them Nov 17 14:26:00 Just list it on the ToH/Hardware wiki page Nov 17 14:26:09 and close issues stating to read said page Nov 17 14:26:14 hell, make a bot do that Nov 17 14:26:16 I guess the interesdection of devices without etherner, multiple of them supported by the same image, not based on dts / using images with matadata trailer is rather small to nonexistent Nov 17 14:26:28 *intersection Nov 17 14:26:42 probably Nov 17 14:26:53 I'd guess the same Nov 17 14:27:06 worst case they'll have an on-wifi brick, same situation as now Nov 17 14:27:09 So if such ever exist, deal with it specifically then Nov 17 14:27:15 crazy idea, checksum per config section Nov 17 14:27:17 *a non-wifi Nov 17 14:27:30 why Nov 17 14:27:34 literally why Nov 17 14:27:36 jow: indeed, nothing will be worse in htat way either Nov 17 14:28:14 that solution is so janky in terms of logic flow, its a crutch Nov 17 14:28:48 jow: on no-ethernet devices *with* a button we could even re-use the low power AP for failsafe mode Nov 17 14:29:36 If you were going to go down the 15 minute window path, you'd just md5sum /etc/config/wireless on target build then have a service match the result to the current, if its >15 minutes, /sbin/wifi down Nov 17 14:30:03 Red_M: there is no /etc/config/wireless on target build, it is dynamically generated on (first) boot Nov 17 14:30:22 however that md5sum could be put somewhere (/tmp/ likely suffices) Nov 17 14:30:35 the one of the first time config generation Nov 17 14:30:50 when /etc/config/wireless is not existent Nov 17 14:30:55 honestly, just make the preset WPA2 PSK the default and, I agree with the failsafe mode as well Nov 17 14:31:27 That seems the most sensible solution to move forward with wifi only devices Nov 17 14:32:39 Red_M: we need to either force people to set their own password by having none, or provide a unique, unguessable password Nov 17 14:33:01 have you seen the process for the root password on first boot? Nov 17 14:33:15 s/first boot/no password/g Nov 17 14:33:26 Do that again... Nov 17 14:33:31 but for the wifi password Nov 17 14:34:18 Red_M: currently you need to have physical access for that, an insecure wifi password will allow drive-by hacking Nov 17 14:35:26 I'm starting to dislike 15min approach the more it is taight here =) Nov 17 14:35:47 the crux of the issue is that you can't have encryption with no password for wifi Nov 17 14:36:29 literally was meaning with the preset password Nov 17 14:37:45 While, for example, WPS does have it's flaws, if device has the button, then make it the default way on such wifi-only device.. so still needs at least physcal access... without anything at all but having wifi itself, it is indeed harder to thing any sane _secure_ default.. but I guess on there the default PW and/or even the 15min timer thing would be somewhat okay... as currentl alternative is basically "soft brick" Nov 17 14:38:27 olmari: I heard more and more client devices drop wps Nov 17 14:39:00 jow: mm... that too.. Nov 17 14:39:53 I do still generally like the idea of being safest possible per default... but in theory does it make sense that default also be "soft brick" if not bakeing in own configuration or hack serial console access or so on Nov 17 14:40:39 I know it is more or less the current default too, and I also imagine persons hacking owrt onto such devices knows what they are doing.. but again that's another angle for the whole stuff =) Nov 17 14:41:40 tbh, if you're installing OWRT on an SD card, you've most likely read the hardware page to get the iamge Nov 17 14:57:37 Red_M: a static password everybody knows is the same level of security as no password Nov 17 14:58:16 not if its a requirement to change said password Nov 17 14:58:29 its literally only for first time config Nov 17 14:59:29 still, same level of security, we are not talking about what user has to change and will or will not change, we are talking about initial AP running with known or without password at all Nov 17 15:00:37 lowering TX power just make it harder to 'hack' but also doesn't prevent e.g. quickly accessing device and erasing firmware mtd partition :) Nov 17 15:01:15 Then you'll be providing serial access to every device that has this setup of connectivity then? Nov 17 15:01:37 Both sides of thinking has merit, thing still is that currently if user does nothing, user will get soft-brick.. No idea is this any large epidemia in the wild tough =) Nov 17 15:01:42 all of that is just a compromise between some level of security and support for currently unsupportable devices Nov 17 15:01:54 or writing a guide that works on windows to build OWRT with an image that has wifi preconfigured? Nov 17 15:01:59 olmari: probably it Nov 17 15:02:04 So then users can load it? Nov 17 15:02:15 olmari: probably it's not but there are more devices with wireless only hitting market Nov 17 15:03:38 Proper guide for how user can imagebuild own wireless PW in the image, if not going to lenghts of having super easy parameter to do it Nov 17 15:03:40 the Zsun one is probably the most known one, ~3y old? Nov 17 15:04:07 also if you're wanting to focus on just these devices, they're SD cards... Nov 17 15:04:26 Whats not to say you allow the user to edit the config via the SD card side Nov 17 15:04:37 pseudocode imagebuild crippledevice.bin --wifi-psk="thekeyIwant" and builder (or whatnot) knows how to handle rest for the given device Nov 17 15:04:40 Red_M: that doesn't change anything, some have SD card, some don't, solution shouldn't depend on having SD card or not Nov 17 15:05:19 plus, what filesystem user should use on that card? should we make decision for them, including support only for ext? what about win users? Nov 17 15:06:08 just remember, you brought up not getting issues about the preset password, imagine providing support for people setting up a build environment for the iamges Nov 17 15:06:22 olmari: I think the problem is that those devices don't have support now, because there is no way to use them with images generated by default Nov 17 15:06:26 most of them are also probably going to be on windows Nov 17 15:06:29 pepe2k: I don't think that should be owrt concern.. owrt dupports whtever it needs per default.. user can modify if can, and if don't know how, also not strictly our problem Nov 17 15:06:40 Red_M: good point Nov 17 15:06:59 like this just isn't easy for us or the user Nov 17 15:07:18 olmari: we have defaults already, disabled WiFi by default, that's the current status quo Nov 17 15:07:19 and as much as I like to say "git gud" most people don't want to Nov 17 15:07:39 so ¯\_(ツ)_/¯ Nov 17 15:08:01 there is a level of compromise that you have to give way to Nov 17 15:08:35 like the other day I updated to the latest RC1 of 19.07 to get WPA3, nearly all of my clients had issues Nov 17 15:08:42 so I had to go back to 180.06 Nov 17 15:08:47 *18.06 Nov 17 15:09:13 yes WPA3 is somewhat more secure but it broke every client I had Nov 17 15:09:18 IMHO the solution should be universal, without taking care of per-device settings or some static passwords buried in code base Nov 17 15:09:26 whats the point if the user cannot use it anymore Nov 17 15:09:49 Red_M: git gud and find the reason of the problem? :) Nov 17 15:10:08 I have enabled WPA3 in most of devices I cater, with ballback WPA2 support, so far nothing seems to be broken Nov 17 15:10:09 broadcom Nov 17 15:10:12 don't be a cunt Nov 17 15:10:23 sure, only WPA3 can break plenty things as most nothing still support it really Nov 17 15:10:37 Red_M: language, please Nov 17 15:10:47 Don't be a dick Nov 17 15:10:57 Don't slap unless you expect to be slapped back Nov 17 15:11:58 One can slap back without bad words.. presentation is key on many occasions Nov 17 15:12:30 olmari: +1 Nov 17 15:13:44 KanjiMonster: regarding the question about know if all wifi got configured, I suppose we know how many we expect for particular device? Nov 17 15:14:27 excluding boards with add-on cards, which probably are out of scope here, I can't imagine other example Nov 17 15:15:14 Yeah, I think the scope is, or definately should be, exactly devices that does not have any other means... Nov 17 15:15:37 pepe2k: sure, but what if for some reason one of the devices never gets detected (in a multi-wifi setup) because of broken driver/device/missing driver ... - then you'll wait indetinitely for the "probe" to finish Nov 17 15:16:09 oh and soft brick Nov 17 15:16:16 or a required restart Nov 17 15:16:22 which is still a PITA Nov 17 15:19:45 KanjiMonster: good point, but here we assume two+ radio devices, am I right? Nov 17 15:20:33 KanjiMonster: why not wait just for one of the radios to come up? hm... still possible race issue here Nov 17 15:20:40 pepe2k: well on one wifi devices you'll have a soft-brick in that case either way, since no wifi means no way to spawn an AP ;P Nov 17 15:25:36 and no way to actually test all devices without breaking them as that might be a runtime related problem, got it Nov 17 15:26:33 but on the other hand, a static password has the same issue, if the radio doesn't work, you get a brick Nov 17 15:27:10 pepe2k: what might work is waiting for /etc/config/wireless to exist, and check if all wifis are disabled - if it's a modified config, it will already contain all existing wifis, and if its a "fresh" config, then only disabled wifis can be added later by wifi detect, so not having all is fine in the latter case Nov 17 15:27:12 so I'm not sure if that should be considered as a 'feature blocker', there is no way we can assure everything works Nov 17 15:28:40 KanjiMonster: I kind of got lost, how could wifi config get modified by the user if it's possible only over WiFi in case of devices we discuss here about? Nov 17 15:28:44 Foremostly I'd declare all this as future convenience improvements, rather than really anything "key thing to do before next release" type Nov 17 15:28:50 chicken egg problem Nov 17 15:29:33 olmari: that's for sure, but this topic has been discussed so many times before that it could be finally solved _somehow_ Nov 17 15:29:35 pepe2k: the user might reboot the system at a later stage, once they configured it Nov 17 15:30:45 KanjiMonster: who do you mean by they? Nov 17 15:30:57 pepe2k: the user Nov 17 15:31:04 they (singular) Nov 17 15:31:29 Like implied an improvement would also be guide and tools that make peoples to generate image with own wifi PW as easy as possible.. instead of trying to figure out way to geneate safe image to crippled device per default =) Nov 17 15:31:34 KanjiMonster: but I thought the WiFi will be still disabled by default and it will get enabled for that timeout period after all expected radios get up Nov 17 15:31:53 KanjiMonster: thus, user isn't able to modify anything before Nov 17 15:32:23 (maybe over serial but in that case there a way to fix bricked device) Nov 17 15:33:12 for the first time AP we definitely shouldn't touch /etc/config/wireless, but instead generate a "static" hostapd config Nov 17 15:33:35 directly in /tmp? Nov 17 15:33:43 yes Nov 17 15:33:47 could work Nov 17 16:53:05 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Nov 17 17:11:26 *yawn* Nov 17 18:26:50 blogic: hi Nov 17 18:31:06 *woof* Nov 17 18:38:46 aparcar[m]: hey Nov 17 18:59:45 swalker: thanks Nov 17 19:02:29 we use a pretty old version of the wireless-regdb (2017-10-20) in OpenWrt 19.07 Nov 17 19:03:21 some of the regulataion informations are updated, most of them allow more frequencies, but I think they also made some parts more strict Nov 17 19:03:36 should we update to make sure we are in compliance? Nov 17 19:04:24 but I thinbk it needed python3 now, but could be that it still works with python2, at least I saw some patches for python2 Nov 17 19:04:56 Hauke: it does not Nov 17 19:05:02 ran into that 3 days ago Nov 17 19:06:23 At what stage does device tree get compiled and added? Nov 17 19:06:34 Necrosporus: depends ont he target Nov 17 19:06:39 I wonder if I need make clean after I changed dts file Nov 17 19:06:49 but in general after the kernel is built and then it gets appended to the image Nov 17 19:06:53 All I want is to alter partition table for ramips r3050 Nov 17 19:07:02 make target/install Nov 17 19:09:04 My router has vendor fw settings patition before firmware. Given it's 4M device, any extra bit of space is valuable Nov 17 19:10:05 I do not understand why this partition is marked read-only though. It is not important at all, all it has are settings which can be altered via web-interface Nov 17 19:10:20 which router ? Nov 17 19:10:27 dir300b1 Nov 17 19:10:41 Quite popular router, there are a lot of them in Russia Nov 17 19:10:45 Still in use Nov 17 19:11:04 Many internet providers used to sell them to abonents Nov 17 19:11:19 you mean devconf ? Nov 17 19:11:38 One which is after devdata Nov 17 19:11:45 third partition, mtd2 in openwrt Nov 17 19:11:51 devconf Nov 17 19:12:02 it will hold the devices config for the original fw Nov 17 19:12:12 and thus allows revert to original fw i assume Nov 17 19:12:25 might also hold uboot config Nov 17 19:12:42 ah wait, its the factory partition it holds the wifi calibration data Nov 17 19:12:46 I am very sure without this partition you still can revert to original fw, you will just need to restore settings or click them in web interface Nov 17 19:12:51 wiping it will kill your wifi forever Nov 17 19:13:06 devdata is important Nov 17 19:13:10 devconf isn't Nov 17 19:13:59 0x000000000000-0x000000030000 : "u-boot" Nov 17 19:13:59 0x000000030000-0x000000040000 : "devdata" Nov 17 19:13:59 0x000000040000-0x000000050000 : "devconf" Nov 17 19:13:59 0x000000050000-0x000000400000 : "firmware" Nov 17 19:14:07 it is indeed named incorrectly Nov 17 19:14:37 well, the bootloader will flash to firmware Nov 17 19:14:47 so you cannot change it Nov 17 19:15:01 right. I want to move the beginning of firmware to 40000 Nov 17 19:15:13 and expand firmware by one sector Nov 17 19:15:33 as i said the bootloader menu wont let you flash to 40000 Nov 17 19:15:44 and there needs to be an easy install path Nov 17 19:15:45 Who said I can't flash it via mtd write? Nov 17 19:16:12 you can do it on your router for sure just we wont accept a patch to make that change upstream Nov 17 19:16:26 Alright. I said. This partition is sadly marked read-only. Is it possible to flash from openwrt? Nov 17 19:16:49 it wont work Nov 17 19:16:57 If not I still can flash via tftp command in uboot prompt. I already did it once Nov 17 19:16:59 the bootloader will try to boot from 50000 Nov 17 19:17:09 Unless I tell it to boot from 40000 Nov 17 19:17:20 well then go for it Nov 17 19:17:39 Sadly bootloader ignores bootcmd variable Nov 17 19:26:41 blogic, I think I will need to flash the bootloader to make change of offset permanent Nov 17 19:27:25 It could be hardcoded somewhere in uboot itself rather then be set from a variable :( Nov 17 19:33:18 with this patch the new wireles-regdb also works with python2: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=651e39dee8605995b736b6056c6f7dc5c5a9c948 Nov 17 19:55:20 could you guys take a look at this? -> https://forum.openwrt.org/t/sta-speed-slows-down-after-eap-reauthentication/48506 Nov 17 19:55:45 trying to gather more info before opening a bug report, if necessary Nov 17 20:08:42 it would really help if you could get closer where this problem started Nov 17 20:09:01 t4h4[m]: like try a commit in the middle between wheer it was working and when you staretd to see these problems Nov 17 20:15:07 Hauke: Will I be able to build an older version of wpad/hostapd as well? Not familiar with the openwrt build system. Nov 17 22:05:00 mangix: did you submit that flashrom patch to add ARC support upstream? Nov 17 22:22:05 stintel: yes Nov 17 22:23:03 https://github.com/flashrom/flashrom/pull/88 Nov 17 22:23:57 ok that review had activity 2 days ago Nov 17 22:24:16 unfortunately the patch doesn't apply to v1.1 Nov 17 22:24:37 maybe I can grab it from your PR and that might apply Nov 17 22:24:50 I need 1.1 for mx25l51245g support Nov 17 22:25:47 that... is interesting. uscan shows flashrom as up to date. Nov 17 22:25:51 swalker: ^^ Nov 17 22:26:07 mangix: I'm preparing a PR to bump it Nov 17 22:26:37 sounds good Nov 17 22:28:36 is there a recommended way to strip out a test causing the configure to fail from configure.ac? should I just wing it with sed? Nov 17 22:29:20 Strykar: I've seen SED and patches. I prefer the latter. Nov 17 22:29:28 *sorry former Nov 17 22:29:53 wouldn't a patch be cleaner? Nov 17 22:30:11 or is it too much to commend out 10 lines? Nov 17 22:30:29 meh guess so. It doesn't really matter. Nov 17 22:30:50 Some people here complain about the amount of local patches. Nov 17 22:32:01 I'd say if it's upstreamable -> patch, if not -> sed ? Nov 17 22:32:26 although a patch that fails to apply is easier to spot than a sed that no longer has any effect Nov 17 22:32:29 I opened an issue upstream, I'll give it some time first I guess - https://github.com/duosecurity/duo_unix/issues/170 Nov 17 22:32:59 got duo 2FA working with openssh Nov 17 22:33:40 stintel: know what that gnu89 in flashrom's Makefile is about? Nov 17 22:34:12 mangix: nope Nov 17 22:34:25 there's also a PKG_SOURCE_SUBDIR. That only applies to git packages AFAIK Nov 17 22:34:49 mangix: no, it's needed, because of the stupid v in the tarbal since 1.1 Nov 17 22:35:09 flashrom-1.0.tar.xz vs flashrom-v1.1.tar.xz Nov 17 22:35:14 That's what PKG_BUILD_DIR is for :) Nov 17 22:35:23 ah Nov 17 22:35:38 ok got confused, but I didn't add that PKG_SOURCE_SUBDIR did I : Nov 17 22:35:53 cleanup is for another commit, and maybe another day Nov 17 22:36:28 well, might as well take the time. CircleCI failed :P Nov 17 22:37:07 both libusb-1.0 and libusb-compat are listed as dependencies. rofl. Nov 17 22:37:41 ah bugger Nov 17 22:37:42 cp: cannot stat '/home/stijn/Development/LEDE/source/staging_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-7.4.0_musl_eabi/lib/libssp.so.*': No such file or directory Nov 17 22:37:47 what is this crap all the time Nov 17 22:37:54 can't do make package/blah/{clean,compile} anymore Nov 17 22:42:47 great, closing the PR hides the CI info Nov 17 22:43:50 stintel: https://6138-20307838-gh.circle-artifacts.com/0/home/build/build_dir/logs/package/feeds/packages/flashrom/pci/compile.txt Nov 17 22:44:04 had it open Nov 17 22:44:24 full builds. pci does not Nov 17 22:44:29 ah Nov 17 22:44:32 thanks Nov 17 22:45:27 hmmm not even related to that backported patch Nov 17 22:56:36 mangix: stupid 'v' as stintel noted Nov 17 22:57:17 uscan: Newest version of flashrom on remote site is v1.1, local version is 1.0 Nov 17 23:03:00 I do wonder why we keep updating GCC Nov 17 23:03:11 each new release makes bigger binaries Nov 17 23:20:54 build #44 of lantiq/falcon is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Ffalcon/builds/44 Nov 17 23:35:59 xback: it could be that you have to do similar changes like these to backports for the next kernel update: https://www.spinics.net/lists/backports/msg04930.html Nov 17 23:36:09 I plan to do a new backports release in the next few days Nov 17 23:51:14 Hauke: looks a lot like that would be the issue, as fq.h, fq_impl.h and skbuff.h are provided by the backports package Nov 18 00:01:39 pkgadd: is there already an issue known? Nov 18 00:02:59 Hauke: xback's report on https://www.spinics.net/lists/netdev/msg612654.html and I've also seen it on ipq806x/ ath10k http://paste.debian.net/1116719/ Nov 18 00:03:38 pkgadd: I didn't know about this, but this is very likely related Nov 18 00:04:53 yes, I'm preparing a build now (will take a bit to scrape the patches from the mailing list archive) Nov 18 00:06:37 "ip rule add iif br-lan lookup 100" - works just fine in openwrt. Traffic coming from br-lan uses routing table 100. Nov 18 00:07:08 "ip rule add iif wlan0 lookup 200 - does not work. Like if traffic is not coming in rom wlan0 at all, (tcpdump wlan0 works fine) Nov 18 00:20:02 nbd: you added a more complex pci_disable_link_state() implementation to backports: https://git.openwrt.org/d64daf7026ce47788f12130462a3107bdab8718f Nov 18 00:20:17 is this really needed or can we just call the old implementation and return 0 Nov 18 00:24:13 pkgadd: xback: I send a patch which should fix this problem Nov 18 00:24:23 thanks Nov 18 00:24:32 please apply it to master and 19.07 if it works Nov 18 00:29:44 hrm. I don't understand this dual channel wifi thing Nov 18 00:39:57 Hauke: there are systems on which pci_disable_link_state can't disable aspm (because aspm is not under OS control) Nov 18 00:40:23 Hauke: without my extra changes, mt76 doesn't detect this and leaves aspm enabled Nov 18 01:02:30 nbd: To be a pest, has there been any further progress with MT7628 4addr issues? Nov 18 01:06:32 Hauke: that doesn't quite seem to be sufficient, http://paste.debian.net/1116726/ with kernel 4.19.84/ ipq806x Nov 18 01:08:55 upstream changes fq->perturbation = prandom_u32(); to get_random_bytes(&fq->perturbation, sizeof(fq->perturbation)); Nov 18 01:15:04 Is anyone aware of any Broadcom driver support for 19.7? Nov 18 01:20:20 you're going to have to be more specific Nov 18 01:27:00 So I have a Netgear N6250 that technically will run openwrt but it implies that I more than likely would not have 5G because of the lack of public Broadcom drivers. Nov 18 01:28:56 So I'm digging to see if any drivers were included that weren't in the past. Nov 18 01:39:29 both WLAN cards won't be usable (54 MBit/s max via b43), and no, there are has never been a (better-) driver for BCM4360 or BCM43217 Nov 18 01:42:47 and neither is that likely to change, 'ever' Nov 18 01:44:23 Well, that's unfortunate. Based on what I've read though I should be able to get at least 2.4 with the older firmware? Nov 18 01:55:51 no **** ENDING LOGGING AT Mon Nov 18 02:59:57 2019