jnetstream-users Mailing List for jNetStream Protocol Decoder
Brought to you by:
voytechs
Menu
▾
▴
jnetstream-users — User list for JNetStream project
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(5) |
Mar
(2) |
Apr
(3) |
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(5) |
Feb
|
Mar
(1) |
Apr
(13) |
May
(17) |
Jun
(3) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2006 |
Jan
|
Feb
(9) |
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(6) |
Aug
(13) |
Sep
(9) |
Oct
(2) |
Nov
|
Dec
|
|
From: Mark B. <voy...@ya...> - 2008-10-04 23:24:14
|
There is already a mechanism in 2.4 for this. The NPL statement is "buffer". Here is an extract of a working example. IP reassembly, but same concept can be applied to TCP. This is from a working IPv4 NPL definition: http://jnetstream.cvs.sourceforge.net/viewvc/jnetstream/jnetstream/config/pr otocols/network/IPv4.npl?view=markup if ( (flags.mf == flags.mf.MORE_FRAGS) || (offset != 0) ) { 452 /* 453 * Since this is a multi fragment message, put remainder 454 * of the data into the buffer identified by "ip.identifier" 455 * and write data starting at offset. Reads until the end of 456 * the current packet. 457 * 458 * packet.remainder = remaining number of bytes in current packet 459 * -2 = subtract Ethernet CRC at the end of the frame. 460 * offset = ip.offset which specifies the offset into the buffer 461 * to start writting at. Packets could arrive out of seq. 462 * 463 * buffer reread = start buffering while pushing the current position. 464 * Rewind the stream back to here and reprocess the 465 * rest of this packet so that all headers in this 466 * fragment packet are complete as well. This means 467 * that fields are going to be decoded twice 468 * 1) for this packet 469 * 2) when reassembly takes place on the buffer. 470 */ 471 buffer reread id, offset * 8, 0; 472 473 } 474 475 if (flags.mf == flags.mf.NO_MORE_FRAGS) { 476 /* 477 * Now process the buffer as if it were a new packet. The current 478 * processing is temporarily suspended and resumed right after the 479 * buffer processing is finished. 480 * 481 * The new packet which results from the buffer data is queued to 482 * be returned right after this fragment is returned. That is on 483 * the next nextPacket() call the decoded buffer packet is returned. 484 * 485 * identifier = buffer identifier (i.e. ip.identifier) 486 * protocol.valuename = name of the first protocol in this buffer which 487 * we take from the IP fragment protocol name. 488 */ 489 buffer process id, protocol.valuename; 490 } As to global variables, you can already set any arbitrary variable in any context, global, packet or local. Cheers, mark... > -----Original Message----- > From: zosrothko [mailto:zos...@or...] > Sent: Wednesday, October 01, 2008 1:04 PM > To: jne...@li... > Subject: [Jnetstream-users] jNetStream 2.4 extension: multi > packets TCP reassembly needs for global static variable > > Hi Mark > > I am currently working on the OSI protocol dissectors and I > got a problem with the RFC1006 > > When a RFC1006 payload is fragmented over multiple TCP > packets, there is no way to understand when the reassembly > process should be finished and the overall buffer passed to > the upper layer. That is why I am proposing you to introduce > in NPL, global static variable that can cross (i.e. > survive/persist) over packets. > > One could use this kind of static variable in order to > reassemble the fragmented packet payload much as like you > have done with the IP fragmentation case. > > IMHO, just adding the modifiers 'static' and 'global' would > be a good way to denote this feature for the already > available variable syntax, but I do not have enough knowledge > of jNetStream to propose you a patch for its implementation. > > Cheers > > zos > > > -------------------------------------------------------------- > ----------- > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge Build the coolest Linux based > applications with Moblin SDK & win great prizes Grand prize > is a trip for two to an Open Source event anywhere in the > world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jnetstream-users mailing list > Jne...@li... > https://lists.sourceforge.net/lists/listinfo/jnetstream-users |
|
From: zosrothko <zos...@or...> - 2008-10-01 17:03:57
|
Hi Mark I am currently working on the OSI protocol dissectors and I got a problem with the RFC1006 When a RFC1006 payload is fragmented over multiple TCP packets, there is no way to understand when the reassembly process should be finished and the overall buffer passed to the upper layer. That is why I am proposing you to introduce in NPL, global static variable that can cross (i.e. survive/persist) over packets. One could use this kind of static variable in order to reassemble the fragmented packet payload much as like you have done with the IP fragmentation case. IMHO, just adding the modifiers 'static' and 'global' would be a good way to denote this feature for the already available variable syntax, but I do not have enough knowledge of jNetStream to propose you a patch for its implementation. Cheers zos |
|
From: Mark B. <voy...@ya...> - 2008-09-27 22:52:35
|
David, Just wanted to add that websites have been up since yesterday afternoon. I forgot that ICMP echos are disabled on my server that's why you won't get a reply :) http works just fine. Cheers, mark... > -----Original Message----- > From: David Deyo [mailto:Dav...@am...] > Sent: Friday, September 26, 2008 7:08 PM > To: voy...@ya...; Jon Schewe > Cc: jne...@li... > Subject: RE: [Jnetstream-users] WebSite > > Mark, > > Thank you! > > -David > -----Original Message----- > From: Mark Bednarczyk [mailto:voy...@ya...] > Sent: Friday, September 26, 2008 3:04 PM > To: David Deyo; 'Jon Schewe' > Cc: jne...@li... > Subject: RE: [Jnetstream-users] WebSite > > > > > -----Original Message----- > > From: David Deyo [mailto:Dav...@am...] > > Sent: Friday, September 26, 2008 12:19 PM > > To: voy...@ya...; Jon Schewe > > Cc: jne...@li... > > Subject: RE: [Jnetstream-users] WebSite > > > > General question: > > Whenever I try to ping jnetstream.com I get ip 69.64.79.98 (dns > > lookup). > > But the ping never replies. > > > > Is jnetstream.com still up? > > Is so, is this the right ip? > > The server is completely offline right now. It will be backup later on > tonight I hope. Yes the IP looks right. > > > > > API question: > > I'm trying to use 3.0a to capture, filter and decode. > > Specifically, I'm trying get an rtp packet into an object that will > > allow me access the sequence numbers in rtp packets over a time > > period. Is this possible? If so, where could I find how > to do that, > > using the 3.0a codebase as a starting point? > > RTP is not iplemented yet. You'd have to write the protocol > yourself and > add it to the Scanner implementation. Eventually this will done > automatically directly from NPL definitions (cross compiled > into java). > > The idea with the scanner is that it contains some of the most common > protocols hard coded to allow as fast as possible scanning of > raw packet > buffers, but then rely on cross-compiled binding objects that are > generated from NPL definitions which are then tried for each protocols > (just like they are in 2.4 right now) until a match is made. Another > words, try hard coded bindings first then NPL compiled bindings as a > last resort. This way any number of standard protocols can be > hardcoded > into a scanner, but still retain flexibility to add new > protocols on the > fly. > > > > > Basically I just need to know what would have to take place > under that > > > API revision, whether it's implemented yet or not. > > (capture, format, decode) > > Once the new protocol is written you can add it to the > protocol registry > and it will be available for the decoding. The process of writing > protocols manually is a little involved and is not intended for > non-advanced users who absolutely need something. There are 4 files > involved with each protocol: > > Rtp - pure interface > RtpHeader - a class implimenting the Rtp interface + extends a > AbstractField class RtpCodec - a factory class for creating and > initializing RtpHeader objects > > then there is also the binding which is not currently implemented in > object form, but hard coded into the scanner which is implemented by > FastScanner class in one of the modules. > > 2.4 has Rtp implemented and is also real easy to use in the mean time, > although you won't achieve the speeds near what 3.0 can. > > Cheers, > mark.... > > > > > dwd > > > > > > > > -----Original Message----- > > From: Mark Bednarczyk [mailto:voy...@ya...] > > Sent: Tuesday, September 23, 2008 6:17 PM > > To: 'Jon Schewe' > > Cc: David Deyo; jne...@li... > > Subject: RE: [Jnetstream-users] WebSite > > > > Yes, something is up. But Drupal is not working. I can't get in via > > the shell account to even look at it. > > > > Cheers, > > mark... > > > > > -----Original Message----- > > > From: Jon Schewe [mailto:jps...@mt...] > > > Sent: Tuesday, September 23, 2008 7:01 PM > > > To: voy...@ya... > > > Cc: 'David Deyo'; jne...@li... > > > Subject: Re: [Jnetstream-users] WebSite > > > > > > The site seems up to me, although the content doesn't look > > so good. My > > > > > own sourceforge projects are up also. > > > > > > Mark Bednarczyk wrote: > > > > Hi David. > > > > Yes everyone is experiencing problems with > > > jnetstream.sf.net. SF.net > > > > team decided to take all the websites down for a couple of > > > week again. > > > > Therefore I'm moving everything over to a dedicated server > > > > http://jnetstream.com. As soon as I get access back to my > > > old website > > > > I'll copy all the docs and examples. > > > > > > > > > > -- > > > Jon Schewe | http://mtu.net/~jpschewe If you see an > attachment named > > > > signature.asc, this is my digital signature. See > > > http://www.gnupg.org for more information. > > > > > > For I am convinced that neither death nor life, neither > angels nor > > > demons, neither the present nor the future, nor any > powers, neither > > > height nor depth, nor anything else in all creation, will > > be able to > > > separate us from the love of God that is in Christ Jesus > > our Lord. - > > > Romans 8:38-39 > > > > > > > > > |
|
From: David D. <Dav...@am...> - 2008-09-26 23:08:10
|
Mark, Thank you! -David -----Original Message----- From: Mark Bednarczyk [mailto:voy...@ya...] Sent: Friday, September 26, 2008 3:04 PM To: David Deyo; 'Jon Schewe' Cc: jne...@li... Subject: RE: [Jnetstream-users] WebSite > -----Original Message----- > From: David Deyo [mailto:Dav...@am...] > Sent: Friday, September 26, 2008 12:19 PM > To: voy...@ya...; Jon Schewe > Cc: jne...@li... > Subject: RE: [Jnetstream-users] WebSite > > General question: > Whenever I try to ping jnetstream.com I get ip 69.64.79.98 (dns > lookup). > But the ping never replies. > > Is jnetstream.com still up? > Is so, is this the right ip? The server is completely offline right now. It will be backup later on tonight I hope. Yes the IP looks right. > > API question: > I'm trying to use 3.0a to capture, filter and decode. > Specifically, I'm trying get an rtp packet into an object that will > allow me access the sequence numbers in rtp packets over a time > period. Is this possible? If so, where could I find how to do that, > using the 3.0a codebase as a starting point? RTP is not iplemented yet. You'd have to write the protocol yourself and add it to the Scanner implementation. Eventually this will done automatically directly from NPL definitions (cross compiled into java). The idea with the scanner is that it contains some of the most common protocols hard coded to allow as fast as possible scanning of raw packet buffers, but then rely on cross-compiled binding objects that are generated from NPL definitions which are then tried for each protocols (just like they are in 2.4 right now) until a match is made. Another words, try hard coded bindings first then NPL compiled bindings as a last resort. This way any number of standard protocols can be hardcoded into a scanner, but still retain flexibility to add new protocols on the fly. > > Basically I just need to know what would have to take place under that > API revision, whether it's implemented yet or not. > (capture, format, decode) Once the new protocol is written you can add it to the protocol registry and it will be available for the decoding. The process of writing protocols manually is a little involved and is not intended for non-advanced users who absolutely need something. There are 4 files involved with each protocol: Rtp - pure interface RtpHeader - a class implimenting the Rtp interface + extends a AbstractField class RtpCodec - a factory class for creating and initializing RtpHeader objects then there is also the binding which is not currently implemented in object form, but hard coded into the scanner which is implemented by FastScanner class in one of the modules. 2.4 has Rtp implemented and is also real easy to use in the mean time, although you won't achieve the speeds near what 3.0 can. Cheers, mark.... > > dwd > > > > -----Original Message----- > From: Mark Bednarczyk [mailto:voy...@ya...] > Sent: Tuesday, September 23, 2008 6:17 PM > To: 'Jon Schewe' > Cc: David Deyo; jne...@li... > Subject: RE: [Jnetstream-users] WebSite > > Yes, something is up. But Drupal is not working. I can't get in via > the shell account to even look at it. > > Cheers, > mark... > > > -----Original Message----- > > From: Jon Schewe [mailto:jps...@mt...] > > Sent: Tuesday, September 23, 2008 7:01 PM > > To: voy...@ya... > > Cc: 'David Deyo'; jne...@li... > > Subject: Re: [Jnetstream-users] WebSite > > > > The site seems up to me, although the content doesn't look > so good. My > > > own sourceforge projects are up also. > > > > Mark Bednarczyk wrote: > > > Hi David. > > > Yes everyone is experiencing problems with > > jnetstream.sf.net. SF.net > > > team decided to take all the websites down for a couple of > > week again. > > > Therefore I'm moving everything over to a dedicated server > > > http://jnetstream.com. As soon as I get access back to my > > old website > > > I'll copy all the docs and examples. > > > > > > > -- > > Jon Schewe | http://mtu.net/~jpschewe If you see an attachment named > > signature.asc, this is my digital signature. See > > http://www.gnupg.org for more information. > > > > For I am convinced that neither death nor life, neither angels nor > > demons, neither the present nor the future, nor any powers, neither > > height nor depth, nor anything else in all creation, will > be able to > > separate us from the love of God that is in Christ Jesus > our Lord. - > > Romans 8:38-39 > > > > |
|
From: Mark B. <voy...@ya...> - 2008-09-26 20:02:25
|
> -----Original Message----- > From: David Deyo [mailto:Dav...@am...] > Sent: Friday, September 26, 2008 12:19 PM > To: voy...@ya...; Jon Schewe > Cc: jne...@li... > Subject: RE: [Jnetstream-users] WebSite > > General question: > Whenever I try to ping jnetstream.com I get ip 69.64.79.98 > (dns lookup). > But the ping never replies. > > Is jnetstream.com still up? > Is so, is this the right ip? The server is completely offline right now. It will be backup later on tonight I hope. Yes the IP looks right. > > API question: > I'm trying to use 3.0a to capture, filter and decode. > Specifically, I'm trying get an rtp packet into an object > that will allow me access the sequence numbers in rtp > packets over a time period. Is this possible? If so, where > could I find how to do that, using the 3.0a codebase as a > starting point? RTP is not iplemented yet. You'd have to write the protocol yourself and add it to the Scanner implementation. Eventually this will done automatically directly from NPL definitions (cross compiled into java). The idea with the scanner is that it contains some of the most common protocols hard coded to allow as fast as possible scanning of raw packet buffers, but then rely on cross-compiled binding objects that are generated from NPL definitions which are then tried for each protocols (just like they are in 2.4 right now) until a match is made. Another words, try hard coded bindings first then NPL compiled bindings as a last resort. This way any number of standard protocols can be hardcoded into a scanner, but still retain flexibility to add new protocols on the fly. > > Basically I just need to know what would have to take place > under that API revision, whether it's implemented yet or not. > (capture, format, decode) Once the new protocol is written you can add it to the protocol registry and it will be available for the decoding. The process of writing protocols manually is a little involved and is not intended for non-advanced users who absolutely need something. There are 4 files involved with each protocol: Rtp - pure interface RtpHeader - a class implimenting the Rtp interface + extends a AbstractField class RtpCodec - a factory class for creating and initializing RtpHeader objects then there is also the binding which is not currently implemented in object form, but hard coded into the scanner which is implemented by FastScanner class in one of the modules. 2.4 has Rtp implemented and is also real easy to use in the mean time, although you won't achieve the speeds near what 3.0 can. Cheers, mark.... > > dwd > > > > -----Original Message----- > From: Mark Bednarczyk [mailto:voy...@ya...] > Sent: Tuesday, September 23, 2008 6:17 PM > To: 'Jon Schewe' > Cc: David Deyo; jne...@li... > Subject: RE: [Jnetstream-users] WebSite > > Yes, something is up. But Drupal is not working. I can't get > in via the shell account to even look at it. > > Cheers, > mark... > > > -----Original Message----- > > From: Jon Schewe [mailto:jps...@mt...] > > Sent: Tuesday, September 23, 2008 7:01 PM > > To: voy...@ya... > > Cc: 'David Deyo'; jne...@li... > > Subject: Re: [Jnetstream-users] WebSite > > > > The site seems up to me, although the content doesn't look > so good. My > > > own sourceforge projects are up also. > > > > Mark Bednarczyk wrote: > > > Hi David. > > > Yes everyone is experiencing problems with > > jnetstream.sf.net. SF.net > > > team decided to take all the websites down for a couple of > > week again. > > > Therefore I'm moving everything over to a dedicated server > > > http://jnetstream.com. As soon as I get access back to my > > old website > > > I'll copy all the docs and examples. > > > > > > > -- > > Jon Schewe | http://mtu.net/~jpschewe > > If you see an attachment named signature.asc, this is my digital > > signature. See http://www.gnupg.org for more information. > > > > For I am convinced that neither death nor life, neither angels nor > > demons, neither the present nor the future, nor any powers, neither > > height nor depth, nor anything else in all creation, will > be able to > > separate us from the love of God that is in Christ Jesus > our Lord. - > > Romans 8:38-39 > > > > |
|
From: David D. <Dav...@am...> - 2008-09-26 16:19:04
|
General question: Whenever I try to ping jnetstream.com I get ip 69.64.79.98 (dns lookup). But the ping never replies. Is jnetstream.com still up? Is so, is this the right ip? API question: I'm trying to use 3.0a to capture, filter and decode. Specifically, I'm trying get an rtp packet into an object that will allow me access the sequence numbers in rtp packets over a time period. Is this possible? If so, where could I find how to do that, using the 3.0a codebase as a starting point? Basically I just need to know what would have to take place under that API revision, whether it's implemented yet or not. (capture, format, decode) dwd -----Original Message----- From: Mark Bednarczyk [mailto:voy...@ya...] Sent: Tuesday, September 23, 2008 6:17 PM To: 'Jon Schewe' Cc: David Deyo; jne...@li... Subject: RE: [Jnetstream-users] WebSite Yes, something is up. But Drupal is not working. I can't get in via the shell account to even look at it. Cheers, mark... > -----Original Message----- > From: Jon Schewe [mailto:jps...@mt...] > Sent: Tuesday, September 23, 2008 7:01 PM > To: voy...@ya... > Cc: 'David Deyo'; jne...@li... > Subject: Re: [Jnetstream-users] WebSite > > The site seems up to me, although the content doesn't look so good. My > own sourceforge projects are up also. > > Mark Bednarczyk wrote: > > Hi David. > > Yes everyone is experiencing problems with > jnetstream.sf.net. SF.net > > team decided to take all the websites down for a couple of > week again. > > Therefore I'm moving everything over to a dedicated server > > http://jnetstream.com. As soon as I get access back to my > old website > > I'll copy all the docs and examples. > > > > -- > Jon Schewe | http://mtu.net/~jpschewe > If you see an attachment named signature.asc, this is my digital > signature. See http://www.gnupg.org for more information. > > For I am convinced that neither death nor life, neither angels nor > demons, neither the present nor the future, nor any powers, neither > height nor depth, nor anything else in all creation, will be able to > separate us from the love of God that is in Christ Jesus our Lord. - > Romans 8:38-39 > |
|
From: Mark B. <voy...@ya...> - 2008-09-26 12:58:06
|
SF.net website is non functional after hosting move by SF.net team and I can't fix it. I'm moving the webserver over to my company's server (http://jnetstream.com and http://jnetpcap.com) which is also currently down for a logistical reason and should be back up today or tomorrow at the latest. Just in case you are wondering where all the webserver have gone. Everything should be back to normal by tomorrow. Cheers, mark... |
|
From: Mark B. <voy...@ya...> - 2008-09-23 23:15:22
|
Yes, something is up. But Drupal is not working. I can't get in via the shell account to even look at it. Cheers, mark... > -----Original Message----- > From: Jon Schewe [mailto:jps...@mt...] > Sent: Tuesday, September 23, 2008 7:01 PM > To: voy...@ya... > Cc: 'David Deyo'; jne...@li... > Subject: Re: [Jnetstream-users] WebSite > > The site seems up to me, although the content doesn't look so > good. My own sourceforge projects are up also. > > Mark Bednarczyk wrote: > > Hi David. > > Yes everyone is experiencing problems with > jnetstream.sf.net. SF.net > > team decided to take all the websites down for a couple of > week again. > > Therefore I'm moving everything over to a dedicated server > > http://jnetstream.com. As soon as I get access back to my > old website > > I'll copy all the docs and examples. > > > > -- > Jon Schewe | http://mtu.net/~jpschewe > If you see an attachment named signature.asc, this is my > digital signature. See http://www.gnupg.org for more information. > > For I am convinced that neither death nor life, neither > angels nor demons, neither the present nor the future, nor > any powers, neither height nor depth, nor anything else in > all creation, will be able to separate us from the love of > God that is in Christ Jesus our Lord. - Romans 8:38-39 > |
|
From: Jon S. <jps...@mt...> - 2008-09-23 23:01:29
|
The site seems up to me, although the content doesn't look so good. My own sourceforge projects are up also. Mark Bednarczyk wrote: > Hi David. > Yes everyone is experiencing problems with jnetstream.sf.net. SF.net > team decided to take all the websites down for a couple of week again. > Therefore I'm moving everything over to a dedicated server > http://jnetstream.com. As soon as I get access back to my old website I'll > copy all the docs and examples. > -- Jon Schewe | http://mtu.net/~jpschewe If you see an attachment named signature.asc, this is my digital signature. See http://www.gnupg.org for more information. For I am convinced that neither death nor life, neither angels nor demons, neither the present nor the future, nor any powers, neither height nor depth, nor anything else in all creation, will be able to separate us from the love of God that is in Christ Jesus our Lord. - Romans 8:38-39 |
|
From: Mark B. <voy...@ya...> - 2008-09-23 18:26:26
|
Hi David. Yes everyone is experiencing problems with jnetstream.sf.net. SF.net team decided to take all the websites down for a couple of week again. Therefore I'm moving everything over to a dedicated server http://jnetstream.com. As soon as I get access back to my old website I'll copy all the docs and examples. more answers inline below.... > -----Original Message----- > From: David Deyo [mailto:Dav...@am...] > Sent: Tuesday, September 23, 2008 2:08 PM > To: jne...@li... > Subject: WebSite > > I'm not sure I understand how to start to use jnetstream. Right now there are 2 version 3.0a1 which is an alpha release I'm working on. You can capture packets and have limited decoding capabilities right now. Version 2.4 has much better decoding capabilities but no live capture support. I've updated 2.4 release with live capture support this weekend and will release it as 2.5. I'm not actively adding features to that old branch, but per many requests I did add the live capture support. 3.0 branch is a lot different from 2.4 in terms of API, speed and functionality. Its much more capable than 2.4 was, but its still under heavy development. > > The apparent latest version for Windows from sourceforge > (jnetstream-3.0a1-win32.zip) > has a couple jars and a dll. In that zip file the jar > jnetstream-3.0a1.jar has an org/ package. On windows you need to add the DLL to \windows directory to to PATH variable in your autoexec.bat. The jars go into your CLASSPATH. http://jnetstream.com has a link to javadocs for 3.0 and 2.4. > I can't seem to find the source tree from cvs or svn that has > that package in it. 2.4 branch is under CVS control while 3.0 is in SVN. You can browse or checkout the source from sf.net using the instructions from main project home page in SF.net > > In older version of jnetstream, there's a standalone > executable jar that allows decoding packets from files. Can > I use jnetstream to both capture and decode a packet? Yes the 2.4 has an application called "slydecoder" but no live capture capabilities only files. The 3.0 doesn't have an application like that at this point. Its just a development library. After I have it 3.0 working correctly I will supply an application like slydecoder, but should be much more capable with file editing capabilities, etc... > > Is there a pdf or readme that covers this type and detail of usage? Yes, on the old jnetstream.sf.net website which has been down for days now :( Cheers, mark... > > > > p.s. > > Is everyone experiencing a problem accessing > http://jnetstream.sourceforge.net/? > > dwd > > |
|
From: David D. <Dav...@am...> - 2008-09-23 18:24:48
|
Is everyone experiencing a problem accessing http://jnetstream.sourceforge.net/ <http://jnetstream.sourceforge.net/> ? |
|
From: Mark B. <voy...@ya...> - 2008-08-26 20:31:37
|
My back is getting better but has really put me out of action for nearly 3 weeks since I came back from Europe. I'm able to work fulltime on jNetStream once again :) Anyway, almost done with the filters. I had to rewrite a lot of the filter API and there are so many dependencies all over. I also added a couple of small variations to jNetPcap to allow faster filter processing in Pcap native BPF virtual machine and basically made jNetPcap BPFProgram compatible with jNetPcap BpfProgram without having to convert between the 2. The jNetPcap API is fully backward compatible with jNetPcap 1.1. I needed to make the necessary changes to filtering API now, since this is low level stuff, before heading over to NPL compiler. I should be done with the filter by tomorrow. CaptureDispatcher with filtering mechanism is already working. Also the ground work for Analyzers is also done. So basically I'm just closing things up and will release a daily build as soon as it all jUnit tests correctly. Then move on to NPL compiler and get those about 60 NPL protocols compiled :) For those interested in a little more here is how things work now in relation to filters and dispatcher. There are many options for filters now. The defaults provide the fastest possible combination which can be overridden. There are 3 types of enum tables which influence how filters are applied: 1) FilterExpression.Type = provides constants for the type of syntax of the filter expression Type.PCAP, Type.NPL, Type.WIRESHARK, Type.SNORT, etc... 2) Filter.Type = The type of filter this is. Type.BPF_KERNEL, Type.BPF_NATIVE, Type.BPF_JAVA, Type.JAVA_VM and others which are "file" record related. 3) Filter.Strategy = Allows the user to suggest a filtering strategy. Strategy.DEFAULT, Strategy.KERNEL, Strategy.KERNEL_IF_POSSIBLE, Strategy.NATIVE, NATIVE_IF_POSSIBLE, INTERPRETED With pretty good defaults chosen. But the user has control over how filters are applied both on each network interface (CaptureDevice) for each capture session and for dispatcher filters which are applied as packets are dispatched to listeners to filter out only required packets. The dispatcher is part of the capture session (main Capture interface) and allows listeners to register with any capture session. There are various events for which a listener can be registered as well as an efficient mechanism for dispatching packets. This second mechanism can completely replace the foreground iterator based approach for fetching packets using iterator's hasNext() and next() methods where now packets can be dispatched to listeners. In addition, each listener can have a packet filter applied before packets are dispatched. This allows different listeners to have different packets delivered to them efficiently from the same capture session. The dispatcher can dispatch raw byte buffers or packet objects, depending on what is needed by each Analyzer. Raw byte buffers are the most efficient means of acquiring packets as they can potentially avoid any overhead with decoding packets into object state especially when an analyzer knows exactly what its looking for within a raw buffer. The capture session also provides Capture.loopForeground() and Capture.loopBackground() methods which dispatch packets via a dispatcher loop (threaded and non-threaded or blocking/nonblocking). Analyzers can now efficiently hook onto a Capture session, specify exactly what they are interested in and do their own processing in separate threads. Writing analyzers is the fun part and I will squeeze in between next releases at minimum the Flow, TCP and Statistics analyzers to provide capture and protocol statistics, reconstruct tcp streams, analyze for errors/warnings and group packets into network flows. There have been too many delays over this summer with my progress, but I hope to make all this up quickly over the next few weeks. Cheers, mark.... "The definition for insanity is doing the same thing over and over again and expecting a different result" - Albert Einstein |
|
From: Mark B. <voy...@ya...> - 2008-08-07 21:12:29
|
I'm somewhat back in action :)
I'm looking into the BitBuffer issue reported and also working on filters.
As soon as I have something concrete written or fixed, I'll make an
immediate daily build.
The live-capture module will be used to compile libpcap expression using
Pcap.compileNoPcap() call found in jNetPcap library. Then compiled filters
will be appropriately set depending on the type of capture. If its a live
capture (a live network interface), a normal Pcap.setFilter() will be used,
if the capture is a jNS file type such as SnoopFile or PcapFile then
appropriate BPF Virtual Machine will be chosen. Remember jNS doesn't utilize
jNetPcap's Pcap.openOffline() call to read in libpcap files, but supplies
its own implementation in java which includes full editing capabilities.
On Win32 systems the native libpcap BPF VM will be used using
WinPcap.offlineFilter() call, and on all other platforms the jNS provided
pure java BPF VM implementation. Since the compiled BPF bytecodes are
fairely short, there isn't any noticable difference in speed between the
native BPF VM and the java BPF VM jNS provides. Except when the filter is
set in the kernel and packets are filtered close to the NIC, that can only
be implemented by jNetPcap anyway.
I'm also begining work on analyzers starting with the Flow and TCP
analyzers. That is why the filters have to implemented first as analyzers
need a very efficient way of selecting a set of packets from all the
incoming packets. The goal is so that raw buffers can be delivered to an
analyzer, then the analyzer may choose to instantiate a packet or not,
depending on what its' function is. This way we avoid the overhead of
creating a packet to be passed to an analyzer that may decide that the
packet is not needed, or that it only needs a certain payload from the
buffer and discards everything else. Filters work at the ByteBuffer level,
not the packet object level, so we may be able to avoid creating packets
until the user requests them. But if the user also doesn't need packet
objects and can work with raw buffers, then no packets will ever have to be
instantiated yet flows and tcp streams will be collected.
For those interested, a little about how the filters were designed in jNS.
There are 3 components to a filter.
1) Filter VM type = currently only BPF VM is supported. In the future,
direct compilation to java byte code will be provided as well for non live
capture filters.
2) Filter Expression = Pcap and NPL expressions are supported, although NPL
doesn't work yet (until the NPL compiler is finished)
3) FilterTarget = ProtocolTarget and FileRecordTarget. ProtocolTarget tells
jNS to scan the contents of the packet, while FileRecordTarget tells jNS to
scan the record headers of capture files and leave the packet contents
alone. When you use any of of the File.seek() operations for example you are
using a set of builtin FileRecordTarget targets.
So FilterExpression takes a string and compiles it based on the subclass
that implements that interface. PcapExpression for example uses a libpcap
compiler to compile the expression, while NplExpression uses a NPL compiler
to compile and generate the neccessary BPF byte code program.
I'm going to slightly alter the API and add a new factory method
Captures.setDefaultFilterExpressionType(FilterExpressionType type) which
will allow the user to override the default FilterExpression type when using
any of the capture factory methods that take a filter as a string. Those are
convenient methods such as Capture.openLive(String filter_expression), but
they do not allow the user currently to override how the expression is to be
interpreted. So you'll be able to do as follows:
Captures.setDefaultFilterExpressionType(FilterExpressionType.PCAP);
Captures.setDefaultFilterType(FilterType.BPF);
Captures.openLive("host 192.168.1.1");
The alternative is to explicitely set the expression type in the open call:
Captures.openLive(new PcapBpfFilter("host 192.168.1.1");
Or using the capture.setFilter(new PcapBpfFilter("host 192.168.1.1");
Other combinations that will be possible are FilterExpressionType.NPL and
FilterType.JASM. The defaults are PCAP and BPF for expression and filter
type.
This type of filter architecture provides great flexibility. Expression
syntax is separated from actual filter implementation. Other filter types
could be propriatory filter byte codes that are implemented on certain NICs
by vendors. Could even create filters for custom capture file formats that
utilize for example a database of information about packets stored in that
file for super efficiency. (That is something that jNetStream's NAP file
format provides support for.)
Cheers,
mark...
-----------------------------
|
|
From: Mark B. <voy...@ya...> - 2008-08-06 16:21:20
|
Thanks Frederic,
I'm still out of commission myself.
I will revist the BitBuffer as that is a core routine that has to be 100%
correct all the time under all circumstances.
Cheers,
mark...
----- Original Message -----
From: "Frédéric Dreier" <fre...@dr...>
Cc: <Jne...@li...>
Sent: Wednesday, August 06, 2008 4:31 PM
Subject: Re: [Jnetstream-users] Error in TCP decode
Good morning Mark,
I will be unreachable until next monday so I already send you what I found.
- my implementation of readBitsOneAtATime(). Perhaps it is not so good
but it just does the trick until the original one will be fixed.
- something in FastScanner didn't work after I changed
readBitsOneAtATime(). 32 kept to be added to the ip header length.
Regards,
Frédéric
Fast Scanner ---------------------------------
/**
*
*/
public final boolean scanIp4() {
addToCache(IP4);
r1 = readUByte(Ip4.StaticField.PROTOCOL);
if (DEBUG) {
logger.debug(String.format("Ip4 p=%d, r1=%d\n", offset, r1));
}
//offset += bits.getBits(offset + 4, 4) * 4 * 8 + 32; <<== why +32 ?
offset += bits.getBits(offset + 4, 4) * 32;
switch (r1) {
case 1:
return scanIcmp();
case 6:
return scanTcp();
case 17:
return scanUdp();
}
return true;
}
BitBuffer -------------------------------------
private static final int[] RIGHT_BIT_MASK = new int[33];
static {
// initialize mask used by readBitsOneAtATime()
for (int i = 1; i < RIGHT_BIT_MASK.length; i++) {
RIGHT_BIT_MASK[i] = (RIGHT_BIT_MASK[i - 1] << 1) | 1;
}
}
private int readBitsOneAtATime(int length) {
// basic checks to avoid unnecessary computation
if (length == 0) {
return 0;
}
if (length > 32) {
throw new IndexOutOfBoundsException("0 >= range <= 32bits");
}
// value is stored in long since length+posBits
// could be greater than 32.
long value = current;
int acc = 8 - posBits;
// concatenate buffer byte per byte
for (; acc < length; acc += 8) {
// fetch next byte
posBits = 8;
fetch();
// append new current byte
value = (value << 8) | (current & 0xFF);
}
// right-align the bits and mask high bits
value = (value >> (acc - length)) & RIGHT_BIT_MASK[length];
// update posBits value
posBits = (posBits + length) % 8;
// return
return (int) value;
}
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jnetstream-users mailing list
Jne...@li...
https://lists.sourceforge.net/lists/listinfo/jnetstream-users
|
|
From: Frédéric D. <fre...@dr...> - 2008-08-06 14:31:30
|
Good morning Mark,
I will be unreachable until next monday so I already send you what I found.
- my implementation of readBitsOneAtATime(). Perhaps it is not so good
but it just does the trick until the original one will be fixed.
- something in FastScanner didn't work after I changed
readBitsOneAtATime(). 32 kept to be added to the ip header length.
Regards,
Frédéric
Fast Scanner ---------------------------------
/**
*
*/
public final boolean scanIp4() {
addToCache(IP4);
r1 = readUByte(Ip4.StaticField.PROTOCOL);
if (DEBUG) {
logger.debug(String.format("Ip4 p=%d, r1=%d\n", offset, r1));
}
//offset += bits.getBits(offset + 4, 4) * 4 * 8 + 32; <<== why +32 ?
offset += bits.getBits(offset + 4, 4) * 32;
switch (r1) {
case 1:
return scanIcmp();
case 6:
return scanTcp();
case 17:
return scanUdp();
}
return true;
}
BitBuffer -------------------------------------
private static final int[] RIGHT_BIT_MASK = new int[33];
static {
// initialize mask used by readBitsOneAtATime()
for (int i = 1; i < RIGHT_BIT_MASK.length; i++) {
RIGHT_BIT_MASK[i] = (RIGHT_BIT_MASK[i - 1] << 1) | 1;
}
}
private int readBitsOneAtATime(int length) {
// basic checks to avoid unnecessary computation
if (length == 0) {
return 0;
}
if (length > 32) {
throw new IndexOutOfBoundsException("0 >= range <= 32bits");
}
// value is stored in long since length+posBits
// could be greater than 32.
long value = current;
int acc = 8 - posBits;
// concatenate buffer byte per byte
for (; acc < length; acc += 8) {
// fetch next byte
posBits = 8;
fetch();
// append new current byte
value = (value << 8) | (current & 0xFF);
}
// right-align the bits and mask high bits
value = (value >> (acc - length)) & RIGHT_BIT_MASK[length];
// update posBits value
posBits = (posBits + length) % 8;
// return
return (int) value;
}
|
|
From: Joshua P. <jph...@la...> - 2008-08-06 02:11:07
|
I use maven at work, and honestly its more of a pain than it's worth in my opinion. The only usefull thing that it provides to me is the dependency management. I have to agree, it is up to Mark, but I thought I would throw in my $0.02. Regards, Joshua Pheneger >Due to the modularity of the system, Maven makes very god sense as a >build system. I tried using the MasterBuild system and quickly ran >into problems. > >Would you consider the use of Maven to bild and release your project? >If so, I'll volunteer to write Maven based module build system for >you. Also, if you are interested, would you consider changing your >directory structure to the default Maven structure of src/main/java vs >src/java? > >If you like, I could probably have this thrown together by tomorrow. > >Birch > >------------------------------------------------------------------------- >This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >Build the coolest Linux based applications with Moblin SDK & win great prizes >Grand prize is a trip for two to an Open Source event anywhere in the world >http://moblin-contest.org/redirect.php?banner_id=100&url=/ >_______________________________________________ >Jnetstream-users mailing list >Jne...@li... >https://lists.sourceforge.net/lists/listinfo/jnetstream-users > _______________________________________________________________________ Internet Access, Shared & Dedicated Web Hosting. Colocation and Domain Name Registration at http://www.SharedPoint.com |
|
From: Frédéric D. <fre...@dr...> - 2008-08-05 18:19:39
|
Actually I will fligh back in europe tomorrow and also have to visit my
chiro :-)
Actually the "readBitsOneAtATime()" I posted correct something but break
the TCP decoding (start offset is wrong). so I will look at it again (I
find the exercise quite interessting) and I could wait some days. No
problem, really. I will share my thoughts if I find something pertinent.
Regards,
Frederic
Mark Bednarczyk a écrit :
> I made changes in there recently. Its possible I screwed up.
>
> I hurt my back coming back from Europe yesterday and I can barely sit at the
> computer right now. Hopefully tomorrow I'll feel better after my visit to
> the chiropractor today and be able to take a look at the problem quickly. I
> do have some jUnit test cases checked in that test various BitBuffer
> conditions in the CommonUtils module.
>
> Cheers,
> mark...
>
>
>> -----Original Message-----
>> From: jne...@li...
>> [mailto:jne...@li...] On
>> Behalf Of Frédéric Dreier
>> Sent: Tuesday, August 05, 2008 1:10 PM
>> To: Jne...@li...
>> Subject: Re: [Jnetstream-users] Error in TCP decode
>>
>> Hi,
>>
>> I checkout the code from SVN and I thing there is something
>> odd in the "BitBuffer.readBitsOneAtATime()" method. Its
>> probably about the posBits which ich not always added to the offset.
>>
>> I temporary use the following implementation until a fix is
>> commited in SVN (This concats the buffer byte per byte
>> instead bit per bit)
>>
>> Regards,
>> Frédéric
>>
>> private static final int[] RIGHT_BIT_MASK = new int[32];
>> static {
>> // initialize mask used by readBitsOneAtATime()
>> for (int i = 1; i < RIGHT_BIT_MASK.length; i++) {
>> RIGHT_BIT_MASK[i] = (RIGHT_BIT_MASK[i - 1] << 1) | 1;
>> }
>> }
>>
>> private int readBitsOneAtATime(int length) {
>> // basic checks to avoid unnecessary computation
>> if (length == 0) {
>> return 0;
>> }
>> if (length > 32) {
>> throw new IndexOutOfBoundsException("0 >= range
>> <= 32bits");
>> }
>> // value is stored in long since length+posBits
>> // could be greater than 32.
>> long value = current;
>> int acc = 8 - posBits;
>> // concatenate buffer byte per byte
>> for (; acc < length; acc += 8) {
>> // fetch next byte
>> posBits = 8;
>> fetch();
>> // append new current byte
>> value = (value << 8) | (current & 0xFF);
>> }
>> // right-align the bits and mask high bits
>> value = (value >> (acc - length)) & RIGHT_BIT_MASK[length];
>> // update posBits value
>> posBits = (posBits + length) % 8;
>> // return
>> return (int) value;
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>> Frédéric Dreier a écrit :
>>
>>> Hi,
>>>
>>> I have some trouble decoding IP and TCP headers. the header length
>>> and the offset are wrongly decoded in most of the packets.
>>>
>>> Did I do something wrong?
>>>
>>> Regards,
>>> Frederic Dreier
>>>
>>>
>>>
>>> Console output ------------------------------- PACKET DUMP::
>>> 00 12 3F 19 FC 3F 00 07
>>> 84 BC A0 C0 08 00 45 00
>>> 00 28 9D 7A 40 00 2B 06
>>> 25 94 D0 50 98 03 81 AD
>>> A2 C0 00 50 D7 59 29 F4
>>> BC EF 33 C8 F3 C5 50 11
>>> Vers : 4
>>> Hlen : 4 <----- should be 5
>>> TOS : 0
>>> Lgt : 40
>>> ident: 40314
>>> flags: 2
>>> offs : 1 <---- should be 0
>>> TTL : 43
>>> Prot : 6
>>> Src : 208.80.152.3
>>> Dst : 129.173.162.192
>>> Console output -------------------------------
>>>
>>>
>>>
>>> Code snipet ------------------------------
>>> Ip4 ipHd = packet.getHeader(Ip4.class);
>>> Tcp tcpHd = packet.getHeader(Tcp.class);
>>> System.out.println("PACKET DUMP::");
>>> for (int i = 0; i < 6; i++) {
>>> for (int k = i * 8; k < ((i
>>>
>> + 1) * 8);
>>
>>> k++) {
>>> System.out.printf("%02X ",
>>> packet.getBuffer().getBackingBuffer().get(k) & 0xFF);
>>> }
>>> System.out.println();
>>> }
>>> System.out.printf("Vers : %d\n",
>>>
>> ipHd.ver());
>>
>>> System.out.printf("Hlen : %d\n",
>>>
>> ipHd.hlen());
>>
>>> System.out.printf("TOS : %d\n",
>>>
>> ipHd.tos());
>>
>>> System.out.printf("Lgt : %d\n",
>>>
>> ipHd.length());
>>
>>> System.out.printf("ident: %d\n",
>>> ipHd.id()&0xFFFF);
>>> System.out.printf("flags: %d\n",
>>>
>> ipHd.flags());
>>
>>> System.out.printf("offs : %d\n",
>>>
>> ipHd.offset());
>>
>>> System.out.printf("TTL : %d\n",
>>>
>> ipHd.ttl());
>>
>>> System.out.printf("Prot : %d\n",
>>> ipHd.protocol());
>>> System.out.printf("Src : %s\n",
>>>
>> ipHd.source());
>>
>>> System.out.printf("Dst : %s\n",
>>> ipHd.destination());
>>> --------------------------------------------
>>>
>>>
>>>
>> --------------------------------------------------------------
>> -----------
>>
>>> This SF.Net email is sponsored by the Moblin Your Move
>>>
>> Developer's challenge
>>
>>> Build the coolest Linux based applications with Moblin SDK
>>>
>> & win great prizes
>>
>>> Grand prize is a trip for two to an Open Source event
>>>
>> anywhere in the world
>>
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Jnetstream-users mailing list
>>> Jne...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jnetstream-users
>>>
>>>
>> --------------------------------------------------------------
>> -----------
>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK &
>> win great prizes
>> Grand prize is a trip for two to an Open Source event
>> anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Jnetstream-users mailing list
>> Jne...@li...
>> https://lists.sourceforge.net/lists/listinfo/jnetstream-users
>>
>
>
>
|
|
From: Mark B. <voy...@ya...> - 2008-08-05 17:33:11
|
I made changes in there recently. Its possible I screwed up.
I hurt my back coming back from Europe yesterday and I can barely sit at the
computer right now. Hopefully tomorrow I'll feel better after my visit to
the chiropractor today and be able to take a look at the problem quickly. I
do have some jUnit test cases checked in that test various BitBuffer
conditions in the CommonUtils module.
Cheers,
mark...
> -----Original Message-----
> From: jne...@li...
> [mailto:jne...@li...] On
> Behalf Of Frédéric Dreier
> Sent: Tuesday, August 05, 2008 1:10 PM
> To: Jne...@li...
> Subject: Re: [Jnetstream-users] Error in TCP decode
>
> Hi,
>
> I checkout the code from SVN and I thing there is something
> odd in the "BitBuffer.readBitsOneAtATime()" method. Its
> probably about the posBits which ich not always added to the offset.
>
> I temporary use the following implementation until a fix is
> commited in SVN (This concats the buffer byte per byte
> instead bit per bit)
>
> Regards,
> Frédéric
>
> private static final int[] RIGHT_BIT_MASK = new int[32];
> static {
> // initialize mask used by readBitsOneAtATime()
> for (int i = 1; i < RIGHT_BIT_MASK.length; i++) {
> RIGHT_BIT_MASK[i] = (RIGHT_BIT_MASK[i - 1] << 1) | 1;
> }
> }
>
> private int readBitsOneAtATime(int length) {
> // basic checks to avoid unnecessary computation
> if (length == 0) {
> return 0;
> }
> if (length > 32) {
> throw new IndexOutOfBoundsException("0 >= range
> <= 32bits");
> }
> // value is stored in long since length+posBits
> // could be greater than 32.
> long value = current;
> int acc = 8 - posBits;
> // concatenate buffer byte per byte
> for (; acc < length; acc += 8) {
> // fetch next byte
> posBits = 8;
> fetch();
> // append new current byte
> value = (value << 8) | (current & 0xFF);
> }
> // right-align the bits and mask high bits
> value = (value >> (acc - length)) & RIGHT_BIT_MASK[length];
> // update posBits value
> posBits = (posBits + length) % 8;
> // return
> return (int) value;
> }
>
>
>
>
>
>
>
>
> Frédéric Dreier a écrit :
> > Hi,
> >
> > I have some trouble decoding IP and TCP headers. the header length
> > and the offset are wrongly decoded in most of the packets.
> >
> > Did I do something wrong?
> >
> > Regards,
> > Frederic Dreier
> >
> >
> >
> > Console output ------------------------------- PACKET DUMP::
> > 00 12 3F 19 FC 3F 00 07
> > 84 BC A0 C0 08 00 45 00
> > 00 28 9D 7A 40 00 2B 06
> > 25 94 D0 50 98 03 81 AD
> > A2 C0 00 50 D7 59 29 F4
> > BC EF 33 C8 F3 C5 50 11
> > Vers : 4
> > Hlen : 4 <----- should be 5
> > TOS : 0
> > Lgt : 40
> > ident: 40314
> > flags: 2
> > offs : 1 <---- should be 0
> > TTL : 43
> > Prot : 6
> > Src : 208.80.152.3
> > Dst : 129.173.162.192
> > Console output -------------------------------
> >
> >
> >
> > Code snipet ------------------------------
> > Ip4 ipHd = packet.getHeader(Ip4.class);
> > Tcp tcpHd = packet.getHeader(Tcp.class);
> > System.out.println("PACKET DUMP::");
> > for (int i = 0; i < 6; i++) {
> > for (int k = i * 8; k < ((i
> + 1) * 8);
> > k++) {
> > System.out.printf("%02X ",
> > packet.getBuffer().getBackingBuffer().get(k) & 0xFF);
> > }
> > System.out.println();
> > }
> > System.out.printf("Vers : %d\n",
> ipHd.ver());
> > System.out.printf("Hlen : %d\n",
> ipHd.hlen());
> > System.out.printf("TOS : %d\n",
> ipHd.tos());
> > System.out.printf("Lgt : %d\n",
> ipHd.length());
> > System.out.printf("ident: %d\n",
> > ipHd.id()&0xFFFF);
> > System.out.printf("flags: %d\n",
> ipHd.flags());
> > System.out.printf("offs : %d\n",
> ipHd.offset());
> > System.out.printf("TTL : %d\n",
> ipHd.ttl());
> > System.out.printf("Prot : %d\n",
> > ipHd.protocol());
> > System.out.printf("Src : %s\n",
> ipHd.source());
> > System.out.printf("Dst : %s\n",
> > ipHd.destination());
> > --------------------------------------------
> >
> >
> --------------------------------------------------------------
> -----------
> > This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> > Grand prize is a trip for two to an Open Source event
> anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Jnetstream-users mailing list
> > Jne...@li...
> > https://lists.sourceforge.net/lists/listinfo/jnetstream-users
> >
>
>
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK &
> win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jnetstream-users mailing list
> Jne...@li...
> https://lists.sourceforge.net/lists/listinfo/jnetstream-users
|
|
From: Frédéric D. <fre...@dr...> - 2008-08-05 17:10:11
|
Hi,
I checkout the code from SVN and I thing there is something odd in the
"BitBuffer.readBitsOneAtATime()" method. Its probably about the posBits
which ich not always added to the offset.
I temporary use the following implementation until a fix is commited in
SVN (This concats the buffer byte per byte instead bit per bit)
Regards,
Frédéric
private static final int[] RIGHT_BIT_MASK = new int[32];
static {
// initialize mask used by readBitsOneAtATime()
for (int i = 1; i < RIGHT_BIT_MASK.length; i++) {
RIGHT_BIT_MASK[i] = (RIGHT_BIT_MASK[i - 1] << 1) | 1;
}
}
private int readBitsOneAtATime(int length) {
// basic checks to avoid unnecessary computation
if (length == 0) {
return 0;
}
if (length > 32) {
throw new IndexOutOfBoundsException("0 >= range <= 32bits");
}
// value is stored in long since length+posBits
// could be greater than 32.
long value = current;
int acc = 8 - posBits;
// concatenate buffer byte per byte
for (; acc < length; acc += 8) {
// fetch next byte
posBits = 8;
fetch();
// append new current byte
value = (value << 8) | (current & 0xFF);
}
// right-align the bits and mask high bits
value = (value >> (acc - length)) & RIGHT_BIT_MASK[length];
// update posBits value
posBits = (posBits + length) % 8;
// return
return (int) value;
}
Frédéric Dreier a écrit :
> Hi,
>
> I have some trouble decoding IP and TCP headers. the header length and
> the offset are wrongly decoded in most of the packets.
>
> Did I do something wrong?
>
> Regards,
> Frederic Dreier
>
>
>
> Console output -------------------------------
> PACKET DUMP::
> 00 12 3F 19 FC 3F 00 07
> 84 BC A0 C0 08 00 45 00
> 00 28 9D 7A 40 00 2B 06
> 25 94 D0 50 98 03 81 AD
> A2 C0 00 50 D7 59 29 F4
> BC EF 33 C8 F3 C5 50 11
> Vers : 4
> Hlen : 4 <----- should be 5
> TOS : 0
> Lgt : 40
> ident: 40314
> flags: 2
> offs : 1 <---- should be 0
> TTL : 43
> Prot : 6
> Src : 208.80.152.3
> Dst : 129.173.162.192
> Console output -------------------------------
>
>
>
> Code snipet ------------------------------
> Ip4 ipHd = packet.getHeader(Ip4.class);
> Tcp tcpHd = packet.getHeader(Tcp.class);
> System.out.println("PACKET DUMP::");
> for (int i = 0; i < 6; i++) {
> for (int k = i * 8; k < ((i + 1) * 8);
> k++) {
> System.out.printf("%02X ",
> packet.getBuffer().getBackingBuffer().get(k) & 0xFF);
> }
> System.out.println();
> }
> System.out.printf("Vers : %d\n", ipHd.ver());
> System.out.printf("Hlen : %d\n", ipHd.hlen());
> System.out.printf("TOS : %d\n", ipHd.tos());
> System.out.printf("Lgt : %d\n", ipHd.length());
> System.out.printf("ident: %d\n",
> ipHd.id()&0xFFFF);
> System.out.printf("flags: %d\n", ipHd.flags());
> System.out.printf("offs : %d\n", ipHd.offset());
> System.out.printf("TTL : %d\n", ipHd.ttl());
> System.out.printf("Prot : %d\n",
> ipHd.protocol());
> System.out.printf("Src : %s\n", ipHd.source());
> System.out.printf("Dst : %s\n",
> ipHd.destination());
> --------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jnetstream-users mailing list
> Jne...@li...
> https://lists.sourceforge.net/lists/listinfo/jnetstream-users
>
|
|
From: Frédéric D. <fre...@dr...> - 2008-08-05 04:09:32
|
Hi,
I have some trouble decoding IP and TCP headers. the header length and
the offset are wrongly decoded in most of the packets.
Did I do something wrong?
Regards,
Frederic Dreier
Console output -------------------------------
PACKET DUMP::
00 12 3F 19 FC 3F 00 07
84 BC A0 C0 08 00 45 00
00 28 9D 7A 40 00 2B 06
25 94 D0 50 98 03 81 AD
A2 C0 00 50 D7 59 29 F4
BC EF 33 C8 F3 C5 50 11
Vers : 4
Hlen : 4 <----- should be 5
TOS : 0
Lgt : 40
ident: 40314
flags: 2
offs : 1 <---- should be 0
TTL : 43
Prot : 6
Src : 208.80.152.3
Dst : 129.173.162.192
Console output -------------------------------
Code snipet ------------------------------
Ip4 ipHd = packet.getHeader(Ip4.class);
Tcp tcpHd = packet.getHeader(Tcp.class);
System.out.println("PACKET DUMP::");
for (int i = 0; i < 6; i++) {
for (int k = i * 8; k < ((i + 1) * 8);
k++) {
System.out.printf("%02X ",
packet.getBuffer().getBackingBuffer().get(k) & 0xFF);
}
System.out.println();
}
System.out.printf("Vers : %d\n", ipHd.ver());
System.out.printf("Hlen : %d\n", ipHd.hlen());
System.out.printf("TOS : %d\n", ipHd.tos());
System.out.printf("Lgt : %d\n", ipHd.length());
System.out.printf("ident: %d\n",
ipHd.id()&0xFFFF);
System.out.printf("flags: %d\n", ipHd.flags());
System.out.printf("offs : %d\n", ipHd.offset());
System.out.printf("TTL : %d\n", ipHd.ttl());
System.out.printf("Prot : %d\n",
ipHd.protocol());
System.out.printf("Src : %s\n", ipHd.source());
System.out.printf("Dst : %s\n",
ipHd.destination());
--------------------------------------------
|
|
From: J B <mo...@gm...> - 2008-08-05 01:48:36
|
Due to the modularity of the system, Maven makes very god sense as a build system. I tried using the MasterBuild system and quickly ran into problems. Would you consider the use of Maven to bild and release your project? If so, I'll volunteer to write Maven based module build system for you. Also, if you are interested, would you consider changing your directory structure to the default Maven structure of src/main/java vs src/java? If you like, I could probably have this thrown together by tomorrow. Birch |
|
From: Mark B. <voy...@ya...> - 2008-08-02 04:13:08
|
Here is a link to the latest build. I haven't modified anything since it was released. Follow the "visit link" to get at the download page: http://jnetstream.sourceforge.net/node/214 Cheers, mark... ----- Original Message ----- From: "Frédéric Dreier" <fre...@dr...> To: "Mark Bednarczyk" <voy...@ya...> Cc: <Jne...@li...> Sent: Friday, August 01, 2008 3:10 PM Subject: Re: [Jnetstream-users] ClassCastException Hi Mark, It could be that I took the wrong download. Actually I found a workaround so it does not block me anymore. I will try soon to compile everything from SVN so I will get the up-to-date version of the library. Thank you very much, Frederic Mark Bednarczyk a écrit : > Hmm, I thought I had fixed that in the latest build ?#? > > I'm getting ready to head back to the US from Europe right now so I > won't be able to take a look at this until monday. This looks like a > bug and I will release a fixed daily build next week. > > Cheers, > mark... > ----- Original Message ----- From: "Frédéric Dreier" <fre...@dr...> > To: <Jne...@li...> > Sent: Thursday, July 31, 2008 10:14 PM > Subject: [Jnetstream-users] ClassCastException > > >> Hi, >> >> I use Jnetstream since some days and find it great. Now, I have a >> question about this code snippet : >> >> LiveCaptureDevice[] devs = Captures.listCaptureDevices(); >> for (LiveCaptureDevice dev : devs) { >> LiveCapture capture = Captures.openLive(dev); >> ... >> } >> >> By me, it produces the following exception : >> >> Exception in thread "main" java.lang.ClassCastException: >> [Lorg.jnetstream.capture.CaptureDevice; cannot be cast to >> [Lorg.jnetstream.capture.LiveCaptureDevice; >> at >> com.slytechs.jnetstream.livecapture.DefaultLiveCaptureFactory.openLive(Unknown >> >> Source) >> at com.slytechs.capture.LiveFactory.openLive(LiveFactory.java:77) >> at org.jnetstream.capture.Captures.openLive(Captures.java:1427) >> at covered.PacketCollector.openReceivers(PacketCollector.java:50) >> >> Any advice? >> >> Regards, >> Frederic >> >> ------------------------------------------------------------------------- >> >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Jnetstream-users mailing list >> Jne...@li... >> https://lists.sourceforge.net/lists/listinfo/jnetstream-users > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jnetstream-users mailing list Jne...@li... https://lists.sourceforge.net/lists/listinfo/jnetstream-users |
|
From: Frédéric D. <fre...@dr...> - 2008-08-01 13:10:36
|
Hi Mark,
It could be that I took the wrong download. Actually I found a
workaround so it does not block me anymore.
I will try soon to compile everything from SVN so I will get the
up-to-date version of the library.
Thank you very much,
Frederic
Mark Bednarczyk a écrit :
> Hmm, I thought I had fixed that in the latest build ?#?
>
> I'm getting ready to head back to the US from Europe right now so I
> won't be able to take a look at this until monday. This looks like a
> bug and I will release a fixed daily build next week.
>
> Cheers,
> mark...
> ----- Original Message ----- From: "Frédéric Dreier" <fre...@dr...>
> To: <Jne...@li...>
> Sent: Thursday, July 31, 2008 10:14 PM
> Subject: [Jnetstream-users] ClassCastException
>
>
>> Hi,
>>
>> I use Jnetstream since some days and find it great. Now, I have a
>> question about this code snippet :
>>
>> LiveCaptureDevice[] devs = Captures.listCaptureDevices();
>> for (LiveCaptureDevice dev : devs) {
>> LiveCapture capture = Captures.openLive(dev);
>> ...
>> }
>>
>> By me, it produces the following exception :
>>
>> Exception in thread "main" java.lang.ClassCastException:
>> [Lorg.jnetstream.capture.CaptureDevice; cannot be cast to
>> [Lorg.jnetstream.capture.LiveCaptureDevice;
>> at
>> com.slytechs.jnetstream.livecapture.DefaultLiveCaptureFactory.openLive(Unknown
>>
>> Source)
>> at com.slytechs.capture.LiveFactory.openLive(LiveFactory.java:77)
>> at org.jnetstream.capture.Captures.openLive(Captures.java:1427)
>> at covered.PacketCollector.openReceivers(PacketCollector.java:50)
>>
>> Any advice?
>>
>> Regards,
>> Frederic
>>
>> -------------------------------------------------------------------------
>>
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Jnetstream-users mailing list
>> Jne...@li...
>> https://lists.sourceforge.net/lists/listinfo/jnetstream-users
>
|
|
From: Mark B. <voy...@ya...> - 2008-08-01 09:18:48
|
Hmm, I thought I had fixed that in the latest build ?#?
I'm getting ready to head back to the US from Europe right now so I won't be
able to take a look at this until monday. This looks like a bug and I will
release a fixed daily build next week.
Cheers,
mark...
----- Original Message -----
From: "Frédéric Dreier" <fre...@dr...>
To: <Jne...@li...>
Sent: Thursday, July 31, 2008 10:14 PM
Subject: [Jnetstream-users] ClassCastException
> Hi,
>
> I use Jnetstream since some days and find it great. Now, I have a
> question about this code snippet :
>
> LiveCaptureDevice[] devs = Captures.listCaptureDevices();
> for (LiveCaptureDevice dev : devs) {
> LiveCapture capture = Captures.openLive(dev);
> ...
> }
>
> By me, it produces the following exception :
>
> Exception in thread "main" java.lang.ClassCastException:
> [Lorg.jnetstream.capture.CaptureDevice; cannot be cast to
> [Lorg.jnetstream.capture.LiveCaptureDevice;
> at
> com.slytechs.jnetstream.livecapture.DefaultLiveCaptureFactory.openLive(Unknown
> Source)
> at com.slytechs.capture.LiveFactory.openLive(LiveFactory.java:77)
> at org.jnetstream.capture.Captures.openLive(Captures.java:1427)
> at covered.PacketCollector.openReceivers(PacketCollector.java:50)
>
> Any advice?
>
> Regards,
> Frederic
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jnetstream-users mailing list
> Jne...@li...
> https://lists.sourceforge.net/lists/listinfo/jnetstream-users
|
|
From: Frédéric D. <fre...@dr...> - 2008-07-31 20:14:28
|
Hi,
I use Jnetstream since some days and find it great. Now, I have a
question about this code snippet :
LiveCaptureDevice[] devs = Captures.listCaptureDevices();
for (LiveCaptureDevice dev : devs) {
LiveCapture capture = Captures.openLive(dev);
...
}
By me, it produces the following exception :
Exception in thread "main" java.lang.ClassCastException:
[Lorg.jnetstream.capture.CaptureDevice; cannot be cast to
[Lorg.jnetstream.capture.LiveCaptureDevice;
at
com.slytechs.jnetstream.livecapture.DefaultLiveCaptureFactory.openLive(Unknown
Source)
at com.slytechs.capture.LiveFactory.openLive(LiveFactory.java:77)
at org.jnetstream.capture.Captures.openLive(Captures.java:1427)
at covered.PacketCollector.openReceivers(PacketCollector.java:50)
Any advice?
Regards,
Frederic
|
