Hello dear OmNetpp and INET community,
I try to create a UDP sender module that adds a DSCP value to each packet.
Something like this:
module udpAppTag extends UdpApp like IApp
{
parameters:
tagger.typename = "PacketTagger";
}
I read the information from the INET document PacketTagger that there is a dscp parameter in the module.
In addition, I also read some example of setting tagger from showcase Frame Preemption.
something like this:
*.host1.app[0].tagger.vlanId = 1
*.host1.app[1].tagger.vlanId = 0
However, what I plan to do is not on the application level, but on the packet level.
So, how do I assign a different DSCP value to each packet?
For example, if my total simulation time is 1s, at 0.2s, I send the first UDP packet with dscp=1, and at 0.7s, the second with dscp=3.
Should I import a XML file from the .ini file? If there is a sample code, that would be appreciated.
Thank you very much.
Related
I have an application that displays stats about packets in a pcap file. Here is a partial output from a run I did without filters:
192.168.42.4:5082-17.253.27.205:20480 88:66:5a:04:e0:76 00:80:ae:b2:1e:92 S.SA.A
I then ran again with a port filter for 5082 and got nothing, no packets were found.
here is the set filter I used on the reader:
reader->setFilter("port 5082");
reader->setFilter("host 192.168.42.4") and this works fine. I can get filters for MAC addresses, IP, and protocol to work. I can't get any filter with ports in it to work.
reader->setFilter("ost 192.168.42.4 and src port 5082") fails as well.
The following fails as well:
pcpp::PortFilter p(5082, pcpp::SRC_OR_DST);
if (!reader->setFilter(p)) {
fmt::print("Could not set up filter on file");
}
Note: 0 packets found, no error on setFilter.
Any ideas?
I found the problem. seladb question made me take a close look at the capture file. Some how the port numbers I am getting from pcapplusplus are not the same as in the capture as displayed by Wireshark. Now I will have to go back and figure out why my port number from pcapplusplus is corrupt.
Thanks for your response.
The simulation configuration I want is for the vehicle and the RSU to communicate with each other through IEEE 802.11p and LTE through one eNB(eNodeB).
Refer to the veins_hetvnet repository and the paper Simulating cellular communications in vehicular networks: making SimuLTE interoperable with Veins to configure the .ned of each node and write the source code.
The error seems to occur in the code below among omnetpp.ini codes.
# car
**.car[*].masterId = 1
**.car[*].macCellId = 1
# RSU
**.fRSU[*].masterId = 1
**.fRSU[*].macCellId = 1
# Cell (eNodeB)
**.Cell.macCellId = 1
**.Cell.macNodeId = 1
**.dynamicCellAssociation = true
When I run the simulation, the following error occurs.
check_and_cast(): Cannot cast (LteMacEnbRealistic*)MyScenario.Cell.lteNic.mac to type 'LteMacEnbRealisticD2D*' -- in module (LteMacUeRealisticD2D) MyScenario.fRSU[0].lteNic.mac (id=184), during network initialization ..
The paper stated that it was the difference between automatic and manual coupling, but I don't know if that is true.
How can I modify the D2D communication with one eNB?
How I can create traffic light in OMNeT++ and SUMO, i have to create the traffic light and configure in XML file from which file using veins example.
The OMNeT++ proxy modules for SUMO traffic lights are available since Veins 4.7.
If you have a network including a traffic light, you need to add the following lines to your omnetpp.ini file:
*.manager.trafficLightModuleType = "org.car2x.veins.nodes.TrafficLight"
*.manager.trafficLightModuleName = "trafficLight"
*.manager.trafficLightModuleDisplayString = default
*.manager.trafficLightFilter = "MYTRAFFICLIGHTID"
*.trafficLight[*].mobility.x = 0
*.trafficLight[*].mobility.y = 0
*.trafficLight[*].mobility.z = 3
*.trafficLight[*].applType = "YOURAPPLAYERTYPE"
*.trafficLight[*].logicType = "YORUTRAFFICLIGHTLOGIC"
The term MYTRAFFICLIGHTID needs to be replaced with the ID you're using in your SUMO network. If you have multiple traffic lights to control, you can list SUMO IDs separated by spaces.
A traffic light consists of an application (YOURAPPLAYERTYPE) and a logic (YORUTRAFFICLIGHTLOGIC). Both properties are mandatory and need to be specified in your omnetpp.ini.
In the current Veins master branch, the YOURAPPLAYERTYPE is an OMNeT++ module, that uses the DemoBaseApplLayer as a the base module.
class YOURAPPLAYERTYPE: public DemoBaseApplLayer {
....
}
The YORUTRAFFICLIGHTLOGIC is an OMNeT++ module, that uses the TraCITrafficLightAbstractLogic as a the base module.
class YORUTRAFFICLIGHTLOGIC: public TraCITrafficLightAbstractLogic{
....
}
Using Andrew Rapp's XBee-API, how can I sample I/O data via a coordinator from more than two endpoints?
I have 17 Series 1 XBees. I have programmed one to be a coordinator (API mode = 2) and the rest to be endpoints. Using XBee-API I am sending a Force I/O Sample ("IS") remote AT command, unicast to each endpoint. This works perfectly well when there are up to two endpoints, but as soon as a third is added, one of the three always becomes non-responsive (times out with XBeeTimeoutException). It's not always the same physical unit that stops responding, but it is always the third one (for example, if I send Force I/O Sample to Device1, Device2, and Device3, Device3 will time out, and if I change the order to Device3, Device1, Device2, Device2 will time out.
If I set up more than three XBees, about 1 out of 3 will time out - but not every third one.
I've verified that the XBees themselves are fine. I've searched the Internet and Stack Overflow in particular to no avail. I've tried using a simple ZNetRemoteAtRequest. I've tried opening and closing the XBee coordinator serial connection once for all three devices, once per device, and once per program run. I've tried varying the distance between the coordinator and endpoints (never more than five feet apart). I've tried different coordinator configuration parameters (from the Digi documentation). I've tried changing out the XBee for the coordinator.
This is the code I'm using to send the Force I/O Sample request to each endpoint and read the response:
xbee = new XBee(); // Coordinator
xbee.open("/dev/ttyUSB0, 115200)); // Happens before any of the endpoints are contacted
... // Loop through known endpoint addresses
XBeeRequest request = new ZBForceSampleRequest(new XBeeAddress64(endpointAddress));
ZNetRemoteAtResponse response = null;
response = (ZNetRemoteAtResponse) xbee.sendSynchronous(request, remoteXBeeTimeout);
if (response.isOk()) {
// Process response payload
}
... // End loop and finally close coordinator connection
What might help polling I/O samples from more than two endpoints?
EDIT: I found that Andrew Rapp's XBee-API library fakes multithreaded behavior, which causes the synchronization issues described in this question. I wrote a replacement library that is actually multithreaded and correctly maps responses from multiple XBee endpoints: https://github.com/steveperkins/xbee-api-for-java-1-4. When I wrote it Java 1.4 was necessary for use on the BeagleBone, Plug, and Zotac single-board PCs but it's an easy conversion to 1.7+.
Are you using hardware flow control on your serial port? Is it possible that you're sending requests out when the local XBee has deasserted CTS (e.g., asking you to stop sending)? I assume you're running at 115200 bps, so the XBee serial port can keep up with the network data rate.
Can you turn on debugging information, or connect some port monitoring hardware/software to display the data going over the serial port to the local XBee?
I'm trying to learn the ropes on packet queuing, so I thought I'd set up a limitation on traffic coming into port 80 from known Tor Exit nodes. This is on FreeBSD 9, so OpenBSD-specific solutions might not apply (syntax/etc).
# Snipped to mainly the relevant parts
table <torlist> persist file "/var/db/torlist"
# ...
set block-policy return
scrub in all
scrub out on $ext_if all
# What I *want* to do is create a cue for known tor exit nodes
# no single one IP should be able to do more than 56k/sec
# but the combined bandwidth of all tor visitors should not
# exceed 512k/sec, basically limiting Tor visitors to something
# like dialup
altq on $ext_if cbq bandwidth 512k queue { qin-tor }
queue qin-tor bandwidth 56Kb cbq ( default rio )
# ...
block in log all
antispoof for { $ext_if, $tun_if }
antispoof quick for $int_if inet
### inbound web rules
# Main Jail ($IP4_PUB3 is my webserver IP)
pass in on $ext_if inet proto tcp from <torlist> to $IP4_PUB3 port www synproxy state queue qin-tor
pass in on $ext_if inet proto tcp to $IP4_PUB3 port www synproxy state
The problem is, when the altq, queue, and pass line specific for torlist are enabled, all connections are extremely slow. I've even tested my own IP against pfctl -t torlist -T test , and got back "0/1 addresses match", and if I test one from the list it's "1/1 addresses match"
So I'm not really educated in the matter of what exactly I'm doing wrong, I was assuming the pass in line with in it would only be applied to the IPs listed in that table, as such my own IP wouldn't validate on that rule and would pass onto the next one.
Getting it working isn't urgent, but any help in understanding where I'm failing would be greatly appreciated.
Turns out that I didn't quite understand how altq works. When I created a queue on my external interface with only one queue I created a default for all connections. As a result I had to define my top speed plus create a default queue for everything else.
For example if my system has 100Mb top
altq on $ext_if cbq bandwidth 100Mb queue { qin-www, qin-tor }
queue qin-www bandwidth 98Mb priority 1 cbq ( default borrow )
queue qin-tor bandwidth 56Kb priority 7 cbq ( rio )
...
pass in on $ext_if inet proto tcp to $IP4_PUB3 port www synproxy state
pass in on $ext_if inet proto tcp from <torlist> to $IP4_PUB3 port www synproxy state queue qin-tor
(doesn't need to be on top since pf parses all the rules unless you use 'quick')
In this way only those IPs matching in gets throttled down to the qin-tor queue, everything else not defined defaults to the qin-www queue.
The FAQ on OpenBSD's pf didn't seem to make this clear to me until I thought about why there would be an error for a "default", then I figured maybe it applies to the whole interface, so need to define a default for rules not marked to a specific queue.
So there it is... the solution to my 'simple' problem. Hopefully anyone else who has this problem comes accross this.
This is the FAQ I was going by for packet queueing: http://www.openbsd.org/faq/pf/queueing.html