Problems with UdpEchoApp and real world network emulation

48 views
Skip to first unread message

张腾

unread,
Jun 2, 2023, 8:15:33 AM6/2/23
to OMNeT++ Users
According to the documentation, UdpEchoApp will send back packets after receiving them. So I hope that the node containing the application layer app can return information after receiving an incoming message from the outside. But I am currently encountering some problems ------------------------- You can see echoed on the running interface (GUI): (x)pks number is in is constantly changing, so does this prove that the node received the message and then sent the return packet. I execute my python client file on the linux command line and input the information I want to pass in, but I do not receive the packet returned by OMNeT++ on my interface.
I added two lines of input to UdpEchoAPP, and saw its output in OMNeT++, I hope this can also help you。 I have searched for a long time but can't find the problem, I hope you can help me. Thanks!!!
Below is my ned code, ini file,run.sh and my python client file

void UdpEchoApp::socketDataArrived(UdpSocket *socket, Packet *pk) { // determine its source address/port L3Address remoteAddress = pk->getTag<L3AddressInd>()->getSrcAddress(); int srcPort = pk->getTag<L4PortInd>()->getSrcPort(); pk->clearTags(); pk->trim(); // statistics numEchoed++; emit(packetSentSignal, pk); // send back socket->sendTo(pk, remoteAddress, srcPort); std::cout<<"ip:"<<remoteAddress<<std::endl; std::cout<<"port:"<<srcPort<<std::endl; } This is the OMNeT++ console input: ip:192.168.2.2 port:3797

run.sh.txt
ini.txt
client.py.txt
ned.txt

张腾

unread,
Jun 4, 2023, 2:42:08 AM6/4/23
to OMNeT++ Users
I seem to have found the problem from the logs.
** Event #2206 t=7.943636755 Drone.host[19].ipv4.ip (Ipv4, id=927) on Ext-UDP--1 (inet::Packet, id=3819)

INFO: Received (inet::Packet)Ext-UDP--1 (14 B) (inet::SequenceChunk) length = 14 B from upper layer.
INFO (Aodv)Drone.host[19].aodv: Finding route for source <unspec> with destination 192.168.2.2
INFO (Aodv)Drone.host[19].aodv: Missing route for destination 192.168.2.2
DETAIL (Aodv)Drone.host[19].aodv: Queuing datagram, source <unspec>, destination 192.168.2.2
INFO (Aodv)Drone.host[19].aodv: Starting route discovery with originator 145.236.0.33 and destination 192.168.2.2
INFO (Aodv)Drone.host[19].aodv: Sending a Route Request with target 192.168.2.2 and TTL= 2

This means that it has no route to the destination 192.168.2.2, and the node is an aodv node, which will initiate an rreq message. However, 192.168.2.2 is not the internal ip address of OMNeT++, but the external one. Is it necessary to add a static route or other methods? Hope to get your help

张腾

unread,
Jun 4, 2023, 4:03:26 AM6/4/23
to OMNeT++ Users
I try to follow the method in example/emulation/pinger. Set the ip address of eth0 to 192.168.2.1. At this time, I went to check the routing table of host[19] and found that there was a route of 192.168.2.0/24 gw:* metric=1 if:eth0. But at this time the log still shows Missing route for destination 192.168.2.2. I really can't find a solution, hope someone can help me

张腾

unread,
Jun 8, 2023, 6:59:26 AM6/8/23
to OMNeT++ Users
solved
Reply all
Reply to author
Forward
0 new messages