**** BEGIN LOGGING AT Tue Dec 04 03:00:15 2018 Dec 04 04:44:19 gch981213[w]: who is your manufacturer? Dec 04 04:57:38 biangbiangmian: I'm using HiWiFi HC5661A and HiWiFi uses this approach for all their routers. (Which also means current OpenWrt firmwares for these routers all have a broken WiFi MAC address.) Dec 04 05:55:34 i think i'm seeing the same thing on mine Dec 04 05:56:03 also a shenzhen based manufacturer, i think they might be partners with zbt's team Dec 04 05:58:01 i need to double check later, but the mac address looks familiar Dec 04 06:51:58 stintel: the lldpd configure libcap tests are protected by a check for -n $libcap_CFLAGS / -n $libcap_LIBS Dec 04 06:52:33 stintel: so a CONFIGURE_VARS += libcap_CFLAGS=$(space) libcap_LIBS=$(space) should suffice Dec 04 07:21:30 biangbiangmian: that's just the MAC address in the default EEPROM file provided by MTK. Dec 04 08:53:26 Is anybody able to help a noob out? I've been trying to add support for my device, but haven't been able to get it to run yet. When tying to load the firmware from TFTP I get: "board_bcm963xx: unknown bcm963xx board: 963168_T132A_9" Dec 04 08:53:34 Am I doing something stupid here? Dec 04 08:54:09 jow:ping Dec 04 08:54:14 dedeckeh: pong Dec 04 08:54:51 jow:I'm a bit confused about SNAT redirect rules Dec 04 08:54:58 osimon: sounds like you do not have board setup code registered for the device tag 963168_T132A_9 Dec 04 08:55:47 I thought the src_dport was not used to match traffic but just to rewrite the source port Dec 04 08:56:35 dedeckeh: do you refer to config redirect or config nat? Dec 04 08:56:45 redirect rules Dec 04 08:57:30 jow: I'm new to this, where would I add that to? Dec 04 08:57:55 dedeckeh: for config redirect with target SNAT, src_dip rewrites the source ip and src_dport the source port Dec 04 08:58:58 jow: it does not - I've tried Dec 04 09:00:16 I notice src_dport is also used to match the dst port traffic Dec 04 09:00:42 jow:https://pastebin.com/ECnwzamU Dec 04 09:01:55 dedeckeh: this looks like a bug Dec 04 09:02:12 trying it again, it was late last night :P Dec 04 09:02:40 nope, it doesn't Dec 04 09:02:41 osimon: in target/linux/brcm63xx/patches-4.9/, check the various XXX-board_*.patch files Dec 04 09:03:16 osimon: you probably need to add another patch to the stack adding an entry for .name = "963168_T132A_9" Dec 04 09:04:42 jow: I was actually tempted to just move libcap from packages feed to base repo and enable the dependency Dec 04 09:04:57 it would actually be nice to have libcap and have some stuff not run as root Dec 04 09:05:08 its a waste of space Dec 04 09:05:16 99% of the userbase will run a root only system Dec 04 09:08:21 jow:I guess print_redirect should not pass dpt to fw3_ipt_rule_sport_dport in case of SNAT as a fix ? Dec 04 09:10:59 dedeckeh: yeah Dec 04 09:11:10 dedeckeh: but I'd consider switching to config nat rules Dec 04 09:11:29 they're more explicit and do not suffer from the src_dip / src_dport confusion Dec 04 09:14:02 jow:ok Dec 04 09:18:07 jow: for a network daemon it still improves security if it doesn't run as root .. Dec 04 09:48:32 jow: Thanks for the help so far. One last question before I call it a night. I've just changed the file in the build_dir directory and got things working. How do I go about turning that into a patch? Dec 04 09:51:17 https://oldwiki.archive.openwrt.org/doc/devel/patches#adding_or_editing_kernel_patches Dec 04 10:01:07 gch981213[w]: You should be able to use mtd-mac-address in the dts to pluck it from wherever they're storing it, if it's a fixed offset. Dec 04 10:01:58 Legend, thanks for all the help jow! Dec 04 10:25:43 jow: https://github.com/joeholden/openwrt/commit/a654093caba5f2bacca744d93f1940fdad15d85b - thoughts? also +ipv6 is redundant now afaics Dec 04 10:26:21 since ipv6 is enabled by default it might make more sense to make it the same as ipv4? Dec 04 10:36:15 jwh: ipv4 is defined as bool, so ipv4=0 should work Dec 04 10:36:46 not sure what you mean with "+ipv6 is redundant" Dec 04 10:38:56 as a pppd option, at least, it isn't in the version currently in use (it seems to be from when ipv6 wasn't enabled by default) Dec 04 10:39:17 like ipcp, in the currrent version ipv6cp is turned on by default Dec 04 10:39:32 and 'ipv6' is used to specify identifiers Dec 04 10:40:00 I need to do some more testing, but parity would be nice there Dec 04 10:50:01 jwh: okay, in this case we should invert it Dec 04 10:50:20 option ipv6 0 -> noip6 Dec 04 10:50:24 yeah Dec 04 10:50:29 thats what I'm thinking Dec 04 10:50:47 then ipv4/ipv6 options can be used to turn either one off Dec 04 10:51:28 I don't have a dsl line to hand atm, however, I'll have to setup a pppoe lab Dec 04 10:56:28 xback: planning some more kernel bumps ? Dec 04 10:56:52 Monkeh: It stores like u-boot-env. The MAC address is a ASCII string and the location isn't guaranteed to be a fixed value. Dec 04 11:00:09 stintel: if you _have_ libcap, can it just autoenable some features? Dec 04 11:01:15 karlp: not sure, we might need to do setcap ourselves Dec 04 11:06:01 gch981213[w]: In that case, mtd_get_mac_ascii in etc/board.d/02_network will probably work for you, grep for examples Dec 04 11:11:38 Monkeh: That do work for setting MAC of ethernet but I need a way to set MAC for wifi. I don't quite like the fix_wifi_mac script found in ar71xx/ath79 because phy id isn't always fixed. However it seems that mt76 driver doesn't have a way to load a patched eeprom data like what ath9k did. Dec 04 11:12:11 if you know where it is, couldn't you set it in the initial configuration using macaddr or whatever? Dec 04 11:13:10 why isn't phyid fixed? Dec 04 11:19:12 I'm trying to get openwrt booted on an Marvell Armada 8k device. Using latest openwrt nightly and compiling for the macchiatobin doesn't work very well. I have a kernel on the device that seems based off of http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+Kernel that will boot Ubuntu just fine, and kind of works with OpenWrt as well (4.4.52). Anyone aware of some patch set for Dec 04 11:19:19 Marvell armada 8k somewhere that plays nice with the 4.14.x kernel used in current openwrt (or even newer kernel)? Dec 04 11:20:44 could you elaborate a bit more on "doesn't work very well" ? Dec 04 11:20:54 the primary difference I can notice immediately is that that 4.4.x kernel uses a different NIC driver mmpv2 or something like that Dec 04 11:21:29 karlp: right, it has 2x10GE interfaces and 4x1GE interfaces and if I boot the kernel that boots ubuntu just fine I get eth0-5, but if I boot the macchiatobin I get eth0-2 and none of them work Dec 04 11:22:23 karlp: this is booting on the same openwrt installation just with two different kernels. Dec 04 11:23:29 hm, it might perhaps help if I pastebin the two different kernel boot results, let me do that Dec 04 11:26:42 support seems fairly recent: https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=commit&s=MACCHIATObin Dec 04 11:26:49 from https://openwrt.org/toh/hwdata/marvell/marvell_macchiatobin Dec 04 11:29:51 you can create a new device page to put the two bootlogs, they can be useful Dec 04 11:30:07 see https://openwrt.org/supported_devices/adding_to_toh and specifically https://openwrt.org/meta/create_new_device_page Dec 04 11:32:04 where the 2*10, 4*1 board at? Dec 04 11:32:05 zorun: right, that might be future step Dec 04 11:32:16 https://pastebin.com/PXcSsuR3 for booting a macchiatobin image Dec 04 11:33:31 SwedeMike: which board is it? the macchiatobins only seem to have a single 1G port Dec 04 11:34:05 https://pastebin.com/VZ9KRhNU for the one where I boot their kernel that they use to boot ubuntu Dec 04 11:34:20 zorun: there is no public information on this board, I got it kind of early :P Dec 04 11:35:00 so their kernel uses mvpp2 driver Dec 04 11:35:40 SwedeMike: I see, it looks interesting :) Dec 04 11:36:01 SwedeMike: giiiiiveeeee Dec 04 11:37:37 zorun: the macchiatobins have similar board layout, 2x10GE and 1x2.5GE so they're not that different Dec 04 11:38:02 4 real ports, or switch? Dec 04 11:38:42 jwh: good question, I don't know. They present themselves as eth0 1x10GE, eth1-2 1xGE eth3 1x10GE and eth4-5 1xGE Dec 04 11:38:58 what a curious order :) Dec 04 11:38:58 so from a linux kernel perspective, they're all "native" Dec 04 11:39:02 karlp: indeed. Dec 04 11:39:05 hmmm, kinda weird layout Dec 04 11:39:07 yeah Dec 04 11:39:24 weird board design or less than sensible dts? Dec 04 11:39:46 SwedeMike: could be DSA if its a switch also Dec 04 11:44:39 does the .dtb file say anything meaningful? It doesn't seem to be really human readable? Dec 04 11:45:35 you can decompile it Dec 04 11:45:52 though easier to look at the original source if you can get that from where you built it from Dec 04 11:46:07 karlp: I have asked them how they built that kernel, still waiting for answer. Dec 04 11:46:48 but yes, let me decompile it and see if I see anything interesting. Found what tools to use Dec 04 11:53:13 http://paste.ubuntu.com/p/Crxc3BPD3b/ is the decompiled dtb file Dec 04 11:53:49 they even called it armada-8040-mcbin.dtb (like the macchiatobin) so it might be just that Dec 04 11:55:31 the file even indicates just eth0-2 so... Dec 04 11:58:25 heh Dec 04 11:58:38 driver probing maybe? Dec 04 12:02:37 oh Dec 04 12:02:44 one of those ports is sfi Dec 04 12:02:54 maybe its some weird breakout Dec 04 12:03:17 check mac0 Dec 04 12:20:11 I tried booting my openwrt kernel with their .dtb file, but that worked even worse. Then it doesn't detect any sata or usb controllers or anything. Dec 04 12:21:04 probably some driver specific code, but I'm not expert.... Dec 04 12:21:24 build #1143 of brcm47xx/mips74k is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm47xx%2Fmips74k/builds/1143 Dec 04 12:29:45 ../../lib/ext2fs/hashmap.h:20:19: error: missing binary operator before token "(" Dec 04 12:29:48 #if __GNUC_PREREQ (4, 8) Dec 04 12:29:49 cute Dec 04 12:30:13 I swear they introduce something that breaks non-glibc every release Dec 04 12:49:15 jwh:ipv6 is enabled by defualt due to https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/ppp/files/ppp.sh;h=2d9ca6d284838a7575c0732b1d4c13435fe71b0b;hb=HEAD#l97 in ppp.sh Dec 04 12:49:36 it's not enabled by defualt in the ppp daemon Dec 04 12:49:50 hm Dec 04 12:50:06 it certainly didn't used to be, but the man page implies it is also Dec 04 14:00:26 guess nobody ever bothered turning it on by default after updating the manpage Dec 04 14:04:53 for want of just a tiny bit of AF parity on linux heh Dec 04 14:15:27 Hi, guys! Does anyone know if there is lua bindings for uclient or any other way to do ubox/uloop based io in lua? Dec 04 14:17:42 https://git.openwrt.org/?p=project/libubox.git;a=blob;f=examples/uloop-example.lua;h=9b0684e648a77300544b15a95e5f151eda082510;hb=HEAD Dec 04 14:21:15 Thanks! ...but may be there is some async httpclient library? :) I mean uclient would match, but I can't find lua bindings, and luci-lib-httpclient has lua bindings but is blocking :( Dec 04 14:27:57 * ldir sticks head in oven https://github.com/openwrt/openwrt/pull/1398 Dec 04 14:50:38 ldir:again the GitGub-webinterface :) Dec 04 14:52:00 Github. Making low quality contributions easy since 2007. Dec 04 14:52:56 To be fair, the first time I sent a contribution to OpenWRT, I spent more time trying to figure out how to make git-send-email work right than I had spent making the code changes in the first place. :P Dec 04 14:54:23 and I was the one arguing that 'there will always be new people and some of them might be our future maintainers' - sigh Dec 04 14:55:24 it would be *really* helpful if the github web i/f had a 'rebase on upstream/master' button. Dec 04 14:57:07 and if it would allow to disable the button to create a PR if some prerequisites aren't met Dec 04 15:15:36 ldir: it does doesn't it? Dec 04 15:15:54 might be a project/repo setting unless I'm thinking of gitlab Dec 04 15:28:30 jwh: I don't think I've seen anything that does the equivalent of git fetch upstream, git rebase upstream/master Dec 04 15:29:25 you have a choice of 'merge, squash & merge, rebase & merge' when merging a PR. Dec 04 15:30:30 but that doesn't help the person trying to use a purely web workflow to pull in upstream changes and put theirs on top again. Dec 04 15:33:40 ah Dec 04 15:33:46 yeah Dec 04 15:34:13 I'm happy to be corrected Dec 04 15:36:22 no I think you're right Dec 04 15:50:37 so it's always struck me a stupid/daft/oversight that after forking a repo there's no (obvious) way to keep that repo up-to-date with the fork master. Dec 04 15:51:11 within the web gui that is Dec 04 15:51:21 yeah Dec 04 15:51:43 rebase & merge is probably close enough for most Dec 04 15:57:13 toolchain/gdb seems broken on aarch64 Dec 04 15:58:43 SwedeMike: Your best bet for working kernel would be repos from Marvell itself, check https://github.com/MarvellEmbeddedProcessors Dec 04 16:00:32 tmn505: right, that's where http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+Kernel says to build from. I'm just saddened that I would need to go to a fork to get something working. Dec 04 16:01:39 SwedeMike: happens every single time Dec 04 17:57:47 build #285 of oxnas/ox820 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/oxnas%2Fox820/builds/285 Dec 04 18:40:42 build #326 of ipq40xx/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/326 Dec 04 18:54:41 damn... I was planning to do a PR / merge round tonight but after five wine punches at the cristmas market I'll better refrain from touching anything git related Dec 04 18:55:30 jow: :D Dec 04 18:58:54 SwedeMike: the macchiatobin should be supported by openwrt master Dec 04 18:58:57 are there ayn problems? Dec 04 18:59:03 I do ot have the device Dec 04 18:59:08 *do not Dec 04 18:59:19 Hauke: well, I do't have an macchiatobin, I have something similar (also Marvell Armada 8k based) Dec 04 18:59:36 SwedeMike: what are you going to use it for? Dec 04 18:59:53 jwh: 10GE home gateway POC Dec 04 18:59:56 ahhh Dec 04 19:00:23 I'm looking at similar use cases for the clear fog boards Dec 04 19:00:40 1G though mostly Dec 04 19:00:46 jwh: I've got macchiatobin on order as well, it just takes a while to get it Dec 04 19:02:43 why do you want to use the "offical" SDK and not openwrt master? Dec 04 19:02:56 the support was added from the same people working on the fork Dec 04 19:03:07 at last the dts was added Dec 04 19:03:18 Hauke: I tried to use openwrt master, that was the entire idea. Dec 04 19:05:15 Hauke: if I use their .dts file with openwrt kernel built for macchiatobin then sata/usb/mmc doesn't work. Their .dts file works fine with their kernel, and it also works with the 4.4.x kernel I got directly from that macchiatobin downloads part. So there is something weird going on and that forked kernel does more than the nightly 4.14.x kernel Dec 04 19:38:50 SwedeMike: openwrt should also provide a dts file Dec 04 19:39:02 probably the interface changed between the kernel 4.4 and 4.14 Dec 04 19:43:23 Hauke: yes, and the dts file for macchiatobin doesn't yield a working solution, none of the NICs work when I use that. Dec 04 19:43:44 neither does the generic 8040 target Dec 04 19:44:27 don't drink & code... Dec 04 19:44:30 don't drink & merge ;) Dec 04 19:50:18 build #230 of at91/sama5d2 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/230 Dec 04 20:02:13 build #107 of samsung/s5pv210 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/samsung%2Fs5pv210/builds/107 Dec 04 20:12:35 hm, in the mean time I now have a .dts file from the armada 8040 vendor, I'll try it tomorrow and see if I can "compile" it or whatever I need to do Dec 04 21:11:35 KanjiMonster: https://git.lede-project.org/78ca6a5578d6c7b06ca520b0aac965a1babf5417 does not blow up the imagebuilder. The kernels are included as binaries in the ib archive and are not rebuild. It is only the rootfs and the final image which is rebuild. Dec 04 21:36:02 interesting. kmod-video-brcm2835 causes a panic with CONFIG_KERNEL_CC_STACKPROTECTOR_STRONG=y Dec 04 21:38:09 guess I'll try to reproduce this with their kernel instead of our kernel with patches from brcm2708 and report on their github Dec 04 21:38:32 although .. they might not support 4.9 anymore. hmmm. I'll retest first with 4.14 Dec 04 21:42:08 is it preferred to use AutoProbe instead of AutoLoad nowaday? Dec 04 22:04:13 build #778 of ramips/mt76x8 is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Fmt76x8/builds/778 blamelist: Felix Fietkau , Mathias Kresin Dec 04 23:48:34 what do these collectd-chrony ldd errors mean - https://paste.ubuntu.com/p/JBFVxsgMRK/ Dec 05 01:24:53 do we support @{ge,gt,le,lt} in KCONFIG for kmod packages? if not, is this acceptable: CONFIG_VIDEO_BCM2835$(if $(CONFIG_LINUX_4_9),=y) Dec 05 01:28:25 if that's sorted out, brcm2708 will *finally* get 4.14 support **** ENDING LOGGING AT Wed Dec 05 03:00:01 2018