utxobr[m], I wrote my comment. Please don't mind the dose of honesty.

hyc: can you try to reproduce the issue with syncing off one exclusive node with --limit 999999999 added to both nodes?

so that we can make sure that it isn't some bandwidth limit thing

er.... why would it be a bandwidth thing between 2 nodes on a LAN not talking to anyone else?

software bandwidth limit is too small and can be reached in case of fast hardware of peers and fast hw connection between them

But it can be wrong assumption too

we have never changed the default limits and node-to-node syncused to work fine

I routinely sync'd two nodes from each other on localhost without issues, and if bandwidth limit was going to hit anywhere, it would be there

Sync is broken now ?

I mean IBD

cannot get a successful sync of a fresh node from an existing node over LAN with --add-exclusive-node all in one go

it always stops and bans the existing node.

will resume if you manually unban or restart the new node

eh what happened to external/miniupnp in master? trying to update to a nonexistant commit hash

oh, origin changed

git submodule sync

Does it ban soon or after a certain height only ?

seems to be random time intervals, not particular heights

hang on, rebuilding current master, will spin up a new localhost-only test

conn breaks on localhost too

1st instance at height 19456

it reconnected about 1.2sec later and resumed

disconn again at height 29184

Oh it's drop, not ban ?

it will eventually ban

OK. I'll check later today.

disconn again at 38912

48640

58368

you get the idea

hyc, Can you post +-few minutes log around disconnection event from both nodes ?

I have posted these before, but hang on

the last log was only for one node and had not very verbose log level

not sure I'll see the disconnect event at this loglevel

ok, have an event captured

hm, nothing interesting happened on the other side. lemme try again

there must be something interesting :D, keep going

ok logs uploaded

highlandsun.com/hyc/log1.txt and log2.txt

log1 is the fresh node

it's captured from the time of one "disconnected" message to the time of another

log2 is the existing node from the same timespan

both at loglevel 2

so far no bans

hmm, "We can download nothing from this peer" ??

10:00:39.937

That is not a ban inducing drop. It's the caller deciding not to continue.

So if you get banned, there must be another type of drop.

even so, that sounds incorrect. certainly the peer has the entire blockchain left to send

Sure, it could be made to be more precise. Not really relevant though, it'll reconnect.

so so far it's just that, no ban on localhost

I guess I'll have to try it again over LAN, that's where bans showed up last time

can we raise loglevel to logfile without raising level on console?

Not without code changes.

Though --detach might help ?

I just want to see the normal sync Info messages on console

and the disconnect/ban messages

there is some log category magic mooo knows :D

tail -f bitmonero.log | tee log | grep --lined-buffered Sync :P

hmph

I guess that'll work

ok starting over with LAN instead

tail -f doesn't work across log rotation, boo

guess I'll just leave this for a few hours and see if it happens later

`tail -F`

works across log rotations

"hmm, "We can download nothing from this peer" ??" fresh node behaviour: 1. fetch hashes for the next 10000 blocks; 2. fetch these blocks; 3. drop connection since we've fetched all blocks from the peer

but it should be 3. request hashes for the next 10000 blocks if peer has superior advertised height and we've downloaded all previous blocks

id guess this behavior was implemented to get the syncing node to try and find other peers

No, originally it'd do that but I added a number of checks for bad peers and one thing bad peers can do is send bad hash sets, and I think what happens might be that it can't tell between "I'm out of hashes from that peer but I did download stuff just fine" and "I'm out of hashes from that peer because all the ones I got were dud".

which would be a fine behavior unless --add-exclusive-node is being used

right, with --add-exclusive-node I should never see the conn being dropped or banned. ideally.

caught a weird timeout on LAN this time but it looks like the full node froze for a minute.

no log lines at all for 1 minute

this is using the Mac as the full node this time, previously both daemons were on my linux box

but yeah, now the new nde has banned the fullnode

"no log lines at all for 1 minute" with which log level ?

level 2

highlandsun.com/hyc/log3.txt and log4.txt

log3 is the new node

log4 is the full node

freeze occurs after 10:41

after that the new node bans the full node

hyc: unrelated but did you compile for mac arm or is it translating x86_64?

it's arm

"no log lines at all for 1 minute" it can be only due to reached upload software limit

Can you repeat with higher log level or set explicitly high --limit in order to exclude this variant ?

there must be something that explains unresponsiveness

the mac is running as a normal node, so it should also be talking to other peers. also there is a miner pointed at it. it should be processing get_height RPCs once per second.

none of that is occurring, so I think something else is going on inside the daemon at the time

and RPCs are not bandwidth limited at all

anyway we need more info, so it's either higher log level or debug build under gdb or something between

"none of that is occurring" yes, it looks like so

can't catch it in the act though, so gdb is unlikely

`while true; do curl -m 30 127.0.0.1:18081/getheight || kill -STOP $(pgrep -n monerod) && break; done;`

it should catch unresponsiveness

* `while true; do curl -m 30 127.0.0.1:18081/getheight || kill -STOP $(pgrep -n monerod) && break; sleep 1; done;`

hm, ok maybe throttle related

highlandsun.com/hyc/log5.txt and log6.txt

using loglevel 3 on the fullnode

good, one less mysterious problem

loglevel 2 on the new node shows a gap from 16:46:20 to 16:46:44

maybe some math overflow in the throttle sleep calc

2021-05-04 16:46:20.176 [P2P5] TRACE net.throttle contrib/epee/src/network_throttle-detail.cpp:306 SLEEPdbg >>> global-OUT: speed is A=2.12089e+06 vs Max=2.09715e+06 so sleep: D=0.106989 sec E=19461286 (Enow=19494054) M=2.09715e+06 W= 9.176 R= -217819 Wgood 11 History: [0 4458618 3466595 5788042 4839289 417088 43 491611 0 0 ] m_last_sample_time=1.62015e+09

dunno. still a gap in the fullnode log between 16:46:22.493 and 16:$7:13.732

16:47:13.732

jbigs[m], your sorta in the right place. "I am looking for someone to point me in the right direction for where I could get involved with implementations, policy research, marketing, and sales opportunities with Monero. " ..

though id move this to #monero .

Getting involved with implementation is here and github. Pick something that annoys you, get an ok in principle here, make a patch. That's a good way to start.

moneromooo, can you access those matrix.org pastes?

We don't sell monero though, we're not a company. So we don't have a sales department or the like.

Yes.

I tend not to though.

k. didn't know if tor made it difficult etc

No, oddly.

So I hadn't seen that one :)

For policy research, there's a channel called... #monero-policy IIRC. It's infuriating though, since the topic is often mass spying.

There are a few people who do marketing, thunderosa, geonic are some. I think xmrhaelan[m]1 too ?

jbigs see #monero-outreach

Hello, I am looking for someone to show me what missing tests that have to be written for this project or any tasks that needs to be worked on. I am interested in contributing to this open source project in hopes of bettering my skills in C++.

Hi.

Tests are always welcome, thank you :)

I don't have a list handy, but there are several types of tests we have:

unit tests basically test a particular function: if you can isolate a function which doens't need too much state, adding quick runtime unit tests for it is always useful

core tests are for interacting with the chain, so for consensus positive/negative testing - like create a tx or block that's invalid in some way and checking it gets properly rejected

functional tests are high level, using daemon/wallet RPC to ensure stuff works as it should, they're written in python

These are the ones that are likely to be added to.

Core tests are notoriously hard to write (but when you do write one, they're damn powerful).

Writing tests typically requires good working knowledge of how stuff works first though.

For unit tests, this is usually small enough, but core tests and functional tests require more general knowldge in order to make a useful test.

For unit tests, some stuff that's currently internal might be exposable and tested. However, it the exposing part isn't trivial (ie, requires code surgery), it might not be worth the changes. Details in the devil.

Maybe a good first port of call is to grep various RPC calls in tests/functional_tests and seeing if any aren't used/tested.

Actually, you said C++ skills, functional tests are in python, so nevermind.

So, unit tests, you could scour src/cryponote_basic/ to check self contained functions.

Also src/common and contrib/epee.

There are also fuzz tests, in C++. If you find a self contained function that parses/processes untrusted input, it would be a good candidate for a new fuzz test.

Thank you for the feedback! This is actually my first time engaging in an open source project so all this is information is pretty overwhelming and exciting at the same time,

You picked the right community to work in

In the crypto space, it doesn't get much better than the Monero community

The entire currency is a testament to freedom, collaboration, and the protection of privacy and liberty

No other project comes close

Sounds good! (y) :]

.merges

.merge+ 7667 7663 7664 7665 7666 7670 7668 7677 7678 7680 7681 7682 7685 7695

Added