WIZnet IoT iOffload Contest

WIZnet is running a contest this summer for IoT designs that use either the W6100 Internet controller chip or WIZ610io Ethernet  module.  They are looking for 'IoT innovation' and will award five $1000 and ten $500 prizes.  For more details see the IoT iOffload Contest.

WIZnet products include chips and modules to enable networking for microcontrollers.  For example, the Arduino Ethernet Shield 2 uses the W5500 Ethernet Controller.

How to Avoid the DHCP delay if Ethernet is Disconnected in Debian Jessie

In Debian Jessie if the Ethernet port is not connected and the interface is set to automatically use dhcp at boot, the system will still wait for an IP address.  This adds about a minute to the boot time of a BeagleBone Black.  

Here is what you will see during the delay:

[   12.172221] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[***   ] A start job is running for LSB: Raise network interf...26s / no limit)

To avoid the delay change the interfaces file to use something other than dhcp.  Here is a listing of the original file:

root@arm:~# cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)

# Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet dhcp

I just changed dhcp to manual, other options are auto and static.  Look at the man page for interfaces for more information on the other parameters.  

You can still connect Ethernet and use DHCP to get an IP address after the system boots with the dhclient command.

root@arm:~# dhclient eth0

I looked for the cause of this delay and found it mentioned in Debian Bug report logs - #754218

boot hangs forever on LSB job "raise network interfaces"  Message 150 is interesting:

Am 01.12.2014 um 18:08 schrieb Christoph Anton Mitterer:
> On Mon, 2014-12-01 at 18:00 +0100, Michael Biebl wrote:
>> Very likely, yes. If you use DHCP, it can easily take a few seconds for
>> your network to be configured.
>> And now that /etc/init.d/networking both handles allow-hotplug and auto
>> interfaces and blocks for ifup to complete for those interfaces, the
>> delay during boot is kinda expected.
>
> So can we keep the other fix as it is? I mean this will just cause
> another stupid systemd-is-responsible-and-it-sucks hatred storm by
> people... :(

Not quite sure what you mean with "other fix"? Can you elaborate?

You can't eat a cake and have it too.
Either we wait blockingly (and wait actually means, well, delaying your
boot process and making it slower) for ifup to complete during boot as
workaround for broken software which doesn't deal with dynamic network
changes and requires $network, or we don't blockingly wait and cause
that other software to break.

For jessie we decided to take that boot delay hit in exchange for
supporting $network requiring software.

I believe a reasonable fix would be to detect that the port is not connected and skip or interrupt the wait for a DHCP response.  I admit I don’t know how much work that would be, or what else it would break.  Booting seems much faster with systemd otherwise.

STM32F4 Discovery Kit Expansion

The $14 STM32F4 Discovery kit with ARM Cortex-M4 Processor can be expanded with three new boards.  There is a baseboard that provides Ethernet, Micro SD, plus more I/O ($40), an LCD board with touchscreen ($55), and a camera module for video or photos ($34).  See element14 for more information on the Discovery series boards.