**** BEGIN LOGGING AT Wed Mar 04 02:59:57 2020 Mar 04 07:47:53 is there something in OpenWrt (netifd?) that may be adding ff02::2 multicast entry to network interface when bringing interface up/down? Mar 04 07:49:06 when deleting wireless monitor interface after 10 x "ifconfig up && ifconfig down" I can see kernel removing list of multicast addresses each of them for ff02::2 address Mar 04 07:49:46 it's regarding my upstream netdev@ report "Regression: net/ipv6/mld running system out of memory (not a leak)" Mar 04 08:06:35 rmilecki: probably odhcpd? Mar 04 08:07:52 https://lxr.openwrt.org/ident?i=ALL_IPV6_ROUTERS Mar 04 08:58:57 ynezz: i stopped odhcpd, repeated my test, kernel still got multiple ff02::2 entries, so I assume it's some different issue :/ Mar 04 08:59:40 stopping netifd & repeating test - same result Mar 04 09:10:46 any reason this isn't merged yet? https://github.com/openwrt/packages/pull/11468 Mar 04 09:26:28 russell--: I've hit the green button, didn't test it though Mar 04 09:28:33 ynezz: rpcd is *not* exposed to the network Mar 04 09:28:47 it is not even exposed to tcp at all Mar 04 09:29:05 jow: *facepalm* :) Mar 04 09:29:32 but it's reachable over network via ubus Mar 04 09:29:40 via uhttpd-mod-ubus Mar 04 09:30:04 and there only via forced json conversion Mar 04 09:30:28 ubus itself has no network transport Mar 04 09:31:16 ok, I've screwed this, just remembering crashing rpcd with some json input during those libubox fixes Mar 04 09:33:58 I've already all of that paged out, just vaguely remember, that rpcd was reachable over network (sessions?) Mar 04 09:34:17 in default install on 19.07.0 at that time (or some rc) Mar 04 09:35:18 it is reachable via http://.../ubus in case uhttpd-mod-ubus is installed (not the default) or via http://.../cgi-bin/luci/admin/ubus (default) Mar 04 09:35:32 the latter emulates uhttpd-mob-ubus in Lua code Mar 04 09:36:00 I just remember, that I've looked at the respawn param exactly for this reason Mar 04 09:36:24 and found out, that it was ok at that time (5 restarts max) Mar 04 09:36:38 it takes incoming http requests, parses the body json and invokes ubus via libubus Mar 04 09:37:45 crashes were tirggered by libuox json formatter iirc Mar 04 09:37:54 not related to rpcd Mar 04 09:38:15 jow: thanks! Mar 04 09:38:54 jow: right, rpcd has no CI/fuzzing yet, it's on my todo list Mar 04 09:39:04 anyhow, if you think removing respawn is safer then by all means remove it Mar 04 09:39:11 I have no opinion on iot Mar 04 09:40:14 I don't have strong opinion either and I might be wrong as well Mar 04 09:41:19 BTW that part about '[threshold, timeout, retry]' is correct? Mar 04 09:41:34 I've looked only at the code, didn't tried it yet Mar 04 09:47:20 if respawn_threshold is 0, respawn_count will never increase or rather is always set to 0 Mar 04 09:47:36 so it will never exceed respawn_retry Mar 04 09:47:52 and thus have the same effect as respawn_retry == 0 Mar 04 09:47:58 assuming a default of 5 Mar 04 09:49:12 https://lxr.openwrt.org/source/procd/service/instance.c#L616 Mar 04 09:50:01 unless runtime can become negative (which is impossible due to the use of the monotonic clock), it will never be lower than respawn_threshold=0 Mar 04 09:54:59 I wasn't probably clear, if someone sets respawn_retry=3 it will set respawn_treshold=3, not respawn_retry=3 as intended Mar 04 09:55:29 you both may want to follow up on the list to clarify :) Mar 04 09:55:45 it's faster here :p Mar 04 09:56:07 (and more convenient) Mar 04 10:13:05 ynezz: I don't follow, sorry Mar 04 10:14:17 ah you mean that variable thing? I simply ignored that Mar 04 10:14:43 its one of these random uci options nobody ever will use besides the original author Mar 04 10:37:04 * ldir debates going to investigate who is the original author - but thinks better of the idea :-) Mar 04 11:14:02 ldir: are you still looking after dnsmasq? Mar 04 11:14:24 maybe this is interesting to you: https://forum.openwrt.org/t/dnsmasq-full-crashing/56857 Mar 04 11:32:29 ha, dnsmasq, takes aim at both feet and hits 'fire'. Mar 04 11:33:17 the fact that this DNS-over-whatever is still such a brittle endeavour does not exactly inspire confidence Mar 04 11:34:07 but maybe it helped uncover some dnssec implementation bugs in dnsamsq Mar 04 11:35:47 Ok, to try and distill this down - there are circa 140 patches between dnsmasq 2.80 and 2.81rc1 (released yesterday) - there are fixes for dnssec, tcp, all sorts in there. Mar 04 11:36:53 I have been running dnsmasq git head ever since git head moved from 2.80 Mar 04 11:38:24 on another irc chat, I anecdotally have seen some comments that cloudfare broke stuff today. Mar 04 11:38:49 wouldn't be the first time :) Mar 04 11:39:55 any more feedback on this (v3 of the rfc patch)? http://patchwork.ozlabs.org/patch/1244877/#2373864 Mar 04 11:42:53 I don't really want to get into backporting dnssec related patches from HEAD. Mar 04 11:43:21 ldir: can understand that. Maybe bump to 2.81rc1 in master? Mar 04 11:43:25 its master after all Mar 04 11:45:39 When I get a successful build out of my 'not buildbot' with 2.81rc1 I'll move forward on that idea. Mar 04 11:46:41 My 'not buildbot' found an error which I fixed and was accepted upstream... but now I seem to have the same error again... so investigating. Mar 04 11:46:51 at least the 'not buildbot' has been useful :-) Mar 04 11:47:12 'not buildbot' is a bit bulk... what about 'macbot'? ;) Mar 04 11:48:05 *bulky Mar 04 11:54:03 lol - macbot - like it! early lunch, mrs ldir working today so lunch before she goes to work Mar 04 12:50:20 * ldir renames macmini runner to macbot - clears cache and restarts dnsmasq update related build Mar 04 12:53:56 anyone who knows if Freescale T1042 is any good? my client is phasing out their datacenter and they have 2 hw firewalls based on that Mar 04 12:57:33 stintel, i'll have one if you don't mind :p Mar 04 12:59:08 hehe Mar 04 14:27:06 how do i get the ssh clients (dropbear) public key on openwrt? Mar 04 14:27:54 its not under ~/.ssh/id_rsa.pub like usual Mar 04 14:29:47 thats what i would have thought Mar 04 14:29:48 JyZyXEL: /etc/dropbear/authorized_keys Mar 04 14:30:21 stintel: wrong. it was actually: "dropbearkey -y -f /etc/dropbear/dropbear_rsa_host_key" Mar 04 14:31:01 that's not what you asked, that's the SSH host key Mar 04 14:32:04 that's not the key that root ssh client uses? Mar 04 14:33:12 no, that's the host key dropbear offers to the client when the client connects Mar 04 14:33:32 the one that is saved in .ssh/known_hosts Mar 04 14:34:02 i want the key that openwrt ssh client offers to the server Mar 04 14:34:44 I think you are looking for the private key then - this is only kept on the client Mar 04 14:34:55 so if you lost that you'll have to generate a new pair Mar 04 14:35:31 well im looking for the key that would usually be under "~/.ssh/id_rsa.pub", but openwrt doesn't have that Mar 04 14:36:29 you want to initiate SSH from OpenWrt and use a key for authentication? Mar 04 14:36:37 yes Mar 04 14:36:40 ahh Mar 04 14:37:17 JyZyXEL: generate the key somewhere else, embedded devices usually don't have good entropy Mar 04 14:38:48 you'd use dropbearkey for that Mar 04 14:38:48 but if you use dropbearkey it will only write the private key to a file and display what would be in ~/.ssh/id_rsa.pub on stdout Mar 04 14:39:08 the line after "Public key portion is:" Mar 04 14:39:41 simply pasting that line to servers authorized_keys and then using "ssh" didn't make the key work Mar 04 14:40:47 JyZyXEL: generate it with "dropbearkey -y -f .ssh/id_dropbear" Mar 04 14:40:47 the openwrt device will need to have the private key then obviously ... i think .ssh/id_dropbear is customary ... idk tho Mar 04 14:41:07 dropbear ssh client looks for the private key in .ssh/id_dropbear Mar 04 14:41:09 ssh -h Mar 04 14:41:14 it's explained there Mar 04 14:41:48 this kind of question belongs in #openwrt btw Mar 04 14:42:12 i see Mar 04 20:25:58 hmm... I've got suddenly dnsmasq segfaulting on one of my x86 routers.. I do use dns over https and acme too would that ever matter anything.. but I'm at loss why Mar 04 20:26:04 Wed Mar 4 22:24:51 2020 kern.info kernel: [15114.631628] dnsmasq[13617]: segfault at 0 ip 000055f3e3406495 sp 00007ffc7725fe90 error 4 in dnsmasq[55f3e33e0000+36000] Mar 04 20:26:04 Wed Mar 4 22:24:51 2020 kern.info kernel: [15114.632994] Code: ff 48 85 c0 74 20 83 bc 24 80 00 00 00 00 75 16 48 8b 84 24 88 00 00 00 66 c7 00 05 00 48 83 84 24 88 00 00 00 02 48 8b 55 30 <66> 83 3a 02 75 19 48 83 c2 04 48 8d 0d a6 58 01 00 bf 80 00 40 08 Mar 04 20:26:19 OpenWrt SNAPSHOT r11929-2e3cf4500b Mar 04 20:26:30 it either restarts automatically, or crashloops 6 times and stops Mar 04 20:26:51 at few second itnerval all the way up to working hours at a time Mar 04 20:36:58 https://forum.openwrt.org/t/dnsmasq-full-crashing/56857/9 Mar 04 21:13:13 ldir: hm.. sounds awfully similar, or kinda spot on... "from all the things..." =D Mar 04 21:14:53 I have just pushed a bump to 2.81rc1 into master. Mar 04 21:15:36 it's been 18+ months since 2.80 was released. Mar 04 21:16:02 jow: also you are quite correct on the forum thread.. it is worrysome that dnsmasq can crash like that... but I would'nt care to "manuall" admin say bind or some other thing that would need even more manual setup for rest of networking in general =) Mar 04 21:17:05 openwrt has a 2.80 + some backported patches.. I have a feeling that because we've *some* of the backports, but not all 140+ patches, that openwrt is more exposed to the problem. Mar 04 21:17:37 It would be interesting to know if vanilla 2.80 is subject to the problem. Mar 04 21:17:57 s/interesting/useful Mar 04 21:18:57 * ldir says this before the usual mantra of 'dnsmasq is crap' erupts Mar 04 21:20:08 haha Mar 04 21:20:20 it works. most of the time. Mar 04 21:20:57 shit happends aand then you die, that is at least sure Mar 04 21:21:20 ldir: For what it is worth, I've been running 2.80 on my homebrew Linux router since it was released and haven't had any issues. Mar 04 21:21:41 (However, I only use it for DHCP and local DNS, non-local DNS goes through Unbound.) Mar 04 21:25:08 I'm happy an trigger is found and fix being deployed (cloudflare)... Sure we could always bark at dnsmasq but why? unless we see openwrt to switch default to something else totally, all at least I can do is to wait and occasionally ofcourse update system Mar 04 23:09:57 olmari: I also saw a crash in my log and I hope I fixed it some time ago: https://git.openwrt.org/414d0541381d432e69190f394dfe2a6e8122d6bb Mar 04 23:10:39 olmari: it was added in r11925-414d0541381d Mar 04 23:13:28 Mm :) Mar 04 23:13:53 I also think it is dangerous to have only some of the patches backported Mar 04 23:16:50 Yeah, sometimes cherry-picking is wrong way Mar 04 23:41:12 so, did this "new" pkg-conf get merged in then? because it seems to be breaking things for no good reason: https://github.com/openwrt/packages/pull/11507 **** ENDING LOGGING AT Thu Mar 05 02:59:56 2020