Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pcap packets timestamp is relative #3799

Closed
AlonZivony opened this issue Jan 11, 2024 · 0 comments · Fixed by #3800
Closed

Pcap packets timestamp is relative #3799

AlonZivony opened this issue Jan 11, 2024 · 0 comments · Fixed by #3800

Comments

@AlonZivony
Copy link
Collaborator

AlonZivony commented Jan 11, 2024

Currently when capturing network packets into a pcap file a relative time is given:
image

This is done because the network events don't go through the normal pipeline, thus their timestamp isn't modified:

func (t *Tracee) processNetCaptureEvents(ctx context.Context) {
	logger.Debugw("Starting processNetCaptureEvents goroutine")
	defer logger.Debugw("Stopped processNetCaptureEvents goroutine")

	var errChanList []<-chan error

	// source pipeline stage (re-used from regular pipeline)
	eventsChan, errChan := t.decodeEvents(ctx, t.netCapChannel)
	errChanList = append(errChanList, errChan)

	// process events stage (network capture only)
	errChan = t.processNetCapEvents(ctx, eventsChan)
	errChanList = append(errChanList, errChan)

	// pipeline started, wait for completion.
	if err := t.WaitForPipeline(errChanList...); err != nil {
		logger.Errorw("Pipeline", "error", err)
	}
}

The normal timestamp change is now done in the t.normalizeEventCtxTimes processor function.
Later in the flow the packet timestamp is initialized using the event timestamp:

func (p *Pcap) write(event *trace.Event, payload []byte) error {
	info := gopacket.CaptureInfo{
		Timestamp:     time.Unix(0, int64(event.Timestamp)),
		CaptureLength: int(len(payload)),
		Length:        int(len(payload)),
	}

This problem was probably introduced when we moved the time change to support the process tree processor functions.
Anyways, we should probably just add a step in the network capture pipeline that calls the t.normalizeEventCtxTimes function.

Thanks to @oshaked1 for noticing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant