Denm service overwriting port on IVIM service

[brianmc95]

Hi all,

Running into a bizarre issue which I cannot explain.

I'm currently running on commit 4bc468e372091fa392d43c5fc3358821a21534c9, so not majorly out of date but will update shortly though don't see anything in those commits that looks relevant.

I have a configuration with a DENM and IVIM application running on an RSU with 2 OBU vehicles on a simple highway.

The IVIM service is a simple packet mechanism just sending a speed advisory message and is a cPacket, the port is set to btp::ports::IVIM port and has the same port setup for the listener in the associated XML files. The DENM service then simply runs on the DENM ports and again corresponds in XML (DENM port 2002, IVIM port 2006). When I run without the DENM service then the packet is consumed correctly by the receiver service for the IVIM and the TransportDispatcher::indicate method shows that btp_ind.destination_port.host() is 2006 as it should be. Introducing the DENM service then causes this to only say port 2002 and as such makes it so that all packets are consumed by the DENM service whether they are IVIMs or DENMS.

Any ideas as to why? I can share a small working example if possible, otherwise, any hints as to ways to make it so they differentiate would be ideal.

Thanks in advance, Brian

[awillecke]

Hi,

this does not sound right, and services should only get messages on ports they are listening on (when they are not promiscuous).

• How do you verify that messages received in the DEN service are actually IVIMs?
  • When enabling DENMs, can you verify if the port of the IVIMs is correct when they are sent. Is it already false, or does it change in between somewhere?

A minimum (non)-working example would be helpful to investigate this issue.

Best regards Alex

[brianmc95]

Hi Alex,

Thanks for getting back, I'm currently away from the PC I have running but will try to get a fully working example to you as soon as I can.

One thing I might have misconfigured is what you mean by promiscuous, it might be the case that my DEN service is somehow in this mode and consuming them when it shouldn't. Would you be able to explain quite how this works?

As for your questions.

• I configured a scenario where the DEN service would be created but not activated for a period. At that time the IVI service is running correctly and the DEN service then is receiving packets which can only be the IVIMs as no DENMs have been sent at that point, so I am confident that these are indeed IVIMs.
• 100% I've debugged through manually I know that on generating the request for the packet I set the port explicitly to 2006 and tracked it through the layers and saw that it maintains the correct value. Then it appears on reception to be changed but only in the case where a DEN service is active.

Anyway, I'll have an example for you in the next day or so (my day today is busy unfortunately) but feel free to take a look on Monday or Tuesday don't want to put you under pressure and I appreciate the help.

Kind Regards, Brian

[awillecke]

One thing I might have misconfigured is what you mean by promiscuous, it might be the case that my DEN service is somehow in this mode and consuming them when it shouldn't. Would you be able to explain quite how this works?

You can build services, inheriting the ItsG5PromiscuousService, which allows receiving all packets no matter the port. However, having such a service should not prevent other listening services from receiving their designated messages.

• I configured a scenario where the DEN service would be created but not activated for a period. At that time the IVI service is running correctly and the DEN service then is receiving packets which can only be the IVIMs as no DENMs have been sent at that point, so I am confident that these are indeed IVIMs.

I have very little experience with DENMs in Artery, so some suggestions might not be helpful here, but can you check the following:

• Does the activation of use cases and trigger of DEMNs really work as you expect? Maybe a misconfiguration causes more messages being emitted than you planned
• Verify the incorrectly received IVIMs by their content. Maybe add some kind of sequence number for testing
• Does this issue disappear when you disable your IVI service?

Anyway, I'll have an example for you in the next day or so (my day today is busy unfortunately) but feel free to take a look on Monday or Tuesday don't want to put you under pressure and I appreciate the help.

All right. I'm pretty busy myself, so I can't promise anything, but I'll take a look when I have some time.

Best regards Alex

[riebl]

An accidentally enabled promiscuous mode as mentioned by @awillecke was also my first thought. However, I cannot imagine how DenService has registered as a promiscuous listener if you have not touched its implementation. Port numbers of packets are never "adjusted" by the receiving side. I am also hoping for a MWE which can be debugged then.

[brianmc95]

Hi all,

Thanks for getting back, had another look at it today and noticed that I had misconfigured my experiments, I had a DEN service active on RSUs and OBUs. I didn't actually want the service sending messages on the OBU but they were which explains the issue with the DENMs being received. I Re-ran now and the service is operating correctly without the DEN operating on the OBU. Still find the behaviour odd, and happy to share the current version I have if you would like to take a look at it. I imagine it is just a misconfiguration on my end most likely though. I can close the issue unless you'd like to check it out yourselves, I'll likely look into it further

[awillecke]

Glad you found the problem and fixed it. Do you still observe the messages being received on the wrong port? If this still occurs, the MWE would really help investigate a potentially severe issue.

[brianmc95]

So I had another look again this morning to confirm and it's working correctly now. I can't even seem to be able to reproduce it for some reason. Sorry to have wasted your time genuinely don't know what I had configured incorrectly or not but the issue resolved itself and now it's working regardless of what services are active. Happy to do a pull request of the changes I made if it's of interest for you all to take a look at it, also might be useful for the project (added RSU DEN service and some basic DEN use cases which I'd be happy to share with the project and would be good to get input on). Genuinely appears to be working correctly now and don't have an obvious reason as to why this has changed. Will close but let me know if you want me to send in a PR with the branch anyway.

[riebl]

Hi @brianmc95, don't hesitate to share any ideas on how to avoid misconfiguration issues in the future. After all, Artery should be as easy to use as possible. Which can be tricky from time to time…

[brianmc95]

Ah I know it's a complex model and appreciate all the efforts in designing it. I probably would only reiterate some of the previous issues mentioned around documentation, won't claim to be a saint here either everyone hates writing documentation. I'm currently working on a short term research project, at the end I'm due to provide handover documentation. I'll share what I can with you at the end of this and if you think it useful feel free to add it to your website.

I'll mostly be outlining adding scenarios, setting up CLion (which I use usually for Artery), implementing new Use-Cases, channel models, some additional services. Probably be the end of September when this happens but again happy to share then if it's of use (not going to say I'm expert but might help others along).