0

I am curious as to why sockaddr is used inside pcap_addr_t which is given to you when calling pcap_findalldevs. The reason this is not so straight forward is because sockaddr_in contains information about the address and port. This is similar to .NET's System.Net.IPEndPoint class.

If we were looking at a .NET library, I would not expect to see a property such as that with a description about addresses belonging to a device. As far as I know, no protocols define an address and port when describing a device on a system.

On all of my devices (IPv4 and IPv6 only), the port is 0.

When would it be beneficial to associate an address and port to a device as one of its owned endpoints? The reason I ask is because I am developing a C# binding for libpcap and want to know if it would be useful or just erroneous/silly to expose all of the data from sockaddr_in to the user in the form of a System.Net.IPEndPoint property on my NetworkDeviceAddress class which describes the addresses owned by a particular device.

Michael J. Gray
  • 9,784
  • 6
  • 38
  • 67

1 Answers1

1

When would it be beneficial to associate an address and port to a device as one of its owned endpoints?

Rarely at best, and probably never. You're assuming that's why a sockaddr is used.

In fact, it's used as a way of supporting multiple address types; yes, a sockaddr might contain a port number, if it's AF_INET or AF_INET6, but, as the "if it's" clause suggests, it also contains an address family value.

libpcap/WinPcap is a cross-platform library, originally created for BSD UN*X, and created long before .NET even existed, so it was obviously not designed with .NET's networking objects in mind. (pcap_findalldevs() wasn't an API in the original libpcap, but it was added back in August-September 2001, which was before the final version of .NET 1.0 came out.)

The port number is not set to anything significant by pcap_findalldevs(), so there's no need to expose it in your wrapper.

  • Fair enough. I suppose it is convenient to use familiar constructs, especially back in the day. I suppose that if it comes to it some day, someone could make a new protocol and assign devices to certain addresses and ports and `sockaddr` would be still appropriate. I just wanted to make sure nobody knew of any reason to expose the full `sockaddr` and not just the IP addresses. – Michael J. Gray Jul 01 '13 at 02:37
  • `sockaddr`s don't contain ports; `sockaddr_in`s and `sockadr_in6`s do, and they do so because they're used both to refer to IPv4/IPv6 endpoints and TCP/UDP endpoints. The only way you'd have an address and a port at the *same* layer of the networking stack would be with protocols very different from the Internet protocols; at that point a lot of networking stuff would probably need rearchitecting, including the .NET networking stuff. –  Jul 01 '13 at 02:51
  • Sure did mean to write `sockaddr_in` and `sockaddr_in6`, thanks for the correction. – Michael J. Gray Jul 02 '13 at 01:39