Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extLowerInterface emulation fix #926

Closed

Conversation

DBC201
Copy link

@DBC201 DBC201 commented Nov 12, 2023

close #847

@DBC201 DBC201 changed the title add lower layers to ExtLowerEthernetInterface add higher layers to ExtLowerEthernetInterface Nov 12, 2023
@DBC201 DBC201 changed the title add higher layers to ExtLowerEthernetInterface extLowerInterface emulation fix Nov 15, 2023
@levy levy self-assigned this Nov 21, 2023
@levy
Copy link
Contributor

levy commented Mar 27, 2024

I don't know what you are trying to achieve with this PR. The purpose of ExtLowerEthernetInterface is to send packets to the host OS device. It cannot be used with TSN priority queueing at the moment.

@levy levy closed this Mar 27, 2024
@DBC201
Copy link
Author

DBC201 commented Mar 27, 2024

Hello @levy, it doesn't allow any packets to be sent to the host os at all, no matter which node you use it with. I tried a regular switch, standardhost, ethernethost... It also gives the same error on all when it receives packets in the simulation, when used in this manner from omnetpp.ini without modifying the ned files. This is because the inout phys gate in extLowerEthernetInterface.ned is declared but it's not connected to anything in the file. I have fixed the writing issue by connecting this.

Also, I changed the part it writes to the nic, since it tries to write the whole simulation packet, not excluding the data added by the physical layer.

Please correct me if my assumptions are wrong. In my opinion, I believe extLowerEthernetInterface should be it's own node instead of being initialized like this in omnetpp.ini. Because it is connecting to the nic device of the host computer, it is effectively connecting to an external real network, i.e. the cloud. I would actually be happy to open a pull request that implements this, I have also done some work on this as well. Thank you for your time.

@levy
Copy link
Contributor

levy commented Mar 27, 2024

There are examples which use the ExtLowerEthernetInterface module, so it should work as intended. For example, in the examples/emulation/pinger folder you will find a working example, but there are others.

levy@valardohaeris:~/workspace/inet/examples/emulation/pinger$ ./run.sh 
OMNeT++ Discrete Event Simulation  (C) 1992-2022 Andras Varga, OpenSim Ltd.
Version: 6.1pre1, build: internal, edition: Academic Public License -- NOT FOR COMMERCIAL USE
See the license for distribution terms and warranty disclaimer

Setting up Cmdenv...

Loading NED files from /home/levy/workspace/inet/examples:  189
Loading NED files from /home/levy/workspace/inet/showcases:  77
Loading NED files from /home/levy/workspace/inet/src:  1200
Loading NED files from /home/levy/workspace/inet/tests/validation:  5
Loading NED files from /home/levy/workspace/inet/tests/networks:  6
Loading NED files from /home/levy/workspace/inet/tutorials:  20

Preparing for running configuration General, run #0...
Assigned runID=General-0-20240327-15:19:34-122062
Setting up network "ExtPingerExample"...
Initializing...

Running simulation...
** Event #0   t=0   Elapsed: 1.9e-05s (0m 00s)  0% completed  (0% total)
     Speed:     ev/sec=0   simsec/sec=0   ev/simsec=0
     Messages:  created: 17   present: 17   in FES: 2
ExtPingerExample.peer.app[0]: reply of 56 bytes from 192.168.2.2 icmp_seq=0 ttl=64 time=3.543303696 msec (Ext-ICMPv4-ECHO-REPLY-4)
ExtPingerExample.peer.app[0]: reply of 56 bytes from 192.168.2.2 icmp_seq=1 ttl=64 time=1.132277696 msec (Ext-ICMPv4-ECHO-REPLY-29)
ExtPingerExample.peer.app[0]: reply of 56 bytes from 192.168.2.2 icmp_seq=2 ttl=64 time=1.378474696 msec (Ext-ICMPv4-ECHO-REPLY-36)
ExtPingerExample.peer.app[0]: reply of 56 bytes from 192.168.2.2 icmp_seq=3 ttl=64 time=1.417817696 msec (Ext-ICMPv4-ECHO-REPLY-42)
^C** Event #97   t=4.548813502304   Elapsed: 4.49919s (0m 04s)  45% completed  (45% total)
     Speed:     ev/sec=21.5595   simsec/sec=1.01103   ev/simsec=21.3242
     Messages:  created: 75   present: 18   in FES: 3

<!> SIGINT or SIGTERM received, exiting -- at t=4.548813502304s, event #97

Calling finish() at end of Run #0...
5 packets sent, 46 packets received
[INFO]	ExtPingerExample.peer.tcp: finishing with 0 connections open.
--------------------------------------------------------
	ExtPingerExample.peer.app[0]
--------------------------------------------------------
sent: 5   received: 4   loss rate (%): 20
round-trip min/avg/max (ms): 1.13228/1.86797/3.5433
stddev (ms): 1.12401   variance:1.26341e-06
--------------------------------------------------------
[DEBUG]	Ipv4::flush(): pending packets:
[DEBUG]	Ipv4::flush(): packets in hooks: 0
[INFO]	Clear all sockets

End.

The ExtLowerEthernetInterface module is a network interface and not a network node. The phys gate is defined to be loose that means it can be unconnected internally and it doesn't have to be connected externally either.

@DBC201
Copy link
Author

DBC201 commented Mar 27, 2024

In the pinger example the frame never leaves the node. This issue occurs when a frame is sent from another node to the gate which ExtLowerEthernetInterface is set up. If I understand correctly, the electric signal is not decapsulated correctly to ethernet mac. I used standardhost here, but this occurs with switch too.

//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU Lesser General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
// 
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU Lesser General Public License for more details.
// 
// You should have received a copy of the GNU Lesser General Public License
// along with this program.  If not, see http://www.gnu.org/licenses/.
// 

package test_simulation;

import inet.networklayer.configurator.ipv4.Ipv4NetworkConfigurator;
import inet.node.ethernet.Eth100M;
import inet.node.ethernet.EthernetHost;
import inet.node.ethernet.EthernetSwitch;
import inet.node.inet.Router;
import inet.node.inet.StandardHost;


network extlowerethinterface_test
{
    @display("bgb=729,462");
    submodules:
        configurator: Ipv4NetworkConfigurator {
            @display("p=104,144");
        }
        standardHost: StandardHost {
            @display("p=331,144");
        }
        ethernetHost: EthernetHost {
            @display("p=544,366");
        }
    connections:
        ethernetHost.ethg <--> Eth100M <--> standardHost.ethg++;
}
scheduler-class = "inet::RealTimeScheduler"
network = extlowerethinterface_test

*.standardHost.eth[0].typename = "ExtLowerEthernetInterface"
*.standardHost.eth[0].device = "enp46s0"
*.standardHost.eth[0].copyConfiguration = "copyFromExt"

*.ethernetHost.cli.destAddress = "standardHost"
*.ethernetHost.cli.sendInterval = 1s
*.ethernetHost.cli.respLength = 1Kib
*.crcMode = "computed"
**.fcsMode = "computed"
**.duplexMode = true
**.eth*.bitrate = 100Mbps

image

https://www.youtube.com/watch?v=-TxcYJhWjFU

This is what cml uses, hence I proposed a seperate node for extLowerEthernetInterface. It seems more intiuitive and might be easier to maintain in the future.

@levy
Copy link
Contributor

levy commented Mar 27, 2024

In the pinger example the frame leaves the simulated network node and goes into the host OS veth interface set up in run.sh. I think you misunderstand how emulation should work. An ExtLowerEthernetInterface phys gate should not be connected in the simulation, because as the module's name suggests the lower part of the interface resides in the host OS. The phys gate is there only because the module interface requires this.

Please read the relevant chapter in the User's guide and look at the emulation examples/showcases and their documentation on the INET website.

@DBC201
Copy link
Author

DBC201 commented Mar 27, 2024

Oh I see, the gate interacting with the host os is supposed to be internal within the node. It worked when I set it up this way as you stated. However, #847 makes the same mistake I did, if you look at his .ned file. The error is related to that, tsn might not be implemented but his current error is the same as mine.

So this worked for me, if anyone else is reading this pr for a solution:

//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU Lesser General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
// 
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU Lesser General Public License for more details.
// 
// You should have received a copy of the GNU Lesser General Public License
// along with this program.  If not, see http://www.gnu.org/licenses/.
// 

package test_simulation;

import inet.networklayer.configurator.ipv4.Ipv4NetworkConfigurator;
import inet.node.ethernet.Eth100M;
import inet.node.ethernet.EthernetHost;
import inet.node.ethernet.EthernetSwitch;
import inet.node.inet.Router;
import inet.node.inet.StandardHost;


network extlowerethinterface_test
{
    @display("bgb=729,462");
    submodules:
        configurator: Ipv4NetworkConfigurator {
            @display("p=104,144");
        }
        ethernetSwitch: EthernetSwitch {
            @display("p=210,249");
            gates:
                ethg[2];
        }
        ethernetSwitch1: EthernetSwitch {
            @display("p=473,282");
            gates:
                ethg[2];
        }
    connections allowunconnected:
        ethernetSwitch.ethg[1] <--> Eth100M <--> ethernetSwitch1.ethg[1];
}
scheduler-class = "inet::RealTimeScheduler"
network = extlowerethinterface_test


*.ethernetSwitch.eth[0].typename = "ExtLowerEthernetInterface"
*.ethernetSwitch.eth[0].device = "enp46s0"
*.ethernetSwitch.eth[0].copyConfiguration = "copyFromExt"

*.ethernetSwitch1.eth[0].typename = "ExtLowerEthernetInterface"
*.ethernetSwitch1.eth[0].device = "lo"
*.ethernetSwitch1.eth[0].copyConfiguration = "copyFromExt"

**.crcMode = "computed"
**.fcsMode = "computed"
**.duplexMode = true
**.eth*.bitrate = 100Mbps

@levy
Copy link
Contributor

levy commented Mar 27, 2024

Yes, I have already commented on #847

@DBC201
Copy link
Author

DBC201 commented Mar 27, 2024

Oh, I just saw that. Thank you for your help and patience. I couldn't distinguish well how extLowerInterface was supposed to be used and not connected externally. I didn't realize there was an examples folder when I first started learning about inet and either it wasn't obvious or I missed it on the web ui documentation. The showcases were using apps, so I was having this issue and found this github issue instead. It has been a few months since I have been using inet and I am still very much new. Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

A bug occurs when the TsnSwitch uses the ExtLowerEthernetInterface
2 participants