Unable to see UDP traffic about tcpflow HOT 23 CLOSED

The answer to your question ""can't it just work with udp like tcpdump does?" "no, it can't, because the udp packets aren't structured as a continuous stream of human-readable text."

from tcpflow.

Have you tried setting a filter that explicitly allows UDP traffic?

On May 15, 2012, at 6:50 PM, René Berber wrote:

Hi,

Using tcpflow version 1.2.6, with libpcap 1.2.1, in a NAS which is running Linux 2.6.12, I'm unable to see any UDP traffic.

I'm guessing is a problem in my environment, but I just tested with tcpdump and that works.

Any ideas?

---

Reply to this email directly or view it on GitHub:
#2

from tcpflow.

Yes, of course.

Examples of what I've used (just so you see I'm not making a mistake):

$ tcpflow -ce udp

$ tcpflow -ce host deleted and udp port 80

from tcpflow.

Thanks for the bug report. Indeed, it seems that udp isn't working in that version. If you wish to fix it, I'm happy to take the fix.

On May 15, 2012, at 7:20 PM, René Berber wrote:

Yes, of course.

Examples of what I've used (just so you see I'm not making a mistake):

$ tcpflow -ce udp

$ tcpflow -ce host and udp port 80

---

Reply to this email directly or view it on GitHub:
#2 (comment)

from tcpflow.

OK, I'll take a look at the code, see if I can debug what's going on (with one of my favorite tools).

from tcpflow.

After spelunking the code I found that UDP has never been supported (see tcpip.cpp:794).

Just by running with debug level 50 you can also see this:

$ src/tcpflow -d 50 -Ce udp
src/tcpflow[27281]: printing packets to console only
src/tcpflow[27281]: packet header dump suppressed
src/tcpflow[27281]: converting non-printable characters to '.'
src/tcpflow[27281]: using colors
src/tcpflow[27281]: tcpflow version 1.2.6
src/tcpflow[27281]: looking for handler for datalink type 1 for interface egiga0
src/tcpflow[27281]: filter expression: 'udp'
src/tcpflow[27281]: filter code:
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 5
(002) ldb      [23]
(003) jeq      #0x11            jt 4    jf 5
(004) ret      #65535
(005) ret      #0
src/tcpflow[27281]: listening on egiga0
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
...

from tcpflow.

Well, it's never been supported, but I added it recently.

On May 16, 2012, at 5:45 PM, René Berber wrote:

After spelunking the code I found that UDP has never been supported (see tcpip.cpp:794).

Just by running with debug level 50 you can also see this:

$ src/tcpflow -d 50 -Ce udp
src/tcpflow[27281]: printing packets to console only
src/tcpflow[27281]: packet header dump suppressed
src/tcpflow[27281]: converting non-printable characters to '.'
src/tcpflow[27281]: using colors
src/tcpflow[27281]: tcpflow version 1.2.6
src/tcpflow[27281]: looking for handler for datalink type 1 for interface egiga0
src/tcpflow[27281]: filter expression: 'udp'
src/tcpflow[27281]: filter code:
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 5
(002) ldb      [23]
(003) jeq      #0x11            jt 4    jf 5
(004) ret      #65535
(005) ret      #0
src/tcpflow[27281]: listening on egiga0
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
...

---

Reply to this email directly or view it on GitHub:
#2 (comment)

from tcpflow.

On 5/16/2012 8:29 PM, Simson L. Garfinkel wrote:

Well, it's never been supported, but I added it recently.

Do you mean post version 1.2.6?

Should I have downloaded the repository instead of the release?

René Berber

from tcpflow.

Then again, perhaps I didn't add it yet. I think that somebody wanted me to add it and I wasn't sure that it even made sense to do.

On May 16, 2012, at 5:45 PM, René Berber wrote:

After spelunking the code I found that UDP has never been supported (see tcpip.cpp:794).

Just by running with debug level 50 you can also see this:

$ src/tcpflow -d 50 -Ce udp
src/tcpflow[27281]: printing packets to console only
src/tcpflow[27281]: packet header dump suppressed
src/tcpflow[27281]: converting non-printable characters to '.'
src/tcpflow[27281]: using colors
src/tcpflow[27281]: tcpflow version 1.2.6
src/tcpflow[27281]: looking for handler for datalink type 1 for interface egiga0
src/tcpflow[27281]: filter expression: 'udp'
src/tcpflow[27281]: filter code:
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 5
(002) ldb      [23]
(003) jeq      #0x11            jt 4    jf 5
(004) ret      #65535
(005) ret      #0
src/tcpflow[27281]: listening on egiga0
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
src/tcpflow[27281]: got non-TCP frame -- IP proto 17
...

---

Reply to this email directly or view it on GitHub:
#2 (comment)

from tcpflow.

On May 16, 2012, at 6:31 PM, René Berber wrote:

On 5/16/2012 8:29 PM, Simson L. Garfinkel wrote:

Well, it's never been supported, but I added it recently.

Do you mean post version 1.2.6?

Should I have downloaded the repository instead of the release?

Probably not.

René Berber

---

Reply to this email directly or view it on GitHub:
#2 (comment)

from tcpflow.

Looks like that would be useful for some folks. Actually I almost answered there with an advice to try tcpflow and then was somewhat puzzled to see it does only supports TCP. Yeah, the project's name clearly has the "tcp" word in it and I know UDP isn't a streaming protocol and so it doesn't "has flows". But at the same time people routinely think of UDP as implementing some sort of connections. Stateful firewalls such as Linux Netfilter do have a notion of UDP sessions.

So I would have being able to decapsulate UDP traffic won't be an unwelcomed addition. The problem is that it probably requires some sort of code that would deal with non-ASCII bytes in payloads in addition to decapsulation code.

from tcpflow.

It looks like the poster is confused. The packets are not HTTP packets, they are SSDP packets advertising a HTTP service. There is now a comment on the post which makes this clear.

from tcpflow.

Hi, I'm trying to use tcpflow to capture UDP packet payloads as well. tcpdump -A is kind of working for me, but I thought I'd try tcpflow too. It seems I can't capture UDP data either.

from tcpflow.

What do you want to do with the UDP data? You can't put it into TCP streams.
On Jan 25, 2013, at 2:57 PM, Andrew Otto [email protected] wrote:

Hi, I'm trying to use tcpflow to capture UDP packet payloads as well. tcpdump -A is kind of working for me, but I thought I'd try tcpflow too. It seems I can't capture UDP data either.

—
Reply to this email directly or view it on GitHub.

from tcpflow.

I'm trying to debug some packet loss issues. I'm just trying to examine the contents of the UDP packet payload, to see if the expected traffic is making it to the NIC.

On Jan 25, 2013, at 3:01 PM, "Simson L. Garfinkel" [email protected] wrote:

What do you want to do with the UDP data? You can't put it into TCP streams.
On Jan 25, 2013, at 2:57 PM, Andrew Otto [email protected] wrote:

Hi, I'm trying to use tcpflow to capture UDP packet payloads as well. tcpdump -A is kind of working for me, but I thought I'd try tcpflow too. It seems I can't capture UDP data either.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

from tcpflow.

So why are you using tcpflow and not tcpdump?

On Jan 25, 2013, at 3:03 PM, Andrew Otto [email protected] wrote:

I'm trying to debug some packet loss issues. I'm just trying to examine the contents of the UDP packet payload, to see if the expected traffic is making it to the NIC.

On Jan 25, 2013, at 3:01 PM, "Simson L. Garfinkel" [email protected] wrote:

What do you want to do with the UDP data? You can't put it into TCP streams.
On Jan 25, 2013, at 2:57 PM, Andrew Otto [email protected] wrote:

Hi, I'm trying to use tcpflow to capture UDP packet payloads as well. tcpdump -A is kind of working for me, but I thought I'd try tcpflow too. It seems I can't capture UDP data either.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

from tcpflow.

I am using tcpdump, but I was having trouble with it for a bit, and then ran into tcpflow. tcpflow seemed more natural to capture the raw payload data. I'm just letting you know that the udp option doesn't work for me either. I don't need it to, since tcpdump is a fine tool for this job, but since tcpflow advertised that it would work, I thought I'd try it.

On Jan 25, 2013, at 3:07 PM, "Simson L. Garfinkel" [email protected] wrote:

So why are you using tcpflow and not tcpdump?

On Jan 25, 2013, at 3:03 PM, Andrew Otto [email protected] wrote:

I'm trying to debug some packet loss issues. I'm just trying to examine the contents of the UDP packet payload, to see if the expected traffic is making it to the NIC.

On Jan 25, 2013, at 3:01 PM, "Simson L. Garfinkel" [email protected] wrote:

What do you want to do with the UDP data? You can't put it into TCP streams.
On Jan 25, 2013, at 2:57 PM, Andrew Otto [email protected] wrote:

Hi, I'm trying to use tcpflow to capture UDP packet payloads as well. tcpdump -A is kind of working for me, but I thought I'd try tcpflow too. It seems I can't capture UDP data either.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

from tcpflow.

Where is tcpflow advertised as working with UDP traffic?

On Jan 25, 2013, at 3:41 PM, Andrew Otto [email protected] wrote:

I am using tcpdump, but I was having trouble with it for a bit, and then ran into tcpflow. tcpflow seemed more natural to capture the raw payload data. I'm just letting you know that the udp option doesn't work for me either. I don't need it to, since tcpdump is a fine tool for this job, but since tcpflow advertised that it would work, I thought I'd try it.

On Jan 25, 2013, at 3:07 PM, "Simson L. Garfinkel" [email protected] wrote:

So why are you using tcpflow and not tcpdump?

On Jan 25, 2013, at 3:03 PM, Andrew Otto [email protected] wrote:

I'm trying to debug some packet loss issues. I'm just trying to examine the contents of the UDP packet payload, to see if the expected traffic is making it to the NIC.

On Jan 25, 2013, at 3:01 PM, "Simson L. Garfinkel" [email protected] wrote:

What do you want to do with the UDP data? You can't put it into TCP streams.
On Jan 25, 2013, at 2:57 PM, Andrew Otto [email protected] wrote:

Hi, I'm trying to use tcpflow to capture UDP packet payloads as well. tcpdump -A is kind of working for me, but I thought I'd try tcpflow too. It seems I can't capture UDP data either.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

from tcpflow.

Ha, maybe you didn't advertise it, but I was lead here via the aforementioned StackOverflow reply :p

from tcpflow.

Huh. I'll take a look at the link; can you send it to me?
On Jan 25, 2013, at 4:16 PM, Andrew Otto [email protected] wrote:

Ha, maybe you didn't advertise it, but I was lead here via the aforementioned StackOverflow reply :p

—
Reply to this email directly or view it on GitHub.

from tcpflow.

For anyone else winding up here after trying to dump UDP packets with tcpflow, two things to note:

1. There is an older version of tcpflow written by Jeremy Elson that has a man page on the Internet that seems to indicate tcpflow supports UDP. This man page looks a lot like the one included with the version of tcpflow in this repo.
2. Neither version of tcpflow supports UDP processing.

Good luck!

from tcpflow.

For anyone else winding up here after trying to dump UDP packets with tcpflow, two things to note:

1. There is an older version of tcpflow written by Jeremy Elson that has a man page on the Internet that seems to indicate tcpflow supports UDP. This man page looks a lot like the one included with the version of tcpflow in this repo.
2. Neither version of tcpflow supports UDP processing.

Good luck!

1. I took over tcpflow from Jeremy Elson many years ago.

2. What would it mean for a program that processes TCP packets to support "UDP processing." What does that even mean?

from tcpflow.

1. Thank you for the explanation.
2. I'm not a network engineer, but I understand packets well enough. My very very simple answer is another question, sorry: "can't it just work with udp like tcpdump does?" I've been looking for a way visualize statsd packets with ip headers, and tcpdump is the only tool I have, but it's output is awful; lots of nonprintable characters make lots of periods and random letters at the beginning of the packet. The command I ran that I was hopeful would work is: tcpflow -c udp port 8125

Thanks so much for the reply!

from tcpflow.