I am porting some Windows code to Linux. Part of the windows objects properties was not implemented in .net core's linux implementation. UnicastIPAddressInformation.PrefixOrigin is one of them.
.NET Core code docs show define it as:
value that identifies the source of a unicast IP address prefix.
MSDN defines it as:
Specifies how an IP address network prefix was located.
I am searching .NET Core repo browser for the implementation of this property, which returns the following enumeration:
public enum PrefixOrigin
{
Other = 0,
Manual,
WellKnown,
Dhcp,
RouterAdvertisement,
}
I could not find in .NET Core repo browser a class that implements UnicastIPAddressInformation. In .NET Framework repo browser, I understand the struct IdAdapterUnicastAddress is assigned a PrefixOrigin by marshaling OS data into C# classes/types. Anyway, I do not know at this point how to determine which enumeration value should be applied to a given IP.
Knowing barely nothing about computer networks, I am researching what is an IP prefix and how to figure it out. The practical example I could find was this one. As far as I understand, however, it provides a way to calculate the prefix length. I still need to know how to determine the PrefixOrigin enumeration value to a given IP.
Is it something that can be done by simply taking the prefix length into account ? If not, how do I figure out which PrefixOrigin value a given IP should be assigned ?
This field's value is telling you how a configured (or automatically-configured) IP address on the system was determined.
Manual: Somebody keyed it into the adapter configuration GUI in control panel or set it using e.g. netsh or similar.
Well Known: From a well-known source. I'm not really sure if Windows uses this value. It might be used when a 169.254.x.x address is assigned in the absence of any other configuration and when no DHCP server is present.
DHCP: When a DHCP server automatically assigns an IP address, which is the case in almost all home and office networks (but sometimes not on datacenter networks!), this is how you can tell.
Router Advertisement: IPv6 has an automatic configuration system which was supposed to replace DHCP. To keep things simple, think of this as being functionally the same as the field's DHCP value.
Related
I'm working on a project that has server and client roles. I would like to have servers and clients automatically detecting each other. At a first glance, zeroconf seems to be the best solution. But it would add a dependency, Bonjour, to the project. I use Qt for the GUI and Qt has native support of broadcast and multicast. So I'm wondering if it's feasible to just use those features to replace zeroconf?
Here is a decent post about how zeroconf works.
I don't think I need the features of obtaining an IP Address and obtaining a Hostname from zeroconf. All I want is let one instance be aware of other instance's existence.
My current plan is combining broadcast and multicast. Each server chooses a unique multicast group and broadcast this group to the others. When a client wants to connect a to specific server, it joins the corresponding group.
Some people mention that it's normal that routers blocking local broadcast. If this is true, my plan would not be feasible.
Is there any standard way to implement this rather than using zeroconf?
I'm looking for a solution to find out about the MAC number of a user using asp.net website. I know you can get an IP address (don't know why but it can't be complicated) but can i find out the MAC address having the IP?
Edit: I mean programmatically (not manually) in .NET
The IP address is necessary for routing the communication between the client system requesting the information and the server. You can get it, because the IP address is pulled from a lower level in the TCP/IP stack (level 3 I believe). The MAC Address isn't necessary for any of this and hence it isn't included in the communication between the client and the server.
If your site is trusted, you can do this in IE:
http://www.devarticles.com/c/a/JavaScript/Advanced-JavaScript-with-Internet-Explorer-Retrieving-Networking-Configuration-Information/1/
I wouldn't expect it to work for any typical visitors, just users who's systems you already control, like on your local network. There may be a second way in IE if you can find a common activex that generates a guid using CoCreateGuid. It returns the mac address in part of the guid. I wouldn't bet on finding one that's commonly installed though.
no chance to get this sorry.
Even if you could it would not make sense to attempt to get this, when I access a website on the internet my MAC address never leaves my home network.
Ok if the user was on the same LAN say in a company intranet for example this could be determined by having the ip address and using command line tools like arp.
ARP stands for Address Resolution Protocol and it can be used for finding a host's link layer (hardware) address when only its Internet Layer (IP) or some other Network Layer address is known.
Java 6 has a NetworkInterface#getHardwareAddress() method which usually returns the MAC address of the computer in question. You could create a small Java applet to communicate with your web server to obtain the MAC address, though there are ways and means of spoofing a MAC address.
The MAC address you get might not be practical to use. If someone has multiple network adapters then they also have multiple MAC addresses. And it's not uncommon anymore that someone has two networks. (For example, bluetooth, regular cabled and WiFi would already be three.)
A MAC address is just for identification and it can be requested. The Address Resolution Protocol is created for this purpose. By arping you can get a MAC address. Unfortunately, this only works on local networks, not on the Internet. I think that by using IPv6, you might also have a few options. Although I think it would still be limited to just a local system.
Getting the MAC address of your visitor might be considered inappropriate and perhaps even criminal since a MAC address is generally used as an unique identifier. This information could be misused by hackers, especially when the hacker manages to gain physical access to the users network. It would allow him to impersonate the user. Your site might make some security specialists very unhappy...
At http://www.ipaddresslocation.org/find-mac-address.php there's a Java applet which they claim will work. It doesn't on my system with Google Chrome, though.
I have a similar problem (I'm using the client device MAC address as a key to target different content at different devices). This thread has been useful. Given that there seems to be no way to do this implicitly I have instead included the MAC address as one of the parameters passed by the client to the web service.
(N.B. This is not a generic answer, it only makes sense where the client and server are tightly integrated and where there is scope for passing data with the call.)
I don't think this is possible on any platform.
I am trying to use Boost for some IPv6 and multicast network communication. I need to construct an IPv6 multicast socket that uses a specific network interface index.
I was able to find the correct multicast option to set the network interface index in boost/asio/ip/detail/socket_option.hpp:
explicit multicast_request(const boost::asio::ip::address_v6& multicast_address, unsigned long network_interface = 0)
The problem is, I don't know how to find the correct value for the "network_interface" parameter. Is there a way to get the network_interface value using a local IPv6 address that I can provide? I looked in the documentation and examples, but couldn't find anything.
-- Dylan
Each platform provides APIs to enumerate the network interfaces, e.g. getifaddrs for many Unixes and GetAdaptersAddresses for Windows. Note on Windows there is a separate numerical space for IPv4 and IPv6 adapters which makes the API call if_nametoindex quite confusing.
You may wish to inspect the methods I employed in OpenPGM for portability, considering Windows doesn't really have useful adapter names:
http://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/getifaddrs.c
http://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/nametoindex.c
http://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/indextoaddr.c
http://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/indextoname.c
I don't think there's a platform-independent way to figure this out, just as there is no portable solution to enumerating the local addresses.
On Linux, you can find what you want in the second column of /proc/net/if_inet6, which is also available more robustly through the rtnetlink(7) interface.
In IPv6 networking, the IPV6_V6ONLY flag is used to ensure that a socket will only use IPv6, and in particular that IPv4-to-IPv6 mapping won't be used for that socket. On many OS's, the IPV6_V6ONLY is not set by default, but on some OS's (e.g. Windows 7), it is set by default.
My question is: What was the motivation for introducing this flag? Is there something about IPv4-to-IPv6 mapping that was causing problems, and thus people needed a way to disable it? It would seem to me that if someone didn't want to use IPv4-to-IPv6 mapping, they could simply not specify a IPv4-mapped IPv6 address. What am I missing here?
Not all IPv6 capable platforms support dualstack sockets so the question becomes how do applications needing to maximimize IPv6 compatibility either know dualstack is supported or bind separatly when its not? The only universal answer is IPV6_V6ONLY.
An application ignoring IPV6_V6ONLY or written before dualstack capable IP stacks existed may find binding separatly to V4 fails in a dualstack environment as the IPv6 dualstack socket bind to IPv4 preventing IPv4 socket binding. The application may also not be expecting IPv4 over IPv6 due to protocol or application level addressing concerns or IP access controls.
This or similar situations most likely prompted MS et al to default to 1 even tho RFC3493 declares 0 to be default. 1 theoretically maximizes backwards compatibility. Specifically Windows XP/2003 does not support dualstack sockets.
There are also no shortage of applications which unfortunately need to pass lower layer information to operate correctly and so this option can be quite useful for planning a IPv4/IPv6 compatibility strategy that best fits the requirements and existing codebases.
The reason most often mentioned is for the case where the server has some form of ACL (Access Control List). For instance, imagine a server with rules like:
Allow 192.0.2.4
Deny all
It runs on IPv4. Now, someone runs it on a machine with IPv6 and, depending on some parameters, IPv4 requests are accepted on the IPv6 socket, mapped as ::192.0.2.4 and then no longer matched by the first ACL. Suddenly, access would be denied.
Being explicit in your application (using IPV6_V6ONLY) would solve the problem, whatever default the operating system has.
I don't know why it would be default; but it's the kind of flags that i would always put explicit, no matter what the default is.
About why does it exist in the first place, i guess that it allows you to keep existing IPv4-only servers, and just run new ones on the same port but just for IPv6 connections. Or maybe the new server can simply proxy clients to the old one, making the IPv6 functionality easy and painless to add to old services.
For Linux, when writing a service that listens on both IPv4 and IPv6 sockets on the same service port, e.g. port 2001, you MUST call setsockopt(s, SOL_IPV6, IPV6_V6ONLY, &one, sizeof(one)); on the IPv6 socket. If you do not, the bind() operation for the IPv4 socket fails with "Address already in use".
There are plausible ways in which the (poorly named) "IPv4-mapped" addresses can be used to circumvent poorly configured systems, or bad stacks, or even in a well configured system might just require onerous amounts of bugproofing. A developer might wish to use this flag to make their application more secure by not utilizing this part of the API.
See: http://ipv6samurais.com/ipv6samurais/openbsd-audit/draft-cmetz-v6ops-v4mapped-api-harmful-01.txt
Imagine a protocol that includes in the conversation a network address, e.g. the data channel for FTP. When using IPv6 you are going to send the IPv6 address, if the recipient happens to be a IPv4 mapped address it will have no way of connecting to that address.
There's one very common example where the duality of behavior is a problem. The standard getaddrinfo() call with AI_PASSIVE flag offers the possibility to pass a nodename parameter and returns a list of addresses to listen on. A special value in form of a NULL string is accepted for nodename and implies listening on wildcard addresses.
On some systems 0.0.0.0 and :: are returned in this order. When dual-stack socket is enabled by default and you don't set the socket IPV6_V6ONLY, the server connects to 0.0.0.0 and then fails to connect to dual-stack :: and therefore (1) only works on IPv4 and (2) reports error.
I would consider the order wrong as IPv6 is expected to be preferred. But even when you first attempt dual-stack :: and then IPv4-only 0.0.0.0, the server still reports an error for the second call.
I personally consider the whole idea of a dual-stack socket a mistake. In my project I would rather always explicitly set IPV6_V6ONLY to avoid that. Some people apparently saw it as a good idea but in that case I would probably explicitly unset IPV6_V6ONLY and translate NULL directly to 0.0.0.0 bypassing the getaddrinfo() mechanism.
Has anyone had any luck getting MSMQ multicast (PGM) to bind to a specific network interface using the MulticastBindIP registry setting?
MSMQ Multicast (PGM) always seems to bind to the first interface listed by ipconfig. In my case, I have VMware installed, so I have two virtual network interfaces (VMnet8 and VMnet1) as well as my network card. It isn't useful to have MSMQ send PGM packets to the VMware virtual interfaces.
I have attempted to use the MulticastBindIP registry setting (of course, restarting MSMQ after the change), but this does not seem to make any difference. For example, the IP address of my "Local Area Connection" is 172.18.224.245, so I set the following registry key value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters]
"MulticastBindIP"=dword:ac12e0f5
The DWORD is stored with most significant bytes first. However, using wireshark, I can see that the PGM packets are not getting sent to this interface (but still sent to the first interface listed by ipconfig).
The documentation could be wrong, so I also tried variations such as: least significant bytes first and even using a (dot-delimited IPv4-style) string value. Nothing seems to make any difference. The only way I can get MSMQ multicast to bind to the correct interface is to disable all virtual interfaces. This isn't a workable solution.
If anyone is interested, "MulticastBindIP was introduced for Windows 2003 Server and not back-ported to Windows XP". Thanks to John Breakwell's help. See this Microsoft newsgroup discussion for more details.
The only solution I've found on Windows XP is to disable all interfaces except the "Local Area Connection". When you re-start the MSMQ windows service it will bind to the correct network interface (because it's the only one available). I suspect it's not that common to have multiple network cards in a machine running WinXP, but it is common to have VMware or VirtualBox virtual interfaces that expose this issue with MSMQ binding.
FYI, For more recent operating systems, where the MulticastBindIP registry setting is supported, there is some debate on whether the value is a DWORD or REG_SZ.