Forum Topic - strange behavior of using pcap.h: Page 4 of 4 (82 Items)
   
Re: strange behavior of using pcap.h  
> Yao Zhao wrote:
> >
> > Murf: can you get different timestamp for flood packets?
> >
> >
> >   
> I get timestamps with the normal 8 us. resolution, as expected.  The 
> changes that were suggested for mtime will produce ms., not us., 
> resolution, since the hardware clock interrupts (approximately) once per 
> millisecond.
> 
> Murf


You should get 8ms resolution not 8us. as the tick.

Murf is right I forgot qtime is updated by timer so curtime_nto won't get better than 1 ms.
you should write a small program to call ClockPeriod to change system clock to smaller, like 250us. then run your app.
Re: strange behavior of using pcap.h  
>> I get timestamps with the normal 8 us. resolution, as expected.  The 
>> changes that were suggested for mtime will produce ms., not us., 
>> resolution, since the hardware clock interrupts (approximately) once per 
>> millisecond.
>>
>> Murf
>>     
>
>
> You should get 8ms resolution not 8us. as the tick.
>
> Murf is right I forgot qtime is updated by timer so curtime_nto won't get better than 1 ms.
> you should write a small program to call ClockPeriod to change system clock to smaller, like 250us. then run your app.

>
>   
Yea, of course I meant 8ms., not 8us.!  Even when I reread messages two 
or three times before I hit the send button, I still make mistakes.  
Guess I need a smarter "spell" checker....

Murf
Re: strange behavior of using pcap.h  
> > Yao Zhao wrote:
> > >
> > > Murf: can you get different timestamp for flood packets?
> > >
> > >
> > >   
> > I get timestamps with the normal 8 us. resolution, as expected.  The 
> > changes that were suggested for mtime will produce ms., not us., 
> > resolution, since the hardware clock interrupts (approximately) once per 
> > millisecond.
> > 
> > Murf
> 
> 
> You should get 8ms resolution not 8us. as the tick.
> 
> Murf is right I forgot qtime is updated by timer so curtime_nto won't get 
> better than 1 ms.
> you should write a small program to call ClockPeriod to change system clock to
>  smaller, like 250us. then run your app.


Well done. It worked. I really appreciate. I am going to summarize the discussion and make it more useful for anyone who
 may face the same problem. Just one thing I wanna confirm, was replacing libpcap.a necessary or not.
Best Regards,
Mohammad



12:12:13,165995 len:121
12:12:13,165995 len:121
12:12:13,165995 len:121
12:12:13,166206 len:121
12:12:13,166206 len:121
12:12:13,166336 len:121
12:12:13,166336 len:121
12:12:13,166538 len:121
12:12:13,166547 len:121
12:12:13,166547 len:121
12:12:13,166769 len:121
12:12:13,166769 len:121
12:12:13,166769 len:121
12:12:13,166990 len:121
12:12:13,166990 len:121
12:12:13,166990 len:121
12:12:13,166990 len:121
12:12:13,167211 len:121
12:12:13,167211 len:121
12:12:13,167322 len:121
12:12:13,167322 len:121
12:12:13,167543 len:121
12:12:13,167543 len:121
12:12:13,167543 len:121
12:12:13,167773 len:121
12:12:13,167773 len:121
12:12:13,167773 len:121
12:12:13,167773 len:121
12:12:13,167985 len:121
12:12:13,168004 len:121
12:12:13,168004 len:121
12:12:13,168217 len:121
12:12:13,168217 len:121
12:12:13,168327 len:121
12:12:13,168327 len:121
12:12:13,168539 len:121
12:12:13,168548 len:121
12:12:13,168548 len:121
12:12:13,168770 len:121
12:12:13,168770 len:121
12:12:13,168770 len:121
12:12:13,168991 len:121
12:12:13,168991 len:121
12:12:13,169212 len:121
12:12:13,169212 len:121
12:12:13,169323 len:121
12:12:13,169323 len:121
12:12:13,169534 len:121
12:12:13,169544 len:121
12:12:13,169544 len:121
12:12:13,169765 len:121
12:12:13,169765 len:121
12:12:13,169765 len:121
12:12:13,169986 len:121
Re: strange behavior of using pcap.h  
> > > Yao Zhao wrote:
> > > >
> > > > Murf: can you get different timestamp for flood packets?
> > > >
> > > >
> > > >   
> > > I get timestamps with the normal 8 us. resolution, as expected.  The 
> > > changes that were suggested for mtime will produce ms., not us., 
> > > resolution, since the hardware clock interrupts (approximately) once per 
> > > millisecond.
> > > 
> > > Murf
> > 
> > 
> > You should get 8ms resolution not 8us. as the tick.
> > 
> > Murf is right I forgot qtime is updated by timer so curtime_nto won't get 
> > better than 1 ms.
> > you should write a small program to call ClockPeriod to change system clock 
> to
> >  smaller, like 250us. then run your app.
> 
> 
> Well done. It worked. I really appreciate. I am going to summarize the 
> discussion and make it more useful for anyone who may face the same problem. 
> Just one thing I wanna confirm, was replacing libpcap.a necessary or not.
> Best Regards,
> Mohammad
> 
> 
> 
> 12:12:13,165995 len:121
> 12:12:13,165995 len:121
> 12:12:13,165995 len:121
> 12:12:13,166206 len:121
> 12:12:13,166206 len:121
> 12:12:13,166336 len:121
> 12:12:13,166336 len:121
> 12:12:13,166538 len:121
> 12:12:13,166547 len:121
> 12:12:13,166547 len:121
> 12:12:13,166769 len:121
> 12:12:13,166769 len:121
> 12:12:13,166769 len:121
> 12:12:13,166990 len:121
> 12:12:13,166990 len:121
> 12:12:13,166990 len:121
> 12:12:13,166990 len:121
> 12:12:13,167211 len:121
> 12:12:13,167211 len:121
> 12:12:13,167322 len:121
> 12:12:13,167322 len:121
> 12:12:13,167543 len:121
> 12:12:13,167543 len:121
> 12:12:13,167543 len:121
> 12:12:13,167773 len:121
> 12:12:13,167773 len:121
> 12:12:13,167773 len:121
> 12:12:13,167773 len:121
> 12:12:13,167985 len:121
> 12:12:13,168004 len:121
> 12:12:13,168004 len:121
> 12:12:13,168217 len:121
> 12:12:13,168217 len:121
> 12:12:13,168327 len:121
> 12:12:13,168327 len:121
> 12:12:13,168539 len:121
> 12:12:13,168548 len:121
> 12:12:13,168548 len:121
> 12:12:13,168770 len:121
> 12:12:13,168770 len:121
> 12:12:13,168770 len:121
> 12:12:13,168991 len:121
> 12:12:13,168991 len:121
> 12:12:13,169212 len:121
> 12:12:13,169212 len:121
> 12:12:13,169323 len:121
> 12:12:13,169323 len:121
> 12:12:13,169534 len:121
> 12:12:13,169544 len:121
> 12:12:13,169544 len:121
> 12:12:13,169765 len:121
> 12:12:13,169765 len:121
> 12:12:13,169765 len:121
> 12:12:13,169986 len:121

libpcap.a modification is not related to your timestamp problem so no.
Re: strange behavior of using pcap.h  
On Fri, Jul 31, 2009 at 12:40:49PM -0400, Yao Zhao wrote:
> > 
> > Well done. It worked. I really appreciate. I am going to summarize the 
> > discussion and make it more useful for anyone who may face the same problem. 
> > Just one thing I wanna confirm, was replacing libpcap.a necessary or not.
> > Best Regards,
> > Mohammad
> > 
> 
> libpcap.a modification is not related to your timestamp problem so no.

The final I have in mind likely will require a new stack
and libpcap.

Regards,

-seanb
Re: strange behavior of using pcap.h  

Mohammad Dadashzadeh wrote:
>> Mohammad Dadashzadeh wrote:
>>     
>>>>> I would like to get packets one by one. What should I do?
>>>>>
>>>>> Mohammad
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> Sean sent you a libpcap.a that lets you enable immediate mode.  That 
>>>> should be all you need.
>>>>
>>>> Murf
>>>>     
>>>>         
>>> I did that, didn't work, even when I reboot my target machine it can  not 
>>>       
>> connect to net anymore.
>>     
>>> Mohammad 
>>>   
>>>       
>> I compiled the code you published on this thread and linked it with 
>> Sean's libpcap and it worked fine.  I don't think we understand what you 
>> mean by "not working".
>>
>> Murf
>>     
>
>
> I replaced linpcap.a which Sean sent with all libpcap.a files in my development and target machine. I recompiled and 
built the project yet I am getting 8 packets every 1 ms while the packets are transmitted two every 250 usec.
>
> Regards,
> Mohammad
>   
Sean's change was to enable immediate mode in BPF, and had nothing to do 
with timestamps.  You are seeing all the packets that get transmitted, 
and, as has been explained several times in this thread, the resolution 
of the timestamps you see on those packets is limited by the resolution 
of the system clock.  If you really think you need greater resolution on 
the timestamps, it might be better to design you own packet capture 
system, rather than make fundamental changes to the operating system, 
especially by hacking the binaries.

By the way, please understand that I am in no way associated with QNX 
other than being a happy user with about 30 years of experience in 
packet sniffing --- and a little too much time on my hands this week.

Murf
Re: strange behavior of using pcap.h  
I would really appreciate your help and support.