Project

General

Profile

Actions

Bug #6538

closed

tcpdump needs update -- cannot decode most IPv6 RA options

Added by Bruce Simpson almost 8 years ago. Updated over 7 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
06/27/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

The version of tcpdump/libpcap in 2.3.1-x is lagging; this makes debugging IPv6 turn-ups slightly more difficult.

It cannot decode many of the options which the GUI can activate, e.g. default routes (option 24), local domain (option 31), MTU (option 5) etc.

pfSense ships tcpdump/libpcap 4.4.0/1.4.0. As a reference, Mac OS X 10.11 "El Capitain" ships 4.7.3/1.5.3.

Actions #1

Updated by Chris Buechler almost 8 years ago

  • Status changed from New to Not a Bug

we ship what's included in the FreeBSD version used.

Actions #2

Updated by Bruce Simpson over 7 years ago

(From a strictly "consumer of tech" point of view, relying on the base system for this is probably going to cause more grief further down the road.)

Couldn't this be replaced with the port/package? e.g. http://www.freshports.org/net/tcpdump/ is now at 4.7.4.

(The FreeBSD base system is going to be pkg-packaged, as you know, so the issue may well go away in time.)

Actions #3

Updated by Bruce Simpson over 7 years ago

OK, so having run headfirst into the bsdconfig wall, I had a rethink about how to express what this ticket is really about, as I think it's been misunderstood.

It's a bug to ship a feature which can't be diagnosed. The ticket is not about updating tcpdump per se. It's about having a means to diagnose pfSense's behaviour in common IPv6 configurations.

So I'll get around to reopening this at some point. Obviously I can't/don't have the resources to "battle test" pfSense in various IPv6 setups on the scale of e.g. University of New Hampshire Interoperability Laboratory (UNH-IOL), but the big vendors run that gauntlet too.

Having to resort to capturing elsewhere introduces bias -- sometimes, we need to see what the firewall is sending out directly at the source.

Actions

Also available in: Atom PDF