Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/io-net migration/strange behavior of using pcap.h/List of Posts
Forum Topic - strange behavior of using pcap.h: Page 1 of 4 (82 Items)
   
Update
Mohammad Dadashzadeh(deleted)
07/28/2009 10:51 AM
post34722
strange behavior of using pcap.h   
Dear All,

Fortunately I was able to use pcap.h to capture packet in QNX. I am using below command to open a session

/* Open the session in promiscuous mode */
handle = pcap_open_live(dev, 65536, 1, 1000, errbuf);


I am also using below commands to capture and store packets

for(i=0;i<32000;i++)
	{
		packet=pcap_next(handle, &header);
		local_tv_sec = header.ts.tv_sec;
		ltime=localtime(&local_tv_sec);
		strftime( timestr, sizeof(timestr), "%H:%M:%S", ltime);
		fprintf(stream1,"%s,%.6d len:%d\n", timestr, header.ts.tv_usec, header.len);
	}

I have a testing device which sends two packets per 250usec. Therefore, I am expecting to capture packets in the same 
trend.

By the way, two network cards are connected to my QNX target machine and I am using one of them only for data capturing 
from tester.

let's see some part of the captured data. Instead of getting two packets every 250usec I am getting 64 to 65 packets 
every 8389 usec. Is there anything wrong with the settings or netwrok driver in QNX. I tested the same network card in 
windows XP embedded with winpcap and it was working very well. I would be very thankful if you help me.

10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,599566 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955 len:121
10:23:11,607955...
View Full Message
Andrew Boyd(deleted)
07/28/2009 10:54 AM
post34723
RE: strange behavior of using pcap.h   
> I am getting 64 to 65 packets every 8389 usec.

I think the system time which localtime() is 
fetching is only being updated every 10ms timer 
tick.

I think you want a better timestamp - try 
clockcycles() or something like that.

--
aboyd
Sean Boudreau(deleted)
07/28/2009 11:03 AM
post34730
Re: strange behavior of using pcap.h   
On Tue, Jul 28, 2009 at 10:51:19AM -0400, Mohammad Dadashzadeh wrote:
> Dear All,
> let's see some part of the captured data. Instead of getting two packets every 250usec I am getting 64 to 65 packets 
every 8389 usec. Is there anything wrong with the settings or netwrok driver in QNX. I tested the same network card in 
windows XP embedded with winpcap and it was working very well. I would be very thankful if you help me.

That's the clockrate in io-pkt:

# sysctl kern.clockrate
kern.clockrate: tick = 8403, hz = 119

-seanb
Mohammad Dadashzadeh(deleted)
07/28/2009 11:14 AM
post34731
Re: strange behavior of using pcap.h   
can I change it?
Sean Boudreau(deleted)
07/28/2009 11:15 AM
post34732
Re: strange behavior of using pcap.h   
On Tue, Jul 28, 2009 at 11:14:11AM -0400, Mohammad Dadashzadeh wrote:
> can I change it?

It would involve a re-compile.

Regards,

-seanb
Mohammad Dadashzadeh(deleted)
07/28/2009 11:18 AM
post34734
Re: strange behavior of using pcap.h   
Sorry I did not get it,

Recompile of what, Could you please let me know How I can do it?

Regards,
Mohammad
Sean Boudreau(deleted)
07/28/2009 11:23 AM
post34735
Re: strange behavior of using pcap.h   
On Tue, Jul 28, 2009 at 11:18:22AM -0400, Mohammad Dadashzadeh wrote:
> Sorry I did not get it,
> 
> Recompile of what, Could you please let me know How I can do it?

You'd need to check out the source from the networking
repo and follow the instructions here:

http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/Source_Guide

The defines that control this are in io-pkt/sys/sys/time_bsd.h
(look for __QNXNTO__)

Regards,

-seanb
Mohammad Dadashzadeh(deleted)
07/28/2009 12:25 PM
post34743
Re: strange behavior of using pcap.h   
Could I do this in evaluation version where I have QNX Momentics IDE Version 4.6.0?

Mohammad
Mohammad Dadashzadeh(deleted)
07/28/2009 12:48 PM
post34746
Re: strange behavior of using pcap.h   
> Could I do this in evaluation version where I have QNX Momentics IDE Version 4
> .6.0?
> 
> Mohammad
> 
> 
> 


Should I have website downloader to download all the files.
http://community.qnx.com/svn/repos/coreos_pub/trunk/

Mohammad
Mohammad Dadashzadeh(deleted)
07/28/2009 1:01 PM
post34748
Re: strange behavior of using pcap.h   
when I use my user name in this command it does not work?

 svn checkout --username <username> http://community.qnx.com/svn/repos/coreos_pub/trunk


Mohammad
Mohammad Dadashzadeh(deleted)
07/28/2009 1:03 PM
post34750
Re: strange behavior of using pcap.h   
> when I use my user name in this command it does not work?
> 
>  svn checkout --username <username> http://community.qnx.com/svn/repos/coreos_pub/trunk
> 
> 
> Mohammad


it shows :

PRPOFIND request failed on .......
........... 405 method Not allowed
Mohammad Dadashzadeh(deleted)
07/28/2009 5:13 PM
post34759
Re: strange behavior of using pcap.h   
I am trying to recompile the source based on below document

http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253


at the end when I run it says:

/cygdrive/c/QNX641/workspace not a directory
Sean Boudreau(deleted)
07/29/2009 9:59 AM
post34790
Re: strange behavior of using pcap.h   
On Tue, Jul 28, 2009 at 05:13:12PM -0400, Mohammad Dadashzadeh wrote:
> I am trying to recompile the source based on below document
> 
> http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253
> 
> 
> at the end when I run it says:
> 
> /cygdrive/c/QNX641/workspace not a directory

I'm not sure that applies to the networking source...
I've never tried building under the IDE but a
straight 'make' as described here should work.

http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/Source_Guide

Regards,

-seanb
Mohammad Dadashzadeh(deleted)
07/29/2009 10:30 AM
post34796
Re: strange behavior of using pcap.h   
> On Tue, Jul 28, 2009 at 05:13:12PM -0400, Mohammad Dadashzadeh wrote:
> > I am trying to recompile the source based on below document
> > 
> > http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/
> wiki/BuildKernelWithIDE?id=atch1253
> > 
> > 
> > at the end when I run it says:
> > 
> > /cygdrive/c/QNX641/workspace not a directory
> 
> I'm not sure that applies to the networking source...
> I've never tried building under the IDE but a
> straight 'make' as described here should work.
> 
> http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/
> Source_Guide
> 
> Regards,
> 
> -seanb


Should I do this in QNX machine or in development machine I am really confused.
Should I rebuild the entire OS or just Networking core.
svn command works in QNX machine not in development machine.

Regards,
Mohammad
Sean Boudreau(deleted)
07/29/2009 10:35 AM
post34798
Re: strange behavior of using pcap.h   
On Wed, Jul 29, 2009 at 10:30:40AM -0400, Mohammad Dadashzadeh wrote:
> > On Tue, Jul 28, 2009 at 05:13:12PM -0400, Mohammad Dadashzadeh wrote:
> > > I am trying to recompile the source based on below document
> > > 
> > > http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/
> > wiki/BuildKernelWithIDE?id=atch1253
> > > 
> > > 
> > > at the end when I run it says:
> > > 
> > > /cygdrive/c/QNX641/workspace not a directory
> > 
> > I'm not sure that applies to the networking source...
> > I've never tried building under the IDE but a
> > straight 'make' as described here should work.
> > 
> > http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/
> > Source_Guide
> > 
> > Regards,
> > 
> > -seanb
> 
> 
> Should I do this in QNX machine or in development machine I am really confused.
> Should I rebuild the entire OS or just Networking core.
> svn command works in QNX machine not in development machine.

The development machine (note a QNX machine can also
be a development machine).  For this particular issue
only the io-pkt binary need to be touched but it's
often easier to build the entire networking tree as
described in the above link.

Regards,

-seanb
Mohammad Dadashzadeh(deleted)
07/29/2009 11:07 AM
post34803
Re: strange behavior of using pcap.h   
in order to change the 8.39 msec to 32 usec

this is the default
 * 2^23ns = 2^23ns * (1000ms / 10^9ns) = 8.39ms = 119.209Hz
 */
#define NTO_TSHIFT 23
#define NTO_HZ 119
#define NTO_mHZ 119209

I am going to change it to

 * 2^15ns = 2^15ns * (1000ms / 10^9ns) = 32.77us = 30517.578Hz
 */
#define NTO_TSHIFT 15
#define NTO_HZ 30517
#define NTO_mHZ 30517578

and then compile,

is this correct?

Mohammad
Yao Zhao(deleted)
07/29/2009 11:12 AM
post34804
Re: strange behavior of using pcap.h   
that is correct but probably it won't work as many places are assuming 1 HZ is 8ms but now it is not. but you could try.
Mohammad Dadashzadeh(deleted)
07/29/2009 11:29 AM
post34806
Re: strange behavior of using pcap.h   
I downloaded kernel source from
svn checkout --username <username> http://community.qnx.com/svn/repos/coreos_pub/trunk

and followed all the instructions and was able to compile and build the OS.

Now should I download all the below links or one of the is enough?

 svn checkout --username <userid> http://community.qnx.com/svn/repos/core_networking/trunk

Where <userid> is the email address used to create your account on the QNX site.

To check out the 6.4.0 GA release branch source, use

svn checkout --username <userid> http://community.qnx.com/svn/repos/core_networking/tags/6.4.0/GA

To check out the 6.4.0 maintenance branch source (which includes critical fixes to the GA release), use

svn checkout --username <userid> http://community.qnx.com/svn/repos/core_networking/branches/6.4.0/trunk 

Mohammad
Yao Zhao(deleted)
07/29/2009 11:37 AM
post34807
Re: strange behavior of using pcap.h   
what do you want to do? recompile io-pkt or the whole OS?
Mohammad Dadashzadeh(deleted)
07/29/2009 11:47 AM
post34808
Re: strange behavior of using pcap.h   
recompile  io-pkt
John Murphy
07/29/2009 11:48 AM
post34809
Re: strange behavior of using pcap.h   
On an X86 (at least), the clock interrupts happen at a rate close to one per millisecond, so you can never achieve a 
pcap timestamp resolution better than about one millisecond.

If what you're after is better resolution, it might be easier to just build your own bpf.c.


Murf
Mohammad Dadashzadeh(deleted)
07/29/2009 11:51 AM
post34810
Re: strange behavior of using pcap.h   
> On an X86 (at least), the clock interrupts happen at a rate close to one per 
> millisecond, so you can never achieve a pcap timestamp resolution better than 
> about one millisecond.
> 
> If what you're after is better resolution, it might be easier to just build 
> your own bpf.c.
> 
> 
> Murf


From where should I start to learn how to write my own bpf.c file. I was getting very good resolution in win XP using 
winpcap.

Regards,
Mohammad
John Murphy
07/29/2009 11:58 AM
post34813
Re: strange behavior of using pcap.h   
Take a look at sys/net/bpf.c in the networking trunk. I believe it sets the timestamp via a call to microtime, which is 
in sys/currenttime.c, which calsl mtime in the same file), which get the current time, then maks off a bunch of the 
least significant digits.

I may be way off base here, and this might just lead you into another round of "what's going on here?", but I'd sure 
take a look at the other possibilities before I tried to rebuild all of io-pkt with a rather fundamental change --- but 
that's just me.


Murf
Sean Boudreau(deleted)
07/29/2009 12:46 PM
post34817
Re: strange behavior of using pcap.h   
On Wed, Jul 29, 2009 at 11:58:55AM -0400, John Murphy wrote:
> Take a look at sys/net/bpf.c in the networking trunk. I believe it sets the timestamp via a call to microtime, which 
is in sys/currenttime.c, which calsl mtime in the same file), which get the current time, then maks off a bunch of the 
least significant digits.
> 
> I may be way off base here, and this might just lead you into another round of "what's going on here?", but I'd sure 
take a look at the other possibilities before I tried to rebuild all of io-pkt with a rather fundamental change --- but 
that's just me.

It seems to boil down to pcap_open_live() taking a timeout
the smallest value of which boils down to HZ in the stack
(stack rounds up to that value).  A value of zero means wait
until the buffer's full.  There's a BIOCIMMEDIATE bpf ioctl
that would probably help here but libpcap currently only
uses it for AIX.

Soo... The easier 'fix' would be to set BIOCIMMEDIATE in
pcap_open_live() if the timeout is less than a tick which
you can get from sysctl() / sysctlbyname().

-seanb
John Murphy
07/29/2009 1:03 PM
post34819
Re: strange behavior of using pcap.h   
Sean,  are we talking about the resolution of the timestamps, or how often pcap satisfies a read request?

Murf
1234Next

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems