
20
were translated using that flow mapping. Packets would also be mapped based on if they matched
the reverse of that mapping, in order to return packets to their original sender.
Each pattern in the IPRewriter element had a corresponding input. For example, the first pattern
would accept packets on the first input. After the pattern, an output was defined for the forward
and reverse paths. For simplicity, in the configuration files created, the output for forward path of
the first input was the first output, and so forth. The reverse output would correspond to the
forward output of the other mapping pattern.
This element is similar to the IPRewriter, but preformed NAT only on ICMP echo packets. It did
not have the same amount of flexibility as the IPRewriter. It was configured to change the source
address to correspond with that of the host router, and leave the destination address unchanged.
Requests were sent to the first output, replies were sent to the second output.
This element was used to check mappings for ICMP error packets. It checked the patterns used in
the IPRewriter and ICMPPingRewriter elements. If a mapping existed, it was applied, and the
packet sent to output zero. If not, the packet was sent unchanged to output one.
GatewayDevice: Compound Element
This element manages packet flow between Click and a communication device. In the network
implemented, this communication device was the client wireless device or wired Ethernet device.
As shown in Figure 5-1, packets coming from the device were sent through to the next element
within the Click router. Packets destined for the external network were first sent to a queue, from
the queue packets were sent to the device. Since this element could not write to and read from the
device at the same time a schedule was created. The schedule was such that the packets where
sent to the device ten times more often than read from the device.
Figure 5-1: Gateway Device Interaction Diagram
Comentarios a estos manuales