Closed sommer closed 3 years ago
In INET 4.2.2 the network interface is added to the InterfaceTable in INITSTAGE_NETWORK_INTERFACE_CONFIGURATION (2) in the initialize() of the InterfaceEntry compound module. The HostAutoConfigurator module calls addProtocolData
My guess is that the order has changed somehow. Maybe the HostAutoConfigurator stage 2 runs earlier than the InterfaceEntry stage 2? For example, the network layer submodule comes before the network interface submodules in the network node? This is not ideal... :(
First of all, I need to apologize for not finding this issue - usually, we use veins a lot but somehow we did not test the cars simulation, recently.
Regarding the cause: Yes, I think you are right. Within the Ue, the order of the modules was top (app) to down (phy) and therefore, the HostAutoConfigurator did not find the InterfaceData. For the other configurators, this is not a problem since they configure the interfaces in INITSTAGE_NETWORK_CONFIGURATION. Therefore, in the long run it might make sense to modify the HostAutoConfigurator to do the same. For now, and in order to solve the problem without additional modifications of inet, I would suggest to change the order of the Ue submodules. With this modification and a small workaround due to the fact that the HostAutoConfigurator sets all interfaces to broadcast (which is not correct for LteNic), the cars simulations work again. I will create a pull request right now for this fix so you can take a look.
Wow that was fast - thank you so much for the patch! I can confirm that, with it, things work smoothly on my end.
using OMNeT++ 6.0pre10, INET 4.2.2, and Veins 5.1.
Running the
simulations/cars
example throwsRemoving this additional
HostAutoConfigurator
fromCar.ned
gets me one step further, but then throwsNow I'm at my wits' end. Wildly speculating, when
inet::HostAutoConfigurator
runs throughINITSTAGE_NETWORK_INTERFACE_CONFIGURATION
the interface is not yet in the interface table. No idea though whether this is an issue with SimuLTE or INET.