There is a page called "Building from Ecli[p]se" on this website but I find it very confusing. Instead of discussing Eclipse directly, there is extensive discussion about SubVersion. I'm wanting to use Eclipse without SubVersion (I'm using a different version control system). Why is this page that is primarily about SubVersion, entitled "Building from Eclise" ? And is there any general advice about importing the jNetPcap tree into Eclipse elsewhere on this site?
MORE SPECIFICALLY: when I try to bring jNetPcap -with it's build.xml- into Eclipse, the "java.sdk.include.dir" is not correctly evaluated. This value is being printed out within the "comp-jni-linux" target (System Include). It works fine when the build is invoked from the command line but when it's built within Eclipse, it doesn't work at all (it prints out as: "${env.JAVA_HOME}/include" ). Any help on this would be appreciated...
UPDATE: Elipse is not correctly taking in jNetPcap's "build.properties". Even if I explicitly add it in the "External Tools Configurations" window (Properties>AddExternal) it still doesn't work correctly.
SOLVED: tentatively, it looks like this problem may be solved. The solution was to (In eclipse with build.xml selected) go to :
"Run>ExternalTools>ExternalToolsConfigurations>Properties>AddProperty"
...and define "java.sdk.include.dir" as the same path that shows during my command-line build (which, in my case is /usr/java/default/bin/../include). And then I get a SUCCESSFUL build.
I'm finalizing the release. I've been fixing a lot of bugs that were reported to me and working on the API.
I'm adding many different "core" protocols such as SLL, Arp, SpanTree, VLAN, Rip 1 & 2, DNS, Telnet, FTP, ISL and HSRP. All basic types of protocol you will find in a typical networks.
I'm also working on last few bits of the API I needed to change. Specifically with new protocol development adding container classes for sub header, fields. Currently for sub headers for example you have to subclass JHeaderMap. This is very restrictive in its use. Instead you will now be using SubHeader containers as objects within the main header definition. This allows mixing of different type of containers for more complex headers.
Another area that I've addressed is use of custom "field formatters". The existing hardcoded field formats have been replaced with flexible "JFieldFormatter" objects. Each of these objects is used to hook into JFormatter to format the way a field is represented textually. Header definitions can supply their own custom JFieldFormatters and reference them in the annotations. jNetPcap of course comes with a comprehensive array of field formatters that core protocols already utilize, and this new mechanism allows completely new types of fields to be properly displayed.
With the addition of field and header containers you will be able to create very complex header/subheader or field/subfield hierararchies. Formatter is now also extensible with JFieldFormatter objects for new types of fields that need to be formatted for textual output.
Most people will not be affected by these changes as they only affect how headers are defined in jnetpcap, not how they are accessed.
I think that by adding the ARP DLT after WEB_IMAGE in JProtocol, it will put a kink in the StatisticAnalyzer class. This is due to the StatisticAnalyzer constructor iterating through the list of DLT's and assuming that WEB_IMAGE_ID is the last element.
Snap header (native C structure) had a problem reading correctly the 16 bit pid value on win32 platforms. The C++ compiler incorrectly mapped this uneven byte field. The issue has been fixed by positioning a pointer to the location and reading the value directly out of memory instead of relying on a C structure to compute the exact offset since that way is not portable for uneven boundary integers.
Added arp protocol to core protocols. Protocol has a native scanner defined and java header definition with support for all known hardware and protocol types.
Released in: jnetpcap-1.2 and jnetpcap-1.3-dev
When I build jNetPcap, the build fails at the test target saying:
"could not create task or type of type: junit"
...what's this all about? Why doesn't ANT recognize the junit task?
If given raw packet data, either as a byte array or JBuffer, is there a way to construct a protocol object from it? I can see how to do it if given a PcapPacket, but not from raw data.
I dug into this a little more and figured out how to do it using a JMemoryPacket. Works great!
I'm trying to build jNetPcap from sources and my problem is that the "comp-test" target (in build.xml) fails immediately with an error message saying:
"[javac] c/testjnetpcap.cpp skipped - don't know how to handle it"
It looks like it's trying to invoke "javac" on a ".cpp" file.
Textfile showing the last 16 lined before the fail is attached. I have installed cpptasks and it seems to be working properly since there are several lines of "cc" compilation.
Please advise.
I'm wanting to run jNetPcap for capture (on Linux) from Eclipse. I've been doing it by invoking eclipse as Root but there are problems associated with this approach. Once Eclipse is run as Root it writes directories and files with Root permission including hidden files that it uses for configuration and logging. If I then try to run Eclipse as user (ie not root) for some other purpose, massive problems develop because it can't write files it needs to write. In many cases this causes silent crashes; it doesn't even kick up a dialog box or anything; it just fails or hangs.
I would prefer not to have to run eclipse as Root all the time if possible but it seems that once it is run as root, it would always have to be run as root ...otherwise this problem with unwritable config files will cause mysterious crashes.
At this point I'm thinking that perhaps the only solutiion is to have two separate eclipse installs; one as root and the other as user but that seems cumbersome also. Does anyone know of a workaround to this problem?
I believe the answer is no, but thought that it should be asked. Assuming that is the case, how involved would it be to add support for Linux cooked-mode capture (SLL)?