I have jsut managed to send CIFS/SMB Messages from my Cobra to my Windows 7 PC and got correct ansers.
This took a while, and I just needed to share this happy moment 
Look out for my CIFS/SMB client for NETMF in the near future.
3 Likes
Cool! Does this mean that some day we may be able to print to a networked printer, or pull files off of a server?
@ Reinhard Ostermeier - Congratulations! That is pretty impressive, CIFS support would be pretty cool.
Looking forward to see the client!
Not sure about printing. But reading/writing files is the minimum I want to support.
@ andre.marschalek, you mean for challenge/response authentification. This is one of my next points of interrest.
But maybe I start with plain text pwd (if it is accepted by server)
Generally i will support core (PC Network Program 1.0) and NT LM 0.12 dialects.
Current status is:
Basic message framing, parsing, …: done
Negotiating dialect and capabilities: done
Setup SMB session: sending done, checking response is work in progress
Authentification: i hope it works fast (I hate this security stuff)
I downloaded these specs alrerady, but thank you anyway.
For printing I see the same problems as you.
But here is a challenge for anyone who is bored:
Implement a PCL5 driver for NETMF 
I finally did it:
I made my 1st real access from Cobra to Win 7 PC via CIFS/SMB:
I have created a Directory
It’s currently using PlainText authentification, which is not the nice way, but as long as Win 7 accepts it I can focus on other functions.
1 Like
@ Reinhard Ostermeier - That is a real achievement! Well done…
@ Reinhard - Good job!! This capability will open the door for all kinds of applications like remote logging, etc. I know it’s early days, but do you have any idea of the performance?
@ jasdev - I made no performance tests so far, and knowing how many directories you can create per second would be also not very interesting
But I always Keep an eye on Performance issues, so I try not to reallocate buffers too often …
I could shoot someone:
I tried to implement the Transaction2 command, including the Transaction2_Secondary command.
But for some reason the spect tells me that the secondary command must look like this, and wireshark tells me it must look like that.
Both versions are not working at all. (And in some kind of way both versions look wrong to me)
So I decided to look how it looks like when my Win7 accesses my NAS.
Suprise supprise: The Trans2_Secondary command is never used.
It looks like as if it is simply not necessary to use Transaction commands with that much data that it needs to be splitted.
This makes it easier for me to implement, but I already spent one day to find the problem.
Now it looks like the problem is not solvable, everone knows that, and that is why no one uses the secondary command.
Tiny steps towards ‘Tiny CIFS’:
I have 2 new features:
- Enumerating files/directories
- Reading a file (at least a small one)
BTW:
I’d like your advice in some design decissions:
root Namespace: System.NET.CIFS ?
dll name: System.CIFS.dll ?
Naming at all: CIFS (as it is now) or SMB (I basically stick to the [MS-CIFS] spec)
What does SPOT stand for?
Ftp uses a mix of
Microsoft.SPOT.Net, Microsoft.SPOT.Net.Ftp and System.Net
SPOT stands for “Small Personal Objects Technology”. It’s what MS referred to NETMF as in the media.
I would suggest System.NET.CIFS (.dll and namespace).
@ Reinhard Ostermeier - I am no expert in this area, but from my understanding, I would advise against using System as the root of your namespace. The point of namespaces is to remove potential naming conflicts based on the fact that vendors will use a namespace unique to them. Typically that would be their registered domain name. Microsoft uses the System namespace so you should avoid that.
You could for example use
yourdomain.NETMF.yourlibrarynamespace.dll
If you do not have a domain, then pick something that you like that is not in obvious conflict with some other vendor in this space at least.
I used NETMF rather than NET because that seems to be the standard to distinguish between libraries for the Micro Framework vs. the desktop framework. That is of course just a suggestion, you can ignore.
Based on that, something like the following might be what I would go for
yourdomain.NETMF.CIFS
yourdomain.NETMF.Net.CIFS
yourdomain.NETMF.System.Net.CIFS
Btw. Congratulations on your progress, this is really impressive. I have never known any one that implemented CIFS. This is right up there with mIP from @ Valkyrie-MT in my view.
OK, i have some performance data now on downloading files to the EMX:
Small file with 11 Byte takes less then 0.3 sec. -> about 37 Byte/sec.
Large file with 831162 Byte takes in average 3.5 sec. (ranges from 3.3 to 3.9 sec.) -> 237475 Byte/sec. ~ 232 kByte/sec.
I made this measurement by loading 32k blocks into the same buffer all the time, so the processing overhead is minimized here.
I think that is not too bad.
To compare:
My win 7 PC loads a file from my NAS via Gigabit Ethernet with 1.6 MByte/sec.
This is 7 times faster by using a connection that is up to 10 times faster.
I can even think about some performance improovements.
Currently I send 1 resquest, wait for the data, request next block, …
When I look at what win 7 does (via WireShark) then this could be improoved.
Win 7 requests a couple of blocks without waiting for the response in the first place.
Then it reads the responses and sends new requests.
I think about a minor improovement by sending out 2 requests, receive response 1, process, send request 3, receive and process response2, …
By this the waiting time for the responses can be filled with processing (like writing the data to SD).
Great work! Can’t wait until the rest of us can start playing with it. 
You may want to read over this:
working link:
@ ianlee74, @ andre.marschalek - Thank you for the link. It was quite inspirational to me.
I think i will just use
OSRE.CIFS (.dll)