RTOS/PROCESSOR-SDK-AM437X: Ethernet gateway

The RTOS team have been notified. They will respond here.

Marcio,

Yes you should be able to route the packet from eth0 to eth1 by setting up the gateway route table and the CPSW in dual mac mode.

Regards,
Garrett

Hi Garret,

I´ve tried and it did not worked. I must be doing something wrong.

On my test PC1 (IP=192.168.0.100 Gateway=192.168.0.1) is connected in eth0 and sends messages to PC2 (192.169.0.100) connected in eth1.

// Add a route to eth0 (192.168.0.1)

CI_ROUTE RT;
bzero(&RT, sizeof(RT));
RT.IPDestAddr = 0x0000A9CA;    // 192.169.0.0
RT.IPDestMask = 0x0000FFFF;    // 255.255.0.0
RT.IPGateAddr =  0x0100A9CA;  // 192.169.0.1;   
CfgAddEntry(phCfgEntry, CFGTAG_ROUTE, configIndex, 0, sizeof(CI_ROUTE), (UINT8 *)&RT, 0);

Do you have an example?

regards,

Marcio

Marcio,

So you have two ports (eth0/1) IP address (192.168.0.1 and 192.169.0.1) configured properly and able to ping from PC, and just the layer 3 IP routing function not working? It seems you already followed the instruction in 3.2.4.1.1 Constructing a Configuration for a Static IP and Gateway of NDK UG to set up gateway.

We have the dual mac setup example for AM572x (NIMU_DualMacExample_idkAM572x_armExampleproject), but not a gateway/route example.

Regards,
Garrett

Hi Garrett,

Yes, the two Ethernet ports (eth0/1) are working very well.

Including the gateway for sending packets. When the application sends a packet to anther subnet it reaches the external gateway correctly. 

           // Add a gateway
            bzero(&RT, sizeof(RT));
            RT.IPDestAddr = 0;
            RT.IPDestMask = 0;
            RT.IPGateAddr = gatewayIpAddr;
            CfgAddEntry(phCfgEntry, CFGTAG_ROUTE, configIndex, 0, sizeof(CI_ROUTE), (UINT8 *)&RT, 0);

My problem is when eth0 receives a packet that is addressed to a device that is in eh1. For instance when PC1 (IP=192.168.0.100 Gateway=192.168.0.1) sends a packet to PC2 (192.169.0.100), it uses the MAC address of eth0 and the IP of PC2.

regards,
Marcio.

Marcio,

Is the issue still pending or you have found a workaround? Are you testing the route function on AM437x starter kit or your own custom board?
Would it possible to share your project here? I can try to get a starter kit and look into it...

Regards,
Garrett

Hi Garrett,

The issue is still pending.

I am testing on my own board. But I do not thing does it matter.

Sorry my employer does not allow me to share my project. I understand that a better option would be to provide a small application to you, but we are in a hurry here and this fiunctionality is schedulled to a future version.

I would appreciate if in meanwhile you could try on any example that uses dual port MAC and NDK on any AM437x board.


Regards,
Marcio.

Hi Garrett,

I´ve created a small project to test the issue. It is attached.

Funcion ConfigEthenetDevices in main.cpp configures 2 routes, one for the default gateway and one for forwarding packets received in eth0 (192.196.0.1) to eth1 (192.168.0.1).

My test arrangement has a PC1 connected to eth0 of my board or starter kit board (AM437x) and PC2 connected to eht1 through cables (no network switch).

My objective is to send a UDP packet from PC1 to PC2.

Equipment	IP	Network mask	Default Gateway
PC1	192.169.0.100	255.255.0.0	192.169.0.1
eth0	192.169.0.1	255.255.0.0	192.169.0.100
eth1	192.168.0.1	255.255.0.0	192.168.0.100
PC2	192.168.0.100	255.255.0.0	192.168.0.1

Sending pings:

From	To	Result
PC1 (169)	eth0 (169)	SUCCESS
PC1 (169)	eth1 (168)	SUCCESS
PC1 (169)	PC2 (168)	FAIL
PC2 (168)	eth0 (169)	SUCCESS
PC2 (168)	eth1 (168)	SUCCESS
PC2 (168)	PC1 (169)	SUCCESS

 Sending UDP packets: 

From	To	Result
eth0 (169)	PC1 (169)	SUCCESS
eth1 (168)	PC2 (168)	SUCCESS
PC1 (169)	PC2 (168)	FAIL
PC2 (168)	PC1 (169)	FAIL

Regards,

Marcio

ced2_net_test-20180706.zip

Thanks Marcio, I will try to run your project and let you know if any issue...

Regards,
Garrett

Marcio,

Just got a AM437x starter kit and PCs setup. With the project, it seems that only PC1 can ping eth0 and PC2 can ping eth1 in my setup.
There were some link issue associated with UART functions, and I made minor updates to .cfg to pass that error.
Did you have some changes in PDK drivers to get the result you show above?

Regards,
Garrett

Hi Garrett,

Yes, I´ve made the following changes on enet_phy.c. My board does not have UART 0, I do not want to see the prints of enet_phy.c. Sorry for the inconvenience, but remember, this is only a piece of my application.

// MB 2018-05-11: Do not use the TI’s UART_stdio. Disable all printfs
#if 0
/* UART Header files */
#include <ti/drv/uart/UART.h>
#include <ti/drv/uart/src/UART_osal.h>
#include <ti/drv/uart/UART_stdio.h>
#else
static void UART_printf(const char *pcString, ...) {}
#endif

 
About PC1 pinging eth1, I thought this was the normal behavior of the Ethernet Switch of the AM437x.

Regards,