01:33:28 <selsta> .merges
01:33:28 -xmr-pr- 7086 7098 7099 7161
02:09:58 <selsta> .merge+ 7175 7176
02:09:58 <xmr-pr> Added
07:06:30 <ziyzhou[m]> v0.17.1.7 is being killed due to OOM after running several hours. Is it a known issue? Never seen this in previous version.
07:57:16 <selsta> ziyzhou[m]: do you run a public rpc node?
07:57:48 <selsta> also how much RAM does your system have?
08:26:54 <ragn4> .network
10:07:09 <ErCiccione[m]> I wrote in monero but i think it fits here too: I'm spinning another node and i used --add-priority-node to point to another node of mine which is fully synced and doesn't have problems (at least afaict).
10:08:01 <ErCiccione[m]> The problem is that this node gets automatically banned by my syncing node. It's the only node that it's getting banned as far as i can see.
10:09:03 <ErCiccione[m]> Ok. Right now my node blocked another node too
10:18:21 <selsta> ErCiccione[m]: are both nodes on the same network?
10:18:49 <selsta> hmm, can you run with --log-level 1 and check what they are getting banned for exactly?
10:19:53 <ErCiccione[m]> same network -> yes. I started to sync with add-exclusive-node pointing at the same node.
10:19:55 <ErCiccione[m]> sure
10:20:33 <ErCiccione[m]> alright, let's see if i catch it
10:33:42 <andreasromer> Will you HODL Monero or dump it for Tari when it comes out?
11:05:09 <ziyzhou[m]> selsta: yes, public node, 2G RAM.
11:09:52 <selsta> ziyzhou[m]: 2GB might be not enough for a public rpc node, a regular node should be fine with 2GB RAM
11:10:11 <selsta> also there currently seems to be some DoS attack against public rpc nodes which can cause higher CPU usage
11:13:18 <selsta> v0.17.1.8 should have mitigations against the current DoS attack
11:14:07 <ziyzhou[m]> ok
13:32:34 <selsta> .merge+ 7172
13:32:34 <xmr-pr> Added
14:26:09 <ErCiccione[m]> ¯\_(ツ)_/¯ no more bans
14:42:35 <coffeeroaster> I got the gui and CLI wallets compiled and running on the Raspberry PI 4 (64 bit) by disabling hardware AES. Any drawbacks (besides slow mining) that I should be aware of?
14:55:30 <moneromooo> None that I can think of.
14:56:11 <moneromooo> Note thatn you do a little bit of that mining when verifying txes.
14:56:36 <coffeeroaster> at the impressive rate of 40 hash/sec
14:58:20 <coffeeroaster> moneromooo: good to know thanks!
15:00:20 <coffeeroaster> What's the best way to get involved with development?
15:19:10 <moneromooo> You could look at github issues and see if you like anything there.
15:19:20 <moneromooo> Then discuss here or there.
15:19:48 <moneromooo> The best way to get into a project is to see something that annoys you and fix it.
15:20:23 <moneromooo> Though of course it has to not go agianst the project's goals. Like, for an extreme example, say you're annoyed you can't see amounts on a block explorer, you don't get to fix it :)
15:21:11 <moneromooo> Or you could list what you're good at, what you like doing, and people here might have ideas for you.
15:24:08 <coffeeroaster> moneromooo: thanks! I'll take a look. C/C++, system stuff is my bg.
15:26:20 <moneromooo> Expand on system ?
15:31:11 <coffeeroaster> general OS unix/linux/kernel internals
15:32:34 <moneromooo> Familiar with network ?
15:33:23 <coffeeroaster> moneromooo: that too but more from a VOIP perspective (NAT/TURN) etc.
15:37:21 <moneromooo> One longstanding thing we've been needing is someone who groks networks well to improve the DoS resistance of our net code.
15:38:06 <coffeeroaster> sounds interesting. Do you have any bg info I can read on the issue?
15:38:49 <coffeeroaster> I'm assuming this is beyond the blacklisting support added recently?
15:38:51 <moneromooo> Hackerone entries I think.
15:39:27 <coffeeroaster> do you have a link?
15:39:43 <moneromooo> Yes, I'm thinking mostly of things like QoS, connection timeouts based on in/out traffic (ie, slowloris type of attacks), etc.
15:41:34 <moneromooo> Hmm. The search thing on hackerone doesn't seem to work (or needs JS maybe).
15:41:48 <moneromooo> Anyway, there wasn't much really IIRC.
15:43:08 <coffeeroaster> so something like maintain an active table of existing connections and when something seems wonky have a real-time reaction (block, etc.) ?
15:44:09 <moneromooo> We have a drop/block system. It's more about tuning detection of what looks wonky.
15:44:40 <moneromooo> Like, for example, I have a connection timeout, and extend it for every byte received.
15:45:00 <coffeeroaster> ok I see. better detectors
15:45:01 <moneromooo> But it's crude, and I don't think it's actually effective.
15:45:42 <moneromooo> So someone with network experience would already know what works, what doesn't, how to tune these things so false positives are minimized, etc.
15:45:47 <coffeeroaster> Can you point me to the code that does that?
15:45:54 <moneromooo> abstract_tcp_server2.inl mostly
15:46:14 <moneromooo> Warning: this file has lots of random tabs in for some reason, so it looks bad.
15:48:28 <coffeeroaster> sounds like a test suite of simulating a bunch of attacks could be useful. (Or maybe it already exists?)
15:48:40 <moneromooo> It doesn't really.
15:50:46 <coffeeroaster> ok sounds interesting. I've got the code checked out. I'll take a look later today when I have some time.
15:52:40 <moneromooo> Cool, thanks :)
15:53:01 <sethsimmons> <coffeeroaster "ok sounds interesting. I've got "> Great to have someone new jumping in, welcome coffeeroaster :)
15:53:23 <coffeeroaster> sethsimmons: thanks!
16:17:30 <donkeydonkey[m]> i was just thinking that a test suite of attacks and other such would be cool to have... to test code and also to test new nodes and such...
21:07:05 <hyc> #6262 sounds like RNG running out of entropy
21:08:27 <moneromooo> We'd get a stack trace stuck in handshake surely ?
21:08:48 <moneromooo> Or some similar api.
21:10:56 <fmohammed[m]> high CPU usage do to tries to read 1 byte from RNG ?
21:11:06 <fmohammed[m]> due to tries
21:11:20 <fmohammed[m]> in non blocking mode
21:18:47 <hyc> hm ture, should see it in handshake code yeah
21:18:49 <hyc> true
21:27:54 <hyc> is there any reason we don't have something like an rpc_clients <max number> command/setting in monerod?
21:29:40 <moneromooo> Just that nobody added yet AFAIK.
21:35:31 <hyc> I may take a look. setting ulimit on monerod interferes with DNSSEC lookups
21:42:17 <hyc> seems it may be a way to DoS itself. if you set a low limit, you may no longer be able to issue commands to it
22:09:23 <Lyza> allow a whitelist that bypasses the limit, add localhost to the whitelist by default
22:20:34 <hyc> looks like more work than I have time for right now, maybe someone else will be motivated to do it