L3AddressResolver strange behavior using windows 10

[Antonio Virdis]

Hi everyone,

I'm experiencing a strange behavior when using the L3AddressResolver in INET inet-3.4.0 and Windows 10.

When using any custom (non-INET) application, I'm not able to resolve the IP address of the destination node, i.e. the function 

inet::L3AddressResolver().resolve(par("destAddress").stringValue())

called within the initialize of the application, fails with the error  "during network initialization: L3AddressResolver: address `standardHost' not configured (yet?)."

I checked the address of the "standardHost", and I verified that is actually configured.

I was able to reproduce the error with a very basic network, having two standardHosts connected via ppp, and an IPv4NetworkConfigurator.

This error does not happen when using applications declared inside the INET namespace, and does not happen in unix.

Any idea?

[Michele Garau]

Hello everyone,
I confirm the same problem on Windows machines.
It does not affect Windows 10 only, but I have found the same issue on Windows Server 2012 R2 and Windows 7.
Any suggestions on how to face with this kind of errors?

Michele

[Alfonso Ariza Quintana]

I suspect that the problem is the stage that you call L3AddressResolver. You need to wait to stage INITSTAGE_NETWORK_LAYER_3 before you can use L3AddressResolver in the initialize method, in other case you don’t have the guarantee that the address of the nodes are correctly configured.

--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

[Antonio Virdis]

Unfortunately that is not the case. I'm calling the resolve function in stage INITSTAGE_APPLICATION_LAYER, thus it should be safe.

Also, please note that this is actually working in unix systems.

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/NyspIVKY2Us/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

--

Antonio Virdis

[Hayoung Seong]

hi, everyone.

i'm OMNeT++ starter, and i use window10 and ompp++ version5, inet-3.4 

when i simulate simulte tutorial, I've got the same problem 

so i couldn't simulation once. after install simulte.

though i read this post, but I can't fix this error,

how to declare inside the INET namespace when using applications.please, more detail( where).

 additionally how to fix this error. it is occurred  when running multicell

2016년 12월 16일 금요일 오전 4시 19분 54초 UTC+9, Antonio Virdis 님의 말:

[Me]

Did anybodycome to a solution?

[Rudolf Hornig]

Could you possibly file a bug (in INET) with the files needed to reproduce? It's really strange that it is Windows related.

Rudolf

On Thursday, 15 December 2016 20:19:54 UTC+1, Antonio Virdis wrote:

[Michele Garau]

While investigating in order to find the cause of this issue, I've discovered new things, that seem related more to INET than SimuLTE.
My analysis is conducted on OMNeT++ - INET 3.4
On the method L3AddressResolver::resolve(const char *s, int addrType), when while debugging I tried to enter inside the tryResolve method:

       if (!tryResolve(s, addr, addrType))

I discovered that the compiler skips it.
Further investigating, I discovered that this behaviour is due to the fact that IPvXAddressResolver::tryResolve is declared as virtual bool.
When I declare it simply as bool, the compiler correctly enters inside tryResolve, although I still receive some errors.

Breakpoint 5, inet::L3AddressResolver::tryResolve (this=0x63f434, s=0x121c88c4 "ue[0]", result=..., addrType=31) at inet/networklayer/common\L3AddressResolver.cc:71
71        result = L3Address();

Program received signal SIGSEGV, Segmentation fault.

In fact, the older version of SimuLTE, which runs on OMNeT++ 4.6, INET 2.3 work correctly, and in INET 2.3 the method tryResolve is implemented in the IPvXAddressResolver class, where the methods are not virtual.

This analysis doesn't solve the problem, since - as I said before - when declaring the method as non-virtual new problems appear, but I hope it can help other users at finding what is not working on Windows OS.

Michele

[Roger Jolly]

I think my post:

UDPBasicApp Copy/Paste Results in Segmentation Fault

is related.

[Henning P]

Hi there,

I just found a way to circumvent a very similar error under Windows with the L3AddressResolver:
https://groups.google.com/forum/#!topic/omnetpp/BuyOHGYH4Is

Actually, I think this might be the same error as the failing method there is
inet::L3AddressResolver().tryResolve()
and here it is
inet::L3AddressResolver().resolve()