28 replies to this topic

[pascal06]

Hello Netduino Community, Some information about uIP, uIP is a very small open-source TCP/IP stack written by Adam Dunkels from Swedish Institude of Computer Science. Same author as original lwIP. This stack can run also on 8 bits MCU. The official uIP web site: http://www.sics.se/~...x.php/Main_Page This site is dedicated to the first version uIP and it support IPv4. In parallel, Adam Dunkels work on a mini OS named Contiki: http://www.sics.se/contiki/ In this mini-OS, you can see a more up-to-date version of uIP stack for IPv4 and IPv6. This stack is IPv6 ready. Compare to IPv6 support on lwIP which is experimental. It doesn't support Dual Stack, so you need to choice between IPv4 and IPv6. uIP can be used without Contiki. Here is a example of porting IPv6 uIP on Arduino without Contiki using a enc28j60 chip: http://sites.google....ipv6ethershield A little question to Netduino Community : What's your priority regarding porting IPv6 or IPv4 ? Regarding this, one very important information: If you plan to use low-power wireless like 802.15.4, IPv6 can be a good choice because of 6lowPAN. 6lowPAN use header compression to be compatible with 802.15.4. The dream is to be able to communicate with all devices, wire and wireless, simply by using IP. IPv4 over 802.15.4 is impossible due to low MTU size of 802.15.4 frame. Pascal

[greg]

Hello Netduino Community,

Some information about uIP,

uIP is a very small open-source TCP/IP stack written by Adam Dunkels from Swedish Institude of Computer Science. Same author as original lwIP. This stack can run also on 8 bits MCU.

The official uIP web site:
http://www.sics.se/~...x.php/Main_Page

This site is dedicated to the first version uIP and it support IPv4.

In parallel, Adam Dunkels work on a mini OS named Contiki:
http://www.sics.se/contiki/

In this mini-OS, you can see a more up-to-date version of uIP stack for IPv4 and IPv6. This stack is IPv6 ready. Compare to IPv6 support on lwIP which is experimental.

It doesn't support Dual Stack, so you need to choice between IPv4 and IPv6.

uIP can be used without Contiki.

Here is a example of porting IPv6 uIP on Arduino without Contiki using a enc28j60 chip:
http://sites.google....ipv6ethershield

A little question to Netduino Community :
What's your priority regarding porting IPv6 or IPv4 ?

Regarding this, one very important information:
If you plan to use low-power wireless like 802.15.4, IPv6 can be a good choice because of 6lowPAN. 6lowPAN use header compression to be compatible with 802.15.4. The dream is to be able to communicate with all devices, wire and wireless, simply by using IP. IPv4 over 802.15.4 is impossible due to low MTU size of 802.15.4 frame.

Pascal

here in the US the push for IPv6 is low from a consumer/residential front.

Speaking as a network engineer for AT&T Mobility it's huge and we're working on it.

So for me, PERSONALLY, I only need IPv4 at home -- almost all consumer grade routers/firewalls do not support IPv6 here in the US -- the newer ones are starting to (Apple AirportExtreme for example, but since none of the ISPs support it to the consumer no one ever turns it on.

[Szymon]

Hi, Few months ago there was discussion about 802.15.4 support in .NET MF core and according to the last entry it will be included in the next release after .NET MF 4.1: http://www.netmf.com...62-a93f5d3fc110 Can anyone confirm that .NET MF is in fact working on this? And if so I wonder what will be the relationship to uIP project? Personally I'm very interested in the 6lowPAN standard, but I guess this will require appropriate hardware as well. So if Secret Labs can add member to Netduino family with built in 802.15.4 radio this will be perfect. -Szymon

[pascal06]

Hello Szymon, ATMEL provide very nice and sheeper chip for 802.15.4. I personally use AVR-RAVEN DevKit. But 802.15.4 is only for layer 2. 6lowPAN is a IPv6 stack which can work over 802.15.4, because it change header of IPv6 by a compressed version. So, with 6lowPAN, you must use IPv6. What's the relation with uIP ? uIP is the smallest IPv6 stack and it's certified by "IPv6 ready". lwIP is not certified, bigger and only experimental. Now, why we need IP and why is better than other wireless technology. A good start for this reflexion would be IPSO Alliance white papers : http://ipso-alliance.org/ Hope your help, Pascal

[Szymon]

Hi Pascal, Thank you for detailed explanation. I would really love to have all devices communicate over IP. But as a short term goal with Netduino I agree that we should concentrate on the IPv4 stack first. I hope that you will manage to squeze it take less of Netduino ROM than implementation in current Netduino Plus firmware. Please keep us posted on your progress. -Szymon

[Charles]

Haven't seen anything on uIP in months - Is work still ongoing?

[Chris Walker]

Haven't seen anything on uIP in months - Is work still ongoing?

It's a pretty huge project, and I know Pascal has been hacking away at it a bit. I'm guessing that it's more long-term than short-term, but it would be very cool.

Chris

[tibel]

It's a pretty huge project, and I know Pascal has been hacking away at it a bit. I'm guessing that it's more long-term than short-term, but it would be very cool.

Chris

It seems that uIP development continues in Contiki Operating System.
http://contiki.git.s...ore/net;hb=HEAD

Would be great so see an IP stack (maybe already IPv6) on netduino with a smaller memory and flash footprint.

tibel

[hanzibal]

It's a pretty huge project, and I know Pascal has been hacking away at it a bit. I'm guessing that it's more long-term than short-term, but it would be very cool.

Chris

I've ported the uIP device driver for the Microchip ENC28J60 chip as sort of a spin off from my networked music player for the mini. It's based on code from the from ipv6EtherShield mentioned above. Would it be of any value to this project?

[Chris Walker]

Hi hanzibal, We'd definitely appreciate your contributions on a uIP port to .NET Micro Framework. Should we start a codeset for this on an online repository...and a separate forum discussion? Chris

[hanzibal]

Hi hanzibal,

We'd definitely appreciate your contributions on a uIP port to .NET Micro Framework.

Should we start a codeset for this on an online repository...and a separate forum discussion?

Chris

Hi Chris, sorry for my late response - I went straight to bed after my last post This is my first ever contribution to the open source community, apart from a BBS upload of an all x86 asssembler DOS shell extender in the mid-nineties (it's still out there btw)... so I'm not really sure how to proceed here.

Please note that I've only ported the device driver into C#, not any of the other parts of the stack. Got a little cleaning up to do before I can post the code. Hope to be able to do that tonight.

[hanzibal]

Hi Chris and others!

I've now submitted the source for my uIP driver port in my music player project thread.

It would be a great idea to start up an online open source project for the full port of the uIP TCP/IP stack. However, as I'm not very familiar on how to run such a project I'm probably not your man here.

[Stefan]

It would be a great idea to start up an online open source project for the full port of the uIP TCP/IP stack. However, as I'm not very familiar on how to run such a project I'm probably not your man here.

When I get my network board I'll test it. Managing such a "project" doesn't need to be hard. Just open a threat about the network device and a sample on this board, and you help loads of people. It's that simple

[hanzibal]

When I get my network board I'll test it. Managing such a "project" doesn't need to be hard. Just open a threat about the network device and a sample on this board, and you help loads of people. It's that simple

As for my project it would be nice with a full stack but I could settle for a far more lightweight version. For example, I'm already able to use the iPhone, iPad, iPod touch or Android as a remote for my Netduino using only the driver to receive raw ethernet packets. Check out my music player project for screenshot and video.

[Stefan]

Today I got my networking board so I'll look into it this soon (although I have a big todo list atm). bdw while reading your code I noticed you set the MAC-address, so it's not prefixed yet I suppose? I don't know if the Netduino has a unique hardware ID stored somewere, otherwise you could use that. For myself, I thought of using 00:34:38:31:31:4B:4A:35. It's the postal code of a local Mac(Donalds) address

[hanzibal]

Today I got my networking board so I'll look into it this soon (although I have a big todo list atm).
bdw while reading your code I noticed you set the MAC-address, so it's not prefixed yet I suppose?

I don't know if the Netduino has a unique hardware ID stored somewere, otherwise you could use that.
For myself, I thought of using 00:34:38:31:31:4B:4A:35. It's the postal code of a local Mac(Donalds) address

The mac is supplied as a parameter to the constructor, or at least I intended for it to be. I took the mac from my retired wifi chip and think I left it in the example code, ie in Program.cs which is not part of the driver sitting in another project.

Also, while testing I discovered som potential bugs but havn't had time to update the source but give me an hour or two.

Cool thing about McDou

Maybe sombody knows if there's a fused-in hw id in the Netduino, Chris?

[Stefan]

I know Secret Labs has it's own Mac-range: 5C:86:4A:*, but it can be dangerous to just specify a Mac-address. --offtopic-- Reminds me Medion, a computer brand, which sold a lot of PCs in the netherlands with the same Mac-address preconfigured. This became hot news when two neighbours, who bought their computers together, noticed they couldn't be online at the same time. They seemed to share the same mac-address.

[hanzibal]

I have now updated the driver souce code to version 1.0.0.2. Yeah, we should start an online open source project for the stack starting with the driver.

I know Secret Labs has it's own Mac-range: 5C:86:4A:*, but it can be dangerous to just specify a Mac-address.

--offtopic--
Reminds me Medion, a computer brand, which sold a lot of PCs in the netherlands with the same Mac-address preconfigured. This became hot news when two neighbours, who bought their computers together, noticed they couldn't be online at the same time. They seemed to share the same mac-address.

I guess correct procedure would be to apply for our own range of MAC's and then let forum members allocate from that pool. I suppose it's ok to use the MAC of some retired hardware, provided you then destroy the latter - don't you think?

[Stefan]

Using MAC-addresses from old hardware you own (but not use) can't harm a thing. The problem can only rise in two situations: - when two devices in the same network share the same mac-address - when two devices (in seperate networks) communicate to each other and share the same mac-address I'm not even surtain of the last one bdw, depends on a lot of stuff.

[Chris Walker]

- when two devices (in seperate networks) communicate to each other and share the same mac-address

MAC addresses are typically only used for local routing. They can be passed across the Internet, but generally as long as all of your local devices have unique MAC addresses you won't run into any issues.

The Netduino Pluses each come with a unique MAC ID, but the regular Netduinos do not.

We have created a set of "test" MAC addresses which you're welcome to use on Netduinos in your own network. Just be sure to use a different one on each simultaneously-connected device.

5C-86-4A-00-00-09
5C-86-4A-00-00-DA
5C-86-4A-00-00-DB
5C-86-4A-00-00-DC
5C-86-4A-00-00-DD
5C-86-4A-00-00-DE
5C-86-4A-00-00-DF

Chris