\-------------------------/ tcpdump \----------/
I use a network simulation application called NS-2, specifically a module called NSE which allows to run it in "emulation mode". This mode allows to capture packets from "live" networks and use them to simulate a specific network scenario, in a way that this real network traffic will containing realistic delays and packet drops (based on the proposed network scenario). To feed NS-2, I use a combination of VoIP applications running inside UML terminals to provide the network traffic, as follows.
I hate two UML terminals, from now on called guest terminals. Each guest terminal maps its etho interface to a TAP device at the "real machine", from now on called host machine. Inside guest terminal, a
H.323 (VoIP) application called callgen323 is executing, in a way that these apps exchange VoIP packets (IP/UDP/RTP packets). The TAP devices at the host machine are interconnected using a Ethernet bridge named br0.
NS-2 captures the packets at the br0 interface, using the tcpdump library, and after simulating the proper delay from the proposed scenario, NS-2 forwards the packet to the destination interface (was I precise, Daniel? :p ).
In order to avoid duplicated packets, the command "ebtables -I FORWARD --logical-in br0 -j DROP" was called, making the bridge to discard the incoming packets.
If a packet is received by NS-2 and a packet drop was "simulated", the packet is not forwarded; since the bridge already drops the packet, this makes the destination machine never receives it. For further information on this,
please refer to http://ivs.cs.uni-magdeburg.de/EuK/forschung/projekte/nse/index.shtml
Now, I'll describe my problem: when I apply CRTP header compression inside NS-2 AND use an error greater enougth to generate packet drops, a kernel panic occurs; however, if I use CRTP header compression BUT NO
error e.g. no packet drops, nothing happens. It's important to note that the CRTP header compression only occurs inside NS-2; never the Ethernet interfaces at the UML terminals receive compressed packets, only restored ones.
The kernel crash dump indicates "Kernel BUG at net/core/skbuf.c:112! Invalid operand: 0000 [*1]". It also indicates that the process was nse (the NS-2 emulation application), and the call trace indicates that the last methods called were
br_dev_queue_push_xmit[bridge] and br_forward_finish[bridge].
I've already noted that skbuf.c defines the kernel socket buffer, which is stated as the kernel structure used to exchange the packets between network layers. So, if as the kernel dump states, the BUG occurred inside the bridge (when called by the nse process), I suppose the error occurs when the NS-2 forwards back the packet to the destination interface. So, my questions are:
[to uml users] a) Is there any known bug/limitation associated to ebtable FORWARD rules, or the Ethernet bridges, when associated to UML terminals?
[to all] b) Is it possible that a process (nse) running in user mode causes a kernel panic when it seems to be just sending packets?
[to nse users] c) Is it possible that the NSE module causes this kernel panic when sending back the packet to the interfaces, by calling the socket sending method with odd length values?
P.S.: Sorry for the long error description, but I needed to describe the scenario and the problem :p
Thanks in advance,
Manaus - Amazonas - Brazil