Is there a way to read and write raw ethernet packets on the Fez Cobra?
Check this article for .Net:
It should be applicable with few changes for MF as well.
Close but no cigar. Sockets in MF as least the way it is ported for that board in 4.1 does not work in RAW mode. It just raises an exception.
But since there is a way to access low level functions, I was wondering how to read the raw stream off the interface.
I suppose your solution would have worked nicely if sockets worked in raw mode.
What I like about MF is that the source code is available. You can get the current implementation of any class and tweak it any way you want. I would try that with Socket class.
Best way to get real raw data is to add ENC28J60 chip on SPI and then you have full and direct control.
@ Gus: I might have to do that but I’m not crazy about the idea as the project hardware is already complete and tightly packed in a project box.
@ Architect: Although MF is open source, the port for this board doesn’t seem to be available so it wouldn’t be that helpful…
Do you need TCP/IP ethernet through NETMF or oyu only need raw packets? Because you can write an RLP that handles MAC and so you have full control over the packets.
I need both but not at the same time. Which would complicate things if I added the extra chip because then I’d also have to add a switch. I was originally planning on using raw sockets before I knew it didn’t work.
RLP would work just fine. I’m just not sure where to get started with it. Are there any examples or source available?
There are examples for everything, including RLP 
See tutorials please.
Well I would imagine that the functions for reading and writing raw packets on the mac already exist and are part of the port, however, I don’t know the names of these functions so I can’t call them from RLP.
Is the source code for the MF port available?
You will use RLP = you are digging into the hardware and the datasheet normally The port wouldn’t help much I think but it is not available for this particular board.
The source codes provided by the processor manufacture (NXP) are probably more helpful.
I thought the port would be helpful because it already has all of the implementation to read the raw stream and pass it to LWIP.
I thought all this stuff was open source. It’s a shame it isn’t.
I guess I’ll have to see what NXP has to offer.
Thanks
Thanks
Actually that is probably the most unhelpful link ever. Why is everything so secretive about this product? Why is the port closed source and such a secret? It really makes it hard to work with anything that you didn’t implement in the framework. Are you trying to piss your customers off?
The port is closed because GHI spent a lot of time and money producing the most stable, performant, and capable NETMF port around, and they want to be able to profit from it.
You’re not going to be able to use anything “inside” the port from “outside” in RLP. You’re going to have to do it yourself.
If you want GHI’s help (and they’d be happy to help), then you’ll need to discuss a consulting arrangement with them.
What you want to do is not the “norm”. Gus gave you two entirely valid options (ENC28J60 via SPI, and built-in MAC via RLP).
If you’re interested in an open-source port, then those are available (via Cerberus/Cerb40 and Hydra). With one of those, you can compile your own firmware and implement anything you’d like.
Well I appreciate the good work you’ve done on the port by buying a lot of hardware from you.
I chose to use the EMX module because it has ethernet on it first and foremost. If I have to use the ENC28J60 then the whole point of using that hardware doesn’t make sense anymore. Furthermore, as I said earlier, the hardware is already designed and built so reconfiguring the pins(most of them are in use) and finding a larger project box to accommodate the extra hardware is not a viable solution at this time. Also the ENC28J60 is only 10Mbps so that is a performance hit I’m not willing to accept.
RLP is possibly a viable solution, however, the code I got from the CPU manufacturer runs but makes the board unstable so it crashes. Going down that debugging rabbit hole is something I would prefer not to do.
All of these problems would have been eliminated had SocketType.Raw and ProtocolType.Raw been implemented and it was assumed that they were implemented when this hardware was designed.
So I hope you can appreciate my frustration. I like your company and it’s products and would be very happy if they could be made to work, however, if they can’t be made to work I will have to look into what other options are available.
Reply did not come from GHI. Please check for GHI name on the reply.
I’m sorry if I wasn’t clear. I’m just a fellow (happy) customer of GHI.
If you’d like those to be implemented, you should contact GHI about its consulting services.
Not a common request but will forward to our team to look into adding them.