Part 1
요약·해설
일반 interface capture와 cooked mode의 차이, any/cooked virtual interface와 capture IP tunnel을 통한 remote 분석 흐름을 설명합니다.
Interface traffic
Arbitrary L2 packets
Capture IP tunnel
Part 2
접을 수 있는 영어 원문 전체
영어 원문 전체 펼치기
D581E23D695749A5A473CFE4541B56293364DE3545C9A18BA11C2079F7F016A6
.. _net_capture_interface:
Network Packet Capture
######################
.. contents::
:local:
:depth: 2
Overview
********
The ``net_capture`` API allows user to monitor the network
traffic in one of the Zephyr network interfaces and send that traffic to
external system for analysis. The monitoring can be setup either manually
using ``net-shell`` or automatically by using the ``net_capture`` API.
Cooked Mode Capture
*******************
If capturing is enabled and configured, the system will automatically capture
network traffic for a given network interface. If you would like to capture
network data when there is no network interface involved, then you need to use
the cooked mode capture API.
In cooked mode capture, arbitrary network packets can be captured and there
does not need to be network interface involved. For example low level HDLC
packets in PPP can be captured, as the HDLC L2 layer data is stripped away when
using the normal network interface based capture. Also CANBUS or Bluetooth
network data could be captured although currently there is no support in the
network stack to capture those.
The cooked mode capture works like this:
* An ``any`` network interface is created. It acts as a sink where the cooked
mode captured packets are written by the cooked mode capture API.
* A ``cooked`` virtual network interface is attached on top of this ``any``
interface.
* The ``cooked`` interface must be configured to capture certain L2 packet types
using the network interface configuration API.
* When cooked mode capture API is used, the caller must specify what is the
layer 2 protocol type of the captured data. The cooked mode capture API is then
able to determine what to capture when receiving such a L2 packet.
* The network packet capturing infrastructure is then setup so that the ``cooked``
interface is marked as captured network interface.
The packets received by the ``cooked`` interface via the ``any`` interface are
then automatically placed to the capture IP tunnel and sent to remote host
for analysis.
For example, in the sample capture application, these network interfaces
are created:
.. code-block:: c
Interface any (0x808ab3c) (Dummy) [1]
================================
Virtual interfaces attached to this : 2
Device : NET_ANY (0x80849a4)
Interface cooked (0x808ac94) (Virtual) [2]
==================================
Virtual name : Cooked mode capture
Attached : 1 (Dummy / 0x808ab3c)
Device : NET_COOKED (0x808497c)
Interface eth0 (0x808adec) (Ethernet) [3]
===================================
Virtual interfaces attached to this : 4
Device : zeth0 (0x80849b8)
IPv6 unicast addresses (max 4):
fe80::5eff:fe00:53e6 autoconf preferred infinite
2001:db8::1 manual preferred infinite
IPv4 unicast addresses (max 2):
192.0.2.1/255.255.255.0 overridable preferred infinite
Interface net0 (0x808af44) (Virtual) [4]
==================================
Virtual name : Capture tunnel
Attached : 3 (Ethernet / 0x808adec)
Device : IP_TUNNEL0 (0x8084990)
IPv6 unicast addresses (max 4):
2001:db8:200::1 manual preferred infinite
fe80::efed:6dff:fef2:b1df autoconf preferred infinite
fe80::56da:1eff:fe5e:bc02 autoconf preferred infinite
In this example, the ``192.0.2.2`` is the address of the outer end point of the
host that terminates the tunnel. Zephyr uses this address to select the
internal interface to use for the tunnel. In this example it is interface 3.
The interface 2 is a virtual interface that runs on top of interface 1. The
cooked capture packets are written by the capture API to sink interface 1.
The packets propagate to interface 2 because it is linked to the first interface.
The ``net capture enable 2`` net-shell command will cause the packets sent to
interface 2 to be written to capture interface 4, which in turn then capsulates
the packets and tunnels them to peer via the Ethernet interface 3.
The above IP addresses might change if you change the addresses in the
sample :zephyr_file:`samples/net/capture/overlay-tunnel.conf` file.
Sample usage
************
See :zephyr:code-sample:`net-capture` sample application and
:ref:`network_monitoring` for details.
API Reference
*************
.. doxygengroup:: net_capture
Part 3
한국어 전문 번역
Network Packet Capture
Overview
net_capture API는 Zephyr network interface 하나의 traffic을 monitor하고 분석을 위해 외부 system으로 전송하게 합니다. Monitoring은 net-shell에서 수동으로 설정하거나 net_capture API로 자동 설정할 수 있습니다.
Cooked Mode Capture
Capture를 활성화하고 설정하면 지정한 network interface의 traffic을 자동으로 수집합니다. Network interface가 관여하지 않는 network data를 수집하려면 cooked mode capture API를 사용합니다.
Cooked mode에서는 임의의 network packet을 interface 없이 수집할 수 있습니다. 예를 들어 일반 interface 기반 capture에서는 HDLC L2 data가 제거되지만 cooked mode는 PPP의 low-level HDLC packet을 수집할 수 있습니다. CAN bus나 Bluetooth network data도 이론상 수집할 수 있지만 현재 network stack에는 그 capture 지원이 없습니다.
Cooked mode capture는 다음 순서로 동작합니다.
anynetwork interface를 만들어 cooked API가 packet을 쓰는 sink로 사용합니다.any위에cookedvirtual network interface를 연결합니다.- Network interface configuration API로
cookedinterface가 수집할 L2 packet type을 설정합니다. - Caller는 cooked API를 사용할 때 captured data의 layer-2 protocol type을 지정합니다. API는 받은 L2 packet 중 무엇을 수집할지 판별합니다.
cookedinterface를 captured interface로 표시하도록 packet capture infrastructure를 설정합니다.any를 거쳐cooked가 받은 packet은 capture IP tunnel에 놓이고 분석할 remote host로 전송됩니다.
Capture sample application이 만드는 interface 예입니다.
Interface any (0x808ab3c) (Dummy) [1]
================================
Virtual interfaces attached to this : 2
Device : NET_ANY (0x80849a4)
Interface cooked (0x808ac94) (Virtual) [2]
==================================
Virtual name : Cooked mode capture
Attached : 1 (Dummy / 0x808ab3c)
Device : NET_COOKED (0x808497c)
Interface eth0 (0x808adec) (Ethernet) [3]
===================================
Virtual interfaces attached to this : 4
Device : zeth0 (0x80849b8)
IPv6 unicast addresses (max 4):
fe80::5eff:fe00:53e6 autoconf preferred infinite
2001:db8::1 manual preferred infinite
IPv4 unicast addresses (max 2):
192.0.2.1/255.255.255.0 overridable preferred infinite
Interface net0 (0x808af44) (Virtual) [4]
==================================
Virtual name : Capture tunnel
Attached : 3 (Ethernet / 0x808adec)
Device : IP_TUNNEL0 (0x8084990)
IPv6 unicast addresses (max 4):
2001:db8:200::1 manual preferred infinite
fe80::efed:6dff:fef2:b1df autoconf preferred infinite
fe80::56da:1eff:fe5e:bc02 autoconf preferred infinite192.0.2.2는 tunnel을 끝내는 host outer endpoint의 address입니다. Zephyr는 이 address로 tunnel에 쓸 내부 interface를 고르며 예에서는 interface 3입니다.
Interface 2는 interface 1 위에서 실행되는 virtual interface입니다. Capture API는 cooked packet을 sink interface 1에 쓰고, 두 interface가 연결돼 있으므로 packet이 interface 2로 전달됩니다.
net capture enable 2 net-shell command를 실행하면 interface 2로 보낸 packet이 capture interface 4에 기록됩니다. Interface 4는 packet을 encapsulate한 뒤 Ethernet interface 3을 통해 peer로 tunnel합니다.
Sample의 samples/net/capture/overlay-tunnel.conf에서 address를 바꾸면 위 IP address도 달라질 수 있습니다.
Sample usage
net-capture sample application과 Network Traffic Monitoring 문서에서 자세한 사용법을 확인할 수 있습니다.
API Reference
Doxygen group net_capture가 API reference를 제공합니다.
Source
출처
영어 원문에는 문단, 문서 지시문, 표, 코드, 코드 심벌, 경로를 그대로 보존했습니다.