Your favorite 'free' embedded TCP/IP stack? - Page 1
Forum section: electronics / general

author: nctnico
author_rank: Super Contributor
timestamp: July 30, 2013, 10:28:19 pm
content: For a future project I need an embedded TCP/IP stack. I have used uiP before but I found it was quite buggy and not performing very well (especially with Windows clients). So this time I want to use something different. At the moment I have an eye on nichelite (NXP ARM devices come with a license for Nichelite) or Lwip. Any other stacks I missed? Code size isn't really important; I rather use something which is complete.

author: RABeng224
author_rank: Contributor
timestamp: July 30, 2013, 11:09:41 pm
content: I have used the Microchip TCP/IP on a few products. Works well and supports many features. Only thing is that you must use the stack on a Microchip part. I found the PIC32s to be the only real way to go. You need at least 128k of flash if you want to use WiFi.

author: free_electron
author_rank: Super Contributor
timestamp: July 30, 2013, 11:24:14 pm
content: Good luck finding a free one.They all stink (incomplete / incompatible / plain wrong / not portable). The closest working one is the one in uCOS but that is not free...if you want to get out from under the hassle : slap on a Wiznet7xxx series ethernet MAC and you are done. all TCP/IP is handled by that beast. they are cheap

author: westfw
author_rank: Super Contributor
timestamp: July 31, 2013, 12:52:16 am
content: Linux.QuotePerhaps you should describe how small you need it to be. uIP and Linux serve different needs, even if you can get either one on a playing-card sized PCB for $50...(I am coming to the depressing conclusion that Internet THINGS require a pretty significant CPU/etc, just to stand a chance of being able to fit "adequate secuity." Yeah, that probably means using a Raspberry Pi instead of a "Wiznet Ethernet Shield.")

author: nctnico
author_rank: Super Contributor
timestamp: July 31, 2013, 08:15:48 am
content: I haven't decided on an OS yet but if I'm going the OS route I think it will be FreeRtos. It depends on whether I need task scheduling or not. In the past I have implemented my own small HTTP server and client. From my experience TLS/SSL is beyond the reach of a microcontroller so I won't go that route (again).

author: SPRX
author_rank: Regular Contributor
timestamp: July 31, 2013, 09:24:25 am
content: I use Microchip TCP/IP, and is really works for me.I modified the Microchip TCP/IP and developed a Multicast based application recently, and happy with the stack architecture.

author: madires
author_rank: Super Contributor
timestamp: July 31, 2013, 10:01:13 am
content: Quote from: westfw on July 31, 2013, 12:52:16 amI assume with IPv4/IPv6 dual stack, some low level IPv6 stuff like SLAAC, daemons (http/https) and AAA (authentication, authorization and accounting) the common solution will be a gateway running Linux, e.g. Raspberry Pi, and tons of "things" interconnected by a simple bus. Otherwise each "thing" would need a powerful CPU and a OS which makes everyting expensive and large. And the use of RF modules for communication shouldn't be overdone since the ISM bands are already very crowded.

author: nctnico
author_rank: Super Contributor
timestamp: August 01, 2013, 08:23:03 am
content: I don't think a gateway is really required but instead of using TLS/SSL to make something secure you'd need to use a proprietary protocol which ensures a proper level of security.

author: Unknown
author_rank: Unknown
timestamp: August 01, 2013, 08:48:22 am
content: TLS is doable in a 32-bit micro if you just limit yourself to one set of algorithms, and don't offer the dozens of options that implementations like OpenSSL support. A proprietary protocol is not going to offer much security. Good crypto protocol are very hard: even implementations and protocols developed by companies like Google and Microsoft have flaws. A proprietary protocol has no chance of coming even close to the quality that standard protocols like TLS achieved after many years of smart people working on it and finding flaws in it. If even basic TLS is too intensive, then try at least to find a standard protocol that is simpler and cheaper.

author: cyr
author_rank: Frequent Contributor
timestamp: August 01, 2013, 08:54:25 am
content: If code size really isn't important then I would suggest eCos, with the full BSD-derived TCP/IP stack. You need something with external RAM to make that work though (couple of megs probably), not a small micro.

author: Hardcorefs
author_rank: Regular Contributor
timestamp: August 01, 2013, 09:08:53 am
content: Quote from: free_electron on July 30, 2013, 11:24:14 pmIf that nonsense was at all true.... then linux would not work....

author: Dago
author_rank: Frequent Contributor
timestamp: August 01, 2013, 11:57:33 am
content: Quote from: nctnico on August 01, 2013, 08:23:03 amI hope I'm misunderstanding but are you saying that for example ~every web banking connection is insecure because all of them use SSL and not a "proprietary protocol"?

author: madires
author_rank: Super Contributor
timestamp: August 01, 2013, 01:02:00 pm
content: Quote from: nctnico on August 01, 2013, 08:23:03 amSecurity by obscurity doesn't work!

author: free_electron
author_rank: Super Contributor
timestamp: August 01, 2013, 02:53:12 pm
content: Quote from: Hardcorefs on August 01, 2013, 09:08:53 amLinux is an operating system. TS is asking for a stack to go on an embedded processor. he aint going to be running linux on that cpu. He may not be running an operating system at all. There are plenty of network stacks out there that do not employ an operating system .In that category (network stack without OS) , with the restriction free, it is slim pickins to get one that works. The closest one i know is uCos but it is not completely free. You pay licence per install.Microchip has one but that is for their stuff only..Linux has nothing to do with this.

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2013, 02:33:44 pm
content: Quote from: madires on August 01, 2013, 01:02:00 pmA lot of people say thay but they are just parotting anarchaic hackers.First lets find out what obscurity means: it means to hide something. If we look at TLS/SSL then you'll see it will only work securely if the private key is kept secret. So TLS/SSL is security by obscurity! If you look closely at any security measure used to protect communication between two electronic devices you'll see that for it to be secure something (a key, an encryption method or both) must be hidden. So every secret communication between two electronic devices is security by obscurity.Now lets get back to the hackers. What do they really mean by saying security through obscurity doesn't work? They mean to say they don't trust profit driven companies and gouvernments to come up with encryption methods which cannot be hacked or monitored. Its a pure political statement (and a bit of a lack of trust in our engineering skills)!In an ideal world there would be infinite resources available to implement the best available encryption method. In the real world there are always technical tradeoffs. From a technical point of view you need to implement a method which is safe enough and fits within the available resources. For example: you can't run a hefty encryption algorithm in a smart-card so you have to compromise. And even with a component using weak encryption a system as a whole can still be secure. In NL they use Mifare cards as a wireless credit card for public transport. To make things worse: the credit is stored onto the cards without any encryption. The system is still secure though because the administrative back-end notices when the balance (money-in / money-out) doesn't add up.Anyway, it seems my choice is still limited to lwip (open source) and Nichelite (a commercial product for which NXP paid the license)...

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 02, 2013, 02:38:53 pm
content: No. What is meant by "security by obscurity" is when the security of the system depends on the algorithm(s) staying secret. It is OK to depend on the secrecy of keys, as long as there are no problems with your key distribution and management methods (granted that this is easier said than done).

author: madires
author_rank: Super Contributor
timestamp: August 02, 2013, 02:54:32 pm
content: Quote from: nctnico on August 02, 2013, 02:33:44 pmNo, it means that if someone claims he has "the most secure protocol" nobody is able to verify that, because nobody but the owner of the new protocol has access to the algorithm. It's like claiming a new law of physics without providing the scientific evidence and saying "trust me!". Good secure encryption is based on well known and tested methods. Too much proprietary encryption methods (= security by obscurity) were broken and proofed to be badly designed already. If a new encryption method can't be peer-reviewed by several security experts we can't trust the method. The latest example are the engine start codes for VW's (and all of their brands) cars. Current security is just a gag order to silence the security researchers

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2013, 06:13:06 pm
content: Thats parotting anarchaic hackers again... If it ain't open we can't trust it...If you go down that road you'd need to test all your food for toxins as wellIn real life you can hire 'hackers' to test the security level of your system without needing to open the protocols or releasing the specifications. VW probably bought an off-the-shelf system with the required security level (without needing a 1GHz ARM CPU in the keyfob). They just underestimated the resourcefulness of car thieves. This has nothing to do with open or closed encryption systems; its just a bad tradeoff between cost, functionality and ease of use.You can do a small experiment yourself: call a lock smith to open your door. You'll be amazed how fast he/she can pick your lock. Yet most thieves just smash in a window so a good lock even though it can be opened by any expert within severals seconds is an adequate security measure because common thieves clearly lack the skill to pick it.

author: Dago
author_rank: Frequent Contributor
timestamp: August 02, 2013, 06:36:51 pm
content: Quote from: nctnico on August 02, 2013, 06:13:06 pmThat's one hell of a hacker team if they can verify your encryption algorithm in a reasonable time scope. Maybe you could refer us to that hacker team so they could help the whole mathematician community to verify something simple like the AES encryption algorithm is safe to use? It has only been around for 16 years with open specifications and these wankers are still not sure if its safe or not! Surely a no biggie for the "hacker" team.And I have no idea why you would have to put a "1GHz ARM CPU" in the keyfob to implement a reasonable security measure (which VW did not do).But please carry on

author: Unknown
author_rank: Unknown
timestamp: August 02, 2013, 06:44:52 pm
content: Security through obscurity does not mean that you must release the specs, but that releasing the specs should not degrade the security. I.e. making the protocol proprietary will not improve security. Opening the protocol proves that you only rely on the cryptography, and for example the fact that testing 2127combinations takes a very long time, rather than some obscure but trivial to figure out fact.Add to this is that the far majority of people suck and writing secure software or protocols, and relying on standard protocols and standard implementations become a much safer bet. Look at the number of security holes that got fixed in almost any crypto protocol implementation. Are you much smarter then the people who wrote that, or does your implementation contain a similar number of bugs that you didn't find yet but a determined attacker might? Say you optimized a decryption function to make it run faster: you probably just made it vulnerable to side channel attacks.My guess is that VW (and/or their supplier) overestimated the security level of the protocol. Whoever designed it thought it did not contain any unknown weaknesses, and either there was no review or the reviewer failed to spot it.Very few thieves use lockpicking skills because the time it takes to learn, but also the time it takes to open the door. Plus you're looking quite suspicious if the neighbors come by. They rely on speed: smash a window and be gone in less then a minute before anyone notices you. This is generally not a problem for software security: you can buy a program to do the hard work, you can often work from a relatively safe location (eg. a car near the target car in the VW example), and nobody sees you interacting (unless they deployed a network intrusion system and are actually monitoring the alerts). Plus lockpicking is only easy for the cheap locks that nobody cares about (eg. random family homes). Anything containing valuables will use a more sophisticated lock that requires brute force to open without a key. For example a properly designed VW-branded electronic lock.

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2013, 08:19:51 pm
content: Quote from: alm on August 02, 2013, 06:44:52 pmThat is always an interesting discussion: just dump the received data into an encryption engine or use some kind of hand-shaking protocol around it. I like to keep things as simple as possible so I'd ditch the protocol if I can. Most of the security holes are found in surrounding protocols; the versatility of TLS/SSL is not helping much.And then again a system shouldn't rely just on encryption. Security is based on three legs (triple A): Authentification, Authorisation and Accounting. If one leg 'breaks' the system should still be secure.@Dago: 'Hackers for hire' are not going to verify AES etc but they look at how the triple A is implemented and what kind of hacks would be possible. They look at the architecture of a system and if you want also at the implementation (buffer overflows, etc).

author: Unknown
author_rank: Unknown
timestamp: August 02, 2013, 09:13:25 pm
content: The problem is that even the implementation of encryption is non-trivial. ECB is unsuitable for almost any application, for example, but is the default block cipher mode. There are also subtle issues with padding, IVs and even the responses it returns. For example, if the system distinguishes between a checksum failure and incorrect password, then this may already be enough information to break the password in a limited number of tries. And this is just the basic stuff, I'm not a cryptographer.I agree that auditing helps. That's no excuse to make authentication weaker than it needs to be, though.

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 02, 2013, 09:15:23 pm
content: Quote from: alm on August 02, 2013, 06:44:52 pmI don't know, but it might also be that a weakness was identified internally but brushed aside by management.I pointed out what I thought was a serious weakness in the crypto-based security of a product used by the public that an employer of mine developed, but the guy in charge of the product discounted my concern. So far, I think the product has not been compromised and it has been almost 20 years. Then again, the product may have been quietly improved after my involvement.

author: westfw
author_rank: Super Contributor
timestamp: August 02, 2013, 11:34:55 pm
content: QuoteActually, the "don't invent your own" missive comes from the cryptographic research community, and the people who have tried to do it. Mostly, it's "don't invent your own cryptographic algorithms", although there are plenty of cases where people have screwed up the larger aspects of security, even given a "good" cryptographic algorithm to start with. (WEP is one example, IIRC.)(been there, done that. That's why that particular algorithm is now called "obfuscation" rather than "encryption." Sigh.)OTOH, cryptographic researchers have a very high bar for "good."Stanford had/has a free online class on cryptography:https://www.coursera.org/course/cryptoI recommend it. It's pretty fierce, but even if you can't quite follow everything (like me), the descriptions of infamous failures are ... enlightening.

author: flynnjs
author_rank: Contributor
timestamp: August 03, 2013, 08:30:04 am
content: Obsure doesn't mean hidden. It means unclear.A key is hidden, completely out of the reach of an attacker (if you've got it right!)and in a good system it takes a long time for them to guess or calculate it.An obsure system is available to an attacker but just not immediately clear. It isjust a matter of time until it is understood and therefore compromised.It could be possible to have a very obsure system which could take longer tounderstand than the key discovery time for a hidden system.Whether you decide to implement your security by a proper mathamaticallyproven hard function or through obscurity is up to you and depends on:1) The resources available (developement effort, equipment size etc)2) The capability of the attacker you're trying to defend against3) Most importantly: your risk appetite towards the impact and likelihood.

author: nctnico
author_rank: Super Contributor
timestamp: August 03, 2013, 10:04:28 am
content: Quote from: flynnjs on August 03, 2013, 08:30:04 amSo we agree on 'security by obscurity doesn't work' is just FUD. If it wheren't then many security system we depend on each day (rfid tags, credit/debit cards, SIM-card etc, etc) wouldn't work.edit: BTW I never proposed to attempt to design an encryption algorithm from scratch.

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 03, 2013, 10:37:49 am
content: Quote from: nctnico on August 03, 2013, 10:04:28 amWhat do you mean “we”?There is great wisdom in the idea that a cryptosystem's algorithms should be able to withstand public scrutiny and that the only thing that should need to be secret is the key material. The more our society depends on the integrity of protocols for RFID tags, credit/debit cards, etc. the greater the incentive for an attacker to attempt to compromise them. That means more and more resources are likely to be available to attackers of these systems. If the protocols and implementations are not up to the task then we need better ones.

author: flynnjs
author_rank: Contributor
timestamp: August 03, 2013, 05:50:32 pm
content: Sorry this is getting a bit  from TCP/IP stacksQuoteI wouldn't say we agree on that. If resources are limited and thedefender has a very large risk appetite and little to lose then thereis no point in boiling the ocean.What we do agree on is the vast majority of security by obscuritytechniques are many orders of magnitude quicker to compromisethan modern good quality mathematically proven crypto system.Just like embedded engineers chose the "right" micro or FPGAfor the job a good security consultant will also suggest using theright tool for the job.Take, for example, an online game which is free to use and hasno per game revenue. The only thing to be lost through cheatingis the "fun" but it is vulnerable to interception. In this case youwouldn't insist players buy a state of the art quantum crypto boxwould you?

author: nctnico
author_rank: Super Contributor
timestamp: August 03, 2013, 07:16:04 pm
content: Quote from: flynnjs on August 03, 2013, 05:50:32 pmWell its more or less on topic because security issues are something to consider when attaching a microcontroller to a network (or maybe even to internet). Its not trivial to come up with a solution which offers adequate protection while using only a small amount of resources.QuoteLike I typed before: Many systems (rfid tags, debit cards, SIM cards, etc) use secret encryption/hashing algorithms to keep their data safe. AFAIK it took several decades before Mifare RFID cards got hacked. In order to hack a modern RFID tag you'd need to analyse the chip itself by peeling it apart layer by layer. A major disadvantage of using 'open' encryption methods is that the level of security they offer gradually diminishes with the increasing computational power provided by relatively cheap hardware. A while ago someone hired a large chunk of 'computer cloud' to crack passwords. To keep the security level up you'd need to upgrade every few years. Its a real rat race which has killed several 'good' encryption methods. And then there may be flaws in the algorithms themselves. MD5 used to be very popular until someone discovered a severe vulnerability. Nowadays the use of SHA1 is adviced. Now try and update a microcontroller application...In most cases the real problem with getting a system secure is that people don't design systems with security in mind or have little clue about how hackers work. A few years ago I examined a so called secure protocol for home automation from a major vendor. The switches already worked by simply capturing and re-playing the messages. The 'encryption' itself was nothing more than a standard CRC checksum with an adjustable seed.

author: Unknown
author_rank: Unknown
timestamp: August 03, 2013, 08:29:02 pm
content: The advantage of open protocols, like for example TLS, is that they have withstood the test of hackers and cryptographers trying to break it for years. This does not mean they won't get broken, but it is much easier to estimate a time frame for it to be broken. For example, I wouldn't use SHA-1 and especially MD-5 for an application that had to be secure for five years, but I wouldn't be as worried about using AES in a similar application. Because I can look up all known attacks against that algorithm, or ask someone in the field.A closed protocol could be broken in minutes once a determined expert starts researching it. It may have taken years from the day that RFID tag was introduced to the moment it was hacked, but how much time did the researcher spend? How does this compare to the time you would need to invest to find a flaw in say TLS, even if you were determined? The good thing about crypto is that the US government uses it a lot, so if the NSA was aware of an attack on AES, for example, then they would certainly push for new encryption standards. Or try to fix it, like in the DES S-box case.You bring up a good point about limited time that something is secure. I think a few years ago is a bit pessimistic, MD5 was certainly superseded by SHA-1 at least ten years ago. So choosing the best algorithm available in 2000 would probably have given you SHA-1, something that you wouldn't use in new designs today, but it is still usable for many applications. 3DES encryption, which has also been around for 10+ years, is still acceptable today, although you would use AES for new implementations. In general I would plan for any secure system to receive updates, however, either because of flaws in the cryptography, flaws in the implementation, or design flaws. Preferably updates via internet with a default admin password.

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 03, 2013, 10:58:41 pm
content: Quote from: nctnico on August 03, 2013, 07:16:04 pmYes, but there is a strong push from several application industries to switch to or create open standards. For example,this articlefrom a few years ago suggests dropping the proprietary NYC MTA system developed by Cubic for near field communication using smart credit cards. And IIRC Cubic systems are also in place in Washington, London, San Francisco, Brisbane, etc. How well will theopen standards based versionwork? Will it be secure? Remember, it's not just the point of transaction security that matters: the whole network and back-end for clearing transactions, and the human interfaces for straightening out the inevitable problems, matter too.

author: boz
author_rank: Regular Contributor
timestamp: August 18, 2013, 10:44:19 am
content: HiWill your device be a server or a client? Will it be TCP or can you get away with UDP?The ethernet hardware normally handles the lower layers so a embedded client just sending data over a udp socket could do this without a stack `par-say`and just a few lines of code to set an IP address and fill the transmit buffer.Also if your implementing just a client you wont be hacked because there is nothing to hack, if however you implementing a TCP server and controlling say a door lock then security may be a different matter and all the above comments are valid.

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 18, 2013, 10:59:06 am
content: Quote from: boz on August 18, 2013, 10:44:19 amIt's been a few years (almost 20) since I wrote anything for TCP/IP on bare metal, but are you remembering the ARP layer to convert IP addresses into MAC addresses? In my experience a good implementation needs timeouts, sanity checking, caching, retransmissions, etc. Are newer chips really doing all that for you? It's not as complicated as TCP, but more work than UDP. Or are you thinking to avoid all that stuff by just broadcasting it to MAC address FF:FF:FF:FF:FF:FF, and making everybody who doesn't want it filter it?

author: madires
author_rank: Super Contributor
timestamp: August 18, 2013, 12:15:31 pm
content: Quote from: boz on August 18, 2013, 10:44:19 amBroken by design! A fully agree with dfmischler. You also need an ARP cache with timeouts in case the MAC address of the other side changes. Otherwise the device would have to be power cycled. What about IP address assignment? Enter it manually with two buttons? Or should DHCP be supported? And should we start to talk about IPv6? Supporting just IPv4 is a dead end now.QuoteNever assume that a networked device won't never be hacked or exploited. If there are just a few around the world it's less likely but you can't bet on that.

author: nctnico
author_rank: Super Contributor
timestamp: August 19, 2013, 12:38:02 pm
content: Quote from: madires on August 18, 2013, 12:15:31 pmThat is if you want to go the IP route. If you want to go the minimalistic route you can define your own packet structure and use the MAC address to tell where a packet should go. Dumb switches (IOW most of the SOHO switches) don't look further than the MAC addressess anyway. The downside is that this kind of traffic can't be routed over internet (or you'd need to develop a bridge).

author: madires
author_rank: Super Contributor
timestamp: August 19, 2013, 01:13:34 pm
content: Quote from: nctnico on August 19, 2013, 12:38:02 pmOf course you can create you own layer 3 protocol (there a lot already, not just IP) but you have to do it very carefully and it would be very helpful if you know the benefits and problems of other protocols. Binding the destination to a specific MAC is quite problematic because is allows that only the system with that MAC can access the device. Ok, we could add some more MACs but how should the device determine where to send the data? If someone tries to sell that as security feature I'll answer that spoofing MACs is very simple. We could use spoofing also to fix the access problem. But does the user know how to do it? He knows how to use/access the Internet, therefore IP is the best bet.

author: dfmischler
author_rank: Frequent Contributor
timestamp: August 19, 2013, 01:21:54 pm
content: Trust me. Even if you couldn't go finduIPor whatever implementing TCP/IP from scratch is easier/better/saner than developing your own protocol suite. I've been there and done that, admittedly before IPV6,Yes, ARP is a little more complicated than just spitting UDP packets. So is DHCP. But it's worth it

author: nctnico
author_rank: Super Contributor
timestamp: August 19, 2013, 01:30:17 pm
content: The user doesn't need to be bothered with IP adresses. You can use all kinds of discovery mechanisms like a lot of network attached devices employ without the device needing an IP address. Most configuration software comes up with a list of devices it found (usually one) and asks which one the user wants to configure or use. Most users (even field engineers) are completely lost when confronted with having to fill in an IP address.

author: madires
author_rank: Super Contributor
timestamp: August 19, 2013, 02:46:46 pm
content: Quote from: nctnico on August 19, 2013, 01:30:17 pmIf the user's PC has just an IP stack (the default) and the networked device not, how should they communicate? Some devices are shipped with setup tools using the MAC based approach for the initial setup (scanning for known MACs), but an IP address has to be assigned or DHCP be enabled alternatively (often the default action). And because we can't expect users to be IP experts DHCP is enabled by default, it's the default setting for SOHO routers (acting as DHCP server) and all clients. And with IPv6 you got SLAAC (DHCP optionally).

author: nctnico
author_rank: Super Contributor
timestamp: August 19, 2013, 02:57:05 pm
content: With libpcap its pretty easy to send and receive your own packets onto the network card. I've used Uip in the past and I tested/prototyped the network side of the software on a PC. My embedded environment behaved much like a virtual machine where my Uip device had it's own MAC adress inside Windows.Only on consumer SOHO routers DHCP is enabled by default but on professional hardware it most certainly is not. For example Microsoft's crappy DNS/DHCP server simply shuts down when it sees another DHCP server on the network causing all kinds of unwanted effects. In general you don't want multiple DHCP servers on the same network. And then there is lots of other network connected hardware like printers, scanners, etc.

author: madires
author_rank: Super Contributor
timestamp: August 19, 2013, 03:29:43 pm
content: Quote from: nctnico on August 19, 2013, 02:57:05 pmAnd you end up with a custom protocol and a dedicated user space application :-)QuoteYep, if you get professional network elements you're expected to have a good understanding of IP or hired an expert. Therefore SOHO routers got the DHCP server enabled by default. Running services on Windows (servers) requires also some knowledge. BTW, it's just the DHCP server which stops. If the DNS on a domain controller (in case there's only one) would stop the AD would fall apart.