Difference between revisions of "R-Car/Tests:sh eth"

From eLinux.org
Jump to: navigation, search
m (Add TOC)
 
Line 1: Line 1:
 +
{{TOC right}}
 +
 
This document describes test procedures for Renesas Electronics SH EtherMAC.
 
This document describes test procedures for Renesas Electronics SH EtherMAC.
  

Latest revision as of 06:38, 13 November 2017

This document describes test procedures for Renesas Electronics SH EtherMAC.

Wake-on-Lan

Some versions of SH EtherMAC supports Wake-on-Lan using MagicPacket, this describes how to test it on the Renesas Koelsch board. Wake-on-Lan is available since v4.10.

To test WoL the target (Koelsch) and the host needs to have working network configuration. It's possible to have target and host on different subnets as long as packets can be routed directly from host to target. However for this test it is assumed target and host are directly connected and on the same subnet, that way we don't have to worry about routing and such. The network interface on target are named eth0 and the interface on the host are named net0.

1. Find out the MAC address of the target, for example by running the ip command on the target itself.

root@koelsch ~ # ip address show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 2e:09:0a:00:3d:cf brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.6/24 brd 10.0.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2c09:aff:fe00:3dcf/64 scope link 
       valid_lft forever preferred_lft forever

The MAC address 2e:09:0a:00:3d:cf will be used in this example.

2. Set target to listen and wake-up by MagicPacket received on eth0 using ethtool.

root@koelsch ~ # ethtool -s eth0 wol g

3. Suspend target.

root@koelsch ~ # echo mem > /sys/power/state

4. Wake target up by sending MagicPacket from host interface net0 to a target with MAC address 2e:09:0a:00:3d:cf using the tool etherwake.

root@host ~ # etherwake -i net0 2e:09:0a:00:3d:cf


Alternatives to etherwake

There are alternatives to etherwake which can be used to send a MagicPacket. Examples are:

  • wol. If you use wol to send MagicPacket from a host with more then one network interface you are not asked which interface to use, instead which IP address the target have. The IP address is then used to figure out which interface to use. If the IP given to wol do not have a complete entry in the hosts ARP table it will be sent on the host default interface which might or might not be the correct, wol will in any case report that sending of MagicPacket are OK. If WoL do not work for you or more likely stops working at random ensure the MagicPacket are sent on the correct interface as the ARP cache entry might have expired.
  • wakeonlan. wakeonlan uses UDP instead of ICMP, so it can be used by normal (non-root) users. It also supports passing a target host name instead of a target MAC address, which is looked up in /etc/ethers (which you can copy from your DHCP/DNS server if it uses dnsmasq).

Different MTU settings

SH EtherMAC supports changing the MTU, this describes how to test it on the Renesas Koelsch board.

To test changing the MTU on the target (Koelsch) and the host needs to have working network configuration. The network interface on the host needs to support larger MTU values then 1500. For this test it is assumed target and host are directly connected. The network interface on target are named eth0 and the interface on the host are named net0.

1. On host set MTU to something large (9000) was used for this test.

ifconfig net0 mtu 9000 up

2. On target set MTU to something other then 1500, in this test the max MTU of 1978 is used

ifconfig eth0 down
ifconfig eth0 mtu 1978 up

3. Send ping with large payload and observe that it works.

ping -M do -s 1954 <target>

The reason for 1954 instead of 1978:

  • On Linux the ICMP/ping implementation do not encapsulate the 28 byte ICMP (8) + IP (20).
  • The driver internally reserve 4 bytes of transmission buffer for an optional VLAN header (4). And since no VLAN is used in this setup the additional 4 bytes can carry data.

4. For extra verification the packet flow is inspected using tcpdump to verify that there is no packet fragmentation.