I am using DVTK for my various needs for testing DICOM related functionalists with my application. Unfortunately the Query Retrieve SCP client doesn't support IPV6 format. Any other utilities are there to allow to query data using IPV6?
Yo could try dcmqr (*1) from the package dcm4che2 (*2).
I have only used that tool on IPv4 environments. According to the documentation, some packages of the toolkit do support IPv6:
To specify a port with an IPv6 address, enclose the IPv6 address in
square brackets before appending the colon and decimal port number
I have not found specific indications about support for IPv6 in the Q/R tool, so, you will have to test it on your environment.
(*1) http://www.dcm4che.org/confluence/display/d2/dcmqr
(*2) http://www.dcm4che.org/confluence/display/d2/dcm4che2+DICOM+Toolkit
Related
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.
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 found a couple of answers, but they seem to be specifically relating to Windows machines.
So my question is what are the differences between pipes and sockets, and when/how should you choose one over the other?
what are the differences between pipes and sockets, and when/how should you choose one over the other?
Both pipes and sockets handle byte streams, but they do it in different ways...
pipes only exist within a specific host, and they refer to buffering between virtual files, or connecting the output / input of processes within that host. There are no concepts of packets within pipes.
sockets packetize communication using IPv4 or IPv6; that communication can extend beyond localhost. Note that different endpoints of a socket can share the same IP address; however, they must listen on different TCP / UDP ports to do so.
Usage:
Use pipes:
when you want to read / write data as a file within a specific server. If you're using C, you read() and write() to a pipe.
when you want to connect the output of one process to the input of another process... see popen()
Use sockets to send data between different IPv4 / IPv6 endpoints. Very often, this happens between different hosts, but sockets could be used within the same host
BTW, you can use netcat or socat to join a socket to a pipe.
To complete the answer given by Mike, it is important to mention the existence of UNIX domain sockets, which are available on any POSIX compliant operating system. Although very similar to "normal" internet sockets in terms of usage semantics, they are purely local to the machine (of course internet sockets can also work locally), and thus almost behave like a pipe. Almost, because a UNIX pipe is by definition unidirectional:
Pipes and FIFOs (also known as named pipes) provide a unidirectional
interprocess communication channel. A pipe has a read end and a write
end. Data written to the write end of a pipe can be read from the read
end of the pipe. (excerpt from the man page pipe(7))
UNIX domain sockets also have a very unusual feature, as besides data, they also allow sending file descriptors: this way, an unprivileged process can access any file whose descriptor has been sent over the socket. This technique, according to Wikipedia, is used by the ClamAV antivirus scanning daemon.
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.