Hi All,
4727550 was a long standing RFE. Before we take any action, I'd like to ask you guys what the requirements are. E.g., do you plan to use raw socket in what kind of application? What features do you want the most? Which platform do you plan to use? etc.
Feel free to add your comments here.
Thanks,
Edward
Edward
Thanks for the survey.
I have several requirements across all possible platforms:
1. ICMP echo.
2. Ability to look at incoming IGMP. Outgoing IGMP is less important to me, in fact I can probably fudge it with MulticastSocket.join/leaveGroup.
3. Ability to write firewall-like code, i.e. issue TCP RSTs, or ignore incoming SYNs, &c, or tunnel multicasts, stuff like that.
4. Ability to see UDP fragmentation (as referred to by the JGroups guy in 4727550).
5. General ability to see IP packets, e.g. to see/modify the TTL, be a NAT device, be a port forwarder, &c.
6. This is probably the wrong place to mention it but I do need MulticastSocketChannel and I certainly don't understand why it has taken so long to provide.
I don't have any IPv6 requirements personally but it should all be there as transparently as possible.
A survey on the requirements in this area is a great idea.
"ejp" mentions "ICMP echo". In J2SE 5.0 the InetAddress.isReachable method was added to test the reachability of a host. At least on Solaris and Linux, I believe the implementation will send an ICMP echo request if the process has suitable privileges (ie: you are root or you have the right capabilities). If the process doesn't have privileges to create a raw socket then the implementation tries to connect to the TCP echo port instead. If the connection is established or is refused then it assumes the host is reachable.
The ability to see the DF bit in the IP header was also mentioned. Somewhat related but since Java SE 6 the NetworkInterface class has a getMTU method to get the value of the MTU on the interface - this might to size packets (in some cases).
Multicast support in the java.nio.channels package was also mentioned and as Edward says, this is one of the many topics covered by JSR-203. This JSR is targetting jdk7 (assumes of course that it is approved as a component JSR of jdk7).
Ah, yes, the commented out ICMP windows code. The short story is that Windows implementation of ICMP is, how do I say that nicely ... "different". It requires the application to provide the checksum for the header while all the other "proper" ICMP implementations do generate the checksum in the driver. It wouldn't be so bad if you didn't need the source IP address to compute that checksum, but it's not that easy to determine at that point in the code path, specially in case of multiple interfaces. Anyway, at that point, considering the risk and the time left in the development cycle, we decided it was not worth the trouble and commented out the code for a possible future re-visit.
There were other issues with ICMP on Windows, but that was the biggest one.
Hi ejp,
Seems what you need are:
1) read/write ICMPv4/v6 and IGMPv4 packets.
2) build your own IPv4 headers using IP_HDRINCL socket option, e.g. issue TCP RSTs, or see/modify the DP bits.
Also, the difference between IPv4 and IPv6 sockets become explicit here. For example, IP_HDRINCL is IPv4 only and there's no counterpart of it in IPv6. Or, ICMPv6 has type filtering, but ICMPv4 doesn't. So instead of making IPv4/IPv6 transparent, it might be necessary to make IPv4/IPv6 difference explicit for raw socket support.
My application is a hardware simulator, so to write the ethernet controller simulator, we would need to be able to send and receive raw ethernet packets.
For example, to simulate an (old) Digital VAX computer, the ethenet controller simulation needs to be able to send and receive raw packets with at least the following packet types: DECNET, LAT, LAD, LAST, SCCS, loopback, TCP/IP, Novell.
Currently, this is possible in Java by using one of the two(!) Jpcap implementations, which are Java wrappers around publically available libpcap/winpcap software.
The main problems with using the Jpcap wrapper is:
1) It is a pain to get and install the correct version of libpcap for the appropriate target operating system, since it is not provided by default on many systems, and if it is provided by default, it is generally too low a version for proper use
2) installation of libpcap/winpcap is a semi-complex or impossible task for an "end-user" (non-root/non-administrator)
One of the major reasons that the community would like to see Raw Packet support implemented in Java is that current raw packet programming is very system-dependant, and we would like to see a system-independant API provided through Java.
Java has nicely covered socket-based IP programming, now we'd like to extend Java to provide the Raw network APIs for more general network programming.
> Its sad to realize at different occasions, that Java
> is just not usable for this type of application, e.g.
> writing a firewall...
Sure it is! You just need some glue between operating system specific APIs and Java.
This is not really a language issue. It's an issue of what language APIs a given OS supports out of the box. Want to write a firewall using C and deploy it on a LISP machine? Be prepared to write some C/LISP glue, just like you'd write Java/C glue to access APIs written in a C-based OS.
C is so widespread, and so many OSes offer C APIs that C seems "universal". But that's just an illusion. The OSes that happen to be most popular at this time in history happen to provide C APIs to most of their functionality (even then you may occasionally need C/assembly glue for some things).
More and more APIs, such as low level TCP access, will eventually migrate to Java. But ther is no "universal" language, magically able to access any API written in any other language.
> My application is a hardware simulator, so to write
> the ethernet controller simulator, we would need to
> be able to send and receive raw ethernet packets.
>
> For example, to simulate an (old) Digital VAX
> computer, the ethenet controller simulation needs to
> be able to send and receive raw packets with at least
> the following packet types: DECNET, LAT, LAD, LAST,
> SCCS, loopback, TCP/IP, Novell.
>...
> 2) installation of libpcap/winpcap is a semi-complex
> or impossible task for an "end-user"
> (non-root/non-administrator)
>
I would be curious as to when this sort of end user would be running simulations for the described hardware simulator.