Book navigation

Navigation

Added new feature to legacy jNetStream version 2.5

After several requests, I've succummed to peer pressure and added a badly needed feature to legacy jNetStream API (not to be confused with the latest 3.0 release I'm also working on.) This is an update to the old 2.4 which is currently the latest "stable" release.

The new feature is live capture of network packets and will be released as 2.5. I wasn't planning on continuing development on the old 2.4 software train, but I did it anyway.

In any case, look for 2.5 to be released soon, its dependency is on also the new jNetPcap version 1.2 (which hasn't been released yet either.)

The changes add a new PacketInputStream type called "LiveCaptureInputStream" which can be passed into the Decoder and decoded. LiveCaptureInputStream uses jNetPcap to capture packets on a network and passes them over to the Decoder for decoding.

Also added a small change to the NPL binding syntax. Along with normal bindings you can also supply DLT binding numbers to the protocol registry using NPL syntax as follows:

Ethernet = link dlt_pcap 1
Ethernet = link dlt_snoop 4

and etc... The prefix "dlt_" is what makes this special and instead of registering it as a normal binding it keeps a map of DLT to names. In our example the mapping would be made as follows:
For "pcap" map:
1 => Ethernet

and for "snoop" map:
4 => Ethernet

and so on... The Protocol registry (aquired using ProtocolRegistry.getDefault() call) has a new method ProtocolRegistry.mapDltToProtocolName(format, dlt): String

where format is file format name such as "pcap" or "snoop", the dlt is the numerical dlt number to be mapped and returned is the npl protocol name that corresponds to the same protocol in the corresponding format.

Look for release 2.5 very soon. jNetPcap 1.2 will be released at the same time. I'm still adding one last final feature to it to allow better access to PcapBpfProgram peered C structure. This is needed to pass back and forth compiled BPF programs that may not necessarily have been compiled by libpcap C library but by a custom compiler such as the one I'm building in jNetStream (think compiling NPL expressions to BPF code.)

Here is an example:

	public void testCaptureAndDecode() throws IOException, StreamFormatException,
	    EOPacketStream, SyntaxError {
		PcapIf i = LiveCaptureInputStream.listInterfaces()[0]; // grab 1st int
		System.out.println("==> " + i.getDescription());

		/*
		 * Capture just 5 packets from our interface. The count is passed down to
		 * Pcap.dispatch() or Pcap.loop() calls.
		 */
		LiveCaptureInputStream live = new LiveCaptureInputStream(i, 5);

		/*
		 * This is a normal PacketInputStream so we can pass it to the decoder :)
		 */
		Decoder decoder = new Decoder(live);

		int j = 0;
		Packet packet;
		while ((packet = decoder.nextPacket()) != null) {
			System.out.println("packet #" + ++j + " ==> " + packet.getSummary());
		}
	}

And the expected output after running that jUnit test case:

==> Intel(R) PRO/100 VE Network Connection (Microsoft's Packet Scheduler) 
packet #1 ==> 192.168.1.100 > 67.225.158.147 TCP   2974 > 80 [ SYN ] Seq=4237119008 win=65535 Len=
packet #2 ==> 67.225.158.147 > 192.168.1.100 TCP   80 > 2974 [ ACK SYN ] Seq=71537222 Ack=4237119009 win=5840 Len=
packet #3 ==> 192.168.1.100 > 67.225.158.147 TCP   2974 > 80 [ ACK ] Seq=4237119009 Ack=71537223 win=65535 Len=
packet #4 ==> 192.168.1.100 > 67.225.158.147 TCP   2974 > 80 [ ACK ] Seq=4237119009 Ack=71537223 win=65535 Len=
packet #5 ==> 192.168.1.100 > 67.225.158.147 TCP   2974 > 80 [ ACK PSH ] Seq=4237120469 Ack=71537223 win=65535 Len=

Who's online

There are currently 0 users and 9 guests online.

Who's new

  • plaidshirly
  • Ph.Eitt
  • examiner
  • stleary
  • dannyward138