@jamie we’ve already pin-pointed the cause behind the network’s fragmentation. The fix is being introduced and tested currently on YouTube LIVE. As for the CVE-related issue - more time is needed (24-48 hours).
1 Like
It’s all good, we all serve the very same cause!
I’m currently looking into the DOS-vulnerability which was discovered in libssh by the end of 2022. We don’t know yet whether we are facing the very same issue (which hopefully was patched by authors of libssh) or whether it’s an entirely new thing.
I remember patching libssh myself back in 2018-2019… back then authors of libssh did not want to listen and ignored some of the reported issues. Which was when we forked libssh and patched it ourselves in our private branch. Hopefully, it is safe to switch to the main publich branch as of now.
worth to mention that we’ve also included a few additional security-related functionalities, such as the abrupt-shutdown of a connection capability, which can occur at a very early stage - even before the session negotiation has proceeded… the negotiation of cyphers phase is where libssh had a huge attack surface from day 1…
1 Like
Yes. I am aware of that meaning but in the sense that you were directing me within the app, it would not be an example, if I am actually to do it as your direction seeks me to do .surly if you were showing me an ex. I would follow that ex. and then do in the app . So still not sure what you would want me to do . 
@jamie here is an article dedicated to the ⋮⋮⋮ GRIDNET Token mobile app.
So, as the articles goes, once you swipe on the upper part of the screen, once the request becomes visible (after having scanned the QR Code) ex. below:
then you would be shown some of the details. Ex. below:
Yes an example got you 
I’ve already merged our version of libssh with the current state-of-the-art (the version available through vpckg as I was too lazy to build the entire library from scratch - the latest pre-release).
I’ll prepare a VCPKG compatible patch by tonight and hopefully make some our nodes immune to the CVE by tonight.
And as for the deep-fork we’ve encountered, the situation has been already resolved.
Nodes are merging towards a common viewpoint as we speak,- might take a few more minutes though.
@jamie - the very reason for why your transaction was rejected, on the side note - is that due to a fork, majority of nodes were unaware of the most recent value of a ‘nonce’ associated with your account / state-domain (only the current leader was).
Your mobile app was thus notified about the old value of a nonce, - reported by nodes that were stuck way in the past (yet again, due to a fork), for some reason these nodes would not agree on the history of events proposed by the current leader (who already verified and authorized your transaction).
The leader though would not accept a transaction with an old nonce. Errors such as these are not even stored on the chain as a transaction with an invalid nonce is assumed not to have been authorized by you to begin with. Thus, no errors reported by ‘getresult’.
We have fixed the issue (which was caused by one of us having committed an old version of a file by mistake) onto the test-net recently, affecting nodes operated by us. These nodes thus had an issue with analyzing ‘chain-proofs’ - and for that reason - remained stuck in the past.
Thank you for that explanation and info I appreciate .
I have been running my little node this afternoon and I had a BH of 2407 and I appeared to be 100% synced which is far behind the rest of the network and current leader 150.254.30.115 that you reported earlier.
Just running it now and I have 0% sync and no change in BH to the level .
@jamie what are the reported vitals of your node ?
Vitals report as good
Interesting to me that I get this on the flow : [UDT]: unable to connect with 150.254.30.115
Which as reported was the current leader
Is it possible what this means .
Conversation has begun.
[UDT]: connected with 148.251.75.43
Conversation has begun.
[DSM-sync]: scheduling a keep-alive leader notification to 148.251.75.43
NetTask [Type]:startConversation [Result]:succeeded Peer NOT notified. Task Dequeud.
[DSM-sync]: scheduling a keep-alive leader notification to 148.251.75.43
NetTask [Type]:startConversation [Result]:succeeded Peer NOT notified. Task Dequeud.
failed to deserialize message header (unknown protocol version)148.251.75.43:443'.
Signing in just to report that in the end, we’ve already (hopefully) managed to cover both bases.
@jamie check your balance, I’ve made sure you have some assets to play around with.
It indeed was the current leader at the time you wrote. It also was one of the nodes under a libssh CVE-based DOS attack. Maybe the situation has changed by now?
I wouldn’t worry about it. I will check out when this happens but most likely it has to do with the protocols’ multi-plexing mechanics we’ve implemented recently to make data of multiple data-exchange sub-systems flow over the same UDP port. Mostly likely it’s just that the Kademlia sub-system sees a datagram of another protocol and reports that it’s unknown. I’ll verify though.
Has the situation changed in any way on the node which you operate?
It is so reassuring having you aboard @Major!
Myself being a front-end developer (for the most of it), those things are a dark magic to me.
Knowing your background though, I’m guessing you simply must me having lots of fun around…
Thank you yet again.
(…) I say his skills go way beyond making our software resilient against kiddos armed with Metasploit, that’s for sure (…)
anyways - seems like those kiddos having no more luck, at least not today. All stable.
Bless you codesinchaos you didn’t have to do that I already had some . 
Hi vega4 thanks for answering my queries it helps me understand more ,I will run it tomorrow and report to you.