**** BEGIN LOGGING AT Mon Nov 16 02:59:56 2020
Nov 16 03:55:44 <UnknownzD> Hi, I may have found an issue in the dnsmasq package. But I don't want to immediately open the ticket unless someone has confirmed the issue as well. Is there anyone free to help? Currently I have found the same issue to take place on 2 different routers running OpenWRT
Nov 16 03:57:06 <UnknownzD> I have found that when dnsmasq is loading a large amount of hosts via "servers" in a config file (specifically dropped via adblock), dnsmasq has dropped all subsequent TCP enquiry
Nov 16 03:57:24 <UnknownzD> with TCP RST packet sent to the client
Nov 16 03:58:25 <UnknownzD> Normally this would not affect PC connection since PC is mainly using UDP port for enquiry
Nov 16 03:59:03 <UnknownzD> However, my android TV has been sending TCP query to dnsmasq instead, and does not rely on the UDP reply
Nov 16 04:00:12 <UnknownzD> It is confirmed that the packet is not dropped by the firewall since the pcap file captured by the adblock packge under DNS report section has shown the RST packet
Nov 16 04:01:02 <UnknownzD> And I have set all the firewall setting to adopt a drop approach instead of reject approach, therefore a RST packet is unlikely caused by the firewall
Nov 16 04:02:02 <UnknownzD> Any help would be appreciated, and if anyone can confirm this issue, I will submit a ticket in bug tracker as well
Nov 16 04:06:15 <UnknownzD> In addition, I have also confirmed that the /tmp/dnsmasq.d/adb_list.overall (a dnsmasq conf file) dropped by adblock does not contain any malformed directive / parameter as I have confirmed with the regular expression "\n(?!address=)" to see if the file contains any lines unrelated to host blocking
Nov 16 04:08:05 <Namidairo> how many entries is it
Nov 16 04:08:13 <UnknownzD> "log-queries=extra" was also adopted in dnsmasq.conf, and the syslog simply skipped to show anything / any query when TCP request is resolved
Nov 16 04:08:20 <Namidairo> >= 150 entries?
Nov 16 04:08:32 <UnknownzD> Yes, 458090 lines
Nov 16 04:10:00 <UnknownzD> with 2 different routers, one Linksys EA8300, one NetGear R7500 v1
Nov 16 04:10:10 <UnknownzD> Mon Nov 16 10:30:47 2020 user.info adblock-4.0.7[16085]: blocklist with overall 458081 blocked domains loaded successfully (Linksys EA8300 (Dallas), OpenWrt 19.07.4 r11208-ce6496d796)
Nov 16 04:12:15 <UnknownzD> when the DNS cache / adblock config file is being reset via "service adblock restart", the dnsmasq on the router respond to the TCP enquiry
Nov 16 04:12:46 <UnknownzD> But once the config file is dropped and the dnsmasq is reloaded, the dnsmasq no longer respond to TCP enquiry
Nov 16 04:30:37 <UnknownzD> During the test, I have also tried to use all 3 different ways of binding interface (bind-interfaces / bind-dynamic / default) but still shows the same result ....... so I guess it is different from the previously reported bug via RHEL bug tracker
Nov 16 04:46:49 <Grommish> I've had no issues with Adblock or dnsmasq locally, but gimme a sec to test.. I've been blowing my device up all day and haven't turned it back on yet
Nov 16 04:49:26 <UnknownzD> Grommish, I have another user trying to reproduce the result in #openwrt, but he said he has no such issue at all
Nov 16 04:49:44 <UnknownzD> brb, shutting down connection for further test
Nov 16 05:08:09 <UnknownzD> Grommish, did you have similar result?
Nov 16 05:28:51 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
Nov 16 07:28:23 <UnknownzD> For anyone who has read the chat regarding the dnsmasq dropping TCP enquiry issue, in relation to adblock, I have found a temporary workaround that the adblocker will be working but certain functionality will be missing, such as NX domain in the DNS reporting function and the blocked domain enquiry function
Nov 16 07:29:03 <UnknownzD> You can set adblock as using raw as the DNS backend, and then add the following line in the crontab, "*/2 * * * * sed -e 's/^/0.0.0.0 /' /tmp/adb_list.overall > /tmp/adblocker && rm /tmp/adb_list.overall && killall -s SIGHUP dnsmasq &"
Nov 16 07:29:18 <UnknownzD> This will cause the router to check for adblock drop eveyr 2 mintues, and then reformat the list as per attn-host file format
Nov 16 07:29:43 <UnknownzD> in /etc/dnsmasq.conf, add /tmp/adblocker as attn-hosts with "addn-hosts=/tmp/adblocke"
Nov 16 07:29:55 <UnknownzD> "addn-hosts=/tmp/adblocker"
Nov 16 07:30:05 <UnknownzD> if you only use SIGHUP to force dnsmasq to re-read the attn-hosts file, instead of reading a 400k+ line config file for adblocking, it will work
Nov 16 07:30:38 <UnknownzD> Anyway, thanks for anyone that helped, and I will see if anyone can reproduce the issue before submitting the bug ticket
Nov 16 09:27:40 <ldir> Could someone take a look at https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=700029406989ce7964f1370173023371136ad484 for me please - I don't know if there's a more technically correct way to fix it.
Nov 16 09:34:16 <ldir> nbd: ^^^^ you might have more clues
Nov 16 09:51:38 <jow> I wonder about the sudden SADDNS hype
Nov 16 09:52:03 <jow> I though it is common sense that a DNS TXN is only protected by a random 16 bit source port
Nov 16 09:52:37 <jow> ldir: looks reasonable
Nov 16 09:54:13 <rsalvaterra> jow: I believe it's a bit overblown, to be honest.
Nov 16 09:54:45 <jow> some of these things appear as if some people just rediscover how the internet works
Nov 16 09:55:50 <rsalvaterra> I'm still amazed it actually does. :P
Nov 16 09:58:24 <karlp> thankfully we've at least moved on from the "omg, I have physical access and jtag tooling and I could modify memory!"
Nov 16 09:59:03 <rsalvaterra> karlp: Yeah, security people are a bit… overzealous.
Nov 16 09:59:41 <rsalvaterra> Obligatory xkcd… https://xkcd.com/538/
Nov 16 10:10:14 <nitroshift> rsalvaterra, o/
Nov 16 10:11:56 <eduardas> hello, an initramfs boot fails with "Warning: unable to open an initial console."
Nov 16 10:12:18 <eduardas> my inittab https://pastebin.com/kyjsPMmh
Nov 16 10:12:35 <eduardas>  devtmpfs should get mounted
Nov 16 10:12:50 <eduardas>  I have both CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y
Nov 16 10:13:06 <eduardas> so I am unsure why this does not work
Nov 16 10:13:18 <eduardas>  I also use setenv bootargs console=ttyMSM0,115200n8 rootfs=ramfs root=/dev/ram rw
Nov 16 10:13:54 <eduardas> This is using a rather minimal config of Qualcomm's linux-msm 4.4 on the Compex CP01 board for IPQ6018
Nov 16 10:14:30 <eduardas> though inittab might not matter in this case? not sure
Nov 16 10:15:52 <rsalvaterra> nitroshift: o/
Nov 16 13:22:46 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 16 15:35:41 <rr123> rebuild master this morning, my tplink-a7-v5 lost one wifi radio, previously wlan0 for 5G and wlan1 for 2.4G, now wlan0 is 2.4G and 5G is gone with this new daily master build
Nov 16 15:36:04 <hexa-> rr123: nopaste the output of `dmesg`
Nov 16 15:43:55 <rr123> https://nopaste.xyz/?5b876a98befca331#7NBYw3Rii93eyPwMhu1NFj8v1zk2xHt6noLTsWC83pEM
Nov 16 17:45:22 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 16 18:25:42 <adrianschmutzler> ah, I fucked up 11-ath10k-caldata (or technically not me, but I merged it)
Nov 16 18:30:30 <adrianschmutzler> rr123: fix pushed to master
Nov 16 19:29:23 <rr123> adrianschmutzler: thanks, i also fixed it and was preparing a PR then found it's fixed, that's fast
Nov 16 19:33:42 <aparcar[m]> adrianschmutzler: ping
Nov 16 19:33:58 <adrianschmutzler> ja?
Nov 16 19:34:11 <aparcar[m]> I updated the size_compare.sh script
Nov 16 19:34:39 <aparcar[m]> Also I did some more work on the device metadata stuff, should I keep you posted?
Nov 16 19:35:36 <aparcar[m]> Also there is a dangling patchworks patch I don't see any reason not to merge https://patchwork.ozlabs.org/project/openwrt/patch/20200729093228.1268598-3-mail@aparcar.org/
Nov 16 19:36:09 <adrianschmutzler> I typically aware of what happens in the main repo and the mailing list, so only when something is happening elsewhere
Nov 16 19:37:14 <aparcar[m]> In fact don't merge the dangling patch I'll close it
Nov 16 19:37:30 <aparcar[m]> Instead licenses should be renamed to valid SPDX identifiers
Nov 16 19:38:42 <adrianschmutzler> well, i'm not too interested in familiarizing myself with that license subject in detail
Nov 16 19:39:34 <aparcar[m]> fair
Nov 16 19:39:55 <aparcar[m]> I moved the metadata stuff over to https://github.com/aparcar/devices
Nov 16 19:40:48 <adrianschmutzler> Well, we could discuss that at the next meeting which should happen at some point anyway
Nov 16 19:40:58 <aparcar[m]> The schema had some errors but seems mostly fine now. The original data of the wiki has tons of flaws which I try to resolve at some point with Thomas
Nov 16 19:41:24 <adrianschmutzler> if properly prepared, one could then decide where to maintain it
Nov 16 19:42:49 <aparcar[m]> is there an idea for the next meeting?
Nov 16 19:43:46 <adrianschmutzler> Well, it will be hard to work with it if its created directly from the wiki. one should at least extract the device names itself from the main git repo and then only fill those with data from the Wiki.
Nov 16 19:46:03 * rr123 wonders when nftables(fw4?) work will start, from the reading it's mostly about luci related work
Nov 16 19:46:41 <aparcar[m]> yes I added a "tag" to all automatically moved devices, those should go through a manual review process. I'll add some demos of recently added devices.
Nov 16 19:49:45 <aparcar[m]> jow: please add this patch for consistency https://patchwork.ozlabs.org/project/openwrt/patch/20190924202740.11679-1-mail@aparcar.org/
Nov 16 19:49:55 <aparcar[m]> buildbot key storage
Nov 16 20:29:23 <jow> rr123: I already started working on it
Nov 16 20:44:00 <rr123> jow: will it be fw4 and share the same  git as firewall3,want to watch the repo and test it along the way
Nov 16 20:57:27 <jow> rr123: no, it will be a separate repository most likely
Nov 16 21:14:58 <adrianschmutzler> aparcar: btw, the next meeting is actually due for more than a month now, but obviously nobody had the time or interest in scheduling it (i.e. determine a slot where many people are available)
Nov 16 21:15:34 <adrianschmutzler> and preferably we would lift all release blockers for 20.xx beforehand, so we can branch at this meeting
Nov 16 21:18:00 <aparcar[m]> dangole: ping
Nov 16 22:08:56 <aparcar[m]> adrianschmutzler: do you think it makes sense to open mail threads for the last open blockers?
Nov 16 22:09:09 <aparcar[m]> or is someone working on an overivew? the wiki page itself doesn't seem suited for discussion
Nov 16 22:13:55 <nick[m]> blogic: are u fine with reverting to port-isolation on ipq40xx again? Could u comment on https://github.com/openwrt/openwrt/pull/3596#issuecomment-728318378
Nov 16 23:14:29 <adrianschmutzler> aparcar[m]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx
Nov 16 23:17:10 <aparcar[m]> adrianschmutzler: yea I'm aware of it 🙂 should we create mail threads for it?
Nov 16 23:21:58 <rsalvaterra> GCC bump deemed to risky? That's unfortunate… :/
Nov 16 23:22:50 <pkgadd> rsalvaterra: that's just a matter of timing, bumping core toolchain packages now invalidates all testing done
Nov 16 23:30:04 <rsalvaterra> pkgadd: Yeah, totally agree… it's just easy to forget that when we're building our own images with GCC 10.x for months… :)
Nov 16 23:36:57 <pkgadd> in the beginning, after gcc 10 was formally released as stable, it still had quite a few bugs (those are solved by now)
Nov 16 23:37:43 <aparcar[m]> does it make sense to skpi gcc 9 then?
Nov 16 23:40:44 <pkgadd> personally I've not used either on OpenWrt so far (I usually keep the toolchain options, and especially the compiler, at their defaults), but I don't think there'd be much value in looking into gcc-9, unless gcc-10 would show bigger issues (apart from being more strict)
Nov 16 23:41:16 <pkgadd> (but I do use gcc-10 on Debian/ unstable for i386 and x86_64 regularly+)
Nov 16 23:44:27 <enyc> silly question, what does the gcc version change  8.4->10.x  make to the quality/hardening/functionality of  OpenWRT-20.xx ?  some tangeable advantage,  or more just future-proofing release?
Nov 16 23:50:40 <pkgadd> to varying extents, it's all of that - and eventually a mere necessity. yes, sources often have problems with (too-) new compilers, but at the same time they quickly lose compatibility with old ones or require features of newer ones
Nov 16 23:51:26 <pkgadd> especially for ARM, you also see a lot of work happening on the compiler side (and yes, also all of those topics, hardening, performance for newer SOCs, ...)
Nov 17 00:21:49 <aparcar[m]> download server down again?
Nov 17 00:38:06 <pkgadd> apparently
Nov 17 00:46:30 <jow> not down, overloaded
Nov 17 01:09:26 <jow> mirror-02 kernel: [44229028.176241] Out of memory: Kill process 28279 (python3) score 25 or sacrifice child
Nov 17 01:09:34 <jow> mirror-02 kernel: [44229028.176305] Killed process 28279 (python3) total-vm:1310800kB, anon-rss:858912kB, file-rss:0kB, shmem-rss:0kB
Nov 17 01:09:48 <FirstTime_NoTime> Using the latest master and configuring it for a new rt7620 device. I would like the rt2x00 driver to stop registering LEDs as they are not physically connected on this board (i.e. remove rt2800soc-phy1::assoc from /sys/class/leds)  (same for mt76-phy0) . How can I do that?
Nov 17 02:01:30 <mangix> rsalvaterra: GCC 10 has better support for C++20, which is nice.
Nov 17 02:48:06 <rr123> downloads.openwrt.org is down
Nov 17 02:50:00 <rr123> it's said gcc10 finally caught up llvm/clang and got ahead a bit, before gcc10 it's kind of behind
**** ENDING LOGGING AT Tue Nov 17 02:59:56 2020