With TCP SACK, transmission can stall.

[Thomas Reschka:] Martin noticed a bug in TCP SACK and informed Michael about his observation.
To reproduce and see the failure please use the following configuration in INET's tcpsack example.

[Config Problem]
description = "Problem Statement"
**.client.pcapRecorder[0].pcapFile = "Problem_Statement_Client_Log.pcap"
**.server.pcapRecorder[0].pcapFile = "Problem_Statement_Server_Log.pcap"
**.tcp.mss = 1000
**.ppp[*].queue.frameCapacity = 20

At event #3218 the client receives a D-SACK with ACK=86001 from the server.
Hereafter the client retransmits the segment [86001..87001].

At event #3308 the client receives the 3. DUPACK with ACK=86001 from the server.
In the current INET code the client retransmits the segment [86001..87001] again, although already done at event #3308.
This seems to be incorrect, because a timeout did not accour at this point and segment [86001..87001] has recently been retransmitted.

I used omnet++ 4.6 and INET 2.99.0.

Issue migrated from http://dev.omnetpp.org/bugs/view.php?id=803

The MACAddress class use to have the first bit of the first byte as the multicast/unicast bit and now it's correctly set as the last bit (less significant) of the first byte.

The problem is that, as far as I know, the universal/local bit (U/L bit) is omitted and never used. It doesn't even have a function to check it, like isLocal() or something similar (as isBroadcast() or isMulticast()).

However, the real problem is that MAC addresses are assigned by default in the class and they start with 0x0A, and that type of addresses have the U/L bit (the second less significant of the first byte) set to 1, that is, they are meant to be local, but they are not.

This causes confusion and problems if you are working with local MAC addresses (in my case), so the first byte of auto assignment should be something ending in 0, 4, 8 or C in order to have both bits (multicast and local) set to 0.
Additional Information I might be wrong or confused with this issue, since I'm no expert, but this is how it works and how it should work as far as I know. Thank you.

from: http://dev.omnetpp.org/bugs/view.php?id=630

File: BGPFSM.cc
Function: Established::entry()

for (int i=1; igetNumRoutes(); i++)
{...}

why i start from 1

also in
File: OSPFRouting.cc
Function: OSPFRouting::checkExternalRoute(const IPv4Address &route)

for (unsigned long i=0; i < ospfRouter->getASExternalLSACount(); i++)
{...}

why i start from 1

from: http://dev.omnetpp.org/bugs/view.php?id=645

Use of state->rcv_wnd_scale in updateRcvWnd

Info: rfc1323 Section 2.3

The window field (SEG.WND) of every outgoing segment, with the exception of SYN segments, is right-shifted by Rcv.Wind.Scale bits:
SEG.WND = RCV.WND >> Rcv.Wind.Scale.

Currently the scaling factor is used only if scaled_rcv_wnd > TCP_MAX_WIN. Because the scaled_rcv_wnd based on state->rcv_wnd this is not always true. This overwrites the exchanged factor of the handshake. Thus it is not calculated on every outgoing segment.

To reproduce:
Create a setup with

bool windowScalingSupport = true
a **.tcp.advertisedWindow > 65535 (e.g 70000)

a network setup that use the whole window (at least increase the reported arwnd < 65535).

This bug is due to the fact that the maximum number of interfaces is hardcoded :

defs_aodv.h:94

define MAX_NR_INTERFACES 10

And used so :
defs_aodv.h:123
struct dev_info devs[MAX_NR_INTERFACES];

However no checks are performed to verify that this number is not exceeded by the actual numer of interfaces. This can lead to memory corruptions, eg in aodv_uu_omnet.cc:182-185 :

for (int i = 0; i <getNumInterfaces(); i++)
    {
        DEV_NR(i).ifindex = i;
        dev_indices[i] = i;
        ...
     }

If getNumInterfaces() is higher than MAX_NR_INTERFACES, you end up writing somewhere in memory and silently corrupting other data, leading to random hard-to-debug problems that only appears during execution (in the middle of a rather long one for me).

I attached a quick solution (a simple check is performed at initialisation, throwing an error if a problem is detected), although it would be way better to rewrite this with a malloc instead of this fixed size.

inet version 2.5.1

https://gist.github.com/rhornig/b75e770626649bf273eb

As discussed in this OMNeT mailing list thread (https://groups.google.com/d/msg/inetframework-devel/dDUf6RJNMtY/aaSegx5728sJ [^]):

Certain INET examples miss the definition of the tcpType variable in their respective omnetpp.ini files.

Without the following line, the NED indexer misses the connection and reports warnings for the tcp parameters:

**.tcpType = "TCP"

This line needs to be inserted in the following INET example's (i.e. in their omnetpp.ini files):

• tcpwindowscale
• tcptimestamps
• tcpsack
• ber

Pause frame arrival is processed by EtherMACFullDuplex::processPauseCommand() function. When the transmitter is in the WAIT_IFG_STATE the pauseUnitsRequested variable is updated. However, this variable doesn't get checked in the EtherMACFullDuplex::handleEndIFGPeriod() function and the next frame is being transmitted.

Possible Buffer Overflow error in ICMP.cc:

// assemble a message name
char msgname[32];
static long ctr;
sprintf(msgname, "ICMP-error-#%ld-type%d-code%d", ++ctr, type, code);

The maximum char* produces by "sprintf" exceeds the 32 Byte of msgname. If this happens a buffer overflow is thrown. In my experience this happens mainly in long simulations with a high amount of data send via UDP.

Added from a comment in examples/ipv6/ipv6nclients/NClientsEth.ned:

Mixing ethernet and ppp currently doesn't work, due to a bug in FlatNetworkConfigurator6::determineGateIndex.

r1.pppg++ <--> fiberline <--> r2.pppg++;
r2.pppg++ <--> fiberline <--> r3.pppg++;
r3.pppg++ <--> fiberline <--> srv.pppg++;

Issue migrated from: http://dev.omnetpp.org/bugs/view.php?id=138

Originally submitted: 2010-02-05 16:45

In the function extractWiredNeighbors the line

cChannel *transmissionChannel = linkOut->getLocalGate()->getTransmissionChannel()

should actually be

cChannel *transmissionChannel = linkOut->getLocalGate()->findTransmissionChannel()

The former throws an error, but the later returns NULL which should be the correct behavior as it isn't required to have a channel between two modules.

The implementation now will only send one tcpSegment once the application layer put data to buffer, that is the TCP layer will send at most effectiveWin bytes data from the app buffer and let the rest data in the buffer, the left ones will be sent when the application layer put data to the buffer the next time, and this is not what the the application want the TCP layer to do.

Additional Information: I suggest to modify "bool TCPConnection::sendData(bool fullSegmentsOnly, uint32 congestionWindow)"function(in src/transport/tcp/TCPConnectionUtil.cc), after assign effectiveWin to bytesToSend, there's no need to compare the value of bytesToSend and buffered,just assign directly.
The simplest way to repair it is to delete line 697 in src/transport/tcp/TCPConnectionUtil.cc.

from: http://dev.omnetpp.org/bugs/view.php?id=610

If I call doPacking on a IPvXAddress which is an IPv4Address at runtime, the IPvXAddress::doPacking member function for some reason calls itself, which results in an infinite loop. This is the part of the code:

/src/networklayer/contractIPvXAddress.h:
295 inline void doPacking(cCommBuffer *buf, const IPvXAddress& addr)
296 {
297 if (buf->packFlag(addr.isIPv6()))
298 doPacking(buf, addr.get6());
299 else
300 doPacking(buf, addr.get4());
301 }

I do not really understand why this happens, since addr.get4() returns an IPv4Address object - so line 300 should call IPv4Address::doPacking?! However, it seems to work for IPv6: Ctrl+Click on line 298 in the OmNET IDE jumps to the correct function. :-)

Additional Information: I fixed this for myself by passing a "real" IPv4Address:

inline void doPacking(cCommBuffer *buf, const IPvXAddress& addr)
{
if (buf->packFlag(addr.isIPv6()))
doPacking(buf, addr.get6());
else {
IPv4Adress ipv4 = addr.get4();
doPacking(buf, ipv4);
}
}

from: http://dev.omnetpp.org/bugs/view.php?id=735

If you set the positions of moduls within the ini File, through the mobility parameters, they will only interpreted as long values. A cast change in the "MobilityBase.cc" has no effect.
The linked bug from 2011-02-13 discribes the same problem.
Additional Information http://dev.omnetpp.org/bugs/view.php?id=248

from: http://dev.omnetpp.org/bugs/view.php?id=690

The Ieee80211Mac implementation (/inet/src/linklayer/ieee80211/mac/) uses the variable queueModule to store a pointer to an external queueing module. If the user chooses the internal module, then this variable is never initialized. All subsequent code in Ieee80211Mac.cc checks if queueModule is null to determine use of an internal or external queue.

To fix, simply add this [Ieee80211Mac.cc:526]:

if (par("queueModule").stringValue()[0])
{
   ...
} else {
   queueModule = 0;
}

Affects up through INET 2.4

Whether a segfault actually occurs depends on how the compiler treats uninitialized pointers, or sometimes just luck lol :-)

Blah Blah.

Attachment: https://gist.github.com/avarga/12f0fa841bfafdbcdcaf#file-just-a-test

socket.renewSocket() deletes the defined local port in the .NED configuration

Right now ext interface can be enabled in src/makefrag which is just too hidden. It would be better to ship with ext interface disabled (as a feature). User would require just to Enable the feature and go ahead rebuilding.

Also the build process should give a detailed error message whet to do if the PCAP libraries are nit detected by the configure script (install libpcap-dev etc.)

from: http://dev.omnetpp.org/bugs/view.php?id=681

Two active open for each other not worked correctly:
recorded states: CLOSED -> SYN_SENT -> SYN_RECEIVED -> CLOSED
expected states: CLOSED -> SYN_SENT -> SYN_RECEIVED -> ESTABLISHED

The received SYN+ACK packet refused in SYN_RECEIVED status, state changed to Closed instead ESTABLISHED

See the test in INET/tests/module/tcp_syn_2.test.off:
problem occured in step 6 and step 7 in RFC 793, figure 8.
Additional Information RFC 793, page 32: (fixed by RFC 1122)
Simultaneous initiation is only slightly more complex, as is shown in figure 8.
Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to ESTABLISHED.

  TCP A TCP B

1. CLOSED CLOSED

2. SYN-SENT --> <SEQ=100><CTL=SYN> ...

3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT

4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED

5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

7. ... <SEQ=100><ACK=301><CTL=ACK> --> ESTABLISHED

           Simultaneous Connection Synchronization
   
                          Figure 8.
   

from: http://dev.omnetpp.org/bugs/view.php?id=616

The exact version is INET 2.1.0

I'm trying to simulate a NEtwork MObility environment so I need WirelessHost6 to act as a AP and AP client at the same time. To do so, I modify the NodeBase6 to add a new gate (radioAPIn) and APwlan with its connections but when I start the simulation on stage 3 I get the following error:

<!> Error in module (IPv6NeighbourDiscovery) nemo_handover_net.Mobile_Router.networkLayer.neighbourDiscovery (id=128) during network initialization: (cCompoundModule)nemo_handover_net.Mobile_Router: Invalid gate Id -1.

Where Mobile_Router is an instance of WirelessHost6.

If you need more information, please ask. Thanks in advance,
maddie

Additional Information In order not to modify the original ned files I've created a NemoWirelessHost6 (attached) so you can use it in the example of xMIPv6 MIPv6Network.ned and reproduce it.

from: http://dev.omnetpp.org/bugs/view.php?id=650

We're using the following in both of the bind methods:
if (lPort == 0) {
auto udp = check_and_cast<UDP*>(gateToUdp->getPathEndGate()->getOwnerModule());
lPort = udp->getEphemeralPort();
}

from: http://dev.omnetpp.org/bugs/view.php?id=372

There is a problem with the TCP module, somehow dependent on simulation time. The problem is only apparent after about t=10000s (even if started at t=100000s, not execution time dependent).

To recreate: Run the nclients demo using the basicHTTP.ini file but edit the file and set startTime = 10000s + exponential(5s). Clients send SYN, server responds SYN+ACK, TCP module on client side receives SYN+ACK, responds w. ACK and sends ESTABLISHED to the application. Application sends data, but the data is never forwarded by the TCP module. After a while, all clients are stuck in a state as shown below:

Connection 192.168.0.8:80 to 192.168.0.6:1025 on app[0],connId=22 in ESTABLISHED (ptr=0x0xae43288)
PERSIST timer expired
Cannot send probe because send buffer is empty
Staying in state: ESTABLISHED (no FSM event)

Mail me if more info needed: [email protected]

This commit breaks windows builds as windows does not know netif/in.h used in SerializerUtil.cc. I think on windows you can use Winsock2.h instead. But do we really want platform dependent stuff here?

See also my comment here:
618aaf7

There is an error in the method
void AODVRouting::handleBlackListTimer()
if (it->second <= simTime()) {
should be
if (current->second <= simTime()) {

In EtherMACFullDuplex.cc the check condition of "if (pauseUnitsRequested > 0)" needs to be changed to "if (pauseUnitsRequested >= 0)"

I came across the following document:

Mats Rosbach, "Verification of Network Simulators: The good, the bad and the ugly." Master Thesis, UNIVERSITY OF OSLO, Department of Informatics, Nov 2, 2012.

https://www.duo.uio.no/bitstream/handle/10852/34916/1/Rosbach-Master.pdf

Excerpt: "We test three TCP variants in OMNeT++: Tahoe, Reno and NewReno. We run the same five basic scenarios as in ns-2. The results of these basic scenarios are summarized in Table 4.4 and Table 4.5. We can see very clearly that these results do not correspond to the expected results. The three TCP variants all perform more or less exactly the same."

Versions used: OMNeT++ 4.2.0, INET 2.0

These claims would be well worth to investigate, as the thesis generally appears to be a solid work.

Migrated from: http://dev.omnetpp.org/bugs/view.php?id=807

AODV can't identify the interface where a packet has arrive based in the mac address.
Additional Information Proposal solution
aarizaq/inetmanet-3.x@6e11355 [^]

from: http://dev.omnetpp.org/bugs/view.php?id=632

INET version: 1.99.2

TTL in IPv6 packets seems to be decremented more often than necessary.

See tests/module/UDP_ttl_ipv6.test, and compare with the similar IPv4 test. In IPv6, TTL decreases by 6 on this network, whereas in IPv4 only by 4 (that's correct).

Issue migrated from: http://dev.omnetpp.org/bugs/view.php?id=543

Cannot send EtherPauseFrame when the TX is in transmitState = PAUSE_STATE.
If the link is congested in both directions it can lead to a deadlock.
Moreover, the loss-less transmission is not assured, since the pause frame is not sent.
This violates the standard of the Pause frames.

INET version: 2.0

In certain simulations, Ieee80211MAC will start transmitting even when the channel is busy. This should not happen.

The error is in the Radio model that can stay in IDLE when it hears a frame but its receive power is below the sensitivity parameter, see Radio::handleLowerMsgStart(). This is wrong because 'sensitivity' is the minimum power for receiving a frame correctly, not the minimum power that will make concurrent frames garbled.

Migrated from: http://dev.omnetpp.org/bugs/view.php?id=624

Currently "make makefiles" always calls opp_makemake using the "--make-so" flag.
To build static libraries the top-level Makefile has to be edited or opp_makemake has to be called directly. It would be nice if a static build could be enabled while calling "make makefiles" similar to "make MODE=release".
Additional Information Locally I currently insert this line into the top-level Makefile:
LINKMODE ?= so

Then I replace "--make-so" with "--make-$(LINKMODE)".
Now i can call "make LINKMODE=lib makefiles".
from: http://dev.omnetpp.org/bugs/view.php?id=739

According to RFC 2581, page 5:
"Furthermore, upon a timeout cwnd MUST be set to no more than the loss window, LW, which equals 1 full-sized segment (regardless of the value of IW)."

"retransmitData();" has no rexmit limitation (bytesToSend > snd_cwnd) so TCPReno could send more then one segment after RTO, therefore retransmitOneSegment() should be used instead of retransmitData().

test

There is a problem in the method

IPvXAddressResolver::findHostWithAddress(const IPvXAddress & add)

if a node doesn't have a IP address, the program abort
Solution:

aarizaq/inetmanet-3.x@0497090

reassembleAndDelivered() contains this code:

    // tunnelled IP packets are handled separately
    send(packet, "preRoutingOut");

However there is no "preRoutingOut" gate in the IPv4 module.

from: http://dev.omnetpp.org/bugs/view.php?id=462

The result folder issue must be solved some other way and this scalar must be removed from the result set.

from: http://dev.omnetpp.org/bugs/view.php?id=600

Throughput decreases when cwMaxData is set same value with cwMaxData. Using throughput example under wireless directory when

cwMaxData:7
cwMinData:7

values are set measured throughput is 2.6 Mbps. However

cwMaxData: Not Set (Default Value -1)
cwMinData: 7

are set throughput is measured 5.4 Mbps. Both tests are made with 1 AP and 1 wireless client.

from: http://dev.omnetpp.org/bugs/view.php?id=685

If the first socket is bound to ANY/7777, and trying to bind to second to 192.168.1.1/7777, then the second call fails in UDP::findSocketByLocalAddress().

The socket API allows two applications to use the same port provided that they use different local addresses and that SO_REUSEADDR socket option is set to true on all sockets. Sockets bound to a specific address will receive unicast packets sent to that address, while the socket bound to ANY will receive the packets whose destination address does not match any other socket.

from: http://dev.omnetpp.org/bugs/view.php?id=653

Provide extensibility mechanism to pass down options to lower layers (like DSCP ,IP_TOS). see. setsockopt in Linux.

from: http://dev.omnetpp.org/bugs/view.php?id=295

It is impossible to get a useful summary on what IPv4NetworkConfigurator actually did. For one simulation, IP addresses were not configured; when tracking down the problem, the default initialize() log messages from IPv4NetworkConfigurator helped absolutely nothing. Turning on EV_DEBUG was also useless: it printed lots of lines but without context, i.e. it prints things like "Selected interface address: 10.0.0.38" -- but to which interface??? Turning on dumpAddresses is also useless, because it prints on InterfaceEntry::info() and NOT the addresses computed by the configurator (those computed addresses may or may not be actually set on the interfaces!)

Output should be made useful: by default it should print summary info (computed addresses for interfaces on links etc).
EV_DEBUG output should be made more structured (use indentation!)
DumpAddresses should print not only the ie->info() but also the assigned addresses!

Issue migrated from http://dev.omnetpp.org/bugs/view.php?id=673

With INET built inside your OMNeT++ IDE, navigate to the examples folder in the Project Explorer pane. To run an example simulation in Linux, perform the following steps:

Locate the folder that INET has been built in and open the examples folder.
Now double-click on run-demo and select Run in Terminal.
Now you will see an interface that can be used to navigate and launch different simulation examples.

These examples will not load.
Additional Information: run demo does launch, however nothing inside of it works. no examples will run.
from: http://dev.omnetpp.org/bugs/view.php?id=680

It would be great to have apps (tcp/udp client/server) that could tunnel information from a given TCP/UDP port to somewhere in the simulated network. On the other end the corresponding app would get the APP data and would send that to a real service on a pre-configured port. This is how the OMNET sockets sample is working. We could name this ClientTCPSocket / ServerTCPSocket /ClientUDPSocket / ServerUDPSocket

The usecase would be:

• Install a browser and an apache server on a physical machine. The browser obviously can connect to the http server on localhost.
• Instead of connecting to localhost:80 connect to localhost:8080 which would connect to a ClientTCPSocket module in the simulation. That would extract the app data and send it to the simulated network (the source address need to be replaced).
• On the other end ServerTCPSocket receives it and the data is sent to a preconfigured IP:port (the webserver in this case)

This would allow to run real application via a simulated omnet network.

When positioning a mobileHost by setting initialX and initialY both to "0m". Now moving the mobile host with an angle of 270deg(linearMobility) downwards and up again, while reaching the left upper edge again the simulation crashes. Happens with Linear- as well as MassMobility. My constraint area is (0,0,0) to (1000,1000,0). I've only experienced this bug on the left upper edge, when I try doing this at the right end of the constraint area everything works fine.

output: /bin/sh: line 1: 3654 Segmentation fault /home/x/x/x/x/x -c OneWHost -l /home/x/x/libs/inet/inet -n /home/x/x/simulations/x";"/home/x/x/src/x";"/home/x/x/libs/inet/src
make: *** [Run_main] Error 139

But it's not all the time a segmentation fault, it changes! Doing the same simulation multiple times the error messages were "segmentation fault", "illegal instruction" as well as "bus error".
Additional Information Error happens also if setting one of the two parameters initialX or initalY to "0m" and the other one "1m" as well as both set to "1m".

from: http://dev.omnetpp.org/bugs/view.php?id=609

The original Mac80211::createSignal implementation in MiXiM returns a two-dimensional (time x frequency) analog signal representation. The transmission power is constant over the provided range of time and frequency. Nevertheless, the signal uses linear interpolation between its defined points. It also uses the so called out of range value that is set to 0.

These signals are summed up when the RSSI and the SNIR is calculated. The result is also represented using linear interpolation and the out of range value. Unfortunately it's impossible to correctly represent the result this way, because the original signals have more discontinuity (at different locations) in total than the result can represent. In fact the result will interpolate at certain ranges where it should have a discontinuity instead.
Additional Information The attached figure shows two signals before they get added, the expected result, and the actual result. Adding further signals to them makes it even worse...

The following code demonstrates the error in the original MiXiM 1.0 version. To compile the code, the Mac80211::createSignal function must be public. The error still exists in the latest MiXiM 2.3 version. This code should print 101, but it prints 107.667, which is wrong.

Mac80211 mac;
ConstMapping _m1 = mac.createSignal(2, 4, 1, 2E+6)->getTransmissionPower();
ConstMapping *m2 = mac.createSignal(1, 2, 10, 2E+6)->getTransmissionPower();
ConstMapping *m3 = mac.createSignal(4, 1, 100, 2E+6)->getTransmissionPower();
ConstMapping *mTotal = MappingUtils::add(_MappingUtils::add(_m1, *m2), *m3);
std::cout << MappingUtils::findMax(_mTotal) << endl;

The consequences of this bug to higher layer statistical results is unknown.

At aodv_timeout.cc:206
for (i = 0; i < MAX_NR_INTERFACES; i++)
{
if (!DEV_NR(i).enabled)
continue;
aodv_socket_send((AODV_msg *) rerr, rerr_dest,
RERR_CALC_SIZE(rerr), 1, &DEV_NR(i));
}

An exception ("not owner of the object") is thrown when this piece of code is called and when there is more than one interface enabled because the same packet is send several times without being duplicated. See attached file for a proposed fix.

in inet 2.5.1

When a multicast enabled router receive an IGMP report, it wont add a multicast route to the routing table. You can fine a "complete, minimal example" with three files(MUL.ned, omnet.ini and config.xml) attached.

from: http://dev.omnetpp.org/bugs/view.php?id=674

the link layer notification of lost frame can provoke a memory leak

solution
aarizaq/inetmanet-3.x@c70417a

from: http://dev.omnetpp.org/bugs/view.php?id=635

The NetFilter hooks in IPv4 currently allow the interception and possibly reinjection of IP packets in routers. For IPv6, no such interface currently exists. It would be very helpful for a number of use cases to have this interface in IPv6, too, or possibly a general interface that supports both procols.

As debated in #27, implementation of this feature is currently stalled because of a pending major refactoring of the IPv6 code. I'm creating this ticket nevertheless so we don't forget about it.

The TCP model doesn't implement a "read" syscall, i.e. data that have been received (in the correct order) are passed up immediately to the application layer.

Therefore one cannot model a situation when the app doesn't read the received data from the buffer, it fills up, and TCP must report closed window to the sender.

inet version: 2.99.0

Whne mgmtType of wlan Ieee80211Nic is changed from "Ieee80211MgmtSTASimplified" to "Ieee80211MgmtSTA" (so client needs to do connection handshake with AccessPoint) simulation crashes every time with message opp_run.exe has stopped responding (on Windows 7 64 bit platform).

If mgmtType is set to "Ieee80211MgmtSTASimplified" there are no problems with simulation. This problem also arise in other simulations every time if EtherTrafGen or EtherAppCli simple modules are used with Ieee80211Nic when mgmtType is set to "Ieee80211MgmtSTA".

from: http://dev.omnetpp.org/bugs/view.php?id=678

The GaussMarkovMobility module contains a parameter for the variance of the random component of speed magnitude/angle change.

It should contain two different variance parameters, because there are two different normal distribution. Using the same variance parameter makes the equations used to update the speed and angle nonsense, because that variance should have both speed and angle dimensions. Moreover it is used as the standard deviation, and not the variance of the distribution.

from: http://dev.omnetpp.org/bugs/view.php?id=375