Project

General

Profile

Bug #2292

Infinite loop when listNetworkInterfaces returns an address that is either 0.0.0.0 or ::

Added by Alex Afanasyev almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Faces
Target version:
Start date:
12/13/2014
Due date:
% Done:

100%

Estimated time:

Description

In some configurations, listNetworkInterfaces() returns 0.0.0.0 or ::, which causes infinite loop inside TcpFactory and UdpFactory

History

#1 Updated by Junxiao Shi almost 5 years ago

What configuration could cause listNetworkInterfaces to return ANY address?

What's the output of ip addr and ifconfig on such configuration?

This Bug should probably blame listNetworkInterfaces.

#2 Updated by Alex Afanasyev almost 5 years ago

I think 0.0.0.0 can be legitimately returned when IPv4 is not configured on the interface.

In any case. I was getting this when playing with cygwin. I will mention it again later in a separate place, but I was able to compile ndn-cxx, NFD, and run NFD on windows in cygwin environment.

#3 Updated by Junxiao Shi almost 5 years ago

Commit f0fda37fea04f15609897bf0e43d259569828c4a is a correct solution to this Bug.

In addition to this, listNetworkInterfaces should not add ANY address into NetworkInterfaceInfo::ipv4Addresses and NetworkInterfaceInfo::ipv6Addresses when IPv4/IPv6 is not configured. Instead, these vectors shall be left empty.

I suggest making this change in a separate commit under this Bug.

#4 Updated by Davide Pesavento almost 5 years ago

Junxiao Shi wrote:

In addition to this, listNetworkInterfaces should not add ANY address into NetworkInterfaceInfo::ipv4Addresses and NetworkInterfaceInfo::ipv6Addresses when IPv4/IPv6 is not configured. Instead, these vectors shall be left empty.

I don't think I agree with this. listNetworkInterfaces should simply return whatever is configured on the system, it's just a helper. If an interface on the system has an address of 0.0.0.0 or ::, listNetworkInterfaces should return it and not perform any mangling. If a consumer of the listNetworkInterfaces API is unable to deal with such an address, it's the consumer's bug, not listNetworkInterfaces's.

#5 Updated by Alex Afanasyev almost 5 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100

I think I agree with Davide. Whatever system is returning, should be returned by listNetworkInterfaces and the caller needs to process that in some way.

I'm not planning any more work on this issue.

#6 Updated by Junxiao Shi almost 5 years ago

Then add a \warning on listNetworkInterfaces that invalid IP address may be returned.

#7 Updated by Davide Pesavento almost 5 years ago

I don't think 0.0.0.0 qualifies as "invalid". (well, it depends on how you define "invalid"...)

#8 Updated by Junxiao Shi over 4 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF