ADP takes wrong dest_mac

[sachindes]

Hello,

At my setup I do have 2 i210 linux PCs. AVDECC with different entity ids are running at both of end points. Audio science cmdline controller is running at one of this pc.

I am using open avb stack and I had added a logic to start and stop streaming via controller.

However in one of case where 2 streams are running parallel, each end station is talker for stream 1 and listener for stream 2 and vice versa. Same configuration for avdecc as well.

Now i wish to get STREAM Stop/Start logic to work for both of end stations. Remote station as well as host end station. Everything is fine expect:

end_station_imp.cpp:

end_station_imp::end_station_imp(const uint8_t * frame, size_t frame_len) { end_station_connection_status = ' '; adp_ref = new adp(frame, frame_len); struct jdksavdecc_eui64 entity_id; entity_id = adp_ref->get_entity_entity_id(); end_station_entity_id = jdksavdecc_uint64_get(&entity_id, 0); utility::convert_eui48_to_uint64(adp_ref->get_src_addr().value, end_station_mac); end_station_init(); }

Both of end stations broadcast ENTITY_AVAILABLE. As observed remote PC always initiate 1st, causing ENITITY 2 to have PC 2 as end_station_mac whereas it should be for PC 1.

Now once ENTITY_AVAILABLE message received for both entities, end_station_mac will not be overwritten, since it is done once only. Result even after I do select specific ENTITY ID by "select xxxx" command, Stream Start or Stop or any other AEM command goes always to remote end station and never ever to local host( where AVDECC controller and other preferred Entity is located).

How to configure and fix preferred MACs?

[andrew-elder]

I don't think I understand the issue you are describing. The ENTITY_AVAILABLE messages can be observed in any order by the controller. Are you say that you expect the first one observed to be the local entity?

[sachindes]

Yes, I do expect local entity should be recognized along with local MAC address by cmdline controller, which is not happening. I have tried to run avdecc controller(cmdline) on other pc( entity 2) and then i do get different result. "list" shows 2 entities but MAC of remote end point rather than 1 local( for 1st entity) and 2nd as remote edn station's MAC. I feel cmdline do not list or skip ENTITY_AVAILABLE broadcast message for local MAC. As per ieee 1722_1: "An AVDECC Controller may exist within an AVDECC Talker or an AVDECC Listener, or exist remotely within the network in a separate End Station.", so AVDECC controller should be possible to run on any active end point.

I had checked wireshark log. Discovery -ADP broadcast messages are populated from both of end stations.

[andrew-elder]

Do you have the option of running the controller through a different NIC on one of the PCs? I would be interested to know if that shows everything as you expect.

[sachindes]

I thought to try the same, but I have 2 i210 cards on 2 PCs respectively. May be I need to borrow 3rd i210. Is there any other way? We will be able to run with another instance of virtualized IP; but for dedicated mac we will need NIC.

[sachindes]

[andrew-elder]

The controller does not have to run through an i210. Any NIC will do. If there is a motherboard NIC, you can use that. Or a USB network dongle thingy that has Linux drivers will do.

[sachindes]

Now result has changed... Instead of xxxxb3a0 MAC, it shows both entity's MACs as xxxxac:68( earlier cmdline host). I am expecting Entity ID xxxx02 with xxac:68 and Entity ID xxxx01 with xxb3:a0...

This is how Enitity's and 2 Open AVB streams are configured....

Any hint?

BTW, just for test, tried to hard code borad cast MAC into end_station_imp::end_station_imp(const uint8_t * frame, size_t frame_len), but seems changing this adp_ref->get_src_addr().value[n] not enough.

[sachindes]

By wireshark, I can see now ADP ENTITY_AVAILABLE broadcast message is received by xxxxac:68 1st followed by xxb3:a0.....

[andrew-elder]

And they both have different Entity IDs inside the messages?

[sachindes]

Yes.. ENTITY_AVAILABLE is for both entity IDs separately.

I can see pair of these messages from both Mac address as source.

[sachindes]

@andrew-elder In end_station_imp::end_station_imp(const uint8_t * frame, size_t frame_len), i had hard coded end_station_mac with multicast MAC. Now my purpose is solved. i can control streams from both entities selectively.

i do not see any side effect of this change. However any idea how can we ensure solution for such use case within AVDECC lib only.

My understanding was without any source code change, it should have worked.

[andrew-elder]

Thanks for the update. One side effect will be that point to point messages are now broadcast. That isn't so good.

I think it should have worked without that change as well. I'm not sure what the issue is. If you add a print() command just before utility::convert_eui48_to_uint64(adp_ref->get_src_addr().value, end_station_mac); do you see the expected end_station_mac values?

[sachindes]

@andrew-elder

I had tried to print adp_ref->get_src_addr().value before, it shows MAC of remote end station which is as per wireshark ENTITY_AVAIL messages. As a workaround I am editing end_station_mac with multi cast mac.

Yes this is completely workaround. However if I notice wireshark log i.e. Broadcasted ADP messages, there always ADP from remote end station are observed 1st followed by local end station. And as per this order, end_station_imp functionality is justified.

Have you observed such use case where talker + listener is same node( end station), and we expect something like each entity from different MAC?

[sachindes]

@andrew-elder As said earlier end_station_mac = 0x91e0f0010000( multicast address), solved mentioned issue.

Do you have any suggestion about such use case and AVDECC cmd line working?

[andrew-elder]

Did the separate NIC interface work - or not?

I don't often test under Linux, but I see we have another issue that may prompt us to set up a test.

[sachindes]

Nope, I already tried it. I used controller as 3rd NIC and 2 entities on 2 different NICs. Still Controller was taking MAC address of 1st node for both of entities; which is as per order of Entity available multicast messages observed in wire shark log. Entity available is received from both of nodes and from both of entities. Node 1 : Talker 1, Listener 2, Node 2 : Talker 2, Listener 1 --> AVDECC daemon is also run in tis correlation if not, cmdline controller does not list 2 entities. So pair of talker+listener for avdecc daemon exists.

[sachindes]

@andrew-elder Continuing same, i have some more additional points.

For ADP and ACMP, multicast address is used as destination mac; whereas AECP, dest mac address is received for incoming end station entity implementation.

Can AECP also not have multicast mac like others( same thing i have done to solve multiple stream control[AECP] as above) ?

[sachindes]

[jdkoftinoff]

No you may not use multicast for AECP, there are very good reasons to not use multicast for control. You must do unicast to all end stations via AECP.

On Jul 26, 2017, at 1:38 AM, sachindes notifications@github.com wrote:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[andrew-elder]

Agree with @jdkoftinoff - no multicast AECP. Network would potentially flood when many devices are active.

[sachindes]

@andrew-elder @jdkoftinoff So what should we conclude for this observation. I could see I can not control streams selectively with cmd line controlled via AECP in case of multi nodes... Details are provided. We should conclude this issue.

[andrew-elder]

@sachindes - do you have a specific pull request that addresses your issue?

[andrew-elder]

Otherwise we will just close this.