greetings,

"Carnivore Library for Processing" is a packet sniffer library for the Processing programming language

http://rhizome.org/carnivore/processing.php

this is beta software. please let us know if you encounter any bugs and if you have suggestions for improvement. feedback from Linux/Windows users would be especially appreciated.

//RSG

so far so good, but there do appear to be a couple of bugs. I'm running p5 91, under Mac OSX.

(1) no time stamp is being generated - I'm more familiar with the CarnivorePE/Perl model which always reported this. is it an omission ?

(2) it's generating quite a few extraneous (?) packet events which have no IP / Port addresses. the lines generated always begin ' == E ' followed by further garbled characters.

re (1) -- that's fine - it's probably easier to timestamp using the system date than parse it from the output.

re (2) -- here's some output from the basic client you wrote, and yes, I had included setShouldSkipUDP(true) in the setup.

Code:

[PDE] packetEvent:  == E  4  @ @ s V      * d P )  (  &     B      G  > : o
[PDE] packetEvent:  == E  <  @ @ s V      * e P  go        F               G  >    
[PDE] packetEvent:  == E  4  @ 1 ,    *V    P d(  & )               :  G  >
[PDE] packetEvent:  == E  <  @ 1 ,    *V    P eT[    gp    p                :  G  >
[PDE] packetEvent:  == E  4  @ @ s V      * e P  gpT[              G  > :  [PDE] packetEvent:  == E     @ @ rtV      * e P  gpT[       Q      G  > :  GET /assets/img/Banner_magnet.gif?1127290483925 HTTP/1.1  Host: adserver.openmute.org  Connection: keep-alive  Referer: http://adserver.openmute.org/banner/  User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/312.5 (KHTML, like Gecko) Safari/312.3  Accept: */*  Accept-Encoding: gzip, deflate  Accept-Language: en-us 
 

It's clear that some of this is valid packet data from the last line, but as you can see, it comes through with no IP/port info. I've been running several applications to see if this is occuring with any specific protocols, but I've not found any obvious connections.

Running the client under minivore shows very little activity even when I'm forcing network activity under various protocols both from the machine it's running on and others on the network, and again, it's seldom showing IP/port data.

running as hexivore shows more output, but again, very rarely shows IP data, and all lines commence '== 4500 ' (e followed by a null character - is this significant ? i seem to recall sockets using the null char as a terminator/delimiter)

Code:

[PDE] packetEvent:  == 4500 0030 aba2 4000 7006 15d1 5681 b8b3 5681 e39e 0570 01bd 1807 a0e7 0000 0000 7002 ffff 79b7 0000 0204 05ac 0101 0402 
[PDE] packetEvent:  == 4500 0028 2a86 4000 4006 c6f5 5681 e39e 5681 b8b3 01bd 0570 0000 0000 1807 a0e8 5014 0000 a65f 0000 
[PDE] packetEvent:  == 4500 0030 abc8 4000 7006 15ab 5681 b8b3 5681 e39e 0570 01bd 1807 a0e7 0000 0000 7002 ffff 79b7 0000 0204 05ac 0101 0402 
 

I've tried going back a few versions of p5 but all produce the same results...

there is a new version 1.3 of the carnivore library at
http://rhizome.org/carnivore/

it now returns a "CarniPacket" object instead of a string. this is
better because it is no longer necessary in processing to parse the
packet string into from address, to address, from port, etc. you simply
access the CarniPacket class members directly (example:
packet.from_port).

please refer to the new API and see sample code here
http://rhizome.org/carnivore/processing.php

note that because of this change, the concept of "channels" is no longer
necessary and has been removed entirely from the carnivore processing
library. former "carnivore" channel users can simply access
packet.ascii, and "hexivore" users can access packet.data (it's in bytes
now, not text-formated hex).

let me know if it doesn't work for you. i have only tested it on mac osx

yes, this is a feature not a bug =)

you'll notice that carnivore is giving you *two* messages here. the first is that it successfully opened your ethernet device for sniffing (the device with name starting "\Device\NPF_{DA17D4A9..."). the second is that it did not open your second device for sniffing. since your second device is  a "GenericDialupAdapter" (i.e. your modem), you should just ignore this.

basically any PC with a modem will give this warning message. sorry if this is confusing. i could suppress the "GenericDialupAdapter" message if you want?

so i'm guessing that you can capture packets, correct? if not, then there's a different bug/problem you're facing.

//RSG

fixed.

see new sample code at http://rhizome.org/carnivore/processing.php

hi. i'm not sure if what you need is doable given the current design specs for carnivore. (perhaps i'm just not understanding your situation well enough.) sorry! //RSG