66 replies to this topic

[hanzibal]

Hi all!

Just wanted to say that I've successfully got my Netduino mini running the mIP managed tcp/ip stack written by forum member Valkyrie-MT. Fully managed means you can compile and run the stack on any .NET MF device.

The mIP tcp/ip stack is available on CodePlex. A truly impressive and great achievement by Valkyrie-MT, great work!

This is a HTTP-response from a webserver using mIP running on a Netduno mini:
 mip.JPG   98.64KB   186 downloads

mIP is written for .NET MF v4.2 so I had to make a few adjustments for it to run on v4.1. since v4.2 is not available for the mini. I also added a MIP InterfaceProfile (clever construct btw) for the mini using the pins I wired to my trusty old 10$ NIC (the ENC28J60 breakout module seen on the picture below). Since my adjustments are "unofficial" I can't post any code but as said, the full MIP is available on CodePlex.

This is my hardware configuration - it's really small and cheap:
 mip_mini.JPG   132.41KB   191 downloads
So far I've only tested the webserver example of mIP but find it to be both fast and robust even though it is fully managed and despite it is an alfa release. Again, great work by Valkyrie-MT.

[Stefan]

Wow, that's huge! Well done!

[hanzibal]

Wow, that's huge! Well done!

It's actually tiny
Again, remember the stack was written by Valkyrie-MT and not me.

[Stefan]

It's actually tiny

Again, remember the stack was written by Valkyrie-MT and not me.

Still awesome

[Fred]

Very impressive.

[Chris Walker]

Wow, Valkyrie-MT. Great stuff!

[Valkyrie-MT]

Wow, Valkyrie-MT. Great stuff!

Thanks guys. I'm really glad to see Hanzibal got it to work on another router.

Hanzibal, did it acquire an IP automatically? Did the local name resolution work? I see you used the IP address...

-Valkyrie-MT

[Valkyrie-MT]

Hanzibal, If you tell me what pins you are using for the mini, I will add a profile for the Mini into the stack. What pins are you using for these: MOSI SCK MISO INT CS RESET I know the I/Os are somewhat arbitrary, but having an enum for the Netduino Mini will allow beginners to get up and running easier. -Valkyrie-MT

[hanzibal]

Hanzibal, did it acquire an IP automatically?

I'm afraid not, when trying to use DHCP, the debugging window repeatedly printed "Setting IP Adress to " so I used a static IP instead.

Did the local name resolution work?

Surfing to http://mip didn't work if that's what you mean. But I suppose this can be a local problem with my DNS not being able to resolve the name. As I understand, mIP does not perform name resolution, rather you attempt to register the name and IP with the local DNS (i.e. router in my case) - correct?

If you tell me what pins you are using for the mini, I will add a profile for the Mini into the stack. What pins are you using for these:

I added NetduinoMini_ENC28J60 to the InterfaceProfile enum and also these lines to the Networking.Adapter.Start method:

case InterfaceProfile.NetduinoMini_ENC28J60:
    Start(MacAddress, name, SPI.SPI_module.SPI1, (Cpu.Pin)60, (Cpu.Pin)59, (Cpu.Pin)61);
    break;

The pins 60, 59 and 61 above corresponds to Pins.GPIO_PIN_6, Pins.GPIO_PIN_5 and Pins.GPIO_PIN_7 respectively on the Netduino mini. The SPI pins are fixed to pins 14-16 on the mini:
http://www.netduino....omini/specs.htm
As I gather, .NET MF Framework v4.2 is not yet available for the mini, therefore I had to modify mIP to compile for v4.1. Mainly, these mods where about changing the Extensions class since extension methods are not available in v4.1.

I see that mIP logs all kinds off different network events involving other devices on the network. Even though this can be of interest at times (when spoofing), it would be nice with an option to turn the corresponding features off for performance reasons. If I remember correctly you can apply MAC-filter(s) to the ENC28J60 so that it won't be bothered with stuff that are not really of its concern.

Also it would be nice with a construct like this to avoid Debug.Print in release mode:

public static void DBG(string msg)
{
#if DEBUG
            Debug.Print(msg);
#endif
}

[Valkyrie-MT]

Before you read all this, it might be easier to just record a trace in Wireshark of the start up and a page request from a browser and send the pcap to me via private message.

I'm afraid not, when trying to use DHCP, the debugging window repeatedly printed "Setting IP Adress to " so I used a static IP instead.

I think your router is sending a NAK in response to the DHCP request. Two things to figure this out.
1. Put a breakpoint on line 83 of DHCP.cs. If you are hitting that line, the router does not like something.
2. Run Wireshark and look for the DHCP messages. You should see something like this:

Surfing to http://mip didn't work if that's what you mean. But I suppose this can be a local problem with my DNS not being able to resolve the name. As I understand, mIP does not perform name resolution, rather you attempt to register the name and IP with the local DNS (i.e. router in my case) - correct?

Actually, I am using a newer technique that uses multicast called LLMNR. When you click go in the browser, it should try to resolve the "mip" name by sending a multicast LLMNR Name Request. The Netduino, should immediately send a LLMNR Response.

This is what it should look like:

I added NetduinoMini_ENC28J60 to the InterfaceProfile enum and also these lines to the Networking.Adapter.Start method:

case InterfaceProfile.NetduinoMini_ENC28J60:
    Start(MacAddress, name, SPI.SPI_module.SPI1, (Cpu.Pin)60, (Cpu.Pin)59, (Cpu.Pin)61);
    break;

The pins 60, 59 and 61 above corresponds to Pins.GPIO_PIN_6, Pins.GPIO_PIN_5 and Pins.GPIO_PIN_7 respectively on the Netduino mini. The SPI pins are fixed to pins 14-16 on the mini:
http://www.netduino....omini/specs.htm

Super, I'll add that to the source.

As I gather, .NET MF Framework v4.2 is not yet available for the mini, therefore I had to modify mIP to compile for v4.1.
Mainly, these mods where about changing the Extensions class since extension methods are not available in v4.1.

Good point. I'll add the extension method compatibility lines so it will work with both 4.1 and 4.2.

I see that mIP logs all kinds off different network events involving other devices on the network. Even though this can be of interest at times (when spoofing), it would be nice with an option to turn the corresponding features off for performance reasons. If I remember correctly you can apply MAC-filter(s) to the ENC28J60 so that it won't be bothered with stuff that are not really of its concern.

Yes, actually, I did set the Mac filters for Unicast, Broadcast, and directed Multicast, but I did not test to see that it is working right. It would not surprise me if it is not working right. I think it's buggy.

Also it would be nice with a construct like this to avoid Debug.Print in release mode:

public static void DBG(string msg)
{
#if DEBUG
            Debug.Print(msg);
#endif
}

Yeah, I completely agree with this, because it is a lot cleaner... I just keep hoping that the .NET MF team will add the attribute to the Print Method like this:

   [Conditional("DEBUG")]
   public static void Print(string text);

I also have my own implementation, but it is more complex and I didn't want to confuse people.

Update: Also, what model of router do you have and what OS + web browser are you running?

Thanks,
-Valkyrie-MT

[hanzibal]

I think your router is sending a NAK in response to the DHCP request. Two things to figure this out.
1. Put a breakpoint on line 83 of DHCP.cs. If you are hitting that line, the router does not like something.
2. Run Wireshark and look for the DHCP messages. You should see something like this:

Ok, I will try this when I find some time.

Actually, I am using a newer technique that uses multicast called LLMNR. When you click go in the browser, it should try to resolve the "mip" name by sending a multicast LLMNR Name Request. The Netduino, should immediately send a LLMNR Response.

Cool, I wan't aware of how this LLMNR works. I'm very impressed of the mIP feature list.

Good point. I'll add the extension method compatibility lines so it will work with both 4.1 and 4.2.

Changing the extension methods (i.e. removing the "this" modifier of the first parameter of each method of the Extension class was quick and easy. After that I had to change all the calls to the byte[] extension methods and this required some significantly more work and which was of the really tedious kind - but it was worth it to see the mini running a webserver

It might be easier to achieve 4.1 compatibility by writing some kind of wrapper class for byte[]. Don't know if C# supports casting operators (like C++ do) but that could be of good use if you should choose to make a wrapper. You probably know of better ways still.

Yes, actually, I did set the Mac filters for Unicast, Broadcast, and directed Multicast, but I did not test to see that it is working right. It would not surprise me if it is not working right. I think it's buggy.

Probably my old code not working, never tried to set any filters myself.

Update: Also, what model of router do you have and what OS + web browser are you running?

I'm using a Dlink 655 router and Google Chrome on Windows XP (SP3) running on a wired old PC. Regretfully I never tried IE.

Cheers!

[Valkyrie-MT]

Hanzibal, I will respond more thoroughly later, but I know why the name resolution isn't working... Windows XP does not support LLMNR. The good news is that NetBios over TCP should work fine and to enable it just uncomment the line to handle the packets for that. With respect to the DHCP, I have ordered a few routers to test and hopefully, I'll be able to reproduce the DHCP issue. It is probably just a variation on the DHCP message that I have not seen before... -Valkyrie-MT

[hanzibal]

No rush on my behalf. Glad you got the name res part covered. About the DHCP implementation of my router, isn't it just a drag when different manufacturers refrain from following standards. I remember the nightmare of trying to make a website run equally well on both IE and Firefox, ugh.

[Valkyrie-MT]

No rush on my behalf. Glad you got the name res part covered. About the DHCP implementation of my router, isn't it just a drag when different manufacturers refrain from following standards. I remember the nightmare of trying to make a website run equally well on both IE and Firefox, ugh.

Actually, it is more likely that I am not flexibly adhering to different interpretations of the standard.

We'll see.

-Valkyrie-MT

[Valkyrie-MT]

Hanzibal,

I just published a new version of the mIP library with a lot of changes. I have addressed all of your issues either partly or completely. Some of the Highlights are:

• Completely New Driver written from the original Microchip source, so there are no more GPL restrictions
• Cable connect disconenct works great with automatic DHCP address update
• Fixed DHCP negotiation for several routers
• Made extenstion methods compatable with .NET MF 4.1
• Used a Debug.Print command that actually is not compiled in Release mode
• Fixed a huge memory leak (that was causing it to die after 5 minutes, worked for 24 hours straight today having never failed!)
• Added some automatic recovery code (it works, but it could be better. Automatically restarts enc28j60)
• Made Netbios over TCP enabled by default (for WinXP compatability)
• Removed Reset pin because it was clear from the spec sheet that it is never necessary when using SPI
• And more...

-Valkyrie-MT

[hanzibal]

Wow, that is just too cool - don't you ever sleep man?

I can't wait to test this new version but sadly, I have to finish a project that is bugging the life out of me first. I've got a great idea for an application to use mIP and I was planning for a software watchdog to auto-reset itself every 10 minutes or so while waiting for mIP to come out of alpha, but I guess I won't need that anymore

Right now I got a lot more ideas than time and that story is getting kind of old

Even though its a little sad to see my old driver go, the joy over stability and robustness is much greater than my ego and guess the driver was a bit molested from being ported from platform to platform anyway. To think you made one almost from scratch!

Once again, great work Valkyrie-MT!

Btw, did you watch (listen to) the Youtube clip that I referred to in one of my earlier posts in this thread - isn't it powerful?

[Chris Walker]

Valkyrie-MT, You continue to impress. This will be really useful for a lot of people. I'm looking forward to testing it with my the samples of our new Ethernet go!bus module later this month. Very cool! Thanks for all your contributions to the community, Chris

[johanf]

Hi Valkyrie-MT What do I need to do to compile the 0.2 source under .Net MF 4.1? Get compile errors on "Encoding.UTF8.GetChars" when compiling under .Net 4.1 Thanks in advance. Johan

[Valkyrie-MT]

Get compile errors on "Encoding.UTF8.GetChars" when compiling under .Net 4.1

Yeah, the function overload of GetChars that I used is specific to 4.2, but it should be fairly easy to rewrite those few lines to use the GetChars method that is available in 4.1. I know Hanzibal has already done it, perhaps he can chime in with how he made it work. If he doesn't, I'll take a look at it this evening...

But, I believe that is the only remaining 4.1 incompatibility!

-Valkyrie-MT

[hanzibal]

Get compile errors on "Encoding.UTF8.GetChars" when compiling under .Net 4.1

Hi, I can't remember having that particular error - maybe it's new code that wasn't there when I compiled?

Either way, could you tell me at what line and in which file the compilation error occurs? Perhaps you can throw in a snippet covering the error too.