Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/ANDROIDSDK-SITARA: ALE config issue

Part Number: ANDROIDSDK-SITARA
Other Parts Discussed in Thread: AM5728

Tool/software: Linux

AM5728 ALE MODULE says:

if  a recieved packet has a source address that is equal to destination address then the following occurs:

1  the address is learned if the address is not found in the table 

2 the address is updated if the address is found

3 the packet is dropped 

if there are two terminals use am5728 , they have same mac address .

and there is thread to send gratuitous arp to check ip conflict & mac conflict.

they both can send arp request and receive arp request(broadcast) ,and they both can send arp reply but can not receive arp reply.(same src and dst mac address )

so the mac conflict can never be detected !!

but i need to check mac conflict ,  is there any way to resolve ?

  • The factory team have been notified. They will respond here.
  • ok,thanks !
    by the way:
    we are using the dual mac mode.
    the following are all the configuration about ale

    host port : priv->host_port = 0
    cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE, CPSW_ALE_VLAN_AWARE);
    cpsw_ale_control_set(priv->ale, priv->host_port, ALE_PORT_STATE, ALE_PORT_STATE_FORWARD);
    slave port: slave->port_vlan = 1, port_mask = 3
    cpsw_ale_add_vlan(priv->ale, slave->port_vlan, port_mask, port_mask, port_mask, 0);
    cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast, port_mask, ALE_VLAN, slave->port_vlan, 0);
    cpsw_ale_add_ucast(priv->ale, priv->mac_addr, priv->host_port, ALE_VLAN | ALE_SECURE, slave->port_vlan);

    cpsw_ale_add_vlan(priv->ale, priv->data.default_vlan, 7 << priv->host_port, 7 << priv->host_port, 0, 0);

    all this configuaretion can be found in " ti-processor-sdk-linux-am57xx-evm-02.00.00.00 "
    board-support/linux-4.1.6+gitAUTOINC+52c4aa7cdb-g52c4aa7/drivers/net/ethernet/ti/cpsw.c
  • Hello,
    Answerss inline

    if a recieved packet has a source address that is equal to destination address then the following occurs:
    1 the address is learned if the address is not found in the table
    -New conversation if auto learning is enabled
    2 the address is updated if the address is found
    - Node moved and needs to update its location within the switch fabric
    3 the packet is dropped
    - If a packet is received on a segment or port and its SA is equal to its DA, then the source segment or port has already seen the packet We are never allowed to replicate a packet that was seen on a port back to that same port. Basic IEEE802.1 bridging rule.
    So this is correct action based on IEEE802.1d bridging specifications.

    if there are two terminals use am5728 , they have same mac address .
    -It is expected that MAC addresses are unique per device. If the device is allocating addresses it should use locally administered address and request the address from the local address distribution server. It will use its BIA burned-in-address (a unique address per device for the allocation request).

    and there is thread to send gratuitous arp to check ip conflict & mac conflict.
    - they both can send arp request and receive arp request(broadcast) ,and they both can send arp reply but can not receive arp reply.(same src and dst mac address )

    so the mac conflict can never be detected !!
    -There are bigger issues…
    The SA update feature allows nodes to be moved freely around the network and provide conversations to continue. That is you move the cable from one jack to another.
    But in your case, if you update the table for the new address SA=DA, the current old conversation will break. Remember we are not allowed to forward the packet onto a segment or port that has already seen the packet. But updating the SA will break already established communications between active nodes.
    So for your case either
    • Disable SA updates, (which will not allow a Node to move in the network until its address is aged out.)
    o In this case the new node will never see any responses from anything it request, so it will be ignored until the aging table drops the other address.
    • Or authenticate each node address via 802.1X authentication protocols.

    but i need to check mac conflict , is there any way to resolve ?
    - This duplicate MAC address breaks many things, If you are trying to do distributed server, then trunking may be a better alternative.
    Another possibility is to use your BIA address and send to the address you want to use to see if you get a response from that node.