All of lore.kernel.org
 help / color / mirror / Atom feed
* Tcpdump and libipq
@ 2003-10-10  7:32 Oumer Teyeb
  0 siblings, 0 replies; 5+ messages in thread
From: Oumer Teyeb @ 2003-10-10  7:32 UTC (permalink / raw)
  To: netfilter

Hi,

I have posted this question some days ago without being a member of the 
mailing list, and I don't think it has been posted. Now that I am a 
member, hopefully it will be sent this time:-)

I have a program that uses libipq to delay and drop packets, so that the 
transmission will be affected as if the connection is a wireless 
network. It works fine. My intention was to use tcpdump in conjunction 
with my program to see exactly when the packets are arriving, and then 
use tcptrace to plot the graphs. But as libipq is working at the netlink 
socket layer, I am doubting that when a packet reaches my firewall, it 
will alreay be registerd by tcpdump.

For example, I set my program to delay every packet arriving from port 
xx 100 msec. I also run tcpdump in the background to sniff on the same 
flow. Say a  packet arrives at 0.000 in my network card, and it was 
delayed 100 msec by my program and sent to upper layers. Will Tcpdump 
register the packet arrival time as 0.000 or as 100 ? I will try to 
check it myself, but if anyone knows, that will save me some time.

I try to save the data whenever I get it from ip_get_packet, and then 
compared it with the tcpdump I did at the same time. For the test runs, 
I was delaying every packet by one sec (both incoming and outgoing). 
Then I did an FTP session, and I have a very perplexing result:
There is a 1 second diff between the timestamps in the data I set and 
the ones from tcpdump, but only when the packets are outgoing.
For incoming packets it seems the tcpdump timestamp and the timestamp of 
packet from libipq seem the same (ofcourse there can be some microsecond 
differences). Why is it happening this way, and is there a possiblity of 
making tcpdump to save the data only after libipq has taken care of them?

Regards,
Oumer






^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Tcpdump and libipq
@ 2003-10-10  9:22 pigi
  0 siblings, 0 replies; 5+ messages in thread
From: pigi @ 2003-10-10  9:22 UTC (permalink / raw)
  To: netfilter

> Hi,

> Then I did an FTP session, and I have a very perplexing result:
> There is a 1 second diff between the timestamps in the data I set and
the ones from tcpdump, but only when the packets are outgoing.
> For incoming packets it seems the tcpdump timestamp and the timestamp of
packet from libipq seem the same (ofcourse there can be some microsecond
differences). Why is it happening this way, and is there a possiblity of
making tcpdump to save the data only after libipq has taken care of
them?

I'm not an expert, but also from my tests, it seems to work the way you
explained before.
This is a bit annoying, because every application based on pcap ( tcpdump,
snort, iptraf ) are not ( completely ) useful for testing purpose. I have
a firewall with an IDS running on the same machine, and set up some rule
to block some suspicious traffic.
The rules are working, as I can see from the iptables logs, and from
sniffing the INSIDE side of the firewall, but if I sniff (tcpdump/iptraf)
the OUTSIDE interface OR if I get a look in snort logs, I can notice those
suspicious packet entering the interface.
Unfortunally this gives me a lot of false positive alert, because the
snort read the packets BEFORE they reach the iptables ( kernel side ). HTH
Pigi




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Tcpdump and libipq
@ 2003-10-10  7:52 Pierluigi Frullani
  0 siblings, 0 replies; 5+ messages in thread
From: Pierluigi Frullani @ 2003-10-10  7:52 UTC (permalink / raw)
  To: Oumer Teyeb; +Cc: netfilter

> Hi,

> Then I did an FTP session, and I have a very perplexing result:
> There is a 1 second diff between the timestamps in the data I set and
> the ones from tcpdump, but only when the packets are outgoing.
> For incoming packets it seems the tcpdump timestamp and the timestamp of
> packet from libipq seem the same (ofcourse there can be some microsecond
> differences). Why is it happening this way, and is there a possiblity of
> making tcpdump to save the data only after libipq has taken care of them?

I'm not an expert, but also from my tests, it seems to work the way you
explained before.
This is a bit annoying, because every application based on pcap ( tcpdump,
snort, iptraf ) are not ( completely ) useful for testing purpose.
I have a firewall with an IDS running on the same machine, and set up some
rule to block some suspicious traffic.
The rules are working, as I can see from the iptables logs, and from
sniffing the INSIDE side of the firewall, but if I sniff (tcpdump/iptraf)
the OUTSIDE interface OR if I get a look in snort logs, I can notice those
suspicious packet entering the interface.
Unfortunally this gives me a lot of false positive alert, because the
snort read the packets BEFORE they reach the iptables ( kernel side ).
HTH
Pigi


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Tcpdump and libipq
@ 2003-10-10  7:20 Oumer Teyeb
  0 siblings, 0 replies; 5+ messages in thread
From: Oumer Teyeb @ 2003-10-10  7:20 UTC (permalink / raw)
  To: netfilter

Hi,

I have posted this question some days ago without being a member of the 
mailing list, and I don't think it has been posted. Now that I am a 
member, hopefully it will be sent this time:-)

I have a program that uses libipq to delay and drop packets, so that the 
transmission will be affected as if the connection is a wireless 
network. It works fine. My intention was to use tcpdump in conjunction 
with my program to see exactly when the packets are arriving, and then 
use tcptrace to plot the graphs. But as libipq is working at the netlink 
socket layer, I am doubting that when a packet reaches my firewall, it 
will alreay be registerd by tcpdump.

For example, I set my program to delay every packet arriving from port 
xx 100 msec. I also run tcpdump in the background to sniff on the same 
flow. Say a  packet arrives at 0.000 in my network card, and it was 
delayed 100 msec by my program and sent to upper layers. Will Tcpdump 
register the packet arrival time as 0.000 or as 100 ? I will try to 
check it myself, but if anyone knows, that will save me some time.

I try to save the data whenever I get it from ip_get_packet, and then 
compared it with the tcpdump I did at the same time. For the test runs, 
I was delaying every packet by one sec (both incoming and outgoing). 
Then I did an FTP session, and I have a very perplexing result:
There is a 1 second diff between the timestamps in the data I set and 
the ones from tcpdump, but only when the packets are outgoing.
For incoming packets it seems the tcpdump timestamp and the timestamp of 
packet from libipq seem the same (ofcourse there can be some microsecond 
differences). Why is it happening this way, and is there a possiblity of 
making tcpdump to save the data only after libipq has taken care of them?

Regards,
Oumer




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Tcpdump and libipq
@ 2003-10-08  9:14 Oumer Teyeb
  0 siblings, 0 replies; 5+ messages in thread
From: Oumer Teyeb @ 2003-10-08  9:14 UTC (permalink / raw)
  To: netfilter

Hi,
I have a program that uses libipq to delay and drop packets, so that the 
transmission will be affected as if the connection is a wireless 
network. It works fine. My intention was to use tcpdump in conjunction 
with my program to see exactly when the packets are arriving, and then 
use tcptrace to plot the graphs. But as libipq is working at the netlink 
socket layer, I am doubting that when a packet reaches my firewall, it 
will alreay be registerd by tcpdump.

For example, I set my program to delay every packet arriving from port 
xx 100 msec. I also run tcpdump in the background to sniff on the same 
flow. Say a  packet arrives at 0.000 in my network card, and it was 
delayed 100 msec by my program and sent to upper layers. Will Tcpdump 
register the packet arrival time as 0.000 or as 100 ? I will try to 
check it myself, but if anyone knows, that will save me some time.

Regards,
Oumer



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-10-10  9:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-10  7:32 Tcpdump and libipq Oumer Teyeb
  -- strict thread matches above, loose matches on Subject: below --
2003-10-10  9:22 pigi
2003-10-10  7:52 Pierluigi Frullani
2003-10-10  7:20 Oumer Teyeb
2003-10-08  9:14 Oumer Teyeb

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.