Proposal for nic_tap component

Martijn Verschoor verschoor at ...434...
Fri Apr 13 09:50:11 CEST 2018


Hi Emery,

Thanks for your suggestion to log the intercepted network packets in a
pcap(ng) file. This could be a valuable extension to the nic_tap component.

I would recommend to use the proposed nic_tap component to deal with the
interception and implement the pcap(ng) implementation in a dedicated
component.

The proposed nic_tap component only duplicates intercepted packets to
the 'tap' Nic client. Its purpose is to delegate further processing of
the intercepted network packets to other components. For example to a
guest running Linux and Wireshark, or to a component that writes
pcap(ng) files to a storage location.

-- 

Met vriendelijke groet / kind regards,

Martijn Verschoor

Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands
+31 35 631 3253 (office) |  +31 616 014 087 (mobile)

On 07-04-18 14:50, Emery Hemingway wrote:
> Hi Martijn,
> 
> I had considered doing this, but didn't find enought time. I did some
> research though. The 'pcapng' is the file format to use if you want
> compatibility with wireshark. It is also the same format that QEMU
> outputs when used with the '-nic dump,file=...' option. The spec is
> pretty easy to understand: https://github.com/pcapng/pcapng
> 
> I had started on a component, but I can't find any code. I don't
> remember getting very far, but I do remember using the pcapfix utility
> was helpful to see how bad my dumps were.
> http://f00l.de/pcapfix/
> 
> Cheers,
> Emery
> 
> On Thu, 5 Apr 2018 15:07:40 +0200
> Martijn Verschoor <verschoor at ...434...> wrote:
> 
>> Hi everyone,
>>
>> I would like to pitch an idea to improve network protocol debugging on
>> Genode.
>>
>> I value the verbosity option of the `nic_router` and the `nic_dump`
>> components, but sometimes I'd like the ability delve deeper into
>> packets, like I am used to with Wireshark. But extending the log based
>> network debugging in Genode to reach that level of detail clearly
>> doesn't make sense.
>>
>> Another option is to introduce an intercepting `nic_tap` component
>> that implements a bump-in-the-interface between a Nic client and a
>> Nic server and duplicates all packets between the client and the
>> server to a dedicated Nic tap interface. A Nic client connected to
>> the Nic tap interface is presented with all network packets, both up-
>> and downstream, of the intercepted Nic session.
>>
>> The nic_tap is especially useful when running on real hardware. There
>> are various ways to use the nic_tap. An obvious scenario is to setup
>> an instance of VirtualBox with Linux and Wireshark that is routed to
>> use the Nic tap. But it should also be possible to route the Nic tap
>> to an external Nic interface (granted that you have a solution to tie
>> two Nic clients together, but that’s easy enough).
>>
>> In my view the nic_tap would be a valuable and complementing addition
>> to the set of Genode network debugging tools.
>>
>> What do you think, would you benefit from such a component?
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20180413/da9f4b02/attachment.sig>


More information about the users mailing list