Hi Chris,
Thanks for checking this.
Did you use a “Decode as …” with SoupBinTCP? I believe there’s something my
dissector is doing that’s causing the problem (without it, I too see the
relative seq/ack numbers looking correct).
Thanks,
d
> On 4 Dec 2018, at 04:55, Maynard, Chris wrote:
On Dec 3, 2018, at 12:01 PM, Richard Sharpe wrote:
> Over the weekend I was doing some work with rpcap.
>
> I stumbled on one on github but that does not work and uses weird data
> link types for regular Ethernet interfaces. I saw this message from
> dumpcap, for example:
>
>(unknown data l
Hi folks,
Over the weekend I was doing some work with rpcap.
I stumbled on one on github but that does not work and uses weird data
link types for regular Ethernet interfaces. I saw this message from
dumpcap, for example:
(unknown data link type 3)
However, the version in libpcap/rpcapd wor
I enabled the same debug and frame 10 looks good:
analyze_sequence numbers frame:9
FWD list lastflags:0x base_seq:3273800524: nextseq:3273800529
lastack:3273800529
REV list lastflags:0x base_seq:3871803454 nextseq:3871803553
lastack:3871803504
Frame:8 Seq:3871803504 Nextseq:3871803553
> On 3 Dec 2018, at 18:37, Jaap Keuter wrote:
>
> Hi David,
>
> Not at the moment, no. Anyone else?
I discovered some #if’d-out debugging code in tcp_analyse_sequence_number(),
which seems to reflect the problem:
analyze_sequence numbers frame:1
FWD list lastflags:0x base_seq:0: nextseq
Have you recreated the CMakeCache.txt? Could you try running the command in
a completely new environment, but with PCAP_HINTS set to /usr/local for the
first run?
It seems that cmake/modules/FindPCAP.cmake just does not take PCAP_HINTS
and most likely with cmake that's because it has already store
