[Enig123]

When looking into the cause of some strange logs, I was able to locate into CSearch::ProcessResultKeyword where uFromKadVersion was needed from pFromContact found earlier. That's when I realized sometimes peer may respond with another udp port due to outbound udp traffic sent to our ip and our listening udp port.

I did changed into the following codes

void CSearch::ProcessResultKeyword(const CUInt128 &uAnswer, TagList *plistInfo, uint32 uFromIP, uint16 uFromPort)
{
	// Find the contact who sent the answer - we need to know its protocol version
	// Special publish answer tags need to be filtered based on its remote protocol version, because if an old node is not aware
	// of those special tags, it doesn't knows it is not supposed accept and store such tags on publish request, so a malicious
	// publisher could fake them and our remote node would relay them on answers
	uint8 uFromKadVersion = 0;
	CContact* pFromContact = NULL;
	for (ContactMap::const_iterator itContactMap = m_mapTried.begin(); itContactMap != m_mapTried.end(); ++itContactMap)
	{
		CContact* pTmpContact = itContactMap->second;
		if (pTmpContact->GetIPAddress() == uFromIP)
		{
			pFromContact = pTmpContact;
			if (pTmpContact->GetUDPPort() == uFromPort)
				break;
		}
	}

	//Enig123::Only process tags with sender
	if (pFromContact == NULL)
	{
		DebugLogWarning(_T("Unable to find answering contact in ProcessResultKeyword - %s"), (LPCTSTR)ipstr(ntohl(uFromIP)));
		deleteTagListEntries(plistInfo);
		delete plistInfo;
		return;
	}
	else {	//if (pFromContact != NULL)
		uFromKadVersion = pFromContact->GetVersion();
		if (pFromContact->GetUDPPort() != uFromPort)
			DebugLogWarning(_T("Unable to find answering contact in ProcessResultKeyword with same port - %s"), (LPCTSTR)ipstr(ntohl(uFromIP)));
	}

to resolve it.

Today when I tried with similar situation in CSearch::ProcessResponse, the result logs show this is a quite common situation. I am suggesting similar changes of code there too:

void CSearch::ProcessResponse(uint32 uFromIP, uint16 uFromPort, ContactList *plistResults, uint32 uNumContacts)
{
	// Remember the contacts to be deleted when finished
	m_listDelete.insert(m_listDelete.end(), plistResults->begin(), plistResults->end());

	m_uLastResponse = time(NULL);

	//Find contact that is responding.
	CUInt128 uFromDistance((ULONG)0);
	CContact* pFromContact = NULL;
	for (ContactMap::const_iterator itContactMap = m_mapTried.begin(); itContactMap != m_mapTried.end(); ++itContactMap)
	{
		CContact* pTmpContact = itContactMap->second;
		if (pTmpContact->GetIPAddress() == uFromIP)
		{
			uFromDistance = itContactMap->first;
			pFromContact = pTmpContact;
			if (pTmpContact->GetUDPPort() == uFromPort)
				break;
		}
	}

	//Enig123::Only process results with sender
	if (pFromContact == NULL)
	{
		DebugLogWarning(_T("Unable to find answering contact in ProcessResponse - %s"), (LPCTSTR)ipstr(ntohl(uFromIP)));
		delete plistResults;
		return;
	}
	else {	// this part can be commented out after confirming the situation is commonly seen
		if (pFromContact->GetUDPPort() != uFromPort)
			DebugLogWarning(_T("Unable to find answering contact in ProcessResponse with same port - %s"), (LPCTSTR)ipstr(ntohl(uFromIP)));
	}

What are your thoughts on this?

[fox88]

Enig123, on 13 March 2025 - 05:39 AM, said:

When looking into the cause of some strange logs

How to know what is "strange logs"?

Enig123, on 13 March 2025 - 05:39 AM, said:

sometimes peer may respond with another udp port due to outbound udp traffic sent to our ip and our listening udp port.

A bug in KAD implementation?

[Enig123]

fox88, on 13 March 2025 - 01:55 AM, said:

Enig123, on 13 March 2025 - 05:39 AM, said:

When looking into the cause of some strange logs

How to know what is "strange logs"?

These logs have been long gone since the code changes. They were related to line 1145 of kademlia\kademlia\Search.cpp in 0.70b code base.

fox88, on 13 March 2025 - 01:55 AM, said:

Enig123, on 13 March 2025 - 05:39 AM, said:

sometimes peer may respond with another udp port due to outbound udp traffic sent to our ip and our listening udp port.

A bug in KAD implementation?

These are indications of the variety of udp NAT I suppose.

I don't think these responses would pose any security thread since we were the one who sent the requests to these ips in the first place.

This post has been edited by Enig123: 13 March 2025 - 05:55 PM

[fox88]

None of my log files contains TAG_KADAICHHASHRESULT string, which is present in line 1145.

[Enig123]

fox88, on 13 March 2025 - 11:17 AM, said:

None of my log files contains TAG_KADAICHHASHRESULT string, which is present in line 1145.

That's not very common, as I remembered.

Would you please try the latter patch, which was more commonly seen. I've got 533 matches across 4 log files.

[fox88]

Suggested contact map iterator uses incorrect conditions; patches do not change this.
Returning to the official code should be beneficial.

[Enig123]

fox88, on 14 March 2025 - 08:29 AM, said:

Suggested contact map iterator uses incorrect conditions; patches do not change this.
Returning to the official code should be beneficial.

The purpose of the codes is just to demonstrate how common the situation could be, not arguing which is correct or which is wrong.

But if it's a normal action for remote peer due to udp NAT, then potentially the kademlia could be adapted by ignoring udp port match.

[Enig123]

fox88, on 13 March 2025 - 11:17 AM, said:

None of my log files contains TAG_KADAICHHASHRESULT string, which is present in line 1145.

It's also possible with line 1114.

How about search with "ProcessResultKeyword"?

[fox88]

ProcessResultKeyword was never found.
Broken code serves no purposes, and same for invented NAT rules.

[Enig123]

fox88, you're right.

Just took a closer look at these ips, and found they're using a fixed port different from advertised port to send the responses, possibly due to misconfigured firewall rules.

One potentially issue is that I found some of these nodes got into the routing zone, wonder if there's some way to avoid that other than ban these ips.

Edit: In my humble opinion, these responses are legit, and the condition finding pFromContact should be loosen to ip matching only, instead of matching both ip and udp port.

FYI, CSearch::ProcessResultFile and CSearch::ProcessResultNotes the pFromContact was even irrelevant, and the responses are accepted directly.

This post has been edited by Enig123: 16 March 2025 - 04:14 AM