New Ethernet shield

[uberhund]

A few months ago, it was possible to take a $25 xPort device and create a fully DHCP compatible solution for Arduino. It was a tough start, but eventually I got the combination to plug into any network and work *extremely* well, with no code changes needed as units were deployed or moved between networks.

That was then, this is now.

Now it seems that the newest version of the xPort device is $65, but that doesn't matter because its not supported by the existing Arduino shield anyway.

This leaves the WizNet W5100 as the sole, supported, affordable, non-WiFi solution. However, as I understand it, the W5100 not only does NOT provide DHCP, neither does it even know its own MAC address.

This means previous projects that would plug and run into any network, must now have their sketches customized to play nice with other devices in a given network, with no guarantee that the device will continue working if new devices are added to that network.

I hope I have misunderstood the options. Otherwise, is anyone out there aware of developments that would provide a decent replacement to the old xPort solution?

[adafruit]

the xport was better than nothing, but it was still difficult to use and then, of course, discontinued.
ENC28j based solutions are cheap, but require a full tcpip stack to be written, this bloats code by a lot, and is complex to use
the wiznet modules are kind of in the middle, they aren't insanely expensive but you don't have to write a tcpip stack. we started carrying the Arduino Ethernet shield when someone wrote a DHCP client for arduino.

[linuxworks]

you might also consider a hybrid project.

I'm coming to the conclusion that anything 'serious' is going to need access control and authentication. the ethernet/ip library has none of that (that I know of), perish the thought of https

given the fact that many linux 'plastic routers' (openwrt, tomato, etc) already have a quite nice IP and web stack (and can do real work, too, even sql-lite kind of work) its hard to justify over $30 for an arduino ethernet board when a 'plastic router' can be connected to an arduino (i2c or serial) easily enough.

I plan to do such a thing. there was a clearance sale on the seagate POGOPLUG thingies and I am going to try to adapt that onboard system with a minimal linux kernel to be a smart web front-end to my arduino controller stuff.

I just can't see putting a controller that does more than 'gets' online and not having some decent security in front of it.

the ip-on-a-chip has a long way to go before its even close to what you get via a software based security-enabled stack.

I suppose if you are 100% secure in your lan and need no login authentication, etc; then the arduino wiznet thing is ok but it runs out of steam real fast and is only good for pretty minimal web-controlled projects (imho).

[adafruit]

you might also consider a hybrid project...

thanks for posting up - the ethernet shield isn't for everyone - for some it will fit their needs perfectly, others it will not.

[richms]

Anyone know if you can do just plain ethernet on the shield or does it have to go over IP because of something in the chip? I was thinking that just using ethernet frames back to something on a server would be a better way to do it, and then have the server do all the gruntwork with user interface and authentication, with unauthenticated stuff between the server and the arduinos treating it as basically a serial connection or similar.

[linuxworks]

my gut feeling is that you never want to be 'LAN only' which is what you are suggesting.

removing the chance of using a router means you are bridgeable-only. (takes me back to my old networking days at DEC when people really were afraid to 'route' and preferred to 'bridge' instead.)

today, almost no one does that. everything is designed in order to 'scale' and to be portable and mobile. making an assumption that some server is on the very same subnet may hit many of the use-cases but it leaves too many other (useful) ones out.

write you own layer on top of udp or tcp if you really must. but I would not suggest bypassing transport and routing (as layers). they do useful things and they do buy you a lot.

writing your own layer is just a fancy way of saying 'write an app and pick a port # for it'. then have that app do some app-specific protocol to some remote entity (a server with a peer process that you want to talk to). all on top of standard ethernet using standard IP and standard tcp or udp - and YOUR app on top of one of them.

[richms]

The arduino cant ever do something suitable for direct exposure to the internet IMO, so it would be at least behind a https proxy doing the authentication.

For outgoing requests, the lack of https, cookies etc support on the arduino again makes its use to go onto the internet limited, so you would be passing thru a local proxy or server before going out to the internet server you are sending stuff to, making the lack of full IP on the arduino a non issue there.

The only thing a native IP stack adds IMO is the easy ability to make inherently insecure devices. it just doesnt have the memory or cpu to function over a hostile network for anything that you dont want false triggers or spoofed data on. Interesting novilty devices, yes great, but anything home automation etc related shouldn't be exposed like that. To be honest having random ethernet frames blasting over an untrusted lan in the clear is somewhat worrying, but less so than IP stuff.

[linuxworks]

it would be so cool IF there was a mating chip that added 'security' to this whole thing.

like you said, state cookies, https and some firewalling/access lists would really make this useful for more than just demos.

one thing we have learned in the last 10 or so years: if you connect it to something that is online, you MUST secure it.

and I'm not sure that a single layer is good enough. you can say that your local lan should be secure but that's just not enough. access control and firewalling should be on each device and have that last level of security to have to pass thru.

I love the form factor of the ethernet shields; but they need a security co-module at the very least.

arduino systems could actually be more secure than unix based systems (less known, fewer ways 'into' the system, not using conventional disk/memory/io like people are used to, etc. so the embedded system has an advantage if it was used to its full potential.

I'm sure that developing a 'security on a chip' module is WAY harder than just getting IP on a chip I guess until then, a software firewall as a front-end is the only thing we can do, for now, to make this safe to deploy in the real world.

[richms]

If you think the idea of an arduino on your lan is bad, dont look at the current state of the home automation industries because that will seriously freak you out. UDP is the replacement for rs232 on lots of things. That insane movie plotline thing of popping open a door intercom and clipping onto some wires and seeing all the security feeds is not too far off reality in the specs for some smart home stuff I have seen.

[westfw]

I'm not sure that a single layer is good enough. you can say that your local lan should be secure but that's just not enough. access control and firewalling should be on each device and have that last level of security to have to pass thru.

Throw away your arduinos and start buying hawkboards, beagleboards, chumby development systems, and so on. There's not much point to adding a "security processor" with 32bit CPU and megabytes of memory to a tiny microcontroller; better to add IO ports to your linux-running beast. After all, development boards with adequate capabilities are "about $100", and mass-produced boxes (eg wireless routers, for example) get down near bare Arduino prices...

There are some "tiny" encryption algorithms (TEA?) that might be suitable for incorporating into small networked products, but I'm not aware of any standards based on them. They'd likely benefit from obscurity for quite a while, though of course that's not really a valid security mechanism. OTOH, even the best protocols don't protect from password==default...

The wiznet chip does indeed have a "raw ethernet" mode (called "MAC Raw" in the documents.)

[chuckm]

it would be so cool IF there was a mating chip that added 'security' to this whole thing.

WARNING DO NOT READ THIS IS A RANT:

Sigh. Do you know why there are now "security" chips in front of USB ports? How about "security" chips in from of disk drive ports? Or "security" chips in front of your monitors DVI plug?

Kids often miss the fact that Ethernet is the original "universal serial bus" in fact, it is a much better serial bus than the BANNED that Intel foisted on the world and managed to get everyone to pay them taxes on.

There is absolutely no requirement that an ethernet network be able to route packets to the big "I" internet. And if the only way you know how to wire up a network is to give everything full frontal Internet then you need a quick course in network topologies.

You have a machine, we'll call it a "server", which is BANNED against all the latest and greatest attack vectors coming through the cess pool out there, and we add a peripheral to that machine, we'll call it a "nic", which connects that server to a bunch of really useful sensors and actuators and whatnot, over a wire that is a couple of twisted pairs and can go for over 1000 meters and still work. Isn't that cool? And just like all the other peripherals we've hooked up to the server, its disks, its monitor, its keyboard, Etc, we don't burden the peripheral with extra security that the Server os is taking care of for us.

I did warn you,
--Chuck

[linuxworks]

have to disagree with your post 100%. sorry.

ethernet, today, is the layer below IP. IP is mandatory in all sensible cases. (I come from a pretty BANNED networking background, fwiw). the days of using raw ethernet packets is long over. no one sensibly does that anymore (again, look at lan bridging vs routing arguments from about 10 yrs ago).

is the usb bus accessible from the outside world? directly? nope.

rs232? nope.

video? nope!

ethernet is special. its NOT just another serial interconnect. the stuff that drips off ethernet wires often is a mix of local and remote traffic. remote users can get access to your lan and you should design products and services assuming your network is under frequent attack.

[westfw]

look at lan bridging vs routing arguments from about 10 yrs ago

More like 20years ago; we're getting old. Most of the valid purposes of bridges have been subsumed into "switches"... (I'm also an old-time hard core networker.)

remote users can get access to your lan and you should design products and services assuming your network is under frequent attack.

I dunno. There are a lot of ways to protect "dumb" IP network devices on your local ethernet form the horrible outside world (some of which rather remove the advantage of using IP in the first place...) (as an first level defense, you can refuse to accept IP connections from anything other than then local IP network.) It shouldn't be necessary to incorporate "hard" security an every node, and I think I could make a good argument that maintaining adequate hard security on a large number of tiny nodes is not easier or cheaper than maintaining an adequate firewalling setup. The usual problem will be administrative rather than technical: the people who maintain the insecure nodes won't be the same ones that administer the network/firewall... cisco's internal lab networks are full of unsecured and poorly secured devices (a terminal server back-ending every console, accessible by telnet, to start with.) And we're certainly a big shiny target, but I don't think there has ever been trouble along those lines; there are just TOO many levels of protection.

There are still companies advocating (selling!) internet proxy services. http://www.arrayent.com/ comes to mind; they gave a pretty impressive talk at "TI day"/ESC last spring.

[linuxworks]

bill's talking about 'hard security' (lots of layers, filtering up and down the stack) but the arduino ethernet ip-on-a-chip device has NO security at all.

I just don't feel comfortable deploying this to control real world things: my a/c or heating, for example. not without minimal current accepted security and access control.

I'm more concerned with access control on physical things. if 'regular old apache' deserves access control, surely real-world physical devices with web control deserve at least as much, no??

also, you said:

I think I could make a good argument that maintaining adequate hard security on a large number of tiny nodes is not easier or cheaper than maintaining an adequate firewalling setup.

distributed can be more effective, though. still, there's NO reason for this to be either/or. I'm not falling into that fallacy (lol).

[westfw]

bill's talking about 'hard security' (lots of layers, filtering up and down the stack) but the arduino ethernet ip-on-a-chip device has NO security at all.

There isn't any reason that an Arduino internet app can't offer application-level security via a simple address check and/or a cleartext password (though it may not be up to "standard" http-ish security protocols. Being something of a curmudgeon, I'm not that fond of tiny servers running web protocols anyway.) This, combined with "typical" router security features (hosts on your internal internet won't normally be reachable from the internet as a whole, just because of NAT and similar, for example. You have to explicitly set up external access) ought to be sufficient for most applications. Hacking your neighbors' air conditioning just isn't much FUN, you know.