Connecting the card to a LAN is recommended. The Linux machine boots up with servers supporting telnet, ftp and CGI-enabled http (meaning that the card can be accessed with a web browser). On top of this, it’s possible to mount shared folders from both Linux and Windows machines. This is very convenient when developing applications, as there’s no need to copy the files back and forth from and to a fullblown computer to the embedded platform.

Please note that by enabling networking on the card, you expose it to complete control by anyone who can access it. Anyone with access to its network interface can gain superuser access to it without supplying any credentials whatsoever. This is usually not a concern when the card is run on an internal LAN, since the latter is usually behind a firewall preventing requests from the outer world. Nevertheless, it’s important to realize that the card comes with zero networking security (even though it’s possibly to take security measures on this platform).

Setting up Ethernet with DHCP

If there’s a DHCP server available, simply type “dhcp” at shell prompt. When successful, it typically looks like this:

/ # dhcp
udhcpc (v1.17.1) started
Sending discover...
PHY: c0729a0c:07 - Link is Up - 100/Full
Sending discover...
Sending select for
Lease of obtained, lease time 21600
deleting routers
route: SIOCDELRT: No such process
adding dns
adding dns
/ # eth0: no IPv6 routers present

If the DHCP server offers addresses to DNS servers, they will be used as well.

Setting up Ethernet manually

The network can be set up manually with an ifconfig command as well. For example, to assign the card an IP address of with net mask

/ # ifconfig eth0 netmask

To access computers beyond the LAN, a gateway must be specified. Note that by adding this gateway, the card becomes accessible to attackers from the whole internet, which it wouldn’t be otherwise (because it couldn’t establish a connection beyond the LAN).

Having that said, if the gateway is at, it’s declared with

/ # route add default gw

The gateway address must be within the previously given net mask, of course.

To set up DNS servers, edit /etc/resolv.conf as appropriate.

telnet, ftp and web server

Once the network is set up as shown above, connect to the platform with telnet and ftp as usual. No username or password is required for the telnet connections, and neither are they necessary for ftp. The connecting ftp application may prompt the user for these, but they are ignored by the platform; just supply anything you like.

To access the platform as a web server, simply open your browser and type e.g. on the address bar. The IP address should be adjusted to the one assigned to the platform, of course.

The platform can also contact servers with wget (possibly download web pages as well as data from ftp servers). ftpget and ftpput are simple ftp clients. Anyhow, it’s usually easier to let the platform be the server as modern full-blown computers generally don’t have these vulnerable services.

When more than a single occasional file transfer is necessary, it’s wiser to mount a share, as described next.

Accessing shared folders over the network

The Linux kernel is configured to support network filesystem shares. Both UNIX/Linux NFS and Windows SMB are supported, so files may be read and written to both UNIX and Windows computers.

Connection to a windows computer at, with the share name “mydisk”, Windows user name “theuser” and password “thepass” goes

# mount -o user=theuser,password=thepass // /mnt/try

(assuming that /mnt/try exists).

To mount an NFS share:

# mount -o nolock,proto=tcp /mnt/try

The nolock option is crucial here. Without it, the mount simply hangs. Without the proto=tcp part, there’s a good chance that the NFS connection will hang sooner or later. In short use both.

Next recommended reading: Compiling Linux applications