This is the current state of our new reassembly package which does full (IPv4 and TCP) bidirectional reassembly, implements a TCP state machine and various security checks on TCP traffic. It is based on the existing tcpassembly package. A new reassemblydump program is provided which uses the reassembly package, with support for DNS and HTTP reassembly.

The code is probably not fit for merging as-is, however all comments and feedback are welcome at this stage.

The old tcpassembly package and its example programs are removed as the reassemblydump tool supersedes them.

I've hit the same issue as reported in this Stackoverflow question:

Essentially, forwarding a packet between interfaces requires the checksum to be recalculated, however setting SerializeOptions.ComputeChecksums=true does not work as expected and the resulting packets are malformed.

My code is very similar to that listed in the post above, except I'm using IPv6 and forwarding ICMPv6:

    eth := n.eth
    eth.SrcMAC = iface.HardwareAddr
    ipv6 := n.ip6
    ipv6.SrcIP = linklocal
    buf := gopacket.NewSerializeBuffer()
    opts := gopacket.SerializeOptions{ComputeChecksums: true}

    gopacket.SerializeLayers(buf, opts, &eth, &ipv6, &n.icmp)

    handle.WritePacketData(buf.Bytes())

OK... here's the code. I haven't done a smoke test lately but last time I tested it worked on OpenBSD, FreeBSD and NetBSD.

Maybe we should be calling SetBpfBuflen instead of using the default. OpenBSD and NetBSD both default to a BPF bufLen of 32767 but FreeBSD uses 4096... obviously having a larger bufLen should improve performance.

I am developing a new layer decoder for an application layer protocol. Request and response have different footprints, how can I check the flow within my decoder? It depends on the outer layer info, how can I reach it?

Hello,

We have recently seen a performance regression when using gopacket's pcap capabilities. We noticed the regression when we saw the number of packets being processed dropped significantly. When we investigated further we identified that the pcap handle Stats() was reporting Dropped to be around 98% of the total packets processed.

When we started to investigate the issue we rolled back the commits on gopacket and found that the regression was introduced in commit 7d9ba85c47bb41298fed10f5769f793741de187f

Here is the statistics output.

Aug 28 22:18:06 time="2017-08-28T22:18:06Z" level=info msg="Statistics received: 2480538, dropped: 0, interface dropped 0"
Aug 28 22:18:21 time="2017-08-28T22:18:21Z" level=info msg="Statistics received: 2480630, dropped: 0, interface dropped 0"
Aug 28 22:18:36 time="2017-08-28T22:18:36Z" level=info msg="Statistics received: 2480726, dropped: 0, interface dropped 0"
Aug 28 22:18:51 time="2017-08-28T22:18:51Z" level=info msg="Statistics received: 2480812, dropped: 0, interface dropped 0"
Aug 28 22:19:06 time="2017-08-28T22:19:06Z" level=info msg="Statistics received: 2480884, dropped: 0, interface dropped 0"
Aug 28 22:19:21 time="2017-08-28T22:19:21Z" level=info msg="Statistics received: 2480972, dropped: 0, interface dropped 0"
<<< REDEPLOY WITH NEW VERSION OF gopacket >>>
Aug 28 22:20:03 time="2017-08-28T22:20:03Z" level=info msg="Statistics received: 64, dropped: 36, interface dropped 0"
Aug 28 22:20:18 time="2017-08-28T22:20:18Z" level=info msg="Statistics received: 150, dropped: 122, interface dropped 0"
Aug 28 22:20:33 time="2017-08-28T22:20:33Z" level=info msg="Statistics received: 230, dropped: 202, interface dropped 0"
Aug 28 22:20:48 time="2017-08-28T22:20:48Z" level=info msg="Statistics received: 326, dropped: 298, interface dropped 0"
Aug 28 22:21:03 time="2017-08-28T22:21:03Z" level=info msg="Statistics received: 402, dropped: 374, interface dropped 0"
Aug 28 22:21:18 time="2017-08-28T22:21:18Z" level=info msg="Statistics received: 488, dropped: 460, interface dropped 0"
Aug 28 22:21:33 time="2017-08-28T22:21:33Z" level=info msg="Statistics received: 566, dropped: 538, interface dropped 0"
Aug 28 22:21:48 time="2017-08-28T22:21:48Z" level=info msg="Statistics received: 654, dropped: 626, interface dropped 0"
Aug 28 22:22:03 time="2017-08-28T22:22:03Z" level=info msg="Statistics received: 732, dropped: 704, interface dropped 0"
Aug 28 22:22:18 time="2017-08-28T22:22:18Z" level=info msg="Statistics received: 796, dropped: 768, interface dropped 0"
Aug 28 22:22:33 time="2017-08-28T22:22:33Z" level=info msg="Statistics received: 876, dropped: 848, interface dropped 0"
Aug 28 22:22:48 time="2017-08-28T22:22:48Z" level=info msg="Statistics received: 966, dropped: 938, interface dropped 0"
Aug 28 22:23:03 time="2017-08-28T22:23:03Z" level=info msg="Statistics received: 1046, dropped: 1018, interface dropped 0"
Aug 28 22:23:18 time="2017-08-28T22:23:18Z" level=info msg="Statistics received: 1102, dropped: 1074, interface dropped 0"

From the logs we can see that when we redeployed with the latest commits the number of drops started to increase. When we then reverted back to the previous binary the drops returned to zero. We then started to investigate and found that the problem was only introduced in the commit listed above.

System Info

hostname:~# go version
go version go1.8.3 linux/amd64

hostname:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

hostname:~# dpkg --list | grep pcap
ii  libpcap-dev                       1.7.4-2                                    all          development library for libpcap (transitional package)
ii  libpcap0.8:amd64                  1.7.4-2                                    amd64        system interface for user-level packet capture
ii  libpcap0.8-dev                    1.7.4-2                                    amd64        development library and header files for libpcap0.8

This is an experiment, I've made during a cloudy weekend ;) It is based on the DefragIPv4 interface suggested by Graeme some months ago.

I am submitting it for reviewing purpose and get extensive comments from the GoPacket Authors

This implements the DefragIPv4 interface, which embed IPv4 defragmentation, and modify packets in place. It returns false if the packet is fragmented, and caller will need to give subsequent packets. It returns true, if the packet is in its final state (defragmented or just pristine).

root@ubuntu:~/processNet/processNet# go run testversion.go

github.com/google/gopacket/pcap

/home/go/src/github.com/google/gopacket/pcap/pcap.go:30:22: undefined: pcapErrorNotActivated /home/go/src/github.com/google/gopacket/pcap/pcap.go:52:17: undefined: pcapTPtr /home/go/src/github.com/google/gopacket/pcap/pcap.go:64:10: undefined: pcapPkthdr

`package main

import ( "fmt"

    "github.com/google/gopacket/pcap"

)

func main() { fmt.Println(pcap.Version()) }`

Already installed libpcap and c test available What is the reason？

Type SocketStatsV3 is a structure from C, how can I access the values of its fields?

The following code is not compiled:

s1, s2, err: = inputAFpacket.SocketStats ()
log.Println (s2.tp_drops)

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 [email protected] on 27 May 2014 at 3:39

Switch router interfaces to a map to support discontinuous interface ids. Fixes #222

Will admit, Line 107 is messy. Wasn't sure how to easily return a pointer from a map. Added some tests to verify routing functionality works as expected as well.

I have implemented a gopacket layer for the Network Time Protocol (NTP).

As, prior to this project, I was unfamiliar with gopacket and NTP, I have provided detailed comments to explain what I have done.

I have included three tests, and it all works.

Code that could be improved or clarified is marked "FIX".

Ross

This fixes two bugs in the Geneve implementation:

• The decoder was using an incorrect number of bits for the option length field
• The encoder was generating corrupt packets on serialisation due to uninitialised buffer use

I am new to tunnels and network level coding, however there are some great examples using gopacket specifically i found this one Decoding Packet Layers here.

I am interested in understanding PING specifically so I slightly adjusted the code to

	ipLayer := packet.Layer(layers.LayerTypeIPv4)
	if ipLayer != nil {
		fmt.Println("IPv4 layer detected.")
		ip, _ := ipLayer.(*layers.IPv4)

		if ip.Protocol == layers.IPProtocolICMPv4 {
			fmt.Println("icmp")
			fmt.Println("payload ", string(ip.Payload))
			fmt.Printf("From %s to %s\n", ip.SrcIP, ip.DstIP)
			fmt.Println()
			fmt.Printf("packet %+v\r\n", packet.Dump())
		}
		return
	}

What I'm interested in is manipulating the ping response in this case. I.e when my computer is pinged from another device on the network (or the internet if thats configured on the router) can I hijack the response that my machine makes, i.e maybe by changing the payload or the latency (time it takes to respond). I.e can I get the pinger to receive data that is incorrect.

I tried adding a time.Sleep(1 * time.Second) in the above, however it doesn't slow the response down - so what I figure is I am reading the incoming data, but not hijacking the network to manipulate the returned data.

Can gopacket do this? What would the interception of the response look like so that I can add in an arbitrary delay and get ping latency of 1s +

Thanks for all/any help.

I am writing a custom tcp reassembly, and after calling the KeepFrom(offset) method of reassembly.ScatterGather many times, an array out-of-bounds error will occasionally occur here (I checked the context carefully, and the incoming offset is less than Length() available bytes ).

I bet there should be bounds checking to prevent out-of-bounds errors.

nanoSecsFactor set to 1 for ns precision and sets to 1000 for ms precision, but the opposite logic is used in Resolution() function

this patch uses the same logic in Resolution() function as it used during reading

I'm using gopacket to parse DNS packets arriving from eBPF and I noticed that when doing something like:

$ nslookup -type=any example.com

The following code does not work:

and the reason is that layer7, coming from packet.ApplicationLayer(), isn't recognized as type (*layers.DNS), as showed by TypeOf():

l7 type: <nil>
l7 type: <nil>
l7 type: <nil>
l7 type: *gopacket.Payload
l7 type: <nil>
l7 type: *gopacket.Payload
l7 type: <nil>
l7 type: <nil>