**** BEGIN LOGGING AT Tue Jan 07 02:59:58 2020 Jan 07 10:31:31 just tried to use 19.07.0 ath25 ImageBuilder to build images for ubnt2 and ubnt5 devices, however, due to them being commented-out in target/linux/ath25/image/Makefile, they are also unusable in the ImageBuilder (missing kernel.bin)... Jan 07 10:33:02 jow, nbd: isn't there a better way to allow image generation to fail gracefully so a failing image build would affect other target devices? then at least IB would remain usable for too-small-flash devices Jan 07 10:34:40 dangole: this discussion is going on back and forth since forever Jan 07 10:35:03 once we handle failing images gracefully, people complain that we do not error out Jan 07 10:35:18 once we error out, people complain that images are not simply skipped Jan 07 10:39:28 in the end, the lack of error notification in case of a failing image is easy to recover -- just check if the file exists. Jan 07 10:40:08 missing kernel images and having to manually edit .targetinfo and .profiles.mk is a bit more harsh of a drawback Jan 07 10:41:50 this is solved, isn't it? Jan 07 10:41:54 DEFAULT := n Jan 07 10:42:28 for example b0b1d4aaf0b646ba352e2bd446f7074d210b0f01 Jan 07 10:43:32 so someone just needs to remove those comments and add `DEFAULT := n` instead? Jan 07 10:44:19 yeah, I guess so Jan 07 10:45:36 but this is probably not fixing the missing kernel Jan 07 10:46:53 btw, whoever bumped the libubox abi in 19.07 - please don't do it again from now on Jan 07 10:47:21 I bumped it Jan 07 10:47:28 it will render the repositories unusable with existing images and people attempting to force-upgrade the package will brick their devices Jan 07 10:48:18 or to be more specific, the next abiversion bump should also add an soversion to libubox.so Jan 07 10:50:45 so this is not being handled by the abi version bump? Jan 07 10:51:22 no, the abi version bump will ensure that all things are rebuilt and that binary package dependencies are constrained to the newer version Jan 07 10:51:44 but since libubox itself has no soversion, programs will link the unversioned libubox.so instead of some libubox.so.X.Y Jan 07 10:52:03 which prevents parallel installation of different ubox versions Jan 07 10:52:37 ok, so lets fix it now in master? Jan 07 10:53:00 that'd be good Jan 07 10:55:44 ynezz: thanks, i'll replace the commented-out images with DEFAULT := n Jan 07 10:55:52 iirc his can be done in Cmake using SET_TARGET_PROPERTIES(libname PROPERTIES VERSION 123456789) Jan 07 10:56:26 build #84 of ath79/nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Fnand/builds/84 Jan 07 10:56:27 for things like libubox that do not really follow any semantical version model, I suggest using YYYYMMDD of the last incompatible commit Jan 07 10:58:12 what about setting VERSION=ABIVERSION ? Jan 07 10:58:32 passing that to cmake from make Jan 07 11:00:01 would be a possibility as well Jan 07 11:00:38 you just need to make sure that the install recipe of the OpenWrt makefile is generic enough to handle the varying libubox.so.XXX filenames Jan 07 11:00:55 the libubox.so -> libubox.so.XXX symlink must *not* be packaged Jan 07 11:01:08 but it must be installed into the staging prefix in InstallDev Jan 07 11:01:30 https://openwrt.org/docs/guide-developer/package-policies#shared_libraries Jan 07 11:06:11 * ynezz 's head explodes Jan 07 11:11:24 they went crazy on GitLab "Please solve the reCAPTCHA: We want to be sure it is you, please confirm you are not a robot." Jan 07 11:11:34 and I'm logged in Jan 07 11:18:09 recaptcha is much fun if you use some anti-tracking addons in your browser... Jan 07 11:18:34 like having to answer ~10 images before getting the OK Jan 07 11:19:10 exactly Jan 07 11:23:00 Hauke: thanks Jan 07 11:24:22 can someone clarify which package exactly is needed for WPA3? https://openwrt.org/releases/19.07/notes-19.07.0#wpa3_support Jan 07 11:24:41 are hostapd-openssl, wpa-supplicant-openssl and wpad-openssl equivalent? Jan 07 11:25:37 one's hostapd only, one's wpa supplicant only, and ones' both? Jan 07 11:26:47 I mean, if I wanted to enable WPA3, which one should I install? all three? pick any at random? Jan 07 11:26:50 i wonder what broke wpa_supplicant-wolfssl -- i'm using it on some flash-constraint nodes in a 802.11s SAE mesh and it works (and interconnects with nodes using openssl variants) Jan 07 11:27:27 it's not a recent build, master from around March 2019 Jan 07 11:27:30 zorun: if you're only an access point, hostapd is enough, if you'r eonly ever a wifi client, supplicant is enough, if you might want both, wpad. Jan 07 11:28:25 karlp: ok, that's clear, thanks! Jan 07 11:42:41 build #79 of x86/legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Flegacy/builds/79 Jan 07 11:49:33 jow: could you proof-read this note about the new LuCI https://openwrt.org/releases/19.07/notes-19.07.0#client-side_rendering_of_the_luci_web_interface ? Jan 07 11:50:03 should we mark https://openwrt.org/docs/techref/luci2 as deprecated? Jan 07 11:53:32 @zorun: " LUcI web interface:" in the notes got wrong camel-casing, should be "LuCI" Jan 07 11:54:55 build #79 of mxs/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mxs%2Fgeneric/builds/79 Jan 07 11:55:05 dangole: thanks, fixed, now I know why it sounded strange :) Jan 07 12:06:49 https://sha-mbles.github.io/ Jan 07 12:17:41 zorun: Lua usage is not yet deprecated, I'd slightly reword it to something like "Lua usage reduced" Jan 07 12:19:57 jow: thanks, updated Jan 07 12:23:18 Maybe emphasis to "will be deprecated"? Jan 07 12:25:00 Not that it might matter that much on such notice page in itself, my reasoning is that it would emphasise it's preferred to use new stuff, don't use old stuff anymore, as a general rule =) Jan 07 12:25:37 I do assume it is wanted to eventually get rid of, as in default use Jan 07 12:26:10 I mean to the point where some of libraries shouln't be needed anymore in default images :) Jan 07 12:26:35 ..anyway... small notion turned into big thoughts quite instantly =) Jan 07 12:28:49 disconnecting to deploy 19.07 on dgn3500. fingers crossed. Jan 07 12:33:38 jow: related, I was asking for some guidance yesterday, what sort of timeframe do you envisage for migrating luci repo apps/modules? I was going to add translations that were missing to some things, but they're all lua cbis, how aggressively should I be trying to work on moving them to js? Jan 07 12:38:28 stintel: nice, "just" $100k and 900 GPUs Jan 07 12:38:33 and two months... Jan 07 12:41:27 ynezz: if someone decides to move his mining farm to something more lucrative ... :) Jan 07 12:53:46 welp, the long-standing race condition between jffs2 formatting and pci fixup is still there Jan 07 13:02:32 build #80 of lantiq/xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/80 Jan 07 13:10:42 about to try mixed mode for wifi Jan 07 13:24:42 heh, luci won't change wifi settings over wifi anymore, only over ethernet Jan 07 13:29:06 New (luci) settings revert model bites you on places connectivity loses, thus wifi and networking moatly Jan 07 13:29:33 Mostly* Jan 07 13:29:37 build #79 of imx6/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/imx6%2Fgeneric/builds/79 Jan 07 13:30:31 idk what clients support wpa3, so wpa3 connectivity still untested Jan 07 13:32:08 https://community.ui.com/questions/Apple-has-announced-WPA3-support-across-the-iPhone-iPad-line/96359bab-e578-4d0b-8816-928df32ae31c claims iOS 13 devices support WPA3. Jan 07 13:32:13 my experience is that most clients do not support wpa3 properly Jan 07 13:32:30 no ios13 devices at this location Jan 07 13:32:58 I have iOS13 devices, I tried to get WPA3 working a few months ago with openwrt nightly, but failed. Jan 07 13:33:01 see WPA3 support: https://openwrt.org/releases/19.07/notes-19.07.0-rc2 Jan 07 13:33:29 olmari: it mostly _helps_ in those places, but in places where it doesn't, you now get the "failed toa pply, do you want to do a forced apply?" dialog Jan 07 13:33:42 I've normally found it more reliable, but it "breaks differentyly" Jan 07 13:36:14 i just tried disconnecting and reconnecting on a samsung galaxy s8, still shows wpa2-psk Jan 07 13:40:03 karlp: I have no particular timeframe in mind. I'll be quite loaded with non-wrt work until at least March, afterwards I plan to spend some more time Jan 07 13:40:29 karlp: translation-wise, there are no functional differences between Lua and JS code Jan 07 13:40:41 same workflow, same formats etc. Jan 07 13:49:06 I've had some success with WPA3 in 19.07 and trunk. My Pixel 3 can connect with WPA3 (though only if 802.11r is off; turning that on breaks it). Desktop Linux clients with network-manager have also worked, though at the moment it requires configuring with nmtui because KDE plasma-nm won't support WPA3 until the upcoming 5.18 release. Jan 07 13:50:24 I haven't been able to get a Pixel XL with the stock ROM to connect WPA3, but I'm pretty sure that is an issue with the (now unsupported) phone, not the WAP. Jan 07 13:50:24 SwedeMike: Regarding iOS, there was a fix that went in a few weeks ago for that. It enabled my dad's iPhone to connect successfully with WPA3. Jan 07 13:52:45 when i get home, i can test 19.07/wpa3-mixed/802.11r against ios13 Jan 07 13:53:03 Oh, WPA3 support apparently also has some relationship to which WiFi chipset is in the WAP. It has worked for me with ath9k and ath10k-ct, but when I tried it with mwlwifi, my phone saw the network as WPA2 and refused to connect. My Linux laptop connected properly though. Jan 07 13:53:11 jow: this was adding markup to the lua files to make translations appear at all :) Jan 07 13:53:34 the dgn3500 has ath9k Jan 07 13:54:18 and the galaxy s8 is seeing the mixed mode as wpa2 and connecting Jan 07 13:54:19 mamarley: ok, perhaps I should try again. Though, I have marvell devices (WRT1200AC for instance), so that might be problematic Jan 07 13:54:19 related, I had some code that used luci.dispatcher.node_childs to generate some dynamic lists of registered modules. That's now been removed, but it means I can't use the same stuff on 19.07 and master anymore. Could that be kept in luci-compat somehow for instance? Jan 07 13:54:37 i did force 802.11w off, though Jan 07 13:56:36 SwedeMike: The testing I did with mwlwifi was kind of rushed though, so I may have missed something or made a user error. Jan 07 14:04:31 can't seem to find conclusive info online of whether galaxy s8 supports wpa3 Jan 07 14:05:05 Officially, WPA3 support was added in Android 10. Samsung may have done something different though. Jan 07 14:05:17 it's running android 9 Jan 07 14:06:23 unlikely i'd say Jan 07 14:12:39 build #198 of brcm2708/bcm2710 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/brcm2708%2Fbcm2710/builds/198 Jan 07 14:22:08 is here maintainer of luci-app-acme ? Jan 07 14:26:34 zorun: you removed some parts from the changelog page: https://openwrt.org/releases/19.07/changelog-19.07.0 Jan 07 14:26:38 muhaha: played with that literally hours ago in master (of yesterday), ECC is broken, it names files diffirently than with rsa, but tries to use rsa-named files still (: Jan 07 14:26:40 build #184 of layerscape/armv7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/184 Jan 07 14:27:05 olmari what? Jan 07 14:27:10 zorun: could you or someone else please restore it, I do not have access here Jan 07 14:27:48 muhaha: Just randon notion, because acme =) (well, I suppose it's not luci-app failure but acme system in owrt itself) Jan 07 14:28:04 Hauke_work: 07|13:17:41 < jow> zorun: Lua usage is not yet deprecated, I'd slightly reword it to something like "Lua usage reduced" Jan 07 14:28:10 Hauke_work: the change seems legit ? Jan 07 14:28:36 @muhaha: that'd be @tohojo aka. Toke Høiland-Jørgensen Jan 07 14:28:51 olmari: well, I tried to use dnsapi and key=val is not pasted to acme config ( of courrse signing is not working for me too ) Jan 07 14:28:53 build #89 of ar71xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fgeneric/builds/89 Jan 07 14:29:55 olmari: https://github.com/openwrt/packages/pull/10792#issuecomment-566740749 21days ago Jan 07 14:30:16 stintel: I am talking about the changelog https://openwrt.org/releases/19.07/changelog-19.07.0?do=revisions Jan 07 14:31:01 this page is pretty big and the last ~ tousend lines were removed Jan 07 14:31:05 looks truncated. do you guys know how to generate it? Jan 07 14:31:17 oh Jan 07 14:31:17 this was probably an accident becasue the page is so big Jan 07 14:31:44 also, verbose logging does not work, it seems to pass some parameter to logger which ought to go to acme, I think Jan 07 14:31:46 yeah probably Jan 07 14:31:57 can you just revert the last change and add comment from the last change Jan 07 14:32:00 I'll restore the old version? Jan 07 14:32:18 hmmm, username or password wrong Jan 07 14:32:25 back to day job it is then :( Jan 07 14:32:48 muhaha: also, would be kinda crucial to determine is luci-app failing or the acme app itself, after all they're separate things Jan 07 14:32:48 karlp: uhm... problem is that the entire internal represenation of the menu tree changed in dispatcher.lua, so restoring node_childs() is likely not going to help Jan 07 14:37:41 was afraid of that Jan 07 14:37:54 I presume I need to look into how the new menu generation is being done, and emulate that. Jan 07 14:38:08 my new toys are on the way! Jan 07 14:38:19 Hakko FX888D-23BY Digital Soldering Station FX-888D FX-888 (blue & yellow) Jan 07 14:38:20 YAOGONG NEW 858D SMD Hot Air Gun Rework Station Digital Solder 3Nozzles 110V 700W … Jan 07 14:39:48 this was having a "submenu" that could automatically populate it's entries: ala https://zerobin.net/?6297803de612cff7#5dZheEtIiubcaTo5J6lE0WkDrKFKlqolc9pf1b/a9wg= Jan 07 14:40:06 wotcha gonna burn slimey? Jan 07 14:41:01 anything and everything Jan 07 14:41:20 karlp: I'm afraid the only way out atm is having two different code branches, depending on `if dispatcher.node_childs ~= nil` Jan 07 14:41:46 that is if the same codebasy really must support both versions Jan 07 14:41:51 *codebase Jan 07 14:42:39 on master you can access the entire, consolidated menu tree by using dispatcher.menu_json() Jan 07 14:42:46 then traverse that Jan 07 14:45:10 that will work. Jan 07 14:45:16 thanks for the help Jan 07 14:45:49 it's much easier for me to have it support both, I only release our own stuff on the latest release branch, but I need to test stuff on both Jan 07 16:39:46 I tried WPA3 now on 19.07.0 on WRT32x and after installing wpad-openssl and changing settings for wifi to "WPA3-SAE" using luci, my iOS devices just say they can't connect to the ssid when I choose it. Jan 07 16:40:32 https://forum.openwrt.org/t/wpa3-support-in-openwrt/10554/105 talks about an iOS bug. Trying to figure out where I need to put "auth_cache '1'" that there is talk of Jan 07 16:41:21 SwedeMike: auth_cache 1 is activated by default when using SAE since quite some time Jan 07 16:42:41 As you seem to be talking about Marvell WiFi, i would first try it with a different device. I'm using SAE with Linux / iOS and it works without issues (ath10k) Jan 07 16:45:12 blocktrron: thanks, but I don't have any ath10k devices. Jan 07 16:46:31 Are you using 802.11w? I've seen this causing issues with older (2015) MacBooks eventhough they are "supporting" WPA3 Jan 07 16:46:47 no idea about iOS though, earliest I've tried was an iPhone 7 Jan 07 16:46:54 blocktrron: I tried disabling it, but I can't (reverts back to enabled). Jan 07 16:47:11 also says 11w is requirement for WPA3 Jan 07 16:47:47 It's required by specification, but devices will connect to it with it being deactivated Jan 07 16:48:38 blocktrron: luci seems to enforce it as well, I guess I could try changing it in /etc/config/wireless Jan 07 16:50:15 sounds weird - but give it a shot Jan 07 16:50:17 even with "option ieee80211w '0'" I get the same response on my iPhone11 when trying to connect Jan 07 16:50:27 You've installed wpad-full-openssl? Jan 07 16:50:49 blocktrron: wpad-openssl anyway. Jan 07 16:52:23 Do you have any other device with which you can rule out the WiFi driver? It does not have to be ath10k, mt76 or ath9k should work too Jan 07 16:53:58 nothing easily accessible. Jan 07 17:20:42 Hi. I am currently working on bringing up an mt7621 board and am having some problems with configuring the switch Jan 07 17:21:51 As long as I do not set the type of lan to "bridge", I can configure the switch in any way I want. I can create different VLANs, assign ports, etc., etc. I have also verified that networking works by pinging my device Jan 07 17:22:45 As soon as I change the type to bridge, the board either freezes or CPU usage increases significantly (one core at 100%). Looking at the counters for the different ports, I see that they are increasing very fast. I also see 4096 VLANs, which is interesting Jan 07 17:24:07 Has anyone experienced anything similar? I am suspecting the board, as I dont see the issue on other mt7621-boards I have tested with, but I thought I should ask. The configuraton is the "default" (port 0-3 as LAN, port 4 as WAN) and I see the issue with 19.07 and master Jan 07 17:27:08 When the board crashes, or hangs, there is no output in the console Jan 07 18:32:02 Hauke: oops, did I? :/ Jan 07 18:32:07 I'm fixing it Jan 07 20:03:40 in the latest snapshot i have a vpn and services tab that say no modules installed in luci Jan 07 20:05:51 *Component not present. Jan 07 20:41:15 zorun: thanks for fixing it and also thanks for writing the release notes Jan 07 21:20:37 dangole: wil you sedn some patches to make it possible to activate some more boards in the ImageBuiler? Jan 07 21:22:40 Hauke: from what I understood setting 'DEFAULT := n' not only prevents the image from being build but also the needed kernel-image artifact... maybe i got it all wrong, i'll run a build myself to find out. Jan 07 21:34:01 11:45:26 < ynezz> but this is probably not fixing the missing kernel Jan 07 21:47:01 build #74 of brcm2708/bcm2709 is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/74 Jan 07 21:47:03 build #229 of mediatek/mt7622 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/229 blamelist: Matthias Schiffer , Daniel Golle Jan 07 22:04:33 Okay now I'm stumped... luci-ssl-openssl, acme cert, split dns so that on lan side dynamic dns resolves to local ip, ddns keeps public IP pointed properly... FW has ports open... still from internet with https I get "ssl3_get_record:wrong version number" Jan 07 22:05:01 while same address from lan side works fine (split dns works, rebinding protection enabled too) Jan 07 22:05:22 also the addressin general works, SSH works, http without s works (for testing) Jan 07 22:06:40 client curl verbose shows correct IP resolved and all that... Jan 07 22:06:46 makes no sense Jan 07 22:06:56 master from few hours ago on this machine Jan 07 22:07:00 should that matter Jan 07 22:13:11 build #230 of cns3xxx/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/cns3xxx%2Fgeneric/builds/230 blamelist: Matthias Schiffer , Daniel Golle Jan 07 22:19:38 makes absolutely no sense... Jan 07 22:25:53 if I ssh -L 22222::443 to router and curl agains 22222, it again works when allowing insecure ssl Jan 07 22:26:39 same with browse Jan 07 23:36:39 build #229 of x86/geode is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeode/builds/229 blamelist: Matthias Schiffer , Daniel Golle Jan 07 23:36:45 build #103 of malta/be is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/malta%2Fbe/builds/103 blamelist: Matthias Schiffer , Hauke Mehrtens Jan 07 23:58:33 holy mother of uer error... Found the culprit on last issue I ranted just above Jan 08 00:00:03 for some reason we have had long time and rediction from wan to linode server... using 443... THAT is answering, with wrong stuff.... but why did everything else work then? That is because from lan it was hitting lan-ip... only thing failing was 443 from internet, beause such odd rediction **** ENDING LOGGING AT Wed Jan 08 02:59:58 2020