**** BEGIN LOGGING AT Thu Feb 21 02:59:57 2019 Feb 21 05:09:44 anyone around? Feb 21 05:10:25 there's never anyone around Feb 21 05:10:34 i know Feb 21 05:10:39 nope, not a soule. Feb 21 05:11:05 (fyi, if you have a qeustion on irc, ask it, I could have already been replying, instead of goading you) Feb 21 05:11:07 do you know much about DNS/DHCP settings in openwrt? Feb 21 05:11:11 "yes" Feb 21 05:11:21 impatient, you didn't bother to describe network configuration, this is not a technical support channel Feb 21 05:11:23 try asking clear questions that might be possible to _answer_ Feb 21 05:11:24 etc Feb 21 05:11:24 :D Feb 21 05:11:56 i'm trying to push a DNS server through dhcp, i found that option 6 does this for ipv4 Feb 21 05:12:10 i.e., list dhcp_option '6,192.168.1.50' Feb 21 05:13:08 however, windows 10 prefers ipv6 for dns, so even though 192.168.1.50 is listed in DNS so is fd85:cdf8:f8ac::1 Feb 21 05:13:26 thus, all queries are going to openwrt from all windows 10 hosts Feb 21 05:13:52 dhcp_option 6 does not appear to work with ipv6 addresses and i'm not sure how to change this behavior Feb 21 05:14:36 is any reason why you care about whether you serve dns on v4 or v6? Feb 21 05:14:37 I've tried specifying the correct ipv6 address in "Announced DNS servers" under the interfaces IPV6 Settings, but this seems to have not effect as well Feb 21 05:14:58 no, i just want all queries to go to my dns server, not openwrt Feb 21 05:15:15 so don't send dns in ra Feb 21 05:15:26 or whatever it's picking it up from Feb 21 05:15:26 ? Feb 21 05:15:44 are you serving v6 addresses via .... ? Feb 21 05:15:51 that's the thing, i'm not sure how fd85:cdf8:f8ac::1 is being specified Feb 21 05:16:01 that's the ipv6 address of openwrt Feb 21 05:16:11 xy problem, what a surprise :) Feb 21 05:16:15 karlp: :D Feb 21 05:16:22 openwrt serves v6 addresses by default Feb 21 05:17:16 https://openwrt.org/docs/guide-user/network/ipv6/start Feb 21 05:18:19 ok? Feb 21 05:19:05 combine that with a couple of google searches for how dns servers are distributed in ipv6 Feb 21 05:20:04 what am i looking for? Feb 21 05:20:26 no idea, still haven't described network configuration Feb 21 05:20:35 or even posted configs Feb 21 05:20:40 what do you need to know? Feb 21 05:20:56 i'm not doing anything special, this is pretty much a base openwrt Feb 21 05:21:37 dunno how configurable odhcpd is, may need to not use it Feb 21 05:21:41 i'm just looking to push the DNS servers i want to use through DHCP... i can do this for IPV4 using dhcp_option 6 Feb 21 05:22:11 but, for some reason dhcp is also pushing an ipv6 address, which windows 10 preferes Feb 21 05:22:27 it isn't Feb 21 05:22:39 and, i cannot figure out how to prevent dhcp from doing this Feb 21 05:22:57 probably from ra, turn it off by... reading the url Feb 21 05:22:57 so, why then does ipconfig show Feb 21 05:23:08 DNS Servers . . . . . . . . . . . : fd85:cdf8:f8ac::1 Feb 21 05:23:30 anyway, this isn't a support channel, Feb 21 05:24:03 does that mean you aren't going to help me? Feb 21 05:24:38 dunno Feb 21 05:24:57 thanks Feb 21 05:25:01 are you using hdcp for v6?you need to work that out for stareters Feb 21 05:25:26 it is kinda sucky to ask a question in the main channel, in the middle of the night, then ask in the dev channel because you didn't get a response Feb 21 05:25:46 Don't mind grumpy. Feb 21 05:25:57 not middle of the night for me, and i didn't force you to answer Feb 21 05:26:00 sorry Feb 21 05:26:24 just trying to work out a problem i have been unable to resolve through my own research Feb 21 05:28:00 for most of the western hemisphere its night, so Feb 21 05:28:33 so for most of eastern it's not? what's the point? Feb 21 05:30:44 nm Feb 21 05:36:14 malwar3hun73r: i think the point is that much of the US (and canada, etc.) is just recently in or getting to bed, and europe hasn't yet really gotten up. you're right in between when helpful people will be around and interested in pointing to information Feb 21 05:36:32 pretty much Feb 21 05:36:52 ok, i'll try again at a different time Feb 21 13:38:34 dedeckeh: ping Feb 21 13:40:34 ldir:pong Feb 21 13:40:34 dedeckeh: am I correct in thinking what you're trying to get Tony to do is squash his fix commit into the prior commit so we don't have a 'break' commit followed by a 'fix' commit. Feb 21 13:40:35 yes Feb 21 13:41:22 I'll clarify that in the PR :-) Feb 21 13:41:41 thx Feb 21 23:01:28 Is there a way to specify board-specific overrides to the target's config-4.14 (kernel CONFIG_*)? Feb 21 23:09:15 ./target///config-default ?? Feb 21 23:15:01 no, the kernel image is only built once for all devices of a given (sub-)target Feb 21 23:16:12 it needs to contain whatever is needed to support all devices of this (sub-)target, assuming a module --> DEVICE_PACKAGES can't do, with the DTB only appended to the common kernel image Feb 21 23:18:15 UGH, OK -- I'll have to look for other ways to override the bootloader's bootargs; CONFIG_MANGLE_BOOTARGS will almost certainly "kill" other boards Feb 21 23:19:44 it shouldn't, it's more or less opt-in and was already enabled while ipq40xx devices were part of the ipq806x subtarget (the nbg6817 needs it) Feb 21 23:21:03 or rather, it uses CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y from target/linux/ipq806x/patches-4.14/0067-generic-Mangle-bootloader-s-kernel-arguments.patch Feb 21 23:21:24 There's a "mangle" patch for the ipq806x, but not in the ipq40xx (except in my repo) Feb 21 23:22:37 sure, but originally the ipq40xx devices were supported as part of the ipq806x target (the only reason for changing that and moving them to their own target was because of USB incompatibilities) - and CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y was common to all devices back then Feb 21 23:23:18 It deals with extracting the MTD partition number from `root=`, but its more than I need/prefer to *remove* the bootloader's `root=` Feb 21 23:23:33 I'll try it again Feb 21 23:23:57 devices hardcoding bootargs (or taking it from the bootloader verbatim) aren't affected by CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE, only those explicitly specifying append-rootblock Feb 21 23:24:15 in their DTS Feb 21 23:24:22 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=b583aaf5aa57173100b6569ffc60c34405b7dc38 Feb 21 23:26:14 Yes. Agree on the impact. I need to retain `ubi.mtd=11,2048` and either replace `root=ubi0:ubifs` with `oot=/dev/ubiblock0_0` Feb 21 23:26:37 it was originally introduced to ipq806x because of the ea8500 in https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=0ddcbee2615197c8905408422b4a8a9fe7dbe954 no ipq806x devices other than ea8500 and nbg6817 make use of the feature (although it is enabled in the common ipq806x kernel image) Feb 21 23:27:07 or rename the UBI volume name to match `ubifs` instead of the OpenWrt "standard" `rootfs` Feb 21 23:27:35 The ea8500 passes a different set of bootargs, for which that patch works well Feb 21 23:27:53 what are the two alternative cmdline contents? Feb 21 23:28:18 one sec Feb 21 23:29:34 ea6300 (device un process): init=/sbin/init rootfstype=ubifs ubi.mtd=11,2048 root=ubi0:ubifs rootwait rw clk_ignore_unused Feb 21 23:29:44 looking up the ea8500 Feb 21 23:30:59 Feb 21 23:31:15 OEM: EA8500 command line override: console=ttyHSL1,115200n8 init=/sbin/init rootfstype=squashfs ubi.mtd=16,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait ro msm_reserve_memory: 0x44600000, 0x200000 Feb 21 23:31:40 [ 0.000000] Kernel command line: console=ttyMSM0,115200n8 ubi.mtd=14 Feb 21 23:31:46 that doesn't look too bad Feb 21 23:32:18 I'll give it a shot Feb 21 23:32:37 Imay have missed something in my previous attempts Feb 21 23:33:58 so you basically just want bootargs = "console=ttyMSM0,115200n8" and append-rootblock = "ubi.mtd="; with CONFIG_ARM_ATAG_DTB_COMPAT=y && CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y Feb 21 23:34:12 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=0ddcbee2615197c8905408422b4a8a9fe7dbe954 pretty much the same Feb 21 23:35:13 ah, o.k., I've taken the values from the ea8500, so no wonder it's matching my expectations ;) but I do expect something very similar to work for the ea8300 Feb 21 23:44:40 I hope so! While I don't mind cracking a router to install with U-Boot, it isn't the friendliest for most Feb 21 23:45:07 doesn't it have some kind of push-button tftp recovery method? Feb 21 23:45:17 Not that I've figured out Feb 21 23:46:00 I can get the image through the web interface, but it won't boot because of the bootargs Feb 21 23:46:35 Catch-22 in that you can change the U-Boot env once you have OpenWrt running, but you need the env changes to boot OpenWrt Feb 21 23:46:55 yeah, I still haven't found out how to trigger the toggle-bootflag-on-failure mode on my nbg6817... (push-button tftp recovery works though, so it can always recover, and I can toggle the bootflag at runtime - I just haven't found a method to stipulate that in the failure case) Feb 21 23:49:01 the dual-boot feature being functional doesn't need to be part of the original device support patch though, if you can't get it working easily Feb 21 23:50:44 ah, well - considering that you don't know in advance from which partition (OEM firmware) the user has flashed OpenWrt, it probably would better work (as you don't know to which partition set the OpenWrt image has been written to) Feb 21 23:50:58 Exactly Feb 21 23:51:50 It is pretty amsuing to watch the OpenWrt 4.14 kernel trying to run with the OEM's root file system Feb 21 23:52:00 that situation was a little different for the nbg6817, as the original submitter didn't get factory images working in the first submission (and I only retrofitted dual-boot support, witch real factory images coming much later) Feb 21 23:53:32 The trailer from the ea8650v3 (?) work is the same "security" as for the ea8300, so at least I don't have to dig into the validation code in the OEM firmware Feb 21 23:54:05 ea6350v3 Feb 21 23:54:31 nice Feb 21 23:55:04 how incomplete were the original PR attempts? Feb 21 23:55:22 Ummm, I'll be polite Feb 21 23:55:47 It looked like a reasonable copy of the DTS to the OpenWrt tree Feb 21 23:56:02 ...of the OEM's DTS... Feb 21 23:56:18 and leave it at that Feb 21 23:56:33 probably for the best Feb 21 23:57:34 The work I've been doing is consistent with the other ipq40xx devices, including the use of "upstream" devices, rather than the "ad-hoc" MSM bus Feb 22 00:00:56 I really hoped the original PR would have been a little further along Feb 22 00:04:34 You and I both, but at least I'm still having fun with it Feb 22 00:04:45 Hopefully the QCA9888 issues can be resolved Feb 22 00:05:03 That mangle patch, unfortunately, doesn't help Feb 22 00:05:15 "and a root= option in bootloaders command line it will be parsed" (for the MTD partion number) Feb 22 00:05:48 which, for the ea8300, is `root=ubi0:ubifs` Feb 22 00:06:02 there are slightly different versions of the cmdline mangle patches in various targets Feb 22 00:06:10 OK, I'll dig around Feb 22 00:06:25 mvebu has one Feb 22 00:06:49 oxnas Feb 22 00:06:50 Yeah, I saw Feb 22 00:06:55 armada-385-linksys-venom.dts append-rootblock = "root=/dev/mtdblock" Feb 22 00:06:55 qcom-ipq8065-nbg6817.dts append-rootblock = "root=/dev/mmcblk0p"; Feb 22 00:06:55 qcom-ipq8064-ea8500.dts append-rootblock = "ubi.mtd=" Feb 22 00:07:13 (at least as far as *uses* went) Feb 22 00:09:25 Might just look into renaming the UBI volume to match the command line Feb 22 00:09:47 It's not much more ugly than other approaches Feb 22 00:11:24 The UBI subsystem works as expected, just the ref-by-name is the wrong name Feb 22 00:17:07 Unfortunately, `set bootargs ubi.mtd=11 root=ubi0:rootfs` doesn't work -- needs `root=/dev/ubiblock0_0` Feb 22 00:18:22 is that root=/dev/ubiblock0_0 vs root=/dev/ubiblock0_1 or root=/dev/ubiblock1_0? Feb 22 00:18:49 Works from U-Boot: set bootargs ubi.mtd=11 root=/dev/ubiblock0_0 Feb 22 00:19:02 Fails from U-Boot: set bootargs ubi.mtd=11 root=ubi0:rootfs Feb 22 00:19:35 well, what you need in order to boot the alternative partition set? Feb 22 00:20:26 Change to `ubi.mtd=13` (which boot loader does) and load/boot kernel from mtd12 Feb 22 00:21:08 That's been checked and worked, if I flash to 12 instead of 10 Feb 22 00:21:25 hmmm Feb 22 00:22:12 Yeah, https://stackoverflow.com/questions/48801998/passing-bootargs-via-chosen-node-in-device-tree-not-working-for-beaglebone-blac Feb 22 00:22:36 Which, as I understand it says "The bootloader wins" -- hence all these mangle patches Feb 22 00:23:28 normally DTS wins, but you don't want it to win - as you need to find out which partition set to boot from via the bootloader Feb 22 00:24:34 Basically, yes, I need the `ubi.mtd=` argument, and toss the rest Feb 22 00:25:18 There's no partition info in the `root=` argument, and it's "wrong" for at least how the kernel I've git is running Feb 22 00:25:33 ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4018-rt-ac58u.dts might be an example (don't know enough about it to judge) Feb 22 00:25:38 bootargs-append = " ubi.mtd=UBI_DEV"; Feb 22 00:26:27 Hmmm Feb 22 00:30:45 blindly building that now Feb 22 00:35:14 Bah, it's a DTS reference to partition@0 in that DTS Feb 22 02:08:36 Is there a kernel CONFIG that is needed for an ARM (ipq40xx) kernel to recognize `root=ubi0:rootfs` (by volume name) rather than just `root=/dev/ubiblock0_0` ? Feb 22 02:13:04 that would usually be the task for udev (from within the initramfs)... neither of which you have Feb 22 02:13:50 Thanks Feb 22 02:15:25 No clues in the GPL .config either Feb 22 02:15:40 (OEM GPL drop) Feb 22 02:16:25 I once swore that I'd never try top keep BSD and Linux kernel internal in my head Feb 22 02:16:41 Seems like between phones and this, I've long crossed that line **** ENDING LOGGING AT Fri Feb 22 02:59:56 2019