Recommendation for Ethernet chip needed

[richardman]

Any recommendation for a good ethernet chip? High quality is more important than low cost. It will be used in conjunction with a separate MCU. Bonus if the vendor provides TCP/IP stack etc.

Thanks

[nctnico]

I have lined up a Wiznet chip for an upcoming project. I started a thread about it a few months ago; there are some issues regarding powering and reset though. IMHO nothing a good layout + decoupling can't solve.

[djacobow]

Any recommendation for a good ethernet chip? High quality is more important than low cost. It will be used in conjunction with a separate MCU. Bonus if the vendor provides TCP/IP stack etc.

Thanks

Someone else pointed out Wiznet parts. Those are great if you just want TCP/IP off-loaded entirely and want to see a serial modem-like interface instead.

The microchip ENC28J60 shows up a lot in hobby designs. It's got a mac + phy and SPI interface to your uC. There is good driver support out there, but you'll be doing your own TCP/IP on your CPU. It's 10MB/s. ENC624J600 is a 100MB/s part. It's not the cheapest part, but I think you'll have an easier time finding drivers than with some cheaper parts.

[free_electron]

what interface ? the best ones are PCI or PCIx based ... but if the host doesnt have that ...

[richardman]

what interface ? the best ones are PCI or PCIx based ... but if the host doesnt have that ...

MCU, so basic SPI, parallel etc.

[richardman]

Someone else pointed out Wiznet parts. Those are great if you just want TCP/IP off-loaded entirely and want to see a serial modem-like interface instead.

The microchip ENC28J60 shows up a lot in hobby designs. It's got a mac + phy and SPI interface to your uC. There is good driver support out there, but you'll be doing your own TCP/IP on your CPU. It's 10MB/s. ENC624J600 is a 100MB/s part. It's not the cheapest part, but I think you'll have an easier time finding drivers than with some cheaper parts.

So the PROs of using the ENC part is perhaps less costly but more work on the MCU's part?

As I mentioned, cost is not the major concern: quality (and performance) are.

Thanks

[bson]

There's always the classic CS8900A... tons of source code out there, but obviously not the most modern.

[Bruce Abbott]

cost is not the major concern: quality (and performance) are.

What performance do you need, and which MCU are you intending to use?

[Scrts]

Any recommendation for a good ethernet chip? High quality is more important than low cost. It will be used in conjunction with a separate MCU. Bonus if the vendor provides TCP/IP stack etc.

Thanks

Does your microcontroller have RMII/MII interface?
You should also read this: https://www.eevblog.com/forum/projects/which-ether-phy-to-use/

[djacobow]

So the PROs of using the ENC part is perhaps less costly but more work on the MCU's part?

As I mentioned, cost is not the major concern: quality (and performance) are.

Thanks

Free Electron is right that I did not even ask your requirements. I sort of assumed you were working with run of the mill cortex or 8b part with serial interfaces only. The performance for such is never gonna be great, but it's adequate for lots of things.

If you are in need of high performance, then things like PCI. RMI / RMII are phy<=>mac interfaces for parts that have their own MAC, or if you want to use separate MAC and PHY parts. Could be something you want to do, probably not.

You really have to tell us what you're up to.

Regarding IP on your processor, it can be a pain or not. Terminating TCP without an RTOS is something I would not want to do. Running LWIP over your RTOS could be smooth or rough depending on how easy it plugs in. Sometimes RTOSs have already done it for you. Sometimes you only need to handle UDP or even just send individual packets or something and life can be easiesh.


So the answer is ... it depends.

[mrpackethead]

Yes, huge depends.

The wiznet is easy, but its serioulsy painful if you want / need to do anything non-standard with the IP stack. For example multicast...

I've used 1000's of the ENC chips, with PIC microprocessors, ( PIC24 and 32 ) and they run pretty well, thats using a RMII interface.
Theres a bunch of Phy chips that Microchip have just bought ( SMSC ) and Texas Instruments have lots as well.  The TI parts are possibly the most robust.

[westfw]

The wiznet is easy, but its serioulsy painful if you want / need to do anything non-standard with the IP stack. For example multicast...

These days I would be worried about IPv6.

As for built-in TCP/IP, doesn't that limit you to Wiznet and the Lantronix modules?

[Rasz]

ENC28J60. It's 10MB/s. ENC624J600 is a 100MB/s part. It's not the cheapest part, but I think you'll have an easier time finding drivers than with some cheaper parts.

above and wiznet all top out around 1mbit irl

separate MCU

dont, unless its for infrequent small messages

[richardman]

Looking at the STM32F429 right now, so actually we only need something like a Microchip LAN8720A with MII.

[Kjelt]

Investigate properly which PHY to use (10Mb/100Mb should be enough for a F4), search the net for problems, and choose something new but well tested.
Choose an IP stack that supports IPv6 and also check for problems. Don't plan it will work at once or twice, plan weeks extra for software faultfinding and solutions.

[nctnico]

Investigate properly which PHY to use (10Mb/100Mb should be enough for a F4), search the net for problems, and choose something new but well tested.
Choose an IP stack that supports IPv6 and also check for problems. Don't plan it will work at once or twice, plan weeks extra for software faultfinding and solutions.

The first/last time I implemented uIP (I think it is related to lwip) it took me a couple of months to iron all the bugs out and get it working smoothly (I also put a BSD sockets compatible layer on top of uIP). I also second the suggestion to consider using an RTOS for handling network traffic. If this ethernet / IP solution is for use on a module to be used by novices then the Wiznet chip is a good solution. The example projects will be small and the users can't mess up the network stack.

[Kjelt]

Recognizable, it takes way more effort than anyone who hasn't done this before imagines.
A standalone module as the Wiznet will be good enough for 90% of the applications.
Problems start when there are requirements that need some extra than you are stuck.
For instance does the Wiznet do TLS1.2, secure tfpt or other secure protocols? IPv6 support , CoAP? Can it support multicast UDP messages (subscriptions) ?
That kind of requirements that drop in after architects start to think about some problems to solve.

[free_electron]

ehternet over SPI or any other bitbanged i/f is going to be total crap.

You want to use a CPU that has the MAC on-board. wiring such a thing up requires a fast 16 bit data bus , address bus and control signals.
CS8900 is an old cruft. SMSC or AMCC may have solutions but they will be 10Mbit tops with a lone 100Mbit maybe...

[djacobow]

ehternet over SPI or any other bitbanged i/f is going to be total crap.

You want to use a CPU that has the MAC on-board. wiring such a thing up requires a fast 16 bit data bus , address bus and control signals.
CS8900 is an old cruft. SMSC or AMCC may have solutions but they will be 10Mbit tops with a lone 100Mbit maybe...

Meh. There are a lot of applications where performance does not matter one iota, including just about every "internet of things" device. If your product has a 100MHz ARM core with a 256 kiB of RAM, it's unlikely it's going to generate enough data to saturate a 10Mb/s Ethernet link anyway.

What most people seem to be doing with Ethernet these days is providing some management interface like SSH, or hosting a micro-web server, or fetching JSON over a TCP socket, every single one of which can easily be supported by a SPI-connected Ethernet controller.

For a lot of apps, performance is way down on the list of requirements.

[richardman]

Meh. There are a lot of applications where performance does not matter one iota, including just about every "internet of things" device. If your product has a 100MHz ARM core with a 256 kiB of RAM, it's unlikely it's going to generate enough data to saturate a 10Mb/s Ethernet link anyway.

What most people seem to be doing with Ethernet these days is providing some management interface like SSH, or hosting a micro-web server, or fetching JSON over a TCP socket, every single one of which can easily be supported by a SPI-connected Ethernet controller.

For a lot of apps, performance is way down on the list of requirements.

Excellent points! Thanks

[westfw]

Looking at the STM32F429 right now, so actually we only need [a phy]

A chip with a built-in ethernet controller (MAC) is a different animal (although the usually-required external Phy chip is usually similar in cost to an ENCxx chip that includes MAC and Phy.)  One of the Stellaris CM3 chips had ethernet with a built-in Phy, and it had some neat tiny internet modules (http://www.element14.com/community/docs/DOC-49011/l/texas-instrument-mdl-s2e-stellaris-serial-to-ethernet-module ), but so far TI hasn't offered an  equivalent "Tiva" product. :-(

You could do a lot worse that putting some "standard" TCP/IP package on a dedicated separate ARM chip and providing an interface protocol.

One thing to watch out for is encryption.  I watched someone get told recently that an Arduino with Internet connectivity can't send eMail, because it doesn't support the heavy-weight encryption/authentication/security protocols (TLS?), and none of the "real" mail servers will accept email from a non-secure host.

[nctnico]

One thing to watch out for is encryption.  I watched someone get told recently that an Arduino with Internet connectivity can't send eMail, because it doesn't support the heavy-weight encryption/authentication/security protocols (TLS?), and none of the "real" mail servers will accept email from a non-secure host.

That sounds a bit over the top because there are still lots of old e-mail programs in use. It could be true though when wanting to use a provider's e-mail server from outside their network. That typically requires a login + password so could also require encryption.

[mrpackethead]

The new PICMZ32 chips have hardware encryption on them, and work pretty well, for a $5 micro. attached to a PHY i can generate 30-35Mb of meaningful data.

[Kjelt]

Concerning the datarate, most embedded controllers bottleneck will be the SRAM, most IP stacks reserve about 32kB for the buffers.
Even at 10Mb/s that means you have to handle 1,25MB so about 25 ms to handle a 32kB buffer (read out and process).
Lets face it most of these small IP controllers are not meant to be strained to handle this kind of traffic, if you need this get a embedded linux board.
These embedded boards are meant to receive COAP commands and respond to that on occasional basis.

[free_electron]

ehternet over SPI or any other bitbanged i/f is going to be total crap.

You want to use a CPU that has the MAC on-board. wiring such a thing up requires a fast 16 bit data bus , address bus and control signals.
CS8900 is an old cruft. SMSC or AMCC may have solutions but they will be 10Mbit tops with a lone 100Mbit maybe...

Meh. There are a lot of applications where performance does not matter one iota, including just about every "internet of things" device. If your product has a 100MHz ARM core with a 256 kiB of RAM, it's unlikely it's going to generate enough data to saturate a 10Mb/s Ethernet link anyway.

What most people seem to be doing with Ethernet these days is providing some management interface like SSH, or hosting a micro-web server, or fetching JSON over a TCP socket, every single one of which can easily be supported by a SPI-connected Ethernet controller.

For a lot of apps, performance is way down on the list of requirements.

it's not about outgoing performance. the problem is incoming data. you want to be able to receive that at the rate you are being fed. even a 10 megabit pipe can easily overload a cpu if it has to sip its data through a straw between the cpou and ethernet controller.

[nctnico]

That is not a problem. TCP/IP has inherent flow control and you'd be a fool to expect such a device to be able to cope with a lot of data. At some point the buffers are full and data will be dropped. You can say the same about having a 1Gbit device communicating with a 100Mbit ethernet device (through a switch).

[mrpackethead]

Its importnat to remember here that the choice of device is largely dictated by the application!
You dont' take a hand spade to a coal mine, and you don't dig your wifes flower garden with a 400T digger.

I use PIC32s + LAN870x's to receive around 640 multicast packets per second for lighting control data.  ( packet size is 620 bytes ).   It works just fine.     

[Scrts]

Meh. There are a lot of applications where performance does not matter one iota, including just about every "internet of things" device. If your product has a 100MHz ARM core with a 256 kiB of RAM, it's unlikely it's going to generate enough data to saturate a 10Mb/s Ethernet link anyway.

I know a project where STM32F205 does UDP/RTP video broadcasting to the IP network up to 90Mbps. The video is already MPEG-TS, but the processor does many other things too. E.g. MPEG-TS table parsing, PID filtering, table generation, etc.

On the other hand, you will always find 10/100 PHY anyway.

[westfw]

You know what's really sad?  You can probably add an OTS wireless router to your existing wireless design and wind up with a lower BOM than adding hardwired ethernet...

[richardman]

You know what's really sad?  You can probably add an OTS wireless router to your existing wireless design and wind up with a lower BOM than adding hardwired ethernet...

Not for the product I have in mind 

[bson]

That sounds a bit over the top because there are still lots of old e-mail programs in use. It could be true though when wanting to use a provider's e-mail server from outside their network. That typically requires a login + password so could also require encryption.

Just about any ESMTP server on the net these days is going to require at least STARTTLS.  And that's rapidly going away (which is a good thing) to requires TLS from the get-go.  I run my own mail server (and have since the pre-Internet uucpnet bang!address days), and even I don't allow myself to send mail without TLS... for good reason.  Any embedded device on the public Internet is definitely going to need TLS at least, and probably also HMAC for request signing.

[bson]

Kinnexa makes some nice integrated RMII PHYs, all complete with magnetics inside a somewhat oversize RJ45 jack complete with blinkenlights.  Pretty much wire it up using some HS traces and press the 'go' button.  Price: no idea, but they sure look handy.

[nctnico]

That sounds a bit over the top because there are still lots of old e-mail programs in use. It could be true though when wanting to use a provider's e-mail server from outside their network. That typically requires a login + password so could also require encryption.

Just about any ESMTP server on the net these days is going to require at least STARTTLS.  And that's rapidly going away (which is a good thing) to requires TLS from the get-go.  I run my own mail server (and have since the pre-Internet uucpnet bang!address days), and even I don't allow myself to send mail without TLS... for good reason.  Any embedded device on the public Internet is definitely going to need TLS at least, and probably also HMAC for request signing.

If you have ever tried to implement TLS on a microcontroller you would know TLS is a no-go on many microcontrollers so IoT devices need another way to secure themselves. TLS is too big and too clunky for use in a small device. I expect some kind of standard will emerge in the next few years but until then you are on your own to come with a good security scheme which fits your microcontroller.

[westfw]

TLS is a no-go on many microcontrollers so IoT devices need another way to secure themselves.

Exactly.  So probably "many microcontollers cannot send eMail", even if they otherwise support TCP/IP and SMTP.
Sure, you can use some sort of relay; but then why bother having TCP/IP/SMTP on the micro; send UDP datagrams to the relay and let it reformat.
(Presumably, this is one of the reasons that a lot of IoT things are ending up with subscription "cloud servers" that they have to do things through.)

[Kjelt]

TLS in a minimum configuration like CYASSL (WolfSSL) will cost you 20k to 30k ROM and at least 10-15k RAM(minimum config) without PKI, full package runs you over 80kB ROM and 30kB RAM.

[nctnico]

But ask yourself how effective a cut down version of TLS is. Chances are servers are configured to not accept certain (weak) encryption methods.

I'm also not convinced about being unable to send e-mail without TLS. So far I have never seen an internet provider which requires to use TLS to send e-mail from within their own network.

[Kjelt]

Agree, up to date servers should only accept the latest proven ciphers which almost all include PKI.

Personally I think an M4/M7 cortex with 256kB RAM and 1M ROM can easily handle these requirements.
Devices with 64kB RAM and lower are cumbersome to implement TLS and an IP stack, there is hardly any RAM left for the program itself   

[nctnico]

I have some hands-on experience with PolarSSL. One of the problems is that an ARM running at 72MHz will need a lot of time to process the ciphers. I have seen the device I worked on needed about 5 seconds to setup an SSL connection with a web browser.

[Kjelt]

True but that is only the PKI handshake part which is once per connection (authentication and session key). After that the parties switch to symmetrical cryptography with the session key and that is way faster, with HW acceleration we talk about 100's Mbits per second  without HW acc. a few Mbits / s

[richardman]

We are looking at >100MHz F429 with 512M RAM, so I think hardware would be "minimally sufficient".

[Kjelt]

512MB of RAM? External dram then?

[bson]

TLS is a no-go on many microcontrollers so IoT devices need another way to secure themselves.

Exactly.  So probably "many microcontollers cannot send eMail", even if they otherwise support TCP/IP and SMTP.
Sure, you can use some sort of relay; but then why bother having TCP/IP/SMTP on the micro; send UDP datagrams to the relay and let it reformat.
(Presumably, this is one of the reasons that a lot of IoT things are ending up with subscription "cloud servers" that they have to do things through.)

You don't want connected devices to send email anyway.  Email is simply not a good notification mechanism.  You'll want to stand up or use an existing rendez-vous infrastructure and do something like http post an hmac-signed json dict.  (Or implement jsonrpc, which is what I did for samba.tv's connected device middleware.)

[richardman]

512MB of RAM? External dram then?

Yes

[westfw]

Hmm.  thinking slightly outside-the box:  has anyone tried using a microcontroller USB Host port and one of the single-chip USB/Ethernet chips?  Lots less PCB complexity than a even an RMII interface to a phy.  On the minus side, more SW complexity and somewhat less performance (but possibly USEFUL SW complexity.  USB Host stack, mostly-similar chips that include USB HUB...)  (This is how raspberry Pi does ethernet.   This is how MANY laptops do WiFi...)

[djacobow]

512MB of RAM? External dram then?

Ah, with the external memory and a real eth i/f we're getting well into the realm of being a "real computer."  Not what I was imagining when you first posted at all.

Curious how this compares, cost-wise with going with one of the ARM SoC kitchen sink "application processors" with MMU, on-board DRAM, etc. There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

[nctnico]

Hmm.  thinking slightly outside-the box:  has anyone tried using a microcontroller USB Host port and one of the single-chip USB/Ethernet chips?

Not with a microcontroller but I did that in one of my SoC designs in which the SoC didn't have ethernet (=MAC) build in.

[Kjelt]

There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

To get it up and running there is little fuss, to keep it updated and running automa(g)(t)ically at the customer and guarantee 10 years of support there can be a lot of fuss.

[djacobow]

There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

To get it up and running there is little fuss, to keep it updated and running automa(g)(t)ically at the customer and guarantee 10 years of support there can be a lot of fuss.

Were you planning on keeping your 100% hard-coded firmware updated as well? Linux can be a pain in the ass, I get it, but some of the things that are a pain are things that embedded folks just skip altogether. You make a connected device you have opened yourself to vulnerability, and it will need to be maintain, full stop. Now, you could make a good argument that less code means less bugs, with which I agree. But this person is heading in the direction of a full networking stack, modern and complete crypto, etc. Might be less code to do without Linux baggage, but I slight prefer my odds with the well-trodden drivers and OS.

I think most of the work with embedding linux is creating your own 'distro' with every single thing you do not need stripped out. That's a boatload of work.

I've worked in the IoT space and lived the pain. My general sense is that the solutions right now for developers suck. You basically can turn over the keys to a platform company (and pay in perpetuity and be limited to what they thought was a worth doing), roll your own platform, or throw a proper OS on there. I don't like any of those options. And those are the same options and essentially the same complexity if you want to flip a few bits occasionally over the cloud, or you want to complex interactions and streaming Gb of data. Rolling your own, by the way, I find particularly unpleasant for a startup because you end up investing big time and money in "generic" plumbing that has nothing to do with your company's mission.

I think the option I would like to see is an OS _for_ IoT. Cut down, minimal, and, if it implements simpler (but still secure) network protocols, I'm all for that. I'll be happy to do the server-side work to talk.

[bson]

Curious how this compares, cost-wise with going with one of the ARM SoC kitchen sink "application processors" with MMU, on-board DRAM, etc. There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

To run Linux out of external DRAM it's paramount to have on-chip caches.  Far from all processors have this.  Without caching the CPU clock is completely irrelevant past 10MHz or so and the whole thing will run at the speed of the DRAM, which is slooooow.

[Kjelt]

Were you planning on keeping your 100% hard-coded firmware updated as well? Linux can be a pain in the ass, I get it, but some of the things that are a pain are things that embedded folks just skip altogether. You make a connected device you have opened yourself to vulnerability, and it will need to be maintain, full stop. Now, you could make a good argument that less code means less bugs, with which I agree. But this person is heading in the direction of a full networking stack, modern and complete crypto, etc. Might be less code to do without Linux baggage, but I slight prefer my odds with the well-trodden drivers and OS.

I agree Linux is the better choice, however I just wanted to make the point that IF it is connected to the internet, and has open ports, any decent pentester can figure out within 1/2 hour which OS is running exactly, which SSL suite and which open source modules etc. etc. Look up in the vulnerability database all the vulnerabilities in those modules and if not updated owns that device and can use it for what it wants. Now making your own version of an OS/SSL stack is also not an option since although it would take an attacker much more time it actually would come down to security by obscurity.
However if you have a very simple device with no users with higher privileges, no software that can be modified etc. etc. you can become more safe than with Linux.
So actually the only secure thing you can do with any embedded Linux networked device that is not going to be monitored and updated is keep it away from the bad bad internet, close all ports and use other secure channels to communicate with it (a decent server with good firewall that is maintained and updated).
IoT: the Internet of Threads 

[djacobow]

I agree Linux is the better choice, however I just wanted to make the point that IF it is connected to the internet, and has open ports, any decent pentester can figure out within 1/2 hour which OS is running exactly, which SSL suite and which open source modules etc. etc. Look up in the vulnerability database all the vulnerabilities in those modules and if not updated owns that device and can use it for what it wants. Now making your own version of an OS/SSL stack is also not an option since although it would take an attacker much more time it actually would come down to security by obscurity.
However if you have a very simple device with no users with higher privileges, no software that can be modified etc. etc. you can become more safe than with Linux.
So actually the only secure thing you can do with any embedded Linux networked device that is not going to be monitored and updated is keep it away from the bad bad internet, close all ports and use other secure channels to communicate with it (a decent server with good firewall that is maintained and updated).
IoT: the Internet of Threads 

Did you mean Internet of Threats? 

Agree with everything you said. In general, if you have open ports, they will be attacked. You need a way to maintain the device. It's not a trivial problem, and I think most people getting into this space are not taking seriously enough. They think their device is not important enough to be an interesting victim, or they'll fix it when they have to, etc. It's an epic mess in the making.

[Kjelt]

Yes that is what I meant  excuse my dutchenglish.
Oh that little constrained IoT device might not be so interesting itself but the (home/business)network it is attached to might contain more interesting targets, if that little device is the easy way in ....... 

[nctnico]

Yes that is what I meant  excuse my dutchenglish.
Oh that little constrained IoT device might not be so interesting itself but the (home/business)network it is attached to might contain more interesting targets, if that little device is the easy way in ....... 

Now you are assuming an IoT device is connected to internet. The fact is that most network devices are not connected to internet directly so the chance of a device getting hacked is (virtually) zero. If you can access a device from internet it usually is through a central server so they can charge subscription money. The IoT device will use a 'phone home' scheme to contact a pre determined server. There is not much you can do to hack such a device. The weakest points in such a setup are the user application and the central server.

[djacobow]

Now you are assuming an IoT device is connected to internet. The fact is that most network devices are not connected to internet directly so the chance of a device getting hacked is (virtually) zero. If you can access a device from internet it usually is through a central server so they can charge subscription money. The IoT device will use a 'phone home' scheme to contact a pre determined server. There is not much you can do to hack such a device. The weakest points in such a setup are the user application and the central server.

Even if the device is always the driver it can be MITM'd if there is a weakness in the protocols or key exchange. And even if it can't be hacked to Do Something Bad, it can be snooped.

[Kjelt]

Now you are assuming an IoT device is connected to internet. The fact is that most network devices are not connected to internet directly so the chance of a device getting hacked is (virtually) zero.

For businesses yes, if their IT dept. is worth something they probably can keep it safe (although even the DoD in the US was hacked this year) and if their IT dept. has some balls they forbid cheap IoT devices on their network 
For home IoT devices, the nightmare is about to start.
I have read too much horrorstories to trust any commercial cheap device on my network. The hardest are that 40% of the routers are compromised in the factory or have known vulnerabilities. The same routers that should keep the bad guys out in many homes.
The easiest and stupidest example, heard about upnp? You might not even know what your router and new (NAS or external hdd) device are doing automatically behind your back opening ports because of some stupid commercial upnp protocol that both router and device have. And the funniest part is, no normal computer user knows even whats going on.
But then even normal PC's have become extremely vulnerable.
The PC user self clicking on a malware invested picture/pdf they find in their email or daily newspage.
And frankly it is not even the users fault, it is the software morons that instead of making webapplications and scripting safe they allow an outside script to take over your OS and computer 
Who thought of that? To allow a script from a webpage to be allowed to do anything with the OS or hardware. Next PC is going to have a VM and Sandboxie and still need to make backups every month 
Oh well, maybe my job makes me paranoid but I think it is getting much worse before it is getting somewhat better, all signs indicate that the IoT devices revolution when it starts with hundreds of million of connected devices might be the end of a workable internet, I hate to be right this time.

[nctnico]

Now you are assuming an IoT device is connected to internet. The fact is that most network devices are not connected to internet directly so the chance of a device getting hacked is (virtually) zero.

For businesses yes, if their IT dept. is worth something they probably can keep it safe (although even the DoD in the US was hacked this year) and if their IT dept. has some balls they forbid cheap IoT devices on their network 
For home IoT devices, the nightmare is about to start.
I have read too much horrorstories to trust any commercial cheap device on my network. The hardest are that 40% of the routers are compromised in the factory or have known vulnerabilities.
The PC user self clicking on a malware invested picture/pdf they find in their email or daily newspage.

A router is on the frontier of internet and the average PC user can be modelled as a moron. Neither situations are a threat for an IoT device though because a user isn't installing software on an IoT device and the IoT device doesn't have a direct connection to internet. Disclaimer: god forbid people are stupid enough to give every device they have a publicly accessible IPv6 address 

[djacobow]

A router is on the frontier of internet and the average PC user can be modelled as a moron. Neither situations are a threat for an IoT device though because a user isn't installing software on an IoT device and the IoT device doesn't have a direct connection to internet. Disclaimer: god forbid people are stupid enough to give every device they have a publicly accessible IPv6 address 

The IoT device is itself a threat to the rest of your network. Let's say IoT device has facility for self-upgrade by fetching a firmware image from a trusted server. Bad guy figures out how to spoof server and provide image that the unit will see as valid. That image turns IoT device into relay node for Bad Things. Or IoT device transmits back telemetry for "debug purposes" and that telemetry just happens to include Wifi key or other interesting security bits, and that information is easy to decrypt because IoT company stupidly put their private key on the Internet or on their devices. (has happened already). Or IoT device talks through proprietary gateway, with proprietary, but lame security, which exposes passwords, etc.

Personally, I'm not sure I want IoT devices on my network. I might _prefer_ that they be on the public internet with their own IP, on the OUTside of my private/quasi-secure network.

[nctnico]

A router is on the frontier of internet and the average PC user can be modelled as a moron. Neither situations are a threat for an IoT device though because a user isn't installing software on an IoT device and the IoT device doesn't have a direct connection to internet. Disclaimer: god forbid people are stupid enough to give every device they have a publicly accessible IPv6 address 

The IoT device is itself a threat to the rest of your network. Let's say IoT device has facility for self-upgrade by fetching a firmware image from a trusted server. Bad guy figures out how to spoof server and provide image that the unit will see as valid.

Nice theory... now try to perform such a hack... This would at least require spoofing the DNS, mimicing the server, creating a valid firmware image, etc. Not worth the trouble for a device which has very little processing power or storage space.

[djacobow]

Nice theory... now try to perform such a hack... This would at least require spoofing the DNS, mimicing the server, creating a valid firmware image, etc. Not worth the trouble for a device which has very little processing power or storage space.

We'll have to agree to disagree on the feasibility of such attack vectors. I have reason to believe they can and do happen. I'll grant you, the devices are not interesting themselves, but they will probably represent the softest targets on many networks (in part _because_ they are so underpowered, their implementations have cut corners), and once compromised could ease access to more interesting parts of the network.

[Kjelt]

Disclaimer: god forbid people are stupid enough to give every device they have a publicly accessible IPv6 address 

That is already been done and actually one of the big drivers for IPv6, each and every (tiny) device gets an unique (fixed) IP address (can be spoofed ofcourse).
Sensors, thermostats, lampdrivers you name it if they are going to be IP connected they are going to have an fixed IPv6 address.

[nctnico]

Disclaimer: god forbid people are stupid enough to give every device they have a publicly accessible IPv6 address 

That is already been done and actually one of the big drivers for IPv6, each and every (tiny) device gets an unique (fixed) IP address (can be spoofed ofcourse).
Sensors, thermostats, lampdrivers you name it if they are going to be IP connected they are going to have an fixed IPv6 address.

You didn't get my sarcasm: giving every device a publicly available IP address is insanely stupid because every device will be open to all kinds of attacks. The whole IPv6 idea of giving every device it's own public IP address is based on naive technocratic thinking. The beauty of having a NAT router between devices and the internet is that the risk for device specific attacks drops to zero because the devices can't be accessed directly.

[gmb42]

Disclaimer: god forbid people are stupid enough to give every device they have a publicly accessible IPv6 address 

That is already been done and actually one of the big drivers for IPv6, each and every (tiny) device gets an unique (fixed) IP address (can be spoofed ofcourse).
Sensors, thermostats, lampdrivers you name it if they are going to be IP connected they are going to have an fixed IPv6 address.

You didn't get my sarcasm: giving every device a publicly available IP address is insanely stupid because every device will be open to all kinds of attacks. The whole IPv6 idea of giving every device it's own public IP address is based on naive technocratic thinking. The beauty of having a NAT router between devices and the internet is that the risk for device specific attacks drops to zero because the devices can't be accessed directly.

And why wouldn't your IPv6 router to the wider internet implement inbound blocking rules?  Mine does.  I still have to add a rule to permit an inbound connection to the local devices behind the router, regardless of whether it's NATted IPv4 or straight public IPv6.

In summary, it's not NAT that blocks inbound connections, but router\firewall rules.

[nctnico]

In general you don't want to depend on settings in routers for devices to work. That is a recipe for dissaster. It is unlikely that your 80 year old neighbour knows hows how to setup router rules and the service guy who is going to replace it someday will copy the settings (if that is even possible). In companies you'll find IT departments may be absent or incapable/unwilling of making the required changes. It is not unheard of that it takes 4 months to reconfigure a simple broadband router to open a port.

[gmb42]

If that's what happens by default in your "super secure" IPv4 NAT router, why should the defaults be any different in an IPv6 router?  I've not come across such a wide open IPv6 router yet.

NAT in IPv4 is not a security mechanism, it's the firewall rules that don't allow inbound connections, NATted or otherwise that do that.

[nctnico]

Lets go back to where it started: IPv6 was introduced to give every conceivable device a unique IP address so each and every device in this solar system (and beyond) could talk to eachother directly. The last decade it has become clear that such a network is a maintenance and security nightmare and therefore undesirable. If your IPv6 devices are behind a router which blocks incoming connections then they are isolated from the internet just like IPv4 devices would be.

[Electro Fan]

What's the:

1. Lowest cost finished product that that supports Ethernet all the way out to a RJ45 jack?
2. Lowest cost dev platform/board/SoC/whatever that supports Ethernet all the way out to a RJ45 jack?

[westfw]

1. Lowest cost finished product that that supports Ethernet all the way out to a RJ45 jack?

Probably last years model of some wireless router; the one that doesn't do XXX, where XXX is the latest must-have feature (5GHz, Tri-band, quad-stream, ...)  Under $15 from reputable dealers (newegg)

2. Lowest cost dev platform/board/SoC/whatever that supports Ethernet all the way out to a RJ45 jack?

A much harder question, and much of what this thread had been about.  There's a big difference between a PIC/ENCJ combo barely able to communicate with raw ethernet packets, and a linux sbc capable of handling the latest secure internet protocols "in the os."  The "TI connected launchpad" is probably a good candidate.  Then there's that gaggle of ever-cheaper unix systems (raspberry pi, et al) (although they seem to be ditching ethernet in favor of wireless.  Go figure, what with wireless "modules" being cheaper than an RJ45 w/magnetics :-( )

[MagicSmoker]

Looking at the STM32F429 right now, so actually we only need something like a Microchip LAN8720A with MII.

This thread has veered off into the weeds, but for what it's worth, I've had an excellent experience with the LAN8720A PHY connected via RMII to an NXP ARM with a MAC. We use FreeRTOS/OpenRTOS and uIP for the TCP/IP stack. The RTOS worked right out of the box, so to speak, while uIP did require some tweaking, but not much, and it wasn't nearly as painful a process as our previous experience with a Wiznet SPI-to-Ethernet MAC/PHY combo (W5100).

Caveat: This is not something that is connected to the internet.

[richardman]

Ah, with the external memory and a real eth i/f we're getting well into the realm of being a "real computer."  Not what I was imagining when you first posted at all.

Curious how this compares, cost-wise with going with one of the ARM SoC kitchen sink "application processors" with MMU, on-board DRAM, etc. There's something to be said for being able to boot linux and access its device drivers, openssl, console access over ssh, scripting languages, etc, no fuss.

Sorry, out of the loop for a few days. You guys have been busy :-)

We have some very specific requirements in mind, and all shall be revealed probably in Jan/Feb 2016. Remember who we "are"  Currently F429+LAN8xxx something, and "lots" of external SRAM.

[Kjelt]

and "lots" of external SRAM.

Really SRAM or SDRAM? Care to share the partnr? , because wouldn't 512MB of pure SRAM skyrocket the BOM ?

[aon]

2. Lowest cost dev platform/board/SoC/whatever that supports Ethernet all the way out to a RJ45 jack?

A much harder question, and much of what this thread had been about.  There's a big difference between a PIC/ENCJ combo barely able to communicate with raw ethernet packets, and a linux sbc capable of handling the latest secure internet protocols "in the os."  The "TI connected launchpad" is probably a good candidate.  Then there's that gaggle of ever-cheaper unix systems (raspberry pi, et al) (although they seem to be ditching ethernet in favor of wireless.  Go figure, what with wireless "modules" being cheaper than an RJ45 w/magnetics :-( )

The EK-TM4C1294XL launchpad is indeed quite cheap, but when you want to buy the chip that's on it, the price is almost the same as for the whole Launchpad.

If you don't need a lot of performance or peripherals, Wiznet has their W7500(P) SoCs that bundle their TCP/IP+Ethernet stuff with a 48MHz Cortex-M0, 128k of flash and 16k of RAM at about $3/pc (the dev boards are ~$30). The P version has a built-in PHY and was just made available for order last night it seems - I think I'll wait for the European webshop or Mouser to carry them before I get mine, though.

There are some catches I've found while playing with them: they claim HW I2C support but the peripheral has bugs that render it unusable, and they've pretty much silently made their driver library use bitbang instead, and some versions of the block diagram show an RTC - the dev board has even a crystal for it, but there's no documentation for it whatsoever, possibly due to similar reasons as with I2C. Additionally, the only SWD debugging options at the moment seem to be the on-board programmer on the devboard and Keil's ULINK.

[MagicSmoker]

If you don't need a lot of performance or peripherals, Wiznet has their W7500(P) SoCs...
There are some catches I've found while playing with them: they claim HW I2C support but the peripheral has bugs that render it unusable...

The much older W5100 is quite buggy, too, and some of its (presumably firmware) problems have persisted for years. The worst one by far is that it routinely locks up and its hardware reset line can't save it.

[aon]

The much older W5100 is quite buggy, too, and some of its (presumably firmware) problems have persisted for years. The worst one by far is that it routinely locks up and its hardware reset line can't save it.

Yeah, I don't think I'd have the guts to use them in a commercial product in fear of what other issues might uncover themselves. For less serious stuff they're quite enticing tho, especially when coupled with a bargain bin chinese magjack

[nctnico]

I have looked at the newer Wiznet W5500 (IIRC) part and that seems more stable according to others. I started a thread on these chips a while ago and it looks like the power supply and reset cycle need proper attention. In case of doubt you can always put a PMOS in the power supply to the Wiznet chip so you can at least power cycle it.

[richardman]

Really SRAM or SDRAM? Care to share the partnr? , because wouldn't 512MB of pure SRAM skyrocket the BOM ?

Sorry, SDRAM.

[Kjelt]

Then you are moving towards a good solid solution like this
http://www.wiredzone.com/supermicro-servers-compact-embedded-processor-sys-e100-8q-10023744