**** BEGIN LOGGING AT Sat Jul 21 03:00:02 2018 Jul 21 04:09:11 jwh: you must be using a dell Jul 21 04:09:20 i hated the i2c shit Jul 21 04:09:27 its not just dell Jul 21 04:09:30 its very very common now Jul 21 04:09:34 yup Jul 21 04:09:35 across all builders Jul 21 04:10:34 there was a blog post a few years ago about that M$ touchpad crap on the dell sputnik blog, saying that *nix support would require heavy reverse engineering Jul 21 04:10:52 rip him Jul 21 04:10:53 seems like a good idea, but only one OS manages to get it right heh Jul 21 04:10:55 mistell Jul 21 04:11:08 it isn't even like the spec is secret Jul 21 04:11:13 MS published it years ago Jul 21 04:11:31 right Jul 21 04:12:04 its only supported by win8+ (barely, w10 for useful support) Jul 21 04:12:15 but thats still a number of years ago Jul 21 04:13:08 touchpads are just a sad state of affairs Jul 21 04:13:37 i can kinda live with this asus ux390ua's synaptics Jul 21 04:14:31 isn't that i2c too? Jul 21 04:14:41 i had the one below the 390 Jul 21 04:22:48 yeah, it doesn't feel as bad as my xps though Jul 21 04:23:23 i couldn't ever get my xps's touchpad usable Jul 21 04:29:35 For once, I don't think is Microsoft's fault, is the touchpad manufactures, like Elan and Synaptics Jul 21 04:29:42 it is Jul 21 04:29:48 the spec is reasonable Jul 21 04:30:12 both vendor suck (but only in their budget producs, so I guess you get what you pay for) Jul 21 04:30:27 but that doesn't excuse it taking years for kernel support Jul 21 04:30:34 vendors* Jul 21 04:30:59 libinput is improving with every release, and my touchpad is starting to behave correctly Jul 21 04:31:41 No I only have to change the acceleration setting Jul 21 04:31:43 drivers for generic i2c touchpads in windows was done by 2011 Jul 21 04:31:44 hth Jul 21 04:31:45 :P Jul 21 04:31:45 Now* Jul 21 04:32:02 doesn't require any specific driver, its clever enough to work with any generic pad Jul 21 04:32:06 enough to install a vendor driver Jul 21 04:32:25 thats largely the problem with the linux support Jul 21 04:32:28 its per-device Jul 21 04:32:38 rather than a generic driver that can figure out if its a touchpad or not Jul 21 04:33:50 I don't know about your laptop, but mine with a fresh installation of Windows 10 installs "Asus Smart Gesture" automatically, which is really annoying Jul 21 04:35:03 And I have to replace it with an Elan driver, because I think the generic doesn't work with it Jul 21 04:35:28 umm Jul 21 04:35:53 probably recovery/oem hidden partitiont Jul 21 04:36:14 coz the smart gesture drivers aren't on windows update and never will be because they are pure garbage Jul 21 04:36:27 Nop, it happened on a new SSD Jul 21 04:36:47 at least, the ELAN targeted ones aren't Jul 21 04:36:50 I think ACPI has something to do (just a hunch) Jul 21 04:37:09 ELAN actually make good pads Jul 21 04:37:12 its a decent touchpad Jul 21 04:37:19 but the smart gesture garbage is just dumb Jul 21 04:38:32 I didn't wanted to offend someone by saying that, but that was exactly was I was thinking xD Jul 21 04:40:56 don't get me wrong, ELAN were for over a decade, a total disgrqce Jul 21 04:40:59 disgrace Jul 21 04:41:03 utter toss hardware Jul 21 04:41:11 but their new stuff is pretty good Jul 21 04:41:21 mostly coz they supposedly poached a bunch of synaptics people Jul 21 04:41:21 :D Jul 21 04:42:40 entirely unproven claims without any proof, ofc Jul 21 04:44:21 the biggest shame that I have experienced thus far is linux touch screen support on the desktop env side.. the closest that I had ever came for it being usable was with ubuntu 18.x with unity Jul 21 04:44:44 heh Jul 21 04:44:45 hoping that the work being done with the librem phone will drive some progress though Jul 21 04:44:54 linux most certainly is not on the desktop this year Jul 21 04:45:07 or any year for the past 20 when they've been championing it Jul 21 04:45:12 nor for the next 10 Jul 21 04:45:17 heh pretty much Jul 21 04:45:34 but, i always digress when i think about how bad it is trying to run fbsd lolz Jul 21 04:45:35 can't complete with actual desktop focused OSes Jul 21 04:45:43 err, compete Jul 21 04:45:59 yeah Jul 21 04:46:55 so... no that i'm using these wrt routers again, i feel compelled to start building my own images again.. thinking about doing some nerd shit with jenkins and docker Jul 21 05:16:53 heh Jul 21 08:23:26 morning! Jul 21 08:23:30 back from holidays... Jul 21 08:23:58 mamarley: i'll look at that report over weekend Jul 21 08:37:54 ho ho ho...lidays :-) Jul 21 08:52:24 blogic: hi, let's just drop the patches I sent to the m-l. I have no beef there, and frankly I don't care enough to argue over this. Jul 21 09:46:21 I have installed WRT firmware on WDL3600. It works fine but the WLAN is open to public and I want to close it with a password. How? Jul 21 10:26:24 rmilecki: Thanks! If you need any more information or testing done, I would be happy to help! **** BEGIN LOGGING AT Sat Jul 21 10:56:15 2018 Jul 21 12:33:46 trying to compile 18.06: Applying ./patches-2.0/100-musl-compat.patch using plaintext: patching file src/usbipd.c Hunk #1 FAILED at 453. Jul 21 12:35:10 ping lynxis Jul 21 14:07:45 nbd: ping Jul 21 14:10:25 rmilecki: ping Jul 21 14:16:48 jow: pong Jul 21 14:17:07 nbd: I'm about to merge https://github.com/openwrt/openwrt/pull/1160 - do you see any reason why not= Jul 21 14:17:10 ? Jul 21 14:17:21 Its plain upstream backports as far as I can see Jul 21 14:19:16 and I am considering https://github.com/openwrt/openwrt/pull/1161 as well since fixing the crappy false error reporting for ath10k firmware loading would be quite worthwhile, but that backport is huge and I fear it has some regression potential Jul 21 14:21:32 the patch names on 1160 is a bit weird. upstream backports should be in the 3xx range Jul 21 14:21:50 but other than that, i'm okay with it Jul 21 14:22:42 allright, will attempt to clean it up then Jul 21 14:22:59 thanks Jul 21 14:23:37 i think 1161 is also too invasive for a simple warning cleanup Jul 21 15:14:27 Have or not to have...? That is actual question Jul 21 15:32:57 Anyone on that could maybe provide some pointers on configuring new LEDE setup? Jul 21 16:03:19 nbd: this was more work than anticipated - https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=c75bb741e18009bc5c0e82b9ef13a95b9ff18f88 Jul 21 16:12:45 mkresin: blogic: any idea how to handle https://bugs.openwrt.org/index.php?do=details&task_id=1511#comment5111 ? Jul 21 16:12:55 rt288x seems to be yet another 4.14 victim Jul 21 16:28:53 jow: not yet. don't have any rt288x hardware Jul 21 16:29:09 jow: NotTheEvilOne usually fixes issue found upstream Jul 21 16:35:11 mkresin: allright. another one; https://bugs.openwrt.org/index.php?do=details&task_id=1502#comment4615 Jul 21 16:35:30 Anyone on that can answer a couple questions on configuration? Jul 21 16:35:32 mkresin: (max mtu on mt7621) did you ever pushed whatever you did in your staging tree? Jul 21 16:35:51 mkresin: according to another ocmment later mtu up to 2k should be okay Jul 21 16:36:09 Amack: don't ask to ask, just pose your questions Jul 21 16:36:24 jow: upgrade went well, going to restart the VMs soonish Jul 21 16:36:59 f00b4r0: great Jul 21 16:37:35 jow: yes pushed it. but the topic of the ticket change to 9k mtu mentioned in the datasheet doesn't work Jul 21 16:37:53 jow: but it isn't something new, as it never worked Jul 21 16:38:22 i think i know what needs to be changed to support bigger MTU Jul 21 16:38:43 Sorry. I'm trying to set up my openwrt router to connect to my existing wireless network and be able to plug in via Ethernet cable (have to operate in wired config elsewhere in the house too far away from modem to run a direct cable) Jul 21 16:38:50 in the fragment processing part, there is some code that splits up a buffer into multiple descriptors if the buffer exceeds the descriptor size limit Jul 21 16:38:57 but the same is not done for the skb head Jul 21 16:39:12 i plan on unifying the frag and non-frag processing code some more soon Jul 21 16:39:18 jow: I pushed a last one-liner to my buildbot config repo, I think you'll find it trivial enough :) Jul 21 16:39:20 and that might make enabling bigger MTU work as well Jul 21 16:39:41 nbd: mhh. it's obvious with your explaination Jul 21 16:40:01 nbd: but its just another case of lack of hardware Jul 21 16:40:03 Amack: if you run luci you can just click on "scan" in the wireless page to setup a natted wireless client Jul 21 16:40:30 jow: I also replaced a finicky NIC that was connected to the VDSL modem, now it appears we can get the full 50/10. yay ;) Jul 21 16:40:36 nbd: while we are at it. the mt7621 hnat dt node causes dtc warnings Jul 21 16:40:58 mkresin: in any case I'd propose to close "[FS#1502] MT7621 - MTU > 1500 not supported (was previously)" directing to "[FS#1595] MT7621: MTU limited to 2048 despite the hardware supports 9K Jumbo Frame" Jul 21 16:41:04 nbd: it uses the same reg as the ethernet node. shouldn't it be a child of the ethernet node in that case Jul 21 16:41:23 if 2k works its not a regression compared to 17 anymore Jul 21 16:41:35 thats all I'm interested in atm Jul 21 16:41:42 jow: go ahead. I was just undecided what to do with the ticket Jul 21 16:42:04 Jow: I've been able to connect via wireless with no issue, and then connecting to the device over new wifi AP gives internet connectivity, but I can't figure out how to share that with my Ethernet lan. Jul 21 16:42:22 mkresin: so just to be perfectly clear - 2k *does* work now and you did push your changes? Sorry for being dense here Jul 21 16:47:23 jow: correct Jul 21 16:47:59 jow: and I have the same fix for another target in my staging tree. lack of hardware once more Jul 21 16:49:06 now we only need to figure out wth is wrong with ath10k Jul 21 16:50:22 Amack: what do you mean "share"? A client bridge of some sort? Jul 21 16:50:25 jow: pong Jul 21 16:50:35 Hi jow I no you have a lot on, but did you get a chance to look at fixing tables in luci for screenreaders? It's OK if not the changes are good so far what you have dun with the headings and that! I'm asking so I know weather to bother upgrading luci to test. Jul 21 16:51:12 rmilecki: wanted to have a chat regarding the various bcm53xx issues reported Jul 21 16:51:17 Tapper: no progress yet Jul 21 16:51:22 jow: ok Jul 21 16:51:27 OK mate Jul 21 16:52:16 jow: exactly. When hard plugged into the router, i don't get internet connectivity (but I do if I connect via wifi). I need the Ethernet to work tho. Jul 21 16:53:18 Amack: is the remote access point running openwrt too? Jul 21 16:54:12 rmilecki: there's been some reports like e3000 "bricked" after first boot etc. Which seems to relate to "mtd fixtrx" Jul 21 16:54:32 rmilecki: while skimming over the issue tickets I noticed that someone reported that things like dropbear and mtd were missing entirely from the image Jul 21 16:54:36 jow: i just told mamarley i'm going to look at that this weened Jul 21 16:54:43 it's brcm47xx not bcm53xx, but may not be important Jul 21 16:54:48 rmilecki: I wonder if we simply supplied broken images Jul 21 16:55:00 jow: yeah, that made me wonder Jul 21 16:55:08 i'm going to check that this weekend Jul 21 16:55:22 right, I think on bcm53xx people complained about regressed brcmfmac performance Jul 21 16:55:41 jow: I'm probably screwing up terminology. My config: Internet via FiOS, using their modem/router in stock config. I have openwrt installed on a belkin router (BR). BR connected via wifi to FiOS, looking to be able to connect to BR via Ethernet and get internet. Jul 21 16:55:53 rmilecki: sure, is that supposed to mean that I should leave you alone now? :D Jul 21 16:56:19 jow: mainly that I just need some time to get to that ;) Jul 21 16:56:22 thats okay. Will try to dig out my wrt610/e3000 in the meanwhile Jul 21 16:56:35 jow: it's hard to tell anything more about that without some extra research Jul 21 16:57:38 Amack: yeah, clicking "scan" in luci should setup exactly that, when starting from an otherwise default configuration. It will set up a new "wwan" interface which will act like a wan one Jul 21 16:57:48 Amack: lan ethernet gets then natted towards wwan Jul 21 16:58:27 Amack: if that does not work you might have an ip address conflict (192.168.1.x used by FiOS too), in this case simply change the openwrt lan ip to something else, e.g. 192.168.2.1 Jul 21 16:58:58 jow:...wan interface is set up, am I supposed to indicate bridging somewhere? Or do I keep default settings? Jul 21 16:59:20 Amack: client mode wireless interfaces cannot be bridged on openwrt Jul 21 16:59:45 you can only nat them, or use a special wds mode which only works if the remote ap is running openwrt (wds mode) too Jul 21 16:59:51 or use pseudo bridging using relayd Jul 21 17:00:30 in any case, clicking "join" in luci on an otherwise vanilla configuration will set up the natted client mode thing Jul 21 17:00:53 the resulting upstream interface will be called "wwan" (not wan!) Jul 21 17:00:59 wan will remain unused/unconfigured Jul 21 17:01:13 and the four lan ports will act as dhcp server etc. Jul 21 17:01:26 Sorry, yes wwan...autocorrect Jul 21 17:01:41 in this case check for ip address conflicts Jul 21 17:01:49 wwan should not have any 192.168.1.* Jul 21 17:02:00 if it does, you need to renumber the lan Jul 21 17:03:11 jow: my mtd changes didn't even went into 18.06-rc2 https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/openwrt-18.06 Jul 21 17:04:14 jow: rmilecki: The missing packages were with -rc1. The -rc2 images just hang in the bootloader on the first boot. Jul 21 17:04:38 rmilecki: yeah, but those mtd issues "just" fixed badblock behaviour, right? Jul 21 17:04:49 jow: right Jul 21 17:05:00 jow: it sholdn't matter e.g. for E3000 which doesn't use NAND Jul 21 17:05:10 Ok...wwan has a 192.168.1.* address. I've changed the lan config via the interface menu to be a static ip as 192.168.2.1. After that, couldn't connect to luci via Ethernet so had to connect via wifi. Jul 21 17:05:13 rmilecki: so I wouldn't consider them to be responsible for fixing non-booting devices unless all reported incidents are somehow due to bad blocks in the checksum area Jul 21 17:05:34 that too, yea Jul 21 17:05:46 Wifi connection provides Internet connectivity, if I disconnect and rely on Ethernet, no internet Jul 21 17:05:50 jow: right, they should me meaningless for these cases Jul 21 17:06:14 After I installed "mtd" and reran that script, the e3000 was able to reboot successfully on -rc1. Jul 21 17:06:20 Amack: yeah you need to provide more details, like if you receive an ip cia dhcp etc. Jul 21 17:07:07 Amack: if you can reach 192.168.2.1 if you manually configure 192.168.2.2 on your pc Jul 21 17:07:11 Amack: if you can ping 8.8.8.8 Jul 21 17:07:16 Amack: if you can ping google.com Jul 21 17:07:22 standard diagnostics stuff Jul 21 17:08:05 When connected via Ethernet only, right? Jul 21 17:08:09 Amack: yes Jul 21 17:08:20 mamarley: okay so its probably some kernel level issue Jul 21 17:10:22 mamarley: early console it disabled by default for brcm47xx images Jul 21 17:10:29 it's because it was hanging some devices Jul 21 17:10:41 there is probably some crash/hang in early kernel booting Jul 21 17:10:48 so there are two ways to debug it: Jul 21 17:10:58 1) find which commit between rc1 and rc2 broke it Jul 21 17:11:13 2) build image with earlyprintk and try booting it Jul 21 17:11:27 the openwrt commit log between rc1 and rc2 is quite small Jul 21 17:11:55 nothing that looks related apart from "5a40fad22a kernel: bcm47xxpart: fix getting user-space data partition name" Jul 21 17:12:04 jow: ipconfig shows IP address as 192.168.1.223, default gateway of 192.168.1.1, no luck on either ping request (time out and couldn't find respectively) Jul 21 17:12:16 rmilecki: OK, I think I will try 2 first, but I don't have my e3000 with me today so it will probably be tomorrow or Monday. Jul 21 17:12:57 Amack: should be 192.168.2.* something if you changed the openwrt lan ip to 192.168.2.1 Jul 21 17:13:18 jow: about to restart the VMs. Want to give a shot at updating the config now? Jul 21 17:14:17 mamarley: are you running generic or mips74k subtarget builds? Jul 21 17:14:48 rmilecki: generic. I didn't even know the mips74k subtarget would work. Jul 21 17:15:31 mamarley: it would boot, but it doesn't include ssb, so BCM4322 could not be supported Jul 21 17:17:14 jow: manual set to ip 192.168.2.2 gives connectivity just fine. So...is DHCP not working on openwrt router? Jul 21 17:18:05 I can confirm that openwrt-18.06.0-rc1-brcm47xx-generic-standard-squashfs.trx doesn't include "mtd".... uh Jul 21 17:19:50 It is also missing dnsmasq and dropbear. Jul 21 17:20:57 that's right... how?! Jul 21 17:21:03 Just out of curiosity, how does this happen? I remember back with 15.05, the same target was also missing stuff; in that case it was the switch driver (also effectively soft-bricking the router). Jul 21 17:21:46 that should be handled by https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/target.mk;h=a97cda2c3ac1c624b1b759def59cdbded1a4d597;hb=13f64a1e597e00e7bc9cf73866533f668482c4fa Jul 21 17:24:46 I just flashed openwrt-18.06.0-rc2-brcm47xx-generic-standard-squashfs.trx on BCM4706 and it booted Jul 21 17:25:36 it still doesn't include mtd Jul 21 17:28:06 jow: any idea why images could not include mtd dnsmasq dropbear? Jul 21 17:31:09 mips74k subtarget includes mtd dnsmasq and dropbear Jul 21 17:31:15 so it's only about the generic subtarget Jul 21 17:37:10 the only real difference in config.seed is that "generic" target includes: Jul 21 17:37:24 CONFIG_PACKAGE_firewall=y CONFIG_PACKAGE_kmod-ipt-conntrack=y CONFIG_PACKAGE_kmod-ipt-nat=y CONFIG_PACKAGE_kmod-nf-conntrack6=y CONFIG_PACKAGE_kmod-nf-nat=y Jul 21 17:40:27 rmilecki: good question Jul 21 17:43:43 as soon as I select CONFIG_TARGET_brcm47xx: then DEFAULT_mtd becomes =n Jul 21 17:45:42 rmilecki: I wonder if "208a3a1410 build: ensure that iwinfo is selected when building for multiple devices" is related Jul 21 17:45:51 despite the subject, it looks like a generic fix between rc1 and rc2 Jul 21 17:45:52 nbd? Jul 21 17:45:58 f00b4r0: pulled Jul 21 17:46:44 jow: disregard previous. My workstation wasn't accepting new IP address for some reason (even tho correctly aligned ip was showing as leased by wrt router), but after manual ip set showed it was working, I went ahead and connected my target workstation via Ethernet. Immediate DHCP assignment to correct subnet (192.168.2.*), Internet connectivity with no issue. you just made my wife extremely happy since she can now work anywher Jul 21 17:46:51 i just reverted 208a3a1410, rm .config, make menuconfig, selected CONFIG_TARGET_brcm47xx and checked DEFAULT_mtd, it's =n Jul 21 17:46:52 Thanks a ton for the help! Jul 21 17:47:09 rmilecki: also it seems rc1 was already affected by that Jul 21 17:48:02 rmilecki: so it *still* happens in rc2 ? Jul 21 17:48:03 Amack: coolk Jul 21 17:48:09 rmilecki: yes! Jul 21 17:48:21 [19:24] I just flashed openwrt-18.06.0-rc2-brcm47xx-generic-standard-squashfs.trx on BCM4706 and it booted Jul 21 17:48:22 [19:25] it still doesn't include mtd Jul 21 17:48:26 I see Jul 21 17:49:31 but your releases are green, and they should be blue.... Jul 21 17:53:08 jow: nbd: checking tmp/.config-target.in points that DEFAULT_TARGET_brcm47xx_generic doesn't include "select DEFAULT_mtd if TARGET_PER_DEVICE_ROOTFS" Jul 21 17:53:22 such a line is present for DEFAULT_TARGET_brcm47xx_legacy and DEFAULT_TARGET_brcm47xx_mips74k Jul 21 17:53:34 rmilecki: I think the root cause is the device specific profiles Jul 21 17:54:00 rmilecki: target/linux/brcm47xx/generic/profiles/PS-1208MFG.mk contains PACKAGES:=-firewall -dropbear -dnsmasq -mtd -ppp -wpad-mini kmod-b44 block-mount kmod-usb-storage kmod-usb2 kmod-usb-ohci -iptables -swconfig kmod-fs-ext4 Jul 21 17:54:22 rmilecki: I think when per-device rootfs is enabled, buildroot will form the union of all package selections Jul 21 17:54:42 rmilecki: it does not treat the "-" prefix specially Jul 21 17:54:59 i thought target/linux/brcm47xx/generic/profiles/ files should be ignored when using CONFIG_TARGET_MULTI_PROFILE Jul 21 17:55:20 so the union of PROFILE_A with PACAKGES:=foo bar and PROFILE_B with PACKAGES:=bar -baz will be PACKAGES:=foo bar -baz Jul 21 17:55:28 which will disable baz for PROFILE_A Jul 21 17:55:28 uh Jul 21 17:55:41 that's probably correct, I see no other explanation Jul 21 17:56:14 let me dig into it, probably just needs a well placed $(filter-out -%,...) Jul 21 17:58:11 jow: it's a regression since 17.01 anyway... in 17.01 it was working correct, I just check it Jul 21 17:58:13 *checked Jul 21 17:59:19 rmilecki: include/target.mk contains: DEFAULT_PACKAGES := $(filter-out $(patsubst -%,%,$(filter -%,$(PACKAGES))),$(DEFAULT_PACKAGES)) Jul 21 17:59:52 which to me looks like every included profile will substract its "-" prefixed packages from the default selection Jul 21 18:05:21 jow: both VMs seem to be working fine. I have to run an errand, ping me if/when you want to try the new config... Jul 21 18:10:18 f00b4r0: sourceupload appears to upload everything now Jul 21 18:10:23 will revert for now Jul 21 18:10:31 link? Jul 21 18:10:38 http://phase1.builds.lede-project.org/builders/ar71xx%2Fnand/builds/933/steps/sourceupload/logs/stdio Jul 21 18:12:02 jow: that's not running new config Jul 21 18:12:32 ok Jul 21 18:12:54 the df step seems broken, '~' is undefined / ENOENT in exec*() context Jul 21 18:12:58 (unless you edited the common rsync params) Jul 21 18:13:02 probably needs interpolated $HOME Jul 21 18:13:21 http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/915/steps/df/logs/stdio Jul 21 18:13:27 ah crap Jul 21 18:13:38 yeah I got bitten again Jul 21 18:13:52 please revert that one bit, I'll fix Jul 21 18:14:03 http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/915/steps/sourceupload/logs/stdio Jul 21 18:14:11 this is running new config and is working as expected Jul 21 18:14:42 yep Jul 21 18:14:47 all the upload steps here: http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/915 Jul 21 18:14:52 have worked as designed Jul 21 18:14:52 ok cool Jul 21 18:14:58 ;) Jul 21 18:15:19 hi all. I need help for openldap-server on openwrt. Is there anyone with experience Jul 21 18:15:43 jow: and the ccache wrapper seems to be working too! ;) Jul 21 18:15:59 jow: you'll have to apt-get install ccache on -02 and -03 to use it there tho Jul 21 18:17:17 the wrapper works with and without ccache as designed Jul 21 18:17:20 yay! ;) Jul 21 18:18:41 jow: ok so apparently the only thing I broke this time is the 'df' step Jul 21 18:20:10 jow: since there's no shell involved, i can't expand $HOME right? I'll have to use an intermediary slave variable? Jul 21 18:21:06 f00b4r0: guess so Jul 21 18:21:09 ok Jul 21 18:21:31 well if you're happy with the rest, just drop d36567d and commit everything else Jul 21 18:21:43 I'll rework that little bit later, it's purely cosmetic anyway Jul 21 18:21:51 rmilecki: so it is as expected, each included profile .mk will substract its "-" prefix packages from DEFAULT_PACKAGES which is later used as base for per device rootfs building Jul 21 18:21:55 f00b4r0: ok Jul 21 18:22:12 jow: thanks! and please set "shared_wd" to true for 02 and 03 while you're at it ;) Jul 21 18:22:34 rmilecki: so when any profile in the chosen targets has a PACKAGE:=-foo, "foo" will get dropped from all devices Jul 21 18:36:36 jow: ca32373c951c651f4fe5d8f99ddeb8d4f20bbe3e is the first bad commit Jul 21 18:36:43 target.mk: let profile remove from DEFAULT_PACKAGES Jul 21 18:37:35 "git bisect run" is awesome :) Jul 21 18:41:23 rmilecki: https://pastebin.com/vW3w2Luv Jul 21 18:41:42 this seems to work and still allow a single profile (without per device rootfs) allow to opt out of mtd Jul 21 18:42:17 I honestly fail to see why the DEFAULT_PACKAGES mangling is required at all Jul 21 18:43:13 but I'd have no issues with completely reverting either, imho the commit message does not sufficiently explains the changes made and the motivation behind it Jul 21 18:44:09 jow: it fixes CONFIG_TARGET_brcm47xx_generic Jul 21 18:44:43 lets push it then Jul 21 18:44:47 will take care of it Jul 21 18:45:12 rmilecki: seems brcm47xx is only one of three targets still using old style profiles, I'd say there's a lot of bad luck involved Jul 21 18:45:26 and it explains why noone else experiences such issues Jul 21 18:45:33 need help to recover my router, that got dead after successful fw upgrade Jul 21 18:48:26 30/30/30 doesn't work and neither serial connection however the router gets hot while running Jul 21 18:49:54 I've a cp210x UART to USB device can't get anything at the console and followed all possible config options anyone experienced such thing? Jul 21 18:49:59 I can haz stupidquestion? how do I exclude odhcpd when building an image with Image Builder? PACKAGES="-odhcpd" seems to have no effect. Jul 21 18:51:23 (building an image for a NAS box, no point in it doing DHCP.) Jul 21 18:51:54 drmr: i'm pretty sure odhcpd is mandatory Jul 21 18:52:32 try using the buildroot and see if you can strip odhcpd Jul 21 18:53:11 The router as only 3 fixed leds all the time doesn't matter what, do I need a JTAG? Jul 21 18:54:15 rmilecki: allright, so this solves the missing mtd problem at least. Fixes pushed to master and openwrt-18.06 Jul 21 18:58:19 right, now this builds properly I need to add options to the package Jul 21 18:58:21 hnng Jul 21 19:05:07 serial pins at the router shows vcc +3.3v tx and rx +3.3v can i conclude anything from this? Jul 21 19:06:42 mikatone: i can't help, but perhaps you could share what the device is, and the full filename of the firmware you last flashed to it? Jul 21 19:09:04 Fishman: the router is a RT-N66U the firmware was latest available Jul 21 19:10:01 mikatone: i can't find a file named "latest available" on downloads.openwrt.org Jul 21 19:12:05 Fishman: I guess it was this https://downloads.openwrt.org/releases/17.01.5/targets/ar71xx/generic/lede-17.01.5-ar71xx-generic-ubnt-rspro-squashfs-sysupgrade.bin Jul 21 19:12:25 Fishman: sorry that was for my RSPRO Jul 21 19:15:09 Fishman: 17.01.5 generic I guess... Jul 21 19:15:19 any interest in a command-not-found for openwrt? Jul 21 19:15:23 jow: thanks for the fix, I'm OK with dropping these profiles Jul 21 19:15:31 I wrote it, but I have to package it now Jul 21 19:15:41 jow: i'll send PATCH for that i guess Jul 21 19:16:32 Fishman: can't remember it was a month ago, since there I been waiting for the CP2102 serial cable device Jul 21 19:16:32 mikatone: 30/30/30 is really bad thing to do, it erases NVRAM, most CFEs contain incomplete NVRAM for restoring original one, so now you'll have problem with calibration data Jul 21 19:17:05 rmilecki: I've done it after trying normal reset and serial connection etc Jul 21 19:19:04 the device can't connect I see the router has indeed some sort of activity since it gets warm and the serial pins vcc, rx, tx have 3.3v and GND 0v Jul 21 19:19:38 mikatone: the rx pin should not have any voltage on it unless you're transmitting to it Jul 21 19:20:07 Fishman: not I'm not transmitting and I get 3v out of there Jul 21 19:20:09 mikatone: and since it's broadcrap, i personally would be walking away from the device and not wasting any more time on it Jul 21 19:20:26 mikatone: then i would guess it's probably very very broken Jul 21 19:20:59 Fishman: I just don't get how something gets broken while upgrading Jul 21 19:21:05 (or your measurement isn't being done correctly) Jul 21 19:24:52 Fishman: red prob at switch metal shell and black at the pin not seeing why is not fine but i can Jul 21 19:25:22 *i=it Jul 21 19:27:43 scientes: ? Jul 21 19:28:14 jow: can you close https://bugs.openwrt.org/index.php?do=details&task_id=1647 ? I tried changing its "Status" buy I only see "Unconfirmed", "New", "Assigned", "Researching", "Waiting on reporter" and "Requires testing" Jul 21 19:28:23 jow: i don't see "Fixed" status or similar Jul 21 19:28:57 Fishman: also measured the serial device voltages and I get 2.98v between GND and rx / tx Jul 21 19:29:22 jow, https://github.com/shawnl/openwrt/commit/d839cb09d57b671bd72a91df2b0ddddb0a71974d Jul 21 19:30:06 rmilecki: hit the "Close task" button in the upper right corner Jul 21 19:30:11 rmilecki: after logging in Jul 21 19:30:15 oh... Jul 21 19:30:39 thanks Jul 21 19:30:56 https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500 Jul 21 19:31:11 scientes: I have to out myself here... I totally have no idea what this is and what it is supposed to solve Jul 21 19:31:20 I assume it is not a joke of some sort Jul 21 19:31:33 its just when you are using the command line over ssh Jul 21 19:31:34 afaik the external antennae on the v4 are dual band, as with the v3 and as opposed to the v2 where 2.4ghz is internal? Jul 21 19:31:54 if you use a command that is not installed it tells you what package to install to get that command Jul 21 19:32:00 what the hell Jul 21 19:32:07 ruby? Jul 21 19:32:09 give over Jul 21 19:32:35 its written in C Jul 21 19:32:51 I could easily re-write that part, but I wanted something that worked first Jul 21 19:33:02 why would something like this need to be part of openwrt anyway Jul 21 19:33:02 that part is only on the repo Jul 21 19:33:16 scientes: okay and what will it suggest? Jul 21 19:33:21 jow, i've got a pallet of v4s in storage, i'm assuming snapshot support=will be supported in 1806 and perhaps 170106? Jul 21 19:33:27 cause opkg doesn't produce a Contents.gz file Jul 21 19:33:59 jow, if you type "wg" then it will tell you to install "wireguard-tools" Jul 21 19:34:07 okay Jul 21 19:34:10 err, ofc 1701 kernel might be an issue Jul 21 19:34:12 interesting Jul 21 19:34:24 its there by default on ubuntu Jul 21 19:34:28 Fishman: Err, the RX pin would generally be pulled up, that's quite normal Jul 21 19:34:28 ntd: 17.01.6 very unlikely, 18.06 maybe Jul 21 19:34:34 ntd: is it supported in master? Jul 21 19:34:47 ubuntu isn't openwrt. openwrt gets installed to devices with sometimes less than 8MB total storage to work with. Jul 21 19:34:56 scientes: thats on the host anyway, not that useful, no? Jul 21 19:35:10 wiki says that it is supported in snapshot releases, assuming/hoping this means 1806? Jul 21 19:35:20 Monkeh: fair enough Jul 21 19:35:35 jwh, it helps when people are using tutorials they get off the internet Jul 21 19:35:40 that don't work cause software isn't installed Jul 21 19:36:03 https://downloads.openwrt.org/snapshots/targets/ar71xx/generic/openwrt-ar71xx-generic-archer-c7-v4-squashfs-factory.bin Jul 21 19:36:18 it uses like 50K Jul 21 19:36:19 how often do you type random commands on your openwrt device without knowing its installed? Jul 21 19:36:41 its not a general distro Jul 21 19:36:59 ntd: Yes, that should be in 18.06 Jul 21 19:37:01 yeah and it doesn't improove the hardware detection-->which kmod package to install problem Jul 21 19:37:05 ntd: sorry I'm a bit slow tonight, so you have a v4 of what exactly? Jul 21 19:37:11 archer c7 Jul 21 19:37:15 k Jul 21 19:37:38 yeah, generally though the userland package will depend on the appropriate kmods Jul 21 19:37:56 It's getting snapshot builds and the 18.06 rc builds have it, so unless things start catching fire it'll be in 18.06 Jul 21 19:38:11 jwh: I see C7 v4 and C7 v5 support Jul 21 19:38:15 in openwrt-18.06 head Jul 21 19:38:25 jow, don't wanna push you if you're feeling under the weather, but heard/have an opinion on current WPA3 developments? Jul 21 19:38:40 still haven't found anything substantive Jul 21 19:38:45 it'll end in hostapd and thus eventually end up in openwrt Jul 21 19:38:56 new hw not required? Jul 21 19:39:13 jeff posted a good summary in the forum, in the end its just SAE which is new / essential for wpa3 Jul 21 19:39:18 the rest is just optional iot fluff Jul 21 19:39:50 no, more like new wpa_supp / hapd with a bunch of new ciphers and auth protocols Jul 21 19:40:11 some new cert stuff for enterprise, EC etc. Jul 21 19:41:20 ok, ok. thanks. all i found is 11w required+something about a 192 bit se suite Jul 21 19:41:23 .11w is mandatory as well isn't it? Jul 21 19:41:39 ipkg files are compressed twice Jul 21 19:41:42 Monkeh: right, forgot about that Jul 21 19:41:44 which is kinda broken Jul 21 19:41:46 where can i get some more help about serial config etc? Jul 21 19:41:52 So I'm sure there will be some hardware which won't be capable Jul 21 19:41:54 fullmac crap like broadcom devices will probably need new firmware Jul 21 19:41:59 yes Jul 21 19:42:00 Or is adequately broken to not be viable Jul 21 19:42:02 assuming they even bothe Jul 21 19:42:03 r Jul 21 19:42:12 also: marvell Jul 21 19:42:36 jow: bailing for the evening. As far as I can tell, everything is working according to plan ;) Jul 21 19:42:39 It's going to be a few years before it's viable anyway.. Jul 21 19:43:04 i've checked that the targetupload step uploads everything it's supposed to, no more, no less. Jul 21 19:43:10 By the time Winderrs and phones catch up.. Jul 21 19:43:20 scientes: im still confused :) Jul 21 19:43:27 got a link re jeff/wpa3/forum? Jul 21 19:43:36 scientes: fix it then :D Jul 21 19:43:48 scientes: is there a benefit aside from fancy shell completion/package suggestions? Jul 21 19:44:23 does cnf even work with busybox sh? Jul 21 19:48:17 https://forum.lede-project.org/t/wpa3-and-lede-support/10554 Jul 21 19:52:12 jwh, with ENABLE_ASH_BASH_NOT_FOUND_HOOK Jul 21 19:52:47 ah Jul 21 19:56:28 is it disabled by default? Jul 21 19:56:34 i don't want it. :D Jul 21 19:57:36 only have 16MB to work with Jul 21 19:57:50 its only 50K, but yeah probably not on 16MB machines Jul 21 19:58:17 it could be half that with compression Jul 21 19:58:29 I don't really see any benefit to adding it Jul 21 19:58:34 yeah Jul 21 19:58:46 99% of users aren't going to even know its there Jul 21 19:58:48 the less technical users stick to luci Jul 21 19:58:57 * salcedo nods Jul 21 19:59:30 i don't run luci, not compiled in Jul 21 19:59:35 need the space for other stuff Jul 21 20:00:19 so imo it's a luxury for systems with more space Jul 21 21:26:59 in package Makefiles, can I just use SELECT(S) or something instead of depends? Jul 21 21:30:03 jwh: https://openwrt.org/docs/guide-developer/packages#dependency_types Jul 21 21:30:08 <3 Jul 21 21:30:35 even though I use +foo, it still hides it :/ Jul 21 21:31:07 hmm, That's not right Jul 21 21:31:26 yeah Jul 21 21:31:29 thats what I thought Jul 21 21:31:42 unless I've done something dumb... Jul 21 21:31:53 you got something you can double check on? Jul 21 21:31:57 just need to add a feed Jul 21 21:32:06 I might be being dumb Jul 21 21:32:27 You can open menuconfig Jul 21 21:32:44 and search for the package (press "/") Jul 21 21:32:56 yeah Jul 21 21:33:04 That should give you the dependencies and what it selects Jul 21 21:33:17 lemme double check makefile Jul 21 21:33:19 may have broke it Jul 21 21:33:44 either that or its a dependency of a dependency thats causing it to be hidden Jul 21 21:37:30 Look at package/system/mtd/Makefile for a simple example Jul 21 21:37:43 think I fixed it Jul 21 21:37:58 DEPENDS:=+libubox Jul 21 21:38:03 yeah, busted deps will do that, it can be really infuriating to diagnose Jul 21 21:38:15 something was out of sync in my tree, nuked tmp/ etc and its showing up now Jul 21 21:38:30 that'll teach me to be lazy and not start with a clean environment Jul 21 21:39:52 I WILL HAVE NICE THINGS Jul 21 21:42:12 pot noodle tie :D Jul 21 21:42:13 time* Jul 21 22:47:29 k I'm failing at this Jul 21 22:47:58 given... $(if $(CONFIG_PACKAGE_blah_option),-DLOG_PGSQL=TRUE) Jul 21 22:48:08 can I just add another arg for false? Jul 21 22:48:21 so like, $(if $(CONFIG_PACKAGE_blah_option),-DLOG_PGSQL=TRUE, -DLOG_PGSQL=FALSE) Jul 21 22:48:24 ? Jul 21 22:48:39 or is there a better way to set options based on option selection Jul 21 22:49:45 in this case, just need to modify CMAKE_OPTIONS Jul 21 22:52:20 also need to add package depends to menu options I guss Jul 21 22:52:22 guess Jul 21 23:17:51 whats the diffrents 18.06.0-rc2 vs 17.01.5 as the 17.01.5 is smaller then 18.06 rc2 Jul 21 23:18:22 talking about the ramips/rt305x Jul 21 23:18:24 changelog, updated packages Jul 21 23:18:33 probably 4.9 -> 4.14 too Jul 21 23:18:48 wow even on a old dir-615 d2 to Jul 21 23:18:51 lol :P Jul 21 23:20:50 yeah ur right.....18.06.0-rc2 is on k4.14 as i just looked into packages and can see wiregaurd is showing K 4.14.54 Jul 22 01:20:59 Update: Ended up getting a new WRT3200ACM for $150 off eBay Jul 22 01:21:36 What's the easiest way to transfer my settings from my old router to the new one? Jul 22 01:26:40 you will have to configure most of it manually, different hardware means different switch configs, different wlan cards, different gpio/ led configs, different board.json, different... Jul 22 01:28:34 don't use the old configs for anything but a loose guideline Jul 22 01:35:28 gotcha Jul 22 02:06:49 whoa. there's a geth package for openwrt Jul 22 02:07:05 do people really mine on their routers? Jul 22 02:07:51 Well, I mean, a friend of mine uses RPi3s running OWRT as mining controllers.. Jul 22 02:08:05 oh ok Jul 22 02:08:26 And nodes don't imply mining Jul 22 02:31:28 mangix: was tue geth package merged? **** ENDING LOGGING AT Sun Jul 22 03:00:00 2018