**** BEGIN LOGGING AT Mon Jul 02 03:00:00 2018 Jul 02 03:05:06 jwh: found a few lines in firewall openwrt page, not much else, anyway it seems a better UI comparing to iptables, and it is said to be uci-friendly, haven't found examples on that yet Jul 02 03:07:11 thats because iptables just inserts or removes rules Jul 02 03:07:15 fw3 is a management tool Jul 02 03:07:42 there is.. shockingly Jul 02 03:07:45 a firewall config Jul 02 03:07:49 wow right Jul 02 04:01:12 karlp: ping Jul 02 04:59:21 ausjke: fw3 is the 3rd generation firewall on openwrt, it uses native uci configuration for settings Jul 02 04:59:30 ausjke: the advantages compared to plain iptables are: Jul 02 04:59:50 - it integrates with network runtime state and can dynamically map logical network to actual netdevs or subnets Jul 02 05:00:17 - it supports seamless reloads (netdev/ipaddr specific rule rebuilding) Jul 02 05:00:45 - it implements slightly more complex scenarios like nat loopback Jul 02 05:01:15 some people believe that the same can be done with iptables-save/restore and that having a uci macro processor on top is overkill Jul 02 05:01:24 depending on the use-case that might very well be Jul 02 05:13:21 ... Jul 02 05:13:33 jow: https://patchwork.ozlabs.org/patch/932994/ Jul 02 05:13:48 looks legit Jul 02 05:14:16 its the question how to handle these Jul 02 05:14:22 we know the buffer wont exceed 13 Jul 02 05:14:32 but in theory if int_max'ing out would be 17 Jul 02 05:14:53 so either waste 4 bytes or tell gcc when we want to cap/max the output Jul 02 05:18:24 blogic: I prefer the snprintf solution Jul 02 05:18:40 morning btw Jul 02 05:18:45 jow: morning Jul 02 05:18:57 hope your weekend was as good as mine Jul 02 05:19:04 i forgot the internet exists Jul 02 05:19:09 :-D Jul 02 05:19:55 it was okay :) Jul 02 07:02:12 Morning people Jul 02 07:09:25 aloha Jul 02 07:09:46 i am d-touring around wifi wall switches for lighting Jul 02 07:15:39 Hi I was thinking about getting some of thos wifi wall switches pleas let me no how you go with them. Jul 02 07:34:13 blogic: do we still implement that 30s reset default thing? Jul 02 08:05:28 As a general rule is it preferable to backport an upstream kernal driver...with the caveat that it works/doesn't break working installs than maintain our own out of tree package? Jul 02 08:08:57 ldir: tracking upstream should be the prime objective Jul 02 08:09:32 context - there's an upstream apu led driver for apu/2 https://github.com/torvalds/linux/commit/3faee9423ce07186fc9dcec2981d4eb8af8872bb#diff-2db6fa07be0cdad96109af32df98e885 Jul 02 08:11:16 which will have exactly the same problem that muhaha has been on about with dodgy DMI values from the bios :-) Jul 02 08:11:54 but that would be upstream's problem too :-) Jul 02 08:38:57 * ldir runs away from anything apu related. Jul 02 08:39:51 save yourself Jul 02 08:44:36 jow: i believe we do Jul 02 08:44:37 I'm sure the kit is fine, but since I don't have one it probably isn't wise trying to help produce patches for it/them. Jul 02 09:08:05 Hey. Does anyone know, if Ralink RT5350 supports hardware GPIO interrupts with falling/rising edge detection on OpenWRT? Jul 02 09:18:43 airwind: let me check Jul 02 09:19:42 airwind: yes Jul 02 09:19:44 should work Jul 02 09:19:57 the gpio driver has the required callbacks Jul 02 09:29:04 ty, I was reading the datasheet and it was rather cryptic Jul 02 09:30:01 airwind: i think it does Jul 02 09:30:05 but try it our to be sure Jul 02 09:30:28 I'll see, if I need to modify the DTS to enable it Jul 02 09:47:26 lxc fails to build in the 18.06 branch. known issue? Jul 02 09:49:26 mangix: yes? Jul 02 09:51:21 mangix: I always read the scrollback, you can just just ask quesitons when I'm not here too... Jul 02 10:01:26 ldir: yuck. I guess this is common on x86though because they want to include all the modules? Jul 02 10:01:51 the _leds_ one I can at leas tsort of see the reasoning for, it's pins that can't be known Jul 02 10:02:09 but the nuvoton gpio chip one, that just probes for the device, and exposes it's pins. Jul 02 10:17:08 well I think my lesson from all of this is 'don't try to be helpful on hardware you don't own' Jul 02 10:18:17 is that dmidecode validation stuff common on x86 drivers? Jul 02 10:18:20 it seems pretty fragile. Jul 02 10:18:24 but after 5 days of work and a couple of very late nights/early mornings I'm tired and exceptionally grumpy. Jul 02 10:18:58 * karlp passes ldir a bikkie Jul 02 10:19:44 I have no idea. I just tried to help out muhaha and as is typical bit off more than I can chew :-) Jul 02 10:20:22 * ldir adds a cup to of tea to karlp's bikkie and tries to chill. Jul 02 10:22:18 karlp: yes, various x86 drivers do horrible dmidecode things Jul 02 10:28:16 build failure in the lxc package in the 18.06 branch: https://pastebin.com/Vwygdjfa Jul 02 11:28:43 karlp: can you post /proc/interrupts output of your mt7621 device? Jul 02 11:51:57 yeah, tonight. will try and remember. Jul 02 12:43:06 Why doesn't OpenWRT/LEDE use an actual git repo for managing Linux kernel patches and just suck them out of there (into the target/linux directory) instead of chopping up patch files? Jul 02 12:43:29 It would be nice to get some of these patches into an upstream-able condition and out of the OpenWRT tree. Jul 02 12:43:39 In fact, ideal Jul 02 12:43:48 that already happens Jul 02 12:43:59 Well that's good to know Jul 02 12:44:23 they get removed if/when they are upstreamed Jul 02 12:44:23 I'm not sure if ramips is just not popular, but the patches are in bad shape Jul 02 12:44:44 But what about managing them in git instead of the manual patch file process? Jul 02 12:45:28 the past opinion was that putting patches into a forked kernel git repo will not actually encourage upstreaming Jul 02 12:45:47 jow: it's not about encouraging upstreaming, it's about quality Jul 02 12:45:59 I don't see how putting patches into a git repo increases quality Jul 02 12:46:02 Let me give you an example Jul 02 12:46:08 jow: you don't?! Jul 02 12:46:12 no Jul 02 12:46:14 wow Jul 02 12:46:21 i don't either Jul 02 12:46:25 upstreaming means less patches to maintain, just iteratung through a list of patches is much easier Jul 02 12:46:30 a patch is a patch Jul 02 12:46:35 than picking commits etc out of a repo Jul 02 12:46:39 Does anybody here know how healthy source control works? Jul 02 12:47:00 they are in git already Jul 02 12:47:01 DonkeyHotei: some patches are ugly, some of them are good. I disagree Jul 02 12:47:11 as patch files, that's not the same Jul 02 12:47:14 no, we don't know how healthy source control work Jul 02 12:47:15 How do you rebase them later? Jul 02 12:47:21 we've been waiting 15 years for you to come and explain Jul 02 12:47:22 what would you propose? Jul 02 12:47:25 Sorry, I do'nt mean to be disrespectful Jul 02 12:47:34 putting them in git does not make them less ugly Jul 02 12:47:47 patch files are low overhead and complexity, why make it more effort Jul 02 12:48:06 I would propose a proper linux kernel git tree fork with branches for each arch. This will simplify backporting patches from Linux upstream as well as rebasing to later kernels Jul 02 12:49:11 This also more closely complies with industry standards, so new developers will be familiar with the paradigms and it will lower the barriers to entry for developers new to openwrt Jul 02 12:49:12 branches for each arch would make it harder to test patches for side effects on unrelated paltforms Jul 02 12:49:18 that would even complicate upstreaming Jul 02 12:49:41 jow: hmm Jul 02 12:50:02 also many patches target two or more platforms Jul 02 12:50:14 wouldn't fit the arch-per-branch model very well Jul 02 12:50:28 or you would have even more effot in syncing patches accross branches Jul 02 12:50:35 jow: I would have to study it more closely, but a single branch might be sensible as well. It would also force better code since you can't just lazily add something for one arch without the proper checks and #ifdefs, etc. Jul 02 12:50:36 or even have different versions of patches Jul 02 12:51:06 arch per branch is one of the things wrong with dd-wrt Jul 02 12:51:24 jow: yeah, that would be bad. So at the most some common base branch(es) and arch-specific. But a single might be the most sensible route Jul 02 12:52:01 imho the most sensible route would be to minimize the amount of patches Jul 02 12:52:02 DonkeyHotei: yeah, I guess I was thinking from the standpoint of how it already is. I don't think most of the patches will play nicely with eachotehr as-is Jul 02 12:52:10 jow: I would agree Jul 02 12:52:23 I would hate having to manage yet another kernel repo fork Jul 02 12:54:27 I have a personal need for this for a project I'm doing. I'll see if I can talk my boss into allocating some time for it. I would love to work out an improvement proposal. It would be nice to have a single repo with all of the patches. Of course, vigorous enforcement of standards like "you must describe what your patch does", etc. would be necessary Jul 02 12:55:06 the current method seems to work and its easy to add local changes Jul 02 12:55:10 I don't see how putting patch series in a git repo would *improve* things Jul 02 12:55:27 having to deal with yet another repo and rebasing all the time would make it even mpre effort Jul 02 12:55:31 dansan: perhaps try and elaborate on what you _can't_ do at the moment. Jul 02 12:55:34 it does not matter if I add an unannotated patch or do a `git commit -sam "Fix foo"` Jul 02 12:55:42 and a bigger margin for error Jul 02 12:55:59 kernel fork per arch - christ no. Jul 02 12:56:18 * karlp gives ldir another bikkie, "don't worry laddie, it's not going to happen" Jul 02 12:57:12 Here's an example of a manually edited patch gone wrong: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/patches-4.14/0046-mmc-MIPS-ralink-add-sdhci-for-mt7620a-SoC.patch;h=353b6836af48cc2311c52f8a01fe3eccf29d0c90;hb=HEAD Jul 02 12:57:35 how would git help people making a mistake? Jul 02 12:58:14 karlp: What I can't do without an hour of hell? rebase the patches onto another upstream kernel release Jul 02 12:58:34 karlp: Have you ever tried to import them into a git repo? Try to git am them, or even git apply Jul 02 12:58:41 why would I? Jul 02 12:58:52 if you are using other kernels then you are on your own anyway i expect Jul 02 12:58:56 heh Jul 02 12:59:08 karlp: good point. Maybe we should just abandon source control all together and go back to clay tablets! Jul 02 12:59:18 jwh: I'm always on my own Jul 02 12:59:19 no, that's not your question.l Jul 02 12:59:22 lol! Jul 02 12:59:22 dansan: it's in git now. Jul 02 12:59:33 kernel patches on openwrt are usually managed using quilt Jul 02 12:59:34 there's tools for applying them in series, updating them, and refreshing them. Jul 02 12:59:35 karlp: but it's a bastardization Jul 02 12:59:48 not using git Jul 02 12:59:56 jow: oh yeah -- well I can't criticize as I haven't used quilt with this yet, sorry Jul 02 13:00:00 no, it makes a _very_ clear separation of things that are patches and should eventually be removed Jul 02 13:00:12 if you're not using quilt and the wya it was designed to be used, then go do that first. Jul 02 13:00:36 karlp: :( I hope it isn't ugly too Jul 02 13:00:54 dansan: https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem Jul 02 13:01:08 I just don't get why anybody would want to use a patch manager instead of a system like git, but I'll try to keep an open mind Jul 02 13:01:14 what Jul 02 13:01:20 * ldir points at https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/ as well Jul 02 13:01:24 git is just revisopn control Jul 02 13:01:33 to have a *perfectly clear* distinction between local changes and usptream sources Jul 02 13:01:34 karlp, jow: perhaps one of the strongest reasons for not using quilt is that upstream is in git Jul 02 13:01:35 it knows nothing about the contents Jul 02 13:01:41 openwrt does not intend to manage an own kernel tree Jul 02 13:01:58 jow: it should! Jul 02 13:02:01 no, it should not. Jul 02 13:02:06 that's the.... well, the kernel! Jul 02 13:02:31 we take vanilla kernels and try and apply as few patches to them as possible. Jul 02 13:03:40 yeah, but the fact exists that all functionality for the target hardware does not exist upstream, so there's no avoiding them. Also, new hardware will emerge and OpenWRT may be the first place that patches for the new hardware is introduced. Thus, it is the perfect target for a linux fork. Jul 02 13:04:26 sounds like a task for kernel.org, not openwrt Jul 02 13:04:28 you guys will likely be among the first to write drivers for a lot of new hardware Jul 02 13:04:38 lol, until somebody needs it for openwrt! :) Jul 02 13:04:48 DonkeyHotei ^^ Jul 02 13:05:16 Yeah, moan about something not being in the kernel and you're suddenly the one that should add it! :) Jul 02 13:05:19 each has a role to play Jul 02 13:05:31 yeah Jul 02 13:06:11 anway, now that you know about how patches _are_ managed, I suggest going and giving a try and seeing if you really still have anything concrete that must change. Jul 02 13:06:29 Anyway, I should at least open a bug report for this one Jul 02 13:07:16 karlp: Yes, I'll reluctantly read through the docs and try it out.... But as of now I'm still of the opinion that using git would be superior. I'll let you know what I think after going through it all. Jul 02 13:10:29 and now you've also seen whatmost of the community feels about that idea :) Jul 02 13:11:09 if you cause a change i will hunt you down Jul 02 13:11:12 :) Jul 02 13:11:30 closed notabug Jul 02 13:11:53 stintel: the bug is going to be about a ramips patch doign the wrong thing I presume Jul 02 13:12:06 ah :) Jul 02 13:12:58 karlp: breaks the build. In fact, it breaks menuconfig Jul 02 13:13:05 on the kernel Jul 02 13:13:08 what would be even nicer is a patch correcting the wrong thing. Jul 02 13:13:15 really? Jul 02 13:13:21 yes Jul 02 13:13:23 dansan: so, file a bug on that. Jul 02 13:13:27 where abouts, not noticed Jul 02 13:13:39 how would git have prevented that semantic error? Jul 02 13:13:41 ldir: well, that's where we entered this conversation. Jul 02 13:13:47 and make sure it's on the openwrt tree, not when you're using your own external kernel where you tried applying all the patches one by one. Jul 02 13:14:18 jow: because somebody apparently chopped up the patch file manually, as evidenced by the fact that the git diff --stat is still in the comments, but the files are no longer added Jul 02 13:14:29 heh, thats whay im doing as soon as the vendor posts theirs, karlp Jul 02 13:14:32 :D Jul 02 13:14:38 what Jul 02 13:16:29 dansan: you've missed target/linux/ramips/files-4.14/drivers/mmc/host/mtk-mmc/ Jul 02 13:16:45 karlp: But it *should*! That's the point. If I apply them to the same upstream revision it should be identical. This is a software development axiom that should never be violated. Too much custom framework isolates the software project. If I can't apply them to the same upstream kernel outside of the openwrt build process then something is inherently flawed Jul 02 13:17:06 oh damn Jul 02 13:17:33 the patches of course are in git, so a history of the patch file, line by line if need be is available. Jul 02 13:17:33 in /etc/config/dhcp there is a dhcp and an odhcpd, 'ps' show i have 'odhcpd' running in parallel with dnsmasq, how are they related? Jul 02 13:17:56 dansan, if you took the same upstream and applied them the same and got a different result, that's because you didn't apply them properly, Jul 02 13:17:59 jow: WHY!? Jul 02 13:18:06 jow: why would .... Jul 02 13:18:08 ausjke: typically odhcpd is ipv6 & dnsmasq is ipv4 Jul 02 13:18:22 i enabled ipv6 in dnsmasq, and saw 'option dhcpv6' for dnsmasq, what about this 'config odhcpd' portion, should I disable/remove it Jul 02 13:18:26 Why would there be some changes that are patches and others that are files? Jul 02 13:18:32 ausjke: odhcpd manages ipv6 prefix delegation and allocation as well as DHCPv6 and RA Jul 02 13:18:54 Somebody please tell me Jul 02 13:19:01 dansan: normally when they dont exist upstream, so it's easier to work on :) Jul 02 13:19:13 ..... Jul 02 13:19:14 jow: you mean even i enabled ipv6 within dnsmasq, i can and should still run odhcpd? Jul 02 13:19:18 * dansan speechless Jul 02 13:19:24 dansan: we usually avoid adding patches that add whole files. Drivers and Kbuild files are added in source, the only patching done is to wire them into kbuild Jul 02 13:19:35 karlp: well, I guess easier if you aren't using git... :( Jul 02 13:20:04 ausjke: if dnsmasq fulfills all your requirements then you can remove odhcpd Jul 02 13:21:25 jow, karlp: I suppose this goes back to my point, that you guys are breaking from *industry standards* This isn't how we do software in any other arena. you have two dissimilar paradigms to make it easier to do things the way that nobody else does it. This makes local knowledge valuable while devaluing global knowledge. This can only isolate openwrt and deter new developers. Jul 02 13:21:48 if two run in parallel, will they "fight", otherwise one should be disabled to avoid two run in the same time? i ask because one of my ubuntu 1804 PC suddenly failed to get IP from dhcp server on the router yesterday, all other machines are fine Jul 02 13:21:49 dansan: worked so far for us Jul 02 13:22:13 trying to check dhcp logs then realized i have two dhcp running, anyway killing one for debugging purpose Jul 02 13:22:36 jow: That's never good enough for me. If I'm flagrently avoiding change for the sake of avoiding change -- when a better way is out there that can make the software better AND improve the community, then I'm slowly dying. Jul 02 13:22:52 lol Jul 02 13:22:59 fork it then Jul 02 13:23:03 :D Jul 02 13:23:20 I know, but I hate splintering communities. That is what somebody may end up doing though Jul 02 13:23:22 you're rather overestimating the gains. Jul 02 13:23:40 again, please go and actually try things now that you know Jul 02 13:23:49 Well, I'm not a know-it-all, but I've been around a little. Jul 02 13:23:49 or, "read the provided documentation" if you will. Jul 02 13:24:04 the way it is now works for me, drop files and patches in, off we go Jul 02 13:24:17 "industry standard" is a bit of a copout too, there's no "standard" in "industry" Jul 02 13:24:17 i have spoken, etc Jul 02 13:24:33 jow: and I forgot to thank you for pointing out how I missed the files, thank you for that Jul 02 13:24:39 an opening gambit of 'you're doing it wrong' is an interesting approach to the existing community. Jul 02 13:24:51 sure, it is industry standard to have private kernel forks, severely lagging behind, with extremely questionable code quality Jul 02 13:24:52 karlp: I should say "industry best practices" Jul 02 13:25:06 vendor code that is *nowhere near* upstream-able Jul 02 13:25:18 ubuntu is so much in favor of ipv6 these days in that, it sends hundreds of dhcp request in ipv6 and only 3 or 4 ipv4 requests, and it by default will try ipv6 to death before giving ipv4 a chance Jul 02 13:26:03 more likely you are seeing the various autoconfig protocols Jul 02 13:26:07 jow: I'm talking about what the vast majority of the free and open source community has found to be effective and prudent practices when I said "industry standards", but I should have said "best practices" Jul 02 13:26:11 and important changes and fixes *hidden* in deep histories Jul 02 13:26:12 and...i disabled ipv6 on the router, so now everyone can get an ipv4, ubuntu 1806 suddenly could not, no more Jul 02 13:26:12 as well as general ipv6 noise Jul 02 13:26:19 unless Ubuntu are doing something very strange, they'll only try v6 if the machine has a global v6 address configured Jul 02 13:27:04 Dagger: i did got very few ipv6 requests Jul 02 13:27:09 like 1% maybe Jul 02 13:27:09 jow: like vendors know what versiom control is Jul 02 13:27:21 dansan: nobody is preventing you from importing openwrt's patches and driver sources once into a private kernel fork, then use that as external kernel tree in the openwrt build system Jul 02 13:27:47 its even really easy to do Jul 02 13:27:49 there's also some toplevel menuconfig options to set this up Jul 02 13:28:01 if i can do it anybody can Jul 02 13:28:01 jwh: they solve that by staying on kernel v2.6 mostly Jul 02 13:28:05 jwh: The widely accepted best practices to contrast "dropp[ing] files and patches in" would be to make the make the change to the kernel, commit that and have the openwrt regen its patches from the linux fork repo. Jul 02 13:28:16 ldir: heh, well sometimes they bump it Jul 02 13:28:22 dansan: this is already done+# Jul 02 13:28:25 but they never update after that Jul 02 13:28:37 brcm43xx patches for example are frequently sent upstream and backported from there Jul 02 13:28:41 jow: Yes, that's what I'm going to have to do for my case. Jul 02 13:28:52 dansan: that increasrs the effort for both developers and users Jul 02 13:29:01 increases Jul 02 13:29:08 for zero net gain Jul 02 13:29:20 jwh: It shouldn't. It's just a change for openwrt. Jul 02 13:29:30 *would be Jul 02 13:29:37 it meabs i have to fork and track another repo Jul 02 13:29:47 instead of applying patches to my local tree Jul 02 13:30:02 without distrurbing upstream (openwrt) Jul 02 13:30:35 Dagger: sorry, i mean ipv4 requests. are you sure ubuntu only tries ipv6? Jul 02 13:30:40 jwh: It could mean that, but I think there's a clever way of designing it so that it doesn't mean that. I would have to think about it and analyze it more. Jul 02 13:30:44 i went so far to the point to change /etc/gai.conf Jul 02 13:30:51 to make sure it prefers ipv4 Jul 02 13:30:54 does not work Jul 02 13:31:05 already having to track 4 repos Jul 02 13:31:08 dansan: perhaps, there's a chance, that we _did_ think about it :) Jul 02 13:31:10 jwh: When we build, we have to have the kernel tree on our hard drives anyway. I think that could be leveraged in a way to simplify it Jul 02 13:31:19 and this results in the least amoutn of forks that have to be maintained. Jul 02 13:31:21 it'll sort DNS results based on what address families you have available. v6 goes first if both you and the remote host claim to support it, otherwise v4 goes first Jul 02 13:31:24 dansan: fork openwrt, show us your clever approach, who knows, openwrt might switch to it :) Jul 02 13:31:33 yes but they are patched against a vanilla tree Jul 02 13:31:34 as Linus said, show me the code Jul 02 13:31:38 kernel release .tar.bz <<< none shallow kernel git clone Jul 02 13:31:39 you can see what order it's picking with `getent ahosts ` Jul 02 13:31:41 which makes my patches easier too Jul 02 13:31:44 karlp: It would increase complexity by adding a repo, but decrease complexity in the main repo, so it would be a trade-off. Jul 02 13:32:14 you need to examine the build system some more, it wouldnt Jul 02 13:32:18 heh Jul 02 13:32:26 you're making a very big deal about complexity in the main repo, probably because you weren't actually following the documentation in the first place. Jul 02 13:32:39 jwh: It would be the same for the linux-openwrt repo. There would be the vanilla tag (e.g., v4.14.78) and then the openwrt patches on top of that Jul 02 13:32:45 bur whike we are talking about complexity Jul 02 13:32:48 but Jul 02 13:32:56 why seperate feeds, i was curious Jul 02 13:32:57 (`wget` is also good at printing DNS results and showing you errors in the order it gets them) Jul 02 13:33:16 jwh: Yes, I do need to examine the build system more. Jul 02 13:33:29 let's adjourn for now then shall we? Jul 02 13:33:37 with that approach one would need to make at least two commits to two different repositories Jul 02 13:33:48 first update openwrt changes in the kernel repo Jul 02 13:33:49 Ok, thank you all for the discussion. I hope I can come back with some reasonable ideas. Jul 02 13:34:01 then update commit reference / version / tag / checksum in the main repo Jul 02 13:34:33 also copy over the git shortlog from the kernel repo to the main one to add context to the kernel bump commits Jul 02 13:34:38 jow: Yeah, I was thinking about that. Similar to the question for an autotools-based system, do I include the configure script or do I just give you an autogen.sh script. Jul 02 13:34:56 err, an autotools-based project Jul 02 13:35:01 ideally, you do neither Jul 02 13:35:15 and let the repo users generate proper auto* artifacts from source Jul 02 13:35:16 lol! But then it's not autotools based! :) Jul 02 13:35:25 oh, ic Jul 02 13:35:50 I think it's courteous to provide an autogen.sh though -- not everybody agrees on that. Jul 02 13:35:53 anyway stop, no suggesting changes Jul 02 13:36:01 im busy enough as it is Jul 02 13:36:15 (I think it's courteous to not use autotools, but ---- not everybody agrees on that either ;) Jul 02 13:36:24 Well I'll be back once I've studied it more. Also, I'll likely have some questions as I go :) Jul 02 13:36:36 karlp: good point! Jul 02 13:36:37 come back anytime :) Jul 02 13:36:43 ok, thanks again! Jul 02 13:37:40 oh my, what a flame/discussion Jul 02 13:37:50 dansan: there are meany reasons for both solutions Jul 02 13:37:54 no flame, just a discussion Jul 02 13:38:09 i believe get more advanteges from quilt + patches as files Jul 02 13:38:15 Well I most certainly appreciate everybody's time Jul 02 13:39:01 dansan: i got even happier with OpenWrt's model after working for a moment with raspberrypi kernel fork Jul 02 13:39:09 dansan: i know how you use git log, compare branches, etc. Jul 02 13:39:14 dansan: how to compare trees Jul 02 13:39:15 rmilecki: I haven't worked with it in a while Jul 02 13:39:42 But I sure cussed a lot when trying to write a USB driver with the old pi USB host controller driver Jul 02 13:40:01 dansan: the thing is, their hacky changes (commits) got changed a lot over time, but they still carry on the old descriptions Jul 02 13:40:21 dansan: with patches as files, we can update them easily, e.g. when simplyifying / adjusting to upstream changes Jul 02 13:40:29 that makes maintenance easier Jul 02 13:40:33 and patches cleaner Jul 02 13:40:44 so when day comes, they are easier to pick & send upstream Jul 02 13:40:59 that's one of big adventages I see Jul 02 13:41:23 also, creating forksfor every project we patch (we patch A LOT of them), would mean reaaaaly alot of forking Jul 02 13:41:34 rmilecki: As I've said before, I still need to dig more deeply into quilt. But my experience with doing this in git is that it still requires discipline or you just get crappy patches in git instead of on a file system. Jul 02 13:41:37 it's not just the kernel Jul 02 13:41:58 rmilecki: I know, I've been thinking about that as well... Jul 02 13:42:17 Ideally, you have a single good paradigm that you use everywhere Jul 02 13:42:45 busybox, hostapd, mac80211 (wireless-backports), basically any patckage with local patches would need a git repo clone somewhere Jul 02 13:42:46 lxc has 6 patches in owrt atm Jul 02 13:42:47 and not every project is using git, so that breaks it Jul 02 13:42:59 upstream project I mean Jul 02 13:43:09 that would be a huge maintenance burden Jul 02 13:43:56 jow: not necessarily, depending upon how it's set up, but from a repo hosting standpoint, yeah Jul 02 13:45:00 I mean, separating out the burden of maintenance *work* from the required infrastructure and local storage to do the maintenance. Jul 02 13:50:12 rmilecki: given that you were the last person to touch lxc, i ask whether you ever had the occasion to build it with gcc7 Jul 02 13:50:58 DonkeyHotei: i didn't Jul 02 13:51:03 i only saw it failing... Jul 02 13:51:17 so it's known to fail? Jul 02 14:09:28 not just ubuntu1804, iphone also persists ipv6, if i disabled ipv6 on the router, iphone never succeeds connecting to the wifi, same as ubuntu 18.04 Jul 02 14:09:46 the other older machines, ubuntu 1604, windows7 etc are fine without ipv6 Jul 02 14:10:55 my iptables stopped ipv6 packets at mangle/prerouting Jul 02 14:11:09 it Jul 02 14:11:54 it's not about ipv6 forwarding though, it's about i must let my wifi clients to talk ipv6 Jul 02 14:11:59 dedeckeh: are you aware of any recent regressions with ra/ndp relay? Jul 02 14:13:49 stintel:no I'm not aware of any recent regressions with ra/ndp relay Jul 02 14:13:52 hmmm Jul 02 14:14:09 do you see the issue with the latest version ? Jul 02 14:15:46 dedeckeh: well actually not sure, my laptop has a v6 address and default route, but doesn't seem to work. traffic is going out the wan interface though, but doesn't appear to come back Jul 02 14:16:00 so that smells like an issue with the crappy hgw I guess Jul 02 14:18:07 ok you see the traffic on the wan interface; but no return traffic Jul 02 14:19:25 stintel:I did not alter the ndp/ra proxy behavior in the latest version Jul 02 14:20:02 dedeckeh: alright, going to reboot the hgw and see what happens Jul 02 14:25:37 DonkeyHotei: known to me, i have to admit Jul 02 14:25:41 i didn't have time to look at it Jul 02 14:26:37 well, if you do fix it, the fix will need to be backported to the 18.06 branch too Jul 02 15:12:30 * drmr still has this udhcpc problem: https://forum.lede-project.org/t/udhcpc-gives-up-on-dhcp-discovery-too-soon-how-to-remedy/16411 :( Jul 02 15:14:44 udhcpc (as in, proto "dhcp" on an interface) just seems to give up trying for an IP address. Jul 02 15:17:52 drmr:udhcpc is not giving up; only the first 3 discovers are logged Jul 02 15:19:51 ah, okay. so that's not the reason for my problem then. Jul 02 15:20:42 don't think so Jul 02 15:21:24 still, there's something going on, something is keeping it from getting an IP address. Jul 02 15:21:37 * drmr looks into how to turn on more verbose logging. Jul 02 15:32:24 oh boy do I feel stupid now. Jul 02 15:33:38 I still had udhcpd enabled. that seemed to seriously confuse udhcpc running on lan. Jul 02 15:35:15 (and most probably all other devices on my network, too.) Jul 02 15:35:25 stupid me. Jul 02 15:45:07 I really should move eth0 to wan behind its own firewall, though, even though it is a single-port device and will always be on LAN only. Jul 02 16:03:42 hi, when doing config_set (in a callback provided to config_foreach), the new value is not visible "uci show"? Is that the correct behaviour? Jul 02 16:04:15 needs a uci commit iirc yes. Jul 02 16:04:24 uci changes probably shows it. Jul 02 16:05:44 I had the impression that config_sert is like "uci set .." Jul 02 16:06:04 and am suprised that this does not seem to be the case Jul 02 16:10:56 how do I commit changes made by config_set, if these are not even visible via "uci show" Jul 02 16:10:57 ? Jul 02 16:24:27 mwarning: config_set only changes the internal representation of the parsed uci data, you cannot use it to werite back to configs Jul 02 16:24:43 it is an arcane, bugged and old api, don't use it :) Jul 02 16:25:13 so, i got this xiaomi miwifi 3 router a while back.. is the homepage updated and the compatible version would be "the" snapshot? Jul 02 16:26:31 jow: by arcane, you also mean config_foreach etc.? Jul 02 16:26:51 and if so, what is there to use else? Jul 02 16:27:11 config_foreach & friends is fine, but config_set is not Jul 02 16:27:18 ah, ok Jul 02 16:27:49 then I use uci set for those cases Jul 02 16:27:52 thanks! Jul 02 16:27:52 yes Jul 02 16:27:58 hm, can someone explain what the vxlan package does? Jul 02 16:28:23 seems esier than extending netifd of i can do it as ashell script Jul 02 16:28:28 easier Jul 02 16:28:50 or is it entirely config and netifd is aware? Jul 02 16:37:45 jow: can config_set be fixed in the future? Or is it beyond help? Jul 02 16:39:56 anyway, I have updated the wiki Jul 02 17:12:39 since procd does so many things(hotplug,logging), is logd still relevant? Jul 02 17:25:19 hi, the wiki is a bit confusing, but it looks like 5ghz on the netgear r8000 is supported. however, when i try to enable a 5ghz interface, it stays disabled. any tips on how to debug/solve this? Jul 02 17:30:23 tostiheld: lol. Jul 02 17:30:34 You purchased a Broadcom router and now want 5GHz? Jul 02 17:30:53 Of course it won't work, and supported devices page is wrong. Jul 02 17:31:07 If you still can, exchange it to R7800. Jul 02 17:31:17 borrowed it to try it out :D so no 5ghz as i understand Jul 02 17:31:25 Yeah. Jul 02 17:31:33 i'll look into the 7800, thanks! Jul 02 17:31:36 You can try DD-WRT if you want to keep it. Jul 02 17:31:59 dd wrt doesn't seem to support it either and i prefer openwrt more anyways Jul 02 17:32:19 If I want to use a laptop as a WISP router, do I need another wireless NIC? Jul 02 17:32:42 tostiheld: What is your price range? Jul 02 17:33:12 I did some research and can suggest a router that works perfectly on OpenWRT for about any price. Jul 02 17:33:32 Thinking about making a YouTube channel with router recommendations. Jul 02 17:33:40 any price? Jul 02 17:33:47 $20+ Jul 02 17:34:18 https://www.amazon.com/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatible/dp/B073TSK26W Jul 02 17:34:29 Or Raspberry Pi. Jul 02 17:35:22 koops: range is my highest priority, and i am in a noisy environment so i'd like it to be something beefy like the r8000. maybe around 150 euros/dollars/whatever? Jul 02 17:35:51 Do not use a Raspberry Pi as a router. Due to the fact that the NIC (and any add-on NICs) are attached by USB2, along with the RasPi's poor I/O speed, severely limits its maximum throughput. Jul 02 17:36:42 tostiheld:https://www.amazon.com/Linksys-Dual-Band-Wireless-Tri-Stream-WRT3200ACM/dp/B01JOXW3YE/ Jul 02 17:36:45 https://wiki.openwrt.org/toh/recommended_routers Jul 02 17:36:46 perhaps it's better to suggest based on requirements than price Jul 02 17:37:04 https://bluegadgettooth.com/best-openwrt-router/ Jul 02 17:37:06 Mister_X: This page is old. Jul 02 17:37:17 Wait I will look into the second one. Jul 02 17:37:22 it doesn't make any less valid on support Jul 02 17:38:02 5 ghz would be nice for the noise, but not all my devices support it and the r8000 seems to hold up fine on the 2.4ghz band for now so eh Jul 02 17:38:35 koops: thanks for the suggestion Jul 02 17:38:41 tostiheld:R7800, https://www.amazon.com/Linksys-AC1900-Source-Wireless-WRT1900ACS/dp/B014MIBLSA/. Both slightly exceed your price. Jul 02 17:38:46 i ended up using a tp-link archer C7 v2 for the 2.4ghz Jul 02 17:38:53 But both will work in extremely noisy env. Jul 02 17:39:00 Linksys will likely work better. Jul 02 17:39:04 the 3200 one. Jul 02 17:39:13 Hi guys. :D Any place I can check progress on a specific device and if anyone is working on porting it? :D Jul 02 17:39:17 TP-Link started to sign their firmware Jul 02 17:39:26 the main selling point of the 3200 is 5ghz, not 2.4 Jul 02 17:39:27 not always possible to install OpenWRT. Jul 02 17:39:39 koops: this is a v2, off craigslist Jul 02 17:39:53 Used? Jul 02 17:39:56 yeah Jul 02 17:40:10 i used to have some old linksys wrt-54g or something. good times :) Jul 02 17:40:38 I wouldn't personally buy a used router from craigslist. No real way to check if it's safe. I know many ways to maliciously modify a router. Jul 02 17:40:51 Still, I have diagnosed anxiety disorder. Jul 02 17:40:51 TP-Link started to sign their firmware --- is it a problem when using tftp? Jul 02 17:41:17 I have no idea, but likely yes, what's the point of signing it if it can be bypassed. Jul 02 17:41:55 for the average user updating through the web interface Jul 02 17:42:03 nvm Jul 02 17:42:21 They do that for "security and compliance" reasons lol. Jul 02 17:42:30 Except OpenWRT firmware is more secure. Jul 02 17:42:40 DD-WRT is more secure even. Jul 02 17:43:05 how is dd-wrt more secure? Jul 02 17:43:12 more than stock. Jul 02 17:43:32 right. i thought you meant more secure than openwrt, which would seem odd to e Jul 02 17:43:34 me* Jul 02 17:43:34 (Kinda) open source, widely used, likely to be more secure than stock. Jul 02 17:43:43 OpenWRT is the most secure one. Jul 02 17:43:55 what's the difference then? Jul 02 17:44:08 DD-WRT is pretty much proprietary. Jul 02 17:44:17 No real way to compile it by yourself. Jul 02 17:44:26 do they get audited? Jul 02 17:44:39 I don't think there was any real audit. Jul 02 17:45:04 I think OSTIF wants to audit some router firmware but they didn't decide between DD, OpenWRT and Tomato. Jul 02 17:45:19 I suggested OpenWRT. Jul 02 17:45:23 i thought tomato was dead Jul 02 17:45:36 There is continuation by Shibby. Jul 02 17:46:13 that's nice. keeps up the diversity Jul 02 17:46:22 Shibby is almost dead now, but it's been taken over by Kille72 Jul 02 17:46:28 the freshtomato branch Jul 02 17:46:59 Would be better if more people worked on the best, most secure one to be honest (openwrt). And push router manufacturers to officially support it. Jul 02 17:48:07 glinet Jul 02 17:48:16 yeah well. earning money in the foss world is difficult Jul 02 17:48:24 most people don't even care enough to not use their ISP's default modem, let alone use 3rd party firmware Jul 02 17:48:43 Oh, by the way, every firmware except OpenWRT do not use HTTPS for package updates. Jul 02 17:48:48 Automatic audit fail. Jul 02 17:49:10 Your ISP can SSH into your router any moment lol. Jul 02 17:49:17 And you run your LAN through it. Jul 02 17:49:28 as long as the packages are signed it shouldn't matter much. debian and derivates have been on plain text protocols for ages Jul 02 17:49:49 Well, it allows states to censor packages, like Shadowsocks (China). Jul 02 17:49:57 PACKAGES ARE NOT SIGNED. Jul 02 17:50:02 (entware) Jul 02 17:50:27 openwrt pkgs are not signed, either Jul 02 17:50:37 Sure? Jul 02 17:50:45 I think they are signed and over HTTPS. Jul 02 17:50:58 Not only Chinese use Shadowsocks by the way, I use Outline which uses it. Jul 02 17:51:13 It's probably faster than Wireguard too. Jul 02 17:51:22 because it's simpler. Jul 02 17:51:35 Not a full VPN, only allows TCP and UDP. Jul 02 17:51:55 downside: You can't ping or traceroute over it. Jul 02 17:54:21 isn't traceroute on *nix using TCP? Jul 02 17:54:43 And how is that supposed to work? Jul 02 17:55:30 TTL Jul 02 17:55:42 traceroute uses udp Jul 02 17:56:15 https://linux.die.net/man/1/tcptraceroute Jul 02 17:59:09 Will anything break if all IGMP packets are blocked? Jul 02 17:59:16 Simply ping won't work? Jul 02 17:59:38 blocking igmp will also block zeroconf Jul 02 17:59:59 Shadowsocks won't support igmp. Jul 02 18:00:24 I guess if I need ping and IGMP I will do wireguard over shadowsocks. Jul 02 18:08:39 Can I ping over UDP or TCP? Jul 02 18:09:21 *ICMP Jul 02 18:20:12 koops: you know anything about SoftMAC vs. FullMAC? Jul 02 18:20:18 koops: available Broadcom drivers Jul 02 18:20:23 koops: it doesn't seem so Jul 02 18:20:30 tostiheld: R8000 should be well supported Jul 02 18:21:01 Then why doesn't 5GHz interface go UP? Jul 02 18:21:12 koops: why didn'y you help debug that? Jul 02 18:21:45 How? I don't have this device. Jul 02 18:21:56 koops: by providing debugging info to tostiheld Jul 02 18:22:14 koops: that would be much better than just providing non sense info about support state Jul 02 18:23:00 Are you completely sure this router will have 5GHz working? Jul 02 18:23:20 koops: of course not, it can be e.g. broken Jul 02 18:23:27 the R8000 on my desk works Jul 02 18:23:30 Because, isn't broadcom driver 2.4GHz only, and even that doesn't support 11n. Jul 02 18:23:47 different broadcom driver Jul 02 18:23:58 koops: you don't know about chipset, you don't know about FullMAC vs. SoftMAC, you don't know drivers, you don;t know how to verify it Jul 02 18:24:02 maybe it's a bad idea to advise then Jul 02 18:24:24 tostiheld: please run "wifi" command, wait 5 seconds, then run "logread -l 50" and pastebin the output Jul 02 18:24:43 tostiheld: these should be some useful info about starting (and failing?) hostapd Jul 02 18:25:24 So, if I buy R8000, it will work without any issue? Jul 02 18:26:01 Broadcom BCM43602 and BCM4360... Are those different revisions of same chip? Jul 02 18:26:16 koops: i can't and won't guarantee it will work without issues Jul 02 18:26:27 probably noone can guarantee that for any device Jul 02 18:26:55 I completely excluded Broadcom while looking for my own router just in case. Jul 02 18:26:59 koops: they may share the core, but use totally different achitectures Jul 02 18:27:13 koops: please... just google FullMAC vs. SoftMAC Jul 02 18:27:19 4360 is SoftMAC Jul 02 18:27:24 43602 is FullMAC Jul 02 18:28:05 i'll probably have to give 18.06 a try on R8000 to make sure it still works as expected Jul 02 18:28:08 good idea Jul 02 18:28:37 So the MAC layer is the reason? Jul 02 18:28:45 Second data partition (79 MiB) not available in OpenWrt though... Jul 02 18:31:39 Wait, I clearly remember that Broadcom had some other issues. Jul 02 18:31:44 Driver related too. Jul 02 18:34:53 With the CPU, probably hardware acceleration. Jul 02 18:35:00 "clearly" "some" Jul 02 18:35:12 hardware NAT is not supported Jul 02 18:35:17 that shouldn't surprise you probably Jul 02 18:35:23 Why? Jul 02 18:35:24 it was added to kernel very recently Jul 02 18:35:37 only some Mediatek has hw driver Jul 02 18:35:42 and i don't tihnk it's even upstream yet Jul 02 18:35:58 E.g. OpenWRT-specific? Jul 02 18:36:04 Does DD-WRT have it? Jul 02 18:36:10 i thought somebody was working on hardware nat for qualcomm too Jul 02 18:36:16 no idea, check, let us know Jul 02 18:36:35 i'm planning to work on hw nat for Broadcom is time permits Jul 02 18:36:41 code is there in the SDK Jul 02 18:36:53 we "just" need to adapt it to the upstream API Jul 02 18:37:54 Hmm, so maybe those old Linksys E3000s I have will actually be able to NAT at a decent speed. :) Jul 02 18:38:54 rmilecki: cool. Jul 02 18:39:06 mamarley: BCM4718A1 is MIPS, right? Jul 02 18:39:09 Why do routers rarely have hardware AES? Jul 02 18:39:13 mamarley: i'm not sure they got HW NAT Jul 02 18:39:19 Almost none supported by OpenWRT. Jul 02 18:39:21 mamarley: i tihnk HW NAT was added to ARM devices Jul 02 18:39:32 mamarley: with BCM4718A1 you can use software accelerated NAT right now Jul 02 18:39:50 there are enough mips devices with hardware nat Jul 02 18:40:27 I need a hardware AES device for VPN. Jul 02 18:40:34 or ShadowSocks. Jul 02 18:41:27 rmilecki: I'm pretty sure it supported some kind of HW NAT because if I remember correctly there was an option to enable or disable it in the stock FW. I'm not actually using that device anymore though; I Just thought it would be interesting to see how fast it could NAT if HW NAT was supported. Jul 02 18:45:15 has luci any app for intrusion prevention/detection tools? Jul 02 18:47:42 How is possible to change grub timeout? grub.cfg is readonly. Thanks Jul 02 18:49:55 /boot is a separate partition, which you can remount read-write Jul 02 18:50:43 mount -o remount,rw /boot Jul 02 18:51:11 and when you're done: Jul 02 18:51:15 mount -o remount,ro /boot Jul 02 18:54:10 mamarley: these devices got CTF for sure, but that was Broadcom's proprietary software NAT acceleration Jul 02 18:58:34 Ah, OK. I thought that was in hardware. So I guess the new software offloading performs that same function then. Jul 02 19:27:53 DonkeyHotei: thanks Jul 02 19:31:24 mamarley: that's my understanding Jul 02 19:41:15 What is best "outofthebox" best network intrusion system detection/prevention if possible with luci app? Jul 02 19:44:57 Is there any alternative for fail2ban for wrt? Jul 02 19:52:58 Those Belgians are being cheeky again :-) Jul 02 20:16:41 Lukas__, don't know about out of the box, but there are a few on linux: snort, suricata and bro are pretty well known Jul 02 20:16:50 but that requires a lot of cpu Jul 02 20:18:21 for fail2ban, if it's for just ssh, then sshguard or denyhost Jul 02 20:18:43 fail2ban is multi protocols though and I don't think there is any single alternative to it Jul 02 20:18:51 if you need multi protocol Jul 02 20:19:28 in any case, you can always google "Alternative to " Jul 02 20:20:23 ldir: we are winning sir. but you need to put us at a disadvantage first :( Jul 02 20:20:40 i guess first half against brazil we'll just be looking at how good they play >_> Jul 02 20:23:15 lol Jul 02 20:26:40 are you taling about this football thing ? Jul 02 20:26:51 if i only had a TV ..... Jul 02 20:27:39 its not that i hate or dislike football, it simply does not exist in my scope of perception Jul 02 20:28:06 Will my network work correctly if I block ICMP completely (e.g. for forwarding all traffic to SOCKS5 server avoiding leaks)? Jul 02 20:28:20 ?! Jul 02 20:28:25 Like using Tor or Shadowsocks for all traffic. Jul 02 20:28:35 Tor means blocking all UDP except DNS too. Jul 02 20:28:38 * blogic puts on tinfoil hat Jul 02 20:28:53 koops: well some stuff wont work Jul 02 20:29:03 but you wan that i guess Jul 02 20:29:04 It's mostly to avoid censorship lol. Jul 02 20:29:09 No need of tin foil hats. Jul 02 20:29:16 the thing is your question can simply be answered by trying Jul 02 20:29:23 I don't want traffic to leak to outer network though. Jul 02 20:29:45 well, easy way to find out Jul 02 20:29:52 Or maybe using Tor for open wi-fi to avoid liability for user actions on it. Jul 02 20:30:09 well its a superficial question Jul 02 20:30:23 you know you can simply try and see if it works Jul 02 20:31:05 blogic: i don't have cable either. but firefox can tolerate some drm so our i can stream it on our national tv's website Jul 02 20:31:08 yout motivation for asking was prolly something else than getting the technical answer Jul 02 20:31:19 first match of my dear compatriotes i am watching in this world cup Jul 02 20:31:38 Borromini: i must admit i find it really boring Jul 02 20:31:45 I want to make free Wi-Fi for neighbourgs but don't want police to come knocking on my door. Jul 02 20:31:57 everytime i am force to watch football, i am baffled byt why people enjoy it Jul 02 20:32:17 I want it to be speed-limited too. Jul 02 20:32:19 blogic: a bad game feels like 90 minutes wasted. but a bad movie as well :). Jul 02 20:32:33 blogic: i assume you don't like to play it either? that certainly helps i think. Jul 02 20:33:21 Borromini: true Jul 02 20:33:31 Is there a program to create a TUN device that sends all packets to other device but throttles max speed? Jul 02 20:35:28 koops, there are tools to throttle speed Jul 02 20:35:36 Mister_X: thanks. i see. Jul 02 20:35:38 anyway gents i'm out, goodnight. Jul 02 20:36:00 look into tc Jul 02 20:36:58 I want to make free Wi-Fi for neighbourgs but don't want police to come knocking on my door. --- then don't share wifi Jul 02 20:37:11 Lol all traffic goes to Tor. Jul 02 20:37:36 I don't want it to pass through my shadowsocks server either. Jul 02 20:38:12 and tor can be identified when looking at traffic Jul 02 20:39:37 Doesn't matter, *they* will come to exit node operator if they're in Russia. Jul 02 21:04:24 hi, I connect a openwrt router as client with to another router. Jul 02 21:04:38 how can I check if a connection has been established? Jul 02 21:05:16 even when no connection has been establish, the device is still there and up.. Jul 02 21:07:56 mangix: re proc/interrupts from my zbt we1326 https://zerobin.net/?c78c6649a913820b#e/0JKZlZeTrANhgz+YoG38YIx7J56MRQBUwdv+BoPOw= Jul 02 21:09:56 mwarning: luci, ifstatus, ip, ifconfig, ... Jul 02 21:11:34 Can targets, on their kernel config fragment, select the option CONFIG_DEVMEM? Jul 02 21:11:43 because I found 3 targets doing that: gemini, layerscape, and oxnas Jul 02 21:11:55 The option is defined on generic as "# CONFIG_DEVMEM is not set" Jul 02 21:12:16 I think targets that need it should use OpenWRT's KERNEL_DEVMEM config Jul 02 21:19:43 I just found the answer on commit c2fc52a: Jul 02 21:19:44 kernel: remove DEVMEM/DEVKMEM platform overrides Jul 02 21:19:45 Those options are handled via top-level menuconfig instead Jul 02 21:23:44 arch/ subarch (k)config snippets do override the generic config though Jul 02 21:26:19 Yes, that's why it's important to identify what configs are generic and what are target specific Jul 02 21:30:17 pkgadd: yes, that seems to be way to go. Still have to woraround the "wifi status" stalls and causes reboot issues... Jul 02 21:41:26 karlp: ty Jul 02 21:47:57 that's a few weeks ago build now. I've restarted it a few times for 2.4gig dissappearing, and once for 5gig dissappearing and only 2.4 being available. Jul 02 21:48:20 but otherwise, much faster than the miwifi3 it replaced, and also the ISP box it replaced. Jul 02 21:49:29 can you run lspci? Jul 02 21:50:14 would have to rebuild sorry, not right now. Jul 02 21:50:26 i can probably dump stoff from /sys or something though, one tick Jul 02 21:51:27 actually nvm Jul 02 21:51:36 is this enough? https://zerobin.net/?0cd3de3387f3df88#NFmFA3mtx9I2dHeW9eLhaxtYAFAqAS7T5GjG8alBVPY= Jul 02 21:52:20 that...is actually perfect. confirms my suspicions Jul 02 21:52:31 * karlp cheers for ..... something.... :) Jul 02 21:53:00 dts file is wrong. that's why it was failing with the staging driver Jul 02 21:53:34 are we back on this debate about which wifi is on which pci slot again? Jul 02 21:53:56 I thought we fixed that? Jul 02 21:54:08 no just reverted back the driver Jul 02 21:54:09 remember, it didn't work at all before. Jul 02 21:54:23 hrm, there was another fix too I thought. Jul 02 21:54:28 it was a busy day and a half. Jul 02 21:54:29 nope Jul 02 21:54:46 i think the 4.19 bump will introduce the staging stuff for testing Jul 02 21:55:54 hrm, I thought we removed the wrong reg values, and then _also_ reverted some stuff? Jul 02 21:56:15 the reg values thing was incorrect. it was accidental that it worked Jul 02 21:56:26 ah, explains why it worked for some and not others. Jul 02 21:56:39 well, this is now "in production" so I can update it maybe next week Jul 02 21:56:53 I'll be on holidays then so I can break things during the day while the wife's at work. Jul 02 21:57:53 * karlp still thoguht pcie was probeable, why does it need to be set explicitly in dts files? Jul 02 21:59:52 dunno. all the platforms do though Jul 02 22:01:50 karlp: in any case, i'm planning to send this change as preparation: https://gist.github.com/neheb/0383f00790b85f8a877891b518acfddc Jul 02 22:04:42 how did unielec get added as a patchfile adding the dts file, instead of just the dts file?! Jul 02 22:17:40 does the wpad-full/mesh menuconfig stuff still look really borked indenting to anyoen else? Jul 02 22:17:44 is it really meant to be like that? Jul 02 22:18:17 It is a bit iffy looking. Jul 02 22:19:01 if I want wpad-full-openssl, is that now the one underneath mini, or the mesh one underneath full? Jul 02 22:22:26 underneath mini Jul 02 22:22:40 The.. one under mini, yes Jul 02 22:22:43 That's really ugly. Jul 02 22:23:32 * karlp doesn't know how to fix this one.. Jul 02 22:23:43 there used to be a submenu for ssl implementation, Jul 02 22:40:41 Is it a common way in OpenWrt to build both, static and shared libs alongside to support software which relies on a static lib during link time? Jul 02 23:53:55 hello **** ENDING LOGGING AT Tue Jul 03 03:00:00 2018