search

dazer-chen / gopacket

Automatically exported from code.google.com/p/gopacket
BSD 3-Clause "New" or "Revised" License
0 stars 1 forks source link

pcap fails on OSX #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I wrote an app that uses gopacket to capture and analyze some network traffic 
generated by another local application. It works fine on capture files 
generated from `tcpdump` on my machine, but it fails when I run it in live mode 
-- I just don't get any packets.

I boiled this down into an executable test case. It opens a pcap session, sets 
up a filter, sends a packet to 8.8.8.8's UDP discard port, and checks to see 
that it can hear itself. This test succeeds on Linux:

$ go test github.com/willglynn/gopacket-local-test --interface br0
ok      github.com/willglynn/gopacket-local-test    0.675s

...but fails on my Mac:

$ go test --short 
--- FAIL: TestCapture (1.02 seconds)
    gopacket_local_test.go:61: starting capture on interface "en0"
    gopacket_local_test.go:74: capturing on "en0"
    gopacket_local_test.go:95: 2014-05-27 10:33:19.930115476 -0500 CDT: packet sent
    gopacket_local_test.go:91: 2014-05-27 10:33:20.931371869 -0500 CDT: no packets received, timing out
FAIL
exit status 1
FAIL    github.com/willglynn/gopacket-local-test    1.256s

A `tcpdump` session I had running shows that the packet was, in fact, sent:

$ tcpdump -n -i en0 'port 9'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:33:19.930126 IP 172.16.4.167.59296 > 8.8.8.8.9: UDP, length 26

I'm new to go, so please excuse my test case. I'm just happy I can reproduce 
this at all. My Mac is running 10.9 with a Homebrew-installed go:

$ go version
go version go1.2.2 darwin/amd64

Original issue reported on code.google.com by w...@willglynn.com on 27 May 2014 at 3:39

GoogleCodeExporter commented 9 years ago 
Hey, will,

Thanks for the report!  Could you describe (or paste the code showing) how 
you're sending your packet from inside gopacket_local_test.go?  Are you using 
gopacket/pcap's WritePacketData?

  --Graeme

Original comment by gconnell@google.com on 27 May 2014 at 4:40

GoogleCodeExporter commented 9 years ago 
It's pretty boring -- net.DialUDP() followed by a write.

https://github.com/willglynn/gopacket-local-test/blob/master/gopacket_local_test
.go#L29-L47

Original comment by w...@willglynn.com on 27 May 2014 at 4:42

GoogleCodeExporter commented 9 years ago 
Hi,

I have the same issue. Didn't have a look at the code yet but the pcap binding 
from github.com/miekg/pcap works form me. So it is not a general pcap issue. 
I'm using  libpcap version 1.3.0 - Apple version 41

Original comment by boombuler@gmail.com on 28 May 2014 at 5:43

GoogleCodeExporter commented 9 years ago 
Okay, I'm slowly narrowing down what the problem isn't.  No strong leads yet, 
but switching back to pcap_open_live doesn't help, nor does setting the promisc 
flag.  BTW, I've got libpcap 1.59 on my mac, but I'm hoping it'll work.

Could y'all run pcap/pcap_tester locally and let me know what comes out of that?

It works on my Mac, which makes me thing that it's not losing all packets, just 
most of them.  Not that that's a good thing :-P

Original comment by gconnell@google.com on 28 May 2014 at 11:34

GoogleCodeExporter commented 9 years ago 
pcap/pcap_tester seems to work:

$ go run pcap_tester.go 
2014/05/28 19:55:17 Trying capture on "lo0"
2014/05/28 19:55:17 Error capturing on "lo0": skipping loopback
2014/05/28 19:55:17 Trying capture on "gif0"
2014/05/28 19:55:23 Error capturing on "gif0": readpacketdata: Timeout Expired
2014/05/28 19:55:23 Trying capture on "stf0"
2014/05/28 19:55:29 Error capturing on "stf0": readpacketdata: Timeout Expired
2014/05/28 19:55:29 Trying capture on "en0"
2014/05/28 19:55:31 Read packet, 66 bytes, CI: {Timestamp:2014-05-28 
19:55:29.67557 -0500 CDT CaptureLength:66 Length:66}
2014/05/28 19:55:31 Successfully captured on "en0"

Original comment by w...@willglynn.com on 29 May 2014 at 12:56

GoogleCodeExporter commented 9 years ago 
uhmmm I've found the following:
linktype: Null 
for my wifi device... I guess that should not happen?

Original comment by boombuler@gmail.com on 29 May 2014 at 6:11

GoogleCodeExporter commented 9 years ago 
I've seen that too. Setting a filter seems to magically change the link type to 
Ethernet.

Original comment by w...@willglynn.com on 29 May 2014 at 2:19

GoogleCodeExporter commented 9 years ago 
Hmm ,I'm not seeing a similar linktype issue on my end.  Could you print out 
the linktype with %d to get the numeric value?

Original comment by gconnell@google.com on 29 May 2014 at 4:31

GoogleCodeExporter commented 9 years ago 
I updated the code: 
https://github.com/willglynn/gopacket-local-test/commit/401b5cddba09444010db12d0
c167ea6fd7f89059

$ go test --short
--- FAIL: TestCapture (1.03 seconds)
    gopacket_local_test.go:61: starting capture on interface "en0"
    gopacket_local_test.go:70: link type before setting filter: 0
    gopacket_local_test.go:76: link type after setting filter: 1
    gopacket_local_test.go:78: capturing on "en0"
    gopacket_local_test.go:99: 2014-05-29 11:44:00.725931513 -0500 CDT: packet sent
    gopacket_local_test.go:95: 2014-05-29 11:44:01.726452175 -0500 CDT: no packets received, timing out
FAIL
exit status 1
FAIL    github.com/willglynn/gopacket-local-test    1.235s

Original comment by w...@willglynn.com on 29 May 2014 at 4:45

GoogleCodeExporter commented 9 years ago 
I've committed code which should fix the LinkType issue, but it's still not 
fixing the underlying problem of not seeing packets, as far as I can tell.  
Regardless, please 'go get' the master branch (or tag v1.1.0) and let me know 
if you see any changes in behavior.

https://code.google.com/p/gopacket/source/detail?r=c05ae030104a8d789a11bd686b4e1
d1c08468f65
https://code.google.com/p/gopacket/source/detail?r=c9be950d1eb93ba5422d713c4dc00
64bed2fb0f0

Original comment by gsconn...@gmail.com on 29 May 2014 at 6:56

GoogleCodeExporter commented 9 years ago 
Link types now behave as expected:

$ go test github.com/willglynn/gopacket-local-test
--- FAIL: TestCapture (30.00 seconds)
    gopacket_local_test.go:61: starting capture on interface "en0"
    gopacket_local_test.go:70: link type before setting filter: 1
    gopacket_local_test.go:76: link type after setting filter: 1
    gopacket_local_test.go:78: capturing on "en0"
    gopacket_local_test.go:99: 2014-05-29 14:14:39.721288149 -0500 CDT: packet sent
    gopacket_local_test.go:95: 2014-05-29 14:15:09.708665821 -0500 CDT: no packets received, timing out
FAIL
FAIL    github.com/willglynn/gopacket-local-test    30.216s

Original comment by w...@willglynn.com on 29 May 2014 at 7:15

GoogleCodeExporter commented 9 years ago 
Found the issue, with 99% confidence:

https://github.com/jvinet/knock/issues/5

Basically, "read timeout considered harmful" on some platforms.

Handling this correctly is going to be difficult while maintaining backwards 
compatibility... I'll see what I can do.  I might fudge stuff internally to do 
what I want. :)

Original comment by gsconn...@gmail.com on 30 May 2014 at 4:30

GoogleCodeExporter commented 9 years ago 
Sweet success!

Commit 
https://code.google.com/p/gopacket/source/detail?r=01c3d077bd9a98fac6954a18089ad
30795d1d230 should fix your issues.  Make sure you're not passing 0 as a 
timeout into OpenLive directly... see the changes to doc.go for gory details.

I think with this commit, we'll manage to keep backwards compatibility while 
still providing the expected behavior for all users.

Marking issue as fixed, but please update if any issues are still coming up.

Thanks for all the help on this!

Original comment by gsconn...@gmail.com on 30 May 2014 at 5:20

GoogleCodeExporter commented 9 years ago 
Awesome, thanks!

ok      github.com/willglynn/gopacket-local-test    0.234s

Original comment by w...@willglynn.com on 30 May 2014 at 1:15

GoogleCodeExporter commented 9 years ago 
my project still doesn't work but there might be other bugs on my side :) 
Thanks for the super fast fixing speed!

Original comment by boombuler@gmail.com on 30 May 2014 at 1:24