1 |
27 |
unneback |
# Target definition file fragment for ethernet devices.
|
2 |
|
|
#
|
3 |
|
|
# The target-side can instantiate up to four ethernet devices,
|
4 |
|
|
# eth0 to eth3. Each instance requires an entry in the
|
5 |
|
|
# target definition file specifying what underlying Linux
|
6 |
|
|
# kernel facility should be used to implement the I/O. This
|
7 |
|
|
# can take the following forms:
|
8 |
|
|
#
|
9 |
|
|
# 1) an existing ethernet device, e.g.
|
10 |
|
|
# eth0 real eth1
|
11 |
|
|
# thus mapping the eCos device eth0 on to the Linux device eth1.
|
12 |
|
|
# The latter network interface must not currently be in use
|
13 |
|
|
# by Linux. Traffic will flow to and from the real ethernet, and
|
14 |
|
|
# communication is possible with any machine on the LAN.
|
15 |
|
|
#
|
16 |
|
|
# 2) the Linux kernel's tap facility.
|
17 |
|
|
# eth0 ethertap
|
18 |
|
|
# This will result in a Linux ethernet interface such as
|
19 |
|
|
# tap3 appearing. The interface can be configured like any
|
20 |
|
|
# other network device, for example by using the ifconfig
|
21 |
|
|
# command or by creating a configuration file
|
22 |
|
|
# /etc/sysconfig/network-scripts/ifcfg-tap3
|
23 |
|
|
# The result is a virtual ethernet segment visible only
|
24 |
|
|
# to the Linux host and eCos. Bridge software inside the
|
25 |
|
|
# Linux host can be used to connect eCos to a larger network.
|
26 |
|
|
#
|
27 |
|
|
# Optionally a specific tap device can be configured,
|
28 |
|
|
# eth0 ethertap tap3
|
29 |
|
|
# By default the code will pick up the next free tap device,
|
30 |
|
|
# usually tap0. If the Linux interface should come up automatically
|
31 |
|
|
# then this can be achieved with an ifcfg-tap?? configuration
|
32 |
|
|
# file. Explicitly specifying the tap device can avoid some
|
33 |
|
|
# confusion.
|
34 |
|
|
#
|
35 |
|
|
# Both the eCos and the Linux network interface need a unique
|
36 |
|
|
# MAC address. There is no real ethernet hardware involved to
|
37 |
|
|
# supply these addresses, so they have to be invented. The
|
38 |
|
|
# Linux kernel will automatically invent one for its interface.
|
39 |
|
|
# By default a random MAC address will also be generated for
|
40 |
|
|
# the eCos interface, but to make the system more deterministic
|
41 |
|
|
# it is possible to specify the MAC address to be used. This
|
42 |
|
|
# facility is only available in conjunction with an explicit
|
43 |
|
|
# tap device, e.g.:
|
44 |
|
|
# eth0 ethertap tap3 00:01:02:03:04:05
|
45 |
|
|
# The MAC address should be in the usual format: six 2-digit
|
46 |
|
|
# hexadecimal numbers separated by colons. It is the user's
|
47 |
|
|
# responsibility to make sure that the address specified
|
48 |
|
|
# does not match any other real or invented address visible
|
49 |
|
|
# on the local network.
|
50 |
|
|
#
|
51 |
|
|
# It is possible that bursts of ethernet traffic occur, causing
|
52 |
|
|
# packets to arrive faster than they can be forwarded to and
|
53 |
|
|
# processed by eCos. It is desirable that some number of packets
|
54 |
|
|
# be buffered, matching the behaviour of many ethernet devices
|
55 |
|
|
# with built-in fifos. However the number of these packets should
|
56 |
|
|
# be restricted: if eCos stops accepting ethernet packets or
|
57 |
|
|
# cannot handle the data quickly enough, then it is possible that
|
58 |
|
|
# an unlimited number of packets could accumulate in the I/O
|
59 |
|
|
# auxiliary until all available memory and swap space is exhausted.
|
60 |
|
|
# By default up to 16 packets will be buffered per device, but
|
61 |
|
|
# this can be changes with the max_buffer option.
|
62 |
|
|
#
|
63 |
|
|
# The ethernet emulation code can perform logging and limited
|
64 |
|
|
# analysis of each ethernet packet. For example if a particular
|
65 |
|
|
# packet is an IPv4 ICMP request then details of the request
|
66 |
|
|
# will be logged to the main text window. The appearance of the
|
67 |
|
|
# various filters can be controlled here, using the usual
|
68 |
|
|
# options such as -foreground, -background, and -hide.
|
69 |
|
|
#
|
70 |
|
|
# This logging of each ethernet frame can be somewhat time-consuming
|
71 |
|
|
# and, for a long run, require a lot of memory. Logging can be
|
72 |
|
|
# disabled by default if desired, and a button on the toolbar allows
|
73 |
|
|
# this setting to be toggled.
|
74 |
|
|
#
|
75 |
|
|
# Ethernet packets can be up to 1514 bytes, so showing entire packets
|
76 |
|
|
# on a single line can mean very wide lines. In practice the interesting
|
77 |
|
|
# data is usually at the start, so the output can be truncated to a
|
78 |
|
|
# maximum number of bytes. The data is displayed in hex so each byte
|
79 |
|
|
# requires two columns, and some spacing will be added as well to
|
80 |
|
|
# improve legibility.
|
81 |
|
|
|
82 |
|
|
synth_device ethernet {
|
83 |
|
|
## Map eCos devices on to Linux ones.
|
84 |
|
|
|
85 |
|
|
# eth0 real eth1
|
86 |
|
|
# eth0 ethertap
|
87 |
|
|
# eth0 ethertap tap3
|
88 |
|
|
eth0 ethertap tap3 00:FE:42:63:84:A5
|
89 |
|
|
|
90 |
|
|
# eth1 ethertap tap4 00:FE:12:34:56:78
|
91 |
|
|
# eth2 ethertap tap5 00:FE:9A:BC:DE:F0
|
92 |
|
|
# eth3 real eth2
|
93 |
|
|
|
94 |
|
|
## Maximum number of packets that should be buffered per interface.
|
95 |
|
|
## Default 16
|
96 |
|
|
max_buffer 32
|
97 |
|
|
|
98 |
|
|
## Should packets be logged? The default is yes.
|
99 |
|
|
# logging 0
|
100 |
|
|
|
101 |
|
|
## Maximum number of data bytes to be shown.
|
102 |
|
|
## Default 64
|
103 |
|
|
# max_show 128
|
104 |
|
|
|
105 |
|
|
## Filters for the various recognised protocols.
|
106 |
|
|
## By default all filters are visible and use standard colours.
|
107 |
|
|
# filter ether -hide 0
|
108 |
|
|
# filter arp -hide 1
|
109 |
|
|
# filter ipv4 -hide 1
|
110 |
|
|
# filter ipv6 -hide 1
|
111 |
|
|
# filter icmpv4 -hide 1
|
112 |
|
|
# filter icmpv6 -hide 1
|
113 |
|
|
# filter udp -hide 1
|
114 |
|
|
# filter tcp -hide 1
|
115 |
|
|
# filter hexdata -hide 0
|
116 |
|
|
# filter asciidata -hide 0
|
117 |
|
|
}
|