Hi,
I'm a bit confused about the phrase PPP used here, does it mean to capture
on a physical WAN adapter, or capture the decrypted PPTP or L2TP packets
(using VPN)? If the option goes to the former, is there a way to emulate
such a hardware? because I don't have a WAN adapter, and it's important
I'm working on a new extcap that will leverage randpkt-core to give
wireshark a local random packet generator through randpktdump (the new
extcap).
I'm stucking with the DLTs part. The extcap must answer to the external
call about which DLTs it can generate. Randpkt-core can generate 5
different
You could try USER0. The problem here is, that I have to register the
extcap interface with the other interfaces at some point, and usually this
happens way before the capture starts (at which point an extcap utility
might know which DLT it could produce). Therefore I first ask the utility
for all
On Tue, Nov 24, 2015 at 2:00 PM, Dario Lombardo wrote:
>
> Where is it defined? I can't compile something like
>
> g_print("dlt {number=%u}{name=%s}{display=%s}\n", USER0,
> RANDPKT_EXTCAP_INTERFACE, wtap_encap_string(USER0));
>
>From the python example in doc:
Why don't use Exported PDU DLT (poke Anders/Pascal...) ?
On Tue, Nov 24, 2015 at 2:03 PM, Roland Knall wrote:
>
>
> On Tue, Nov 24, 2015 at 2:00 PM, Dario Lombardo <
> dario.lombardo...@gmail.com> wrote:
>
>>
>> Where is it defined? I can't compile something like
>>
>>
On Tue, Nov 24, 2015 at 2:03 PM, Roland Knall wrote:
>
> Which bug are you referring to?
>
> Sorry...
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11733
___
Sent via:Wireshark-dev mailing list
On Tue, Nov 24, 2015 at 12:55 PM, Roland Knall wrote:
> You could try USER0. The problem here is, that I have to register the
> extcap interface with the other interfaces at some point, and usually this
> happens way before the capture starts (at which point an extcap utility
>
On Tue, Nov 24, 2015 at 2:00 PM, Dario Lombardo wrote:
>
>
> I don't like it very much... Having too many interfaces is not likeable.
> Expecially when related to this bug
>
>
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11733
>
>
>> We actually provide a