问题
I've managed to create a number of routing nodes as described in this tutorial:
https://inet.omnetpp.org/docs/tutorials/wireless/doc/step3.html
They work as expected (forward packets in between nodes) but there's a problem in that these packets don't make it past the transport layer.
Looking at Packet.h (inet):
//
// Implements the IPv4 protocol. The protocol header is represented
// by the ~Ipv4Header message class.
//
// <b>Interfacing with higher layer protocols</b>
//
// To send a packet over IPv4 from a higher layer protocol, the module should
// fill in an ~L3AddressReq object, attach it to the packet with the Packets's
// addTag() method, then send the packet to the ~Ipv4 module.
//
// When ~Ipv4 sends up a packet to a higher layer protocol, it will also attach
// an ~L3AddressInd to the packet, with the source and destination IPv4 addresses
// of the IPv4 datagram in which the packet arrived.
//
// ~Ipv4 can serve several higher-layer protocols. The higher layer protocols
// should call registerProtocol with their gate towards the ~Ipv4 module,
// for fill up the protocol-to-gateindex map. When delivering packets to them,
// the output gate is determined from the Protocol in the IPv4 header.
//
// <b>Routing and interfacing with lower layers</b>
//
// The routing table is stored in the module ~Ipv4RoutingTable. When a datagram
// needs to be routed, ~Ipv4 queries ~Ipv4RoutingTable for the output interface
// (or "port") and next hop address of the packet. This is done by directly
// calling C++ methods (such as findBestMatchingRoute(destAddress)) of ~Ipv4RoutingTable.
// No message exchange with ~Ipv4RoutingTable takes place.
//
// A routed datagram will be sent to the queueOut, which is expected to be
// connected to ~INetworkInterface modules.
//
// Routing protocol implementations (e.g. OSPF and ISIS) can also query
// and manipulate the route table by calling ~Ipv4RoutingTable's methods in C++.
//
// <b>Working with Arp</b>
//
// Ipv4 module subscribe to arpResolutionCompleted and arpResolutionFailed signals on Arp module.
// The ~Arp module accessed via arpOut gate, should not insert any module between ~Ipv4 and ~Arp.
// Before Ipv4 module send down a packet to lower layer, ask MacAddress of next hop from Arp via
// method call. If MacAddress unspecified, then start address resolution via Arp method call and
// insert packet to a queue specified by next hop addr.
// When received a arpResolutionCompleted, then send packets from queue of next hop addr.
// When received a arpResolutionFailed, then drop packets from queue of next hop addr.
// When Ipv4 module received an ARP packet from Lower Layer on some queueIn gate,
// then send out this packet on arpOut gate. When received a packet on arpIn gate,
// then send out this packet on the specified queueOut gate.
//
// <b>Performance model, QoS</b>
//
// In the current form, ~Ipv4 contains a FIFO which queues up Ipv4 datagrams;
// datagrams are processed in order. The processing time is determined by the
// procDelay module parameter.
//
// The current performance model comes from the QueueBase C++ base class.
// If you need a more sophisticated performance model, you may change the
// module implementation (the Ipv4 class), and: (1) override the startService()
// method which determines processing time for a packet, or (2) use a
// different base class.
The lines:
// To send a packet over IPv4 from a higher layer protocol, the module should
// fill in an ~L3AddressReq object, attach it to the packet with the Packets's
// addTag() method, then send the packet to the ~Ipv4 module.
//
// When ~Ipv4 sends up a packet to a higher layer protocol, it will also attach
// an ~L3AddressInd to the packet, with the source and destination IPv4 addresses
// of the IPv4 datagram in which the packet arrived.
but it's still not clear. So, should the packet already have a L3AddressReq/L3AddressInd attached to it?
回答1:
It means, that on the receiving side, there is no application configured that listens on the UDP port that is set in the packet. The transport layer just drops the packet in this case.
来源：https://stackoverflow.com/questions/65201574/packets-created-in-udpbasicapp-are-not-forwarded-past-the-transport-ipv4-layer