**** BEGIN LOGGING AT Tue Dec 15 02:59:57 2020
Dec 15 07:36:08 <ynezz> Hauke: I usually add init_debug=5 to the kernel command line
Dec 15 08:31:07 <mangix> jow: can you look at my recent libpcap/tcpdump patches? It seems to be a problem on Arch Linux
Dec 15 09:35:08 <mangix> rsalvaterra: https://git.openwrt.org/?p=project/libubox.git;a=blobdiff;f=utils.h;h=5c53cc0260d39b00e9bec1a8062356904e0060b1;hp=27f81e568bf5aa2d5c1bfe8cec883215e29593f1;hb=357877693ca363b12e6e7e14d345639b2440cd07;hpb=9e52171d70def760a6949676800d0b73f85ee22d broke hnetd
Dec 15 09:35:12 <mangix> rofl
Dec 15 09:35:38 <rsalvaterra> WAT
Dec 15 09:36:02 <mangix> https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/routing/hnetd/nossl/compile.txt
Dec 15 09:36:42 <ynezz> it has passed the CI tests https://gitlab.com/openwrt/project/libubox/-/pipelines/229079358/builds
Dec 15 09:36:52 <ynezz> there is a53 compile check as well
Dec 15 09:37:02 <mangix> that's libubox itself
Dec 15 09:37:08 <mangix> not other packages including it
Dec 15 09:37:11 <rsalvaterra> mangix: I fail to see how, you're probably being bitten by something else… :/
Dec 15 09:37:24 <mangix> rsalvaterra: nope. removing include sys/stat.h fixes it
Dec 15 09:38:14 <ynezz> mangix: stat.h:17:19: error: expected identifier or '(' before '[' token
Dec 15 09:38:19 <ynezz> this would be visible as well
Dec 15 09:38:36 <ynezz> it is using same SDK
Dec 15 09:38:53 <ynezz> so probably hnetd does some include/macro foo?
Dec 15 09:39:05 <mangix> who knows
Dec 15 09:39:32 <mangix> all I know is, removing the include from libubox/utils.h fixes compilation
Dec 15 09:39:50 <ynezz> but that's "fix" :)
Dec 15 09:41:05 <mangix> It's suspicious why include sys/stat.h was added
Dec 15 09:41:19 <mangix> musl defines mode_t in alltypes.h
Dec 15 09:43:54 <rsalvaterra> Yeah, but that doesn't explain what's so special about hnetd…
Dec 15 09:44:19 <mangix> dunno, some random package in routing
Dec 15 09:44:37 <jow> https://github.com/sbyx/hnetd/blob/master/src/pa_core.h#L35
Dec 15 09:44:40 <jow> that's the problem
Dec 15 09:44:54 <mangix> oh, joy
Dec 15 09:45:18 <rsalvaterra> jow to the rescue. :)
Dec 15 09:45:46 <ynezz> I was just about to paste this https://github.com/sbyx/hnetd/blob/master/src/hnetd.h#L111
Dec 15 09:45:49 <ynezz> :)
Dec 15 09:46:10 <jow> the solution will be moving #include "pa_conf.h" before the __unused define (assuming it does not use __unused itself)
Dec 15 09:46:26 <jow> or #include <libubox/utils.h> before declaring __unused
Dec 15 09:46:47 <jow> so simply speaking, make sure all headers are included and processed before declaring __unused
Dec 15 09:47:10 <ynezz> or just don't declare the __unused and use the __attribute__((unused)) directly
Dec 15 09:47:22 <jow> declaring __unused is fine
Dec 15 09:47:33 <jow> but not when done between two direct or indirect sys/*.h includes
Dec 15 09:48:05 <jow> doing any kind of define between two #include's can cause stuff to blow up
Dec 15 09:48:12 <jow> when name collissions occur
Dec 15 09:48:25 <mangix> interesting....
Dec 15 09:48:31 <jow> best is to defer any user code defines until after the last include
Dec 15 09:48:35 <mangix> C23 adds this as a standard keyword
Dec 15 09:48:44 <ynezz> and https://github.com/sbyx/hnetd/blob/c43766610ed30194b048bc070a3c433aec731c40/src/udp46_i.h#L20
Dec 15 09:48:47 <mangix> https://en.cppreference.com/w/c/language/attributes/maybe_unused
Dec 15 09:48:49 <ynezz> so have fun
Dec 15 09:49:40 <jow> maybe rename it to ___unused :P
Dec 15 09:50:00 <ynezz> ____unsed to be future proof
Dec 15 09:50:02 <mangix> GCC 10 supports [[maybe_unused]] in C. cool.
Dec 15 09:50:07 <rsalvaterra> Wait, C23? That's 3 years from now. :P
Dec 15 09:50:08 <jow> or __almost_unused
Dec 15 09:50:26 <mangix> clang 11 does not
Dec 15 09:50:34 <jow> __supposedly_unused works too :)
Dec 15 09:50:59 <rsalvaterra> __used_when_the_compiler_isnt_looking
Dec 15 09:52:07 <rsalvaterra> So, it's an upstream hnetd bug, fortunately.
Dec 15 09:52:21 <mangix> hmmm
Dec 15 09:52:28 <mangix> C23 does not go far enough
Dec 15 09:56:52 <mangix> anyone have GCC9 installed?
Dec 15 09:57:27 <rsalvaterra> GCC 10, here.
Dec 15 09:57:44 <rsalvaterra> I like to live dangerously.
Dec 15 09:58:22 <mangix> bah, does not compile with GCC8
Dec 15 10:01:26 <rsalvaterra> Bump it! :D
Dec 15 10:01:44 <mangix> rsalvaterra: openwrt toolchain is GCC8
Dec 15 10:02:00 <rsalvaterra> Yeah, I know.
Dec 15 10:02:35 <rsalvaterra> Did it compile with GCC 9?
Dec 15 10:02:46 <mangix> I don't have GCC9
Dec 15 10:02:56 <ynezz> CI builds with gcc 8,9,10
Dec 15 10:02:58 <ynezz> -- The C compiler identification is GNU 8.4.0
Dec 15 10:03:21 <ynezz> https://gitlab.com/openwrt/project/libubox/-/jobs/907782381
Dec 15 10:05:46 <mangix> ynezz: I'm talking about [[maybe_unused]] in C.
Dec 15 10:05:59 <ynezz> that wasn't clear
Dec 15 10:09:40 <mangix> hmm auto didn't make it in C23
Dec 15 10:09:42 <mangix> unfortunate
Dec 15 10:13:21 <rsalvaterra> Totally unrelated, is it normal to see package dependency problems when only the packages feed is selected? :/
Dec 15 10:14:16 <rsalvaterra> It doesn't seem right to have packages depending on LuCI stuff… should be the other way around, no?
Dec 15 10:16:01 <mangix> rsalvaterra: giff example pl0x
Dec 15 10:16:55 <rsalvaterra> mangix: https://paste.debian.net/1176960/
Dec 15 10:18:10 <mangix> most of these are from the routing repo
Dec 15 10:18:24 <mangix> What was supposed to happen was routing merging with packages
Dec 15 10:18:31 <mangix> but that got abandoned at some point
Dec 15 10:19:36 <rsalvaterra> Oh, well. It's ugly, but I can live with it. :P
Dec 15 10:20:03 <rsalvaterra> I don't need the routing feed (yet, at least).
Dec 15 10:56:37 <mangix> jow: can you checkhttps://patchwork.ozlabs.org/project/openwrt/list/?series=220501 ?
Dec 15 12:23:41 <Hauke> ynezz: thanks
Dec 15 13:09:46 <nbd> Hauke: btw. feel free to drop 300-mac80211-optimize-skb-resizing.patch in your updates
Dec 15 13:10:27 <nbd> i'll re-do it and post it upstream before we merge the mac80211 updates to master
Dec 15 13:23:12 <Hauke> nbd: ok thanks
Dec 15 13:23:25 <Hauke> I haven't seen a problem when testing it
Dec 15 13:23:48 <nbd> functionally your adjustment looks fine
Dec 15 13:24:07 <Hauke> nbd: the change from Johannes was also backported to 4.19 and I would like to add the security updates to the 19.07 stable branche
Dec 15 13:24:07 <nbd> just needs to be re-done for upstream
Dec 15 13:24:29 <Hauke> ok
Dec 15 13:25:02 <nbd> i'm currently working on 802.11->802.3 decap offload
Dec 15 13:25:07 <nbd> will try to take care of that patch afterwards
Dec 15 13:25:52 <Hauke> ok
Dec 15 13:26:45 <Hauke> should it then be possible to forward traffic between the Ethernet and the Wifi without the CPU seeing it?
Dec 15 13:27:12 <nbd> i will work on that as well
Dec 15 13:27:58 <nbd> pablo will send our work on NAT offload (with my rewritten driver for MTK) upstream soon
Dec 15 13:28:21 <Hauke> nice
Dec 15 13:28:30 <nbd> once that's in the tree, i can build on that for eth<->wifi offload
Dec 15 13:29:03 <nbd> it will be supported for mt7622 on the SoC side and 7915 for wifi
Dec 15 13:29:15 <nbd> maybe also 7615 later, not sure how much offload that one supports
Dec 15 13:30:04 <Hauke> ok
Dec 15 13:30:17 <nbd> either way, 7915 will be the first wifi chip to have upstream eth<->wifi offload support
Dec 15 13:30:30 <Hauke> mt7622 should normally be fast enoght to do this in SW
Dec 15 13:30:55 <nbd> for 1500 byte sized packets, the difference between SW and HW is small
Dec 15 13:31:04 <nbd> for smaller packets, offload will help
Dec 15 13:31:08 <Hauke> ok
Dec 15 13:31:53 <nbd> sw performance is currently around 1700-1800 mbit/s under ideal conditions
Dec 15 13:32:10 <nbd> but still lower when sending to more stations at the same time
Dec 15 13:32:27 <nbd> not sure how much of that is sw limitation
Dec 15 13:33:05 <Hauke> 1800MBit/s with 4x4 160 Mhz?
Dec 15 13:33:14 <nbd> 4x4 80 MHz
Dec 15 13:33:26 <nbd> or 2x2 160 MHz
Dec 15 13:33:41 <Hauke> ok
Dec 15 13:35:56 <rsalvaterra> nbd: You mean encapsulation offloading?
Dec 15 13:36:25 <nbd> rsalvaterra: nope
Dec 15 13:36:30 <nbd> encap offload is already done
Dec 15 13:36:34 <nbd> so i'm working on decap now
Dec 15 13:37:07 <rsalvaterra> Hm… interesting.
Dec 15 13:37:32 <rsalvaterra> Yeah, I know ath10k does encap already, at least for some chips.
Dec 15 13:38:17 <nbd> the hw supports it, not sure how much of the code for it is upstream
Dec 15 13:38:33 <nbd> when i worked on the patch, only ath11k had upstream support
Dec 15 13:39:04 <rsalvaterra> But if MT7615 could be supported, it would be really great, since a lot of them are still paired with the underpowered MT7621.
Dec 15 13:42:00 <rsalvaterra> Ah, this is the ath10k series I remember having seen: https://marc.info/?l=linux-wireless&m=157648814518693&w=4
Dec 15 13:43:53 <Hauke> the first mt7915 devices I saw are also using mt7621
Dec 15 13:44:20 <Hauke> the first mt7621 + mt7915 device is on amazon in Germany
Dec 15 13:44:41 <rsalvaterra> Oh, my…! Well, if it's 2x2:2, it should be usable, I guess…
Dec 15 13:47:52 <rsalvaterra> … but from a cursory search, it seems to be 4x4:4. :/
Dec 15 13:52:06 <Hauke> http://lunarius.fe80.eu/blog/openwrt-d-link-x-1860-mt7915-ax.html
Dec 15 13:52:11 <Hauke> 2x 2x2
Dec 15 13:56:51 <rsalvaterra> Ok, that's better. :)
Dec 15 13:56:54 <rsalvaterra> Thanks!
Dec 15 14:15:32 <russell--> someone is asking me to send them images for ubnt-bullet-ac, would maybe be better if someone reviewed and applied my patch: https://patchwork.ozlabs.org/project/openwrt/patch/87mtylzzdh.fsf@husum.ptp/
Dec 15 14:46:01 <Nick_Lowe> https://github.com/WLAN-Pi/profiler
Dec 15 14:46:07 <Nick_Lowe> We should port this in to OpenWRT IMO
Dec 15 14:47:36 <Nick_Lowe> The ultimate goal being to be able to show the capabilities of the connected clients in both the CLI and in LuCI - by port, I mean the concept
Dec 15 15:43:48 <karlp> I've got a package that compiles on master-ath79, but not on master-sunxi? it's like the paths are different? where does the <target>/usr/lib -L paths come in from? https://paste.jvnv.net/view/8ghmN
Dec 15 15:50:04 <karlp> even for the mips-master, where it says "skipping incompatible" I don't see where it gets the target/usr/lib path to even link with the "right" one at all.
Dec 15 15:53:20 <karlp> (I know it's gross having these "extra" .so's there at all, but it works on mips, and has been working for at least 7 years or so, so curious why it's failing now on sunxi)
Dec 15 16:16:03 <dengqf6> nbd: Hauke: what about mt7621?
Dec 15 18:21:34 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.2% images and 97.1% packages reproducible in our current test framework.)
Dec 15 18:32:19 <Hauke> jow: I found this memory leak in jsonfilter: https://pastebin.com/1MU6asrg
Dec 15 18:32:28 <Hauke> the strdup for string and lable is not freed
Dec 15 18:34:19 <Hauke> I also found this use after free bug in logd when I run logread while new data is written: https://pastebin.com/3y4MZq59 the error message deos not look so nice
Dec 15 18:36:02 <Hauke> here a cleaned up version of the error: https://pastebin.com/GHnDhX8e
Dec 15 19:37:37 <rr123> karlp: do you know what ubus_noauth option for uhttpd for? "do not authenticate json-rpc requests against ubus session api?", what does this mean
Dec 15 21:12:24 <philipp64> If anyone is interested (talking about you, karlp, ;-) ) I’ve added glue to ISC-DHCP so that the dhcpd server updates bind with local DNS information… https://github.com/openwrt/packages/pull/14240
Dec 15 21:22:17 <karlp> I'm really not :)
Dec 15 21:22:36 <karlp> rr123: no idea, git blame, and then ask that person to update the docs?
Dec 15 21:24:01 <rmilecki> dwmw2_gone: i just got bounce from the linux-arm-kernel@lists.infradead.org
Dec 15 21:24:13 <rmilecki> dwmw2_gone: Response: 550-5.1.1 The email account that you tried to reach does not exist.
Dec 15 21:24:20 <rmilecki> i don't think it's expected
Dec 15 21:24:50 <dwmw2_gone> Can you forward it to me?
Dec 15 21:24:58 <dwmw2_gone> It came from one of *my* servers?
Dec 15 21:26:31 <dwmw2_gone> That looks a bit like a sendmail message, perhaps misdirected to you instead of the list when a *recipient* failed to receive it?
Dec 15 21:41:37 <rmilecki> dwmw2_gone: i thought you handle whole lists.infradead.org
Dec 15 21:43:54 <rmilecki> dwmw2_gone: i sent you .eml of respnse I got, sorry if it's not you who I should ping
Dec 15 21:44:38 <rmilecki> oh, now my e-mail didn't reach the dwmw2@
Dec 15 21:44:43 <Nick_Lowe> Can wireless-regdb be updated so that can U-NII-3 channels can be used at a 200 mW EIRP in the UK?
Dec 15 21:45:19 <rmilecki> 550 Verification failed for <zajec5@gmail.com> Previous (cached) callout verification failure Sender verify failed
Dec 15 22:16:48 <jow> rr123: it means that the ubus http interface will be wide open, anyone can execute all methods using any random faked sessions id
Dec 15 22:17:11 <jow> rr123: it is a debugging feature, don't enable it unless you develop something
Dec 15 22:17:19 <philipp64> jow: that doesn’t sound good.
Dec 15 22:18:19 <philipp64> jow: so, is it correct that there’s no way to force one start script to only run after another one (on which it depends) has finished initializing?
Dec 15 22:19:29 <jow> philipp64: well there are way, but since the system can't possibly know how "finished initializing" is defined for any potential service, you need to implement this yourself, e.g. by sending a signal or hotplug event
Dec 15 22:20:03 <philipp64> hm….
Dec 15 22:20:09 <philipp64> any good examples to follow?
Dec 15 22:20:20 <philipp64> it’s Bind and ISC-DHCP(D) in this case.
Dec 15 22:25:25 <jow> well you could simply call /etc/init.d/whatever start when the other thing is finished
Dec 15 22:25:39 <jow> and make /etc/init.d/whatever's boot() method a no-op
Dec 15 22:26:10 <jow> or run /sbin/hotplug-call whatever  potentially with env vars carrying auxiliary info
Dec 15 22:26:37 <jow> thne have an /etc/hotplug.d/whatever/01-blah  which invokes /etc/init.d/qrx restart
Dec 15 22:30:56 <karlp> at boot, things run boot() if defined, or start() if not defined?
Dec 15 22:31:11 * karlp didnt' know you could have things enabled, but not startted at boot. that sounds useful
Dec 15 22:32:22 <jow> yes
Dec 15 22:33:16 <philipp64> jow: that can’t work (the boot/start) thing because it’s legitimate to use Bind both with and without isc-dhcp(d).
Dec 15 22:34:55 <philipp64> Is Bjorn Mork in this channel?
Dec 15 22:37:58 <dwmw2_gone> rmilecki: 2020-12-15 21:22:46 +0000 H=mail-lf1-x141.google.com [2a00:1450:4864:20::141] sender verify fail for <zajec5@gmail.com>: gmail-smtp-in.l.google.com [2607:f8b0:4001:c07::1b] : SMTP error from remote mail server after RCPT TO:<zajec5@gmail.com>: 550-5.1.1 The email account that you tried to reach does not exist. Please try\n550-5.1.1 double-checking the recipient's email address for typos or\n550-5.1.1 unnecessary spaces. Learn
Dec 15 22:37:59 <dwmw2_gone> more at\n550 5.1.1  https://support.google.com/mail/?p=NoSuchUser 133si57999ilb.142 - gsmtp
Dec 15 22:38:15 <philipp64> jow: … unless there’s some cleverness that I’m missing.
Dec 15 22:38:37 <dwmw2_gone> a minute earlier...
Dec 15 22:38:39 <dwmw2_gone> 2020-12-15 20:21:22 +0000 1kpGoC-0007Z9-6L => zajec5@gmail.com R=lookuphost T=verp_smtp H=gmail-smtp-in.l.google.com [2a00:1450:400c:c09::1b] X=TLSv1.3:TLS_AES_256_GCM_SHA384:256 CV=yes K C="250 2.0.0 OK s1si21331354wrv.266 - gsmtp"
Dec 15 22:39:07 <dwmw2_gone> and even later...
Dec 15 22:39:10 <dwmw2_gone> 2020-12-15 21:52:06 +0000 1kpIAj-0008Jm-B3 => zajec5@gmail.com R=lookuphost T=verp_smtp H=gmail-smtp-in.l.google.com [2607:f8b0:4001:c07::1a] X=TLSv1.3:TLS_AES_256_GCM_SHA384:256 CV=yes K C="250 2.0.0 OK q18si17282387iog.68 - gsmtp"
Dec 15 22:39:10 <dwmw2_gone> 2020-12-15 22:07:35 +0000 1kpIQz-0001Cc-DP ** zajec5@gmail.com R=lookuphost T=verp_smtp H=gmail-smtp-in.l.google.com [2607:f8b0:4001:c07::1b] X=TLSv1.3:TLS_AES_256_GCM_SHA384:256 CV=yes: SMTP error from remote mail server after RCPT TO:<zajec5@gmail.com>: 550-5.1.1 The email account that you tried to reach does not exist. Please try\n550-5.1.1 double-checking the recipient's email address for typos or\n550-5.1.1 unnecessary spaces. Learn
Dec 15 22:39:10 <dwmw2_gone> more at\n550 5.1.1  https://support.google.com/mail/?p=NoSuchUser y26si182194jas.84 - gsmtp
Dec 15 22:39:17 <dwmw2_gone> some Google mail servers work, others deny that you exist.
Dec 15 22:45:45 <zorun> ah, I've seen that this evening
Dec 15 22:46:02 <zorun> replying to somebody with a gmail address and getting "this user does not exist"
Dec 15 22:46:15 <zorun> I guess they still have some broken stuff
Dec 15 22:48:00 <philipp64> jow: question for you… my Bind logs keep filling up with warnings about “Permission denied” when local clients try to do IPv6 lookups (AAA) of domains because my “wan” connection is IPv4 only… Does it make sense to detect whether IPv4 or IPv6 (or both) are configured on “wan”, and pass “-4”, “-6”, or neither (aka “both”) as flags to “named” on startup?
Dec 15 22:48:39 <philipp64> I’m happy to do the PR if it’s the right thing to do.
Dec 15 22:49:51 <jow> why can't those queries be simply forwarded as IPv4 ?
Dec 15 22:50:30 <jow> I bind not doing the standard try-IPv6-fallback-to-IPv4 thing that most clients do nowadays?
Dec 15 22:50:54 <dwmw2_gone> I don't even understand what's going on there
Dec 15 22:51:14 <dwmw2_gone> I can't answer the question "what is the IPv6 address of foo.example.com" because the client isn't asking *over* an IPv6 connection?
Dec 15 22:51:16 <dwmw2_gone> That seems insane.
Dec 15 22:51:37 <philipp64> regarding smtp or Bind?
Dec 15 22:52:03 <dwmw2_gone> smtp is simple enough. Here's a nickel, kid. Get yourself a decent mail server.
Dec 15 22:52:09 <dwmw2_gone> I meant bind.
Dec 15 22:53:00 <zorun> more likely bind tries to reach root servers or other NS servers over IPv6, irrespective of the actual queries
Dec 15 22:53:22 <dwmw2_gone> so? It'll then fall back to Legacy IP if it can't reach them over IPv6.
Dec 15 22:53:25 <jow> permission denies likely comes from the local ip policies then
Dec 15 22:53:39 <dwmw2_gone> That still has *nothing* to do with whether it was a TXT, NS, A, or AAAA record being queried.
Dec 15 22:54:05 <dwmw2_gone> We should note, however, that this month marks the 25th anniversary of RFC1883. A full quarter of a century since IPv6 was published.
Dec 15 22:54:45 <dwmw2_gone> I propose a full overhaul of our documentation to make sure we refer to "Legacy IP" consistently.
Dec 15 22:56:04 <Borromini> :P
Dec 15 22:56:53 <jow> philipp64: do you get "permission denied" as well when you try to ping6 2001:4860:4860::8888 ?
Dec 15 23:03:29 <philipp64> Why give an address for an EXTERNAL entity that’s not reachable?
Dec 15 23:03:46 <dwmw2_gone> what makes you think it's not reachable?
Dec 15 23:03:52 <philipp64> jow: affirmative
Dec 15 23:03:53 <dwmw2_gone> Client devices can't have tunnels of their own?
Dec 15 23:03:54 <dwmw2_gone> VPNs?
Dec 15 23:04:04 <dwmw2_gone> split routing?
Dec 15 23:04:22 <philipp64> okay, so what’s the solution to making the “Permission denied” go away?
Dec 15 23:04:34 <zorun> use dnsmasq like everybody else? :-)
Dec 15 23:05:12 <dwmw2_gone> or join us in the 21st century and have IPv6 on your wan :)
Dec 15 23:05:21 <dwmw2_gone> quarter of a century...
Dec 15 23:05:34 <mangix> philipp64: I get replies from that address
Dec 15 23:05:35 <philipp64> dwmw2_gone: not my choice… talk to my ISP.
Dec 15 23:05:47 <dwmw2_gone> You talk to your ISP. Or better still, talk to a better ISP :)
Dec 15 23:05:59 <mangix> 2001 is tunneled, no?
Dec 15 23:06:09 <dwmw2_gone> More seriously, work out where the error is coming from
Dec 15 23:06:21 <dwmw2_gone> if it's just that you don't have a route, you shouldn't get -EPERM.
Dec 15 23:06:55 <dwmw2_gone> If bind is spamming the logs with that, it sounds like a bind bug
Dec 15 23:06:58 <dwmw2_gone> or misconfiguration
Dec 15 23:08:58 <jow> philipp64: what is reported by "ip route get 2001:4860:4860::8888" ?
Dec 15 23:09:24 <jow> that permission denied is an OpenWrt ip policy rule
Dec 15 23:09:39 <jow> it applies to IPv6 traffic that is sent with a wrong source prefix
Dec 15 23:10:11 <jow> to prevent sending ULA or upstream-foreign prefixes out
Dec 15 23:16:26 <jow> lots of gmail bounces
Dec 15 23:16:54 <jow> let's see how many subscriptions will be suspended due to this
Dec 15 23:18:19 <rsalvaterra> As far as side-channel attacks are concerned, this one is *neat*…! https://www.zdnet.com/article/academics-turn-ram-into-wifi-cards-to-steal-data-from-air-gapped-systems/
Dec 16 00:22:12 <f00b4r0> rsalvaterra: looks cute, but I'm reading this as another one of these "exploits" that prerequisite physical access to the target device (arguably non-root in the present case, still...) ;P
Dec 16 00:37:59 <rsalvaterra> Yeah, it's not too practical, but the idea is neat. :)
Dec 16 01:04:44 <dorf> nation state level practical. think natanz.
Dec 16 01:05:00 <dorf> ironic that the israelis developed the exploit...
Dec 16 02:08:25 <philipp64> jow: RTNETLINK answers: Permission denied
**** ENDING LOGGING AT Wed Dec 16 02:59:56 2020