Mark Bednarczyk's blog

1.3.a2 scheduled for next week

I am planning an update jnetpcap-1.3.a2 next week. There have been several bugs fixed since 1.3.a1 was released. Again no new features just bug fixed.

The bug fixes are still being currently tested by select users on all supported platforms.

Bug#2890736 - Concurrent Modification Exception

This bug has resurfaced and I have reopened a ticket for it.

This a synchronization problem is in JMemoryPool class which is used when packet contents are copied around (ie. in PcapPacket and JMemoryPacket constructors and transferTo methods). It was not enough to use a synchronized list for caching memory blocks, but also needed to externally synchronize around iterators returned by the synchronized list. It appears that synchronized list does not return synchronized iterators.

The work around is to synchronize around areas of the user code that invoke either PcapPacket or JMemoryPacket copy constructors. Also around any of the transferTo methods. You should synchronize on the JMemoryPool object as returned by JPacket.getMemoryPool() method.

Here is a sample:


synchronized (packet.getMemoryPool()) {
JPacket packet2 = new PcapPacket(packet);
}

This problem has been fixed and code checked in. The fix will be released with the next release of jnetpcap-1.3.a2 (possibly this weekend).

Nearing official 1.3 stable release

I am working toward the official 1.3 stable release. Just wanted to update everyone ahead of time what will be part of this release and what the changes are in the SVN repository.

The release jnetpcap-1.3.a1 (a1 == alpha 1) contains all of the features found so far with the exception of the "analysis". All analyzers, reassemblers, sequencers, analysis events and the getAnalysis methods have been removed from the API in 1.3 release. This feature is still present in the main development trunk and is designated to be released after 1.3 into one of the jnetpcap-2.X releases sometime Q1 of next year. Not exactly sure if this will be in 2.0 or later since there are other features such as native-dissector, that need to be included before full analysis support can be officially provided. Analysis feature will continue to be released with more frequent development builds.

NAP file format

I needed a bit of a break from working continuously on jNetPcap so I did some work on NAP capture file format. A somewhat of a small rival to pcap-ng file format being developed by pcap folks.

I had an initial design and draft already done, but after revisiting it, found changing things around significantly. The 2 file formats look similar, but they were developed independently, and just happened to end up on a similar track. I guess its a validation of sorts when 2 projects merge on the similar ideas that those ideas are probably the correct ones.

After careful analysis and some basic API implementation on a C library for a public API, the seemingly simple file format turned out to have major issues when it comes to alignment of data. I'm still not quiet sure how pcap-ng format addresses alignment concerns. For NAP alignment especially on architecture platforms requiring strict data alignment such as Itanium processors, it was a significant effort to get all the pieces of the specification to fall into place.

After about 16 different versions of the basic record format I think I have a pretty good candidate for storing packet data in a file. Let me briefly state the objectives of the file format:

  • Provide streaming (sequential access to data) and indexed (random-access) at the same time.
  • Provide correct data alignment for efficient data access
  • Flexible and extensible
  • Fragmentable where large files can be broken down into smaller files, but still associated with each other
  • Flexible where almost any type of data can be stored

All of these goals have been met with the current specification. The data in this format can be streamed such as a socket, http connection and data processed as it arrives while at the same time when in physical file form, the data can be accesses from any part of the file using indexing of records.

The format is based on records stored within it. There are 5 record classes:

64-bit archs

64-bit infrastructure is in place. We should see 64-bit releases for the currently supported platforms within next few weeks.

Syndicate content