Question DLL in Win7 Embeded and Win7 Pro

stulish

Well-known member
Joined
Jun 6, 2013
Messages
61
Programming Experience
3-5
Hi not sure if this is the correct forum thread for this, but i have created a DLL using Vb.net and VS2012 and it works great on my development PC which is Win 7 Professional. The DLL receives Packets over multicast UDP and then reassembles the data and sends acknowledgements back over the network.

This all worked great while developing, i went and installed the app on the system it is to be used on which is a windows 7 embedded system but nothing works, its as it if cant see the data.

I used wireshark to ensure the packets hadn't been stopped by security policies or the firewall and i could see the data arriving in wireshark.

Does anyone have any idea where to look or what to test for, i think there is some driver somewhere that isn't the same in embedded compared to professional, also has anyone else experienced anything like this??


Thanks

Stu
 

Herman

Well-known member
Joined
Oct 18, 2011
Messages
882
Location
Montreal, QC, CA
Programming Experience
10+
Windows Embedded Standard only has .NET 3.5 support, so try making sure you are targetting that framework just in case.
 

stulish

Well-known member
Joined
Jun 6, 2013
Messages
61
Programming Experience
3-5
Thanks Herman,

I will give that a go i used .NET 4.0 but there is nothing groundbreaking in the code so it should recompile easily enough

Stu
 

stulish

Well-known member
Joined
Jun 6, 2013
Messages
61
Programming Experience
3-5
Hi Herman,

Just to let you know, i recompiled at .NET 3.5 and it worked straight away, so thanks for you help i could have seen myself spending hours pulling my hair out :)

Stu
 

stulish

Well-known member
Joined
Jun 6, 2013
Messages
61
Programming Experience
3-5
I spoke too soon,

The problem is back so the compiling with dot net 3.5 wasn't the problem.

The WSE7 system i am using the DLL in has 4 NIC's fitted and having looked on the net this can cause problems, i have pasted the code below that sets up the socket:

Code:
 [COLOR=#a31515][/COLOR]
        _rxEndpoint = [COLOR=blue]New[/COLOR] [COLOR=#2b91af]IPEndPoint[/COLOR](_NICIPaddress, _MulticastPort)
        _rx.Client.SetSocketOption([COLOR=#2b91af]SocketOptionLevel[/COLOR].Socket, [COLOR=#2b91af]SocketOptionName[/COLOR].ReuseAddress, [COLOR=blue]True[/COLOR])
        _rx.ExclusiveAddressUse = [COLOR=blue]False[/COLOR]
        _rx.Client.ReceiveTimeout = 15000
        _rx.Ttl = _tTl
        _rx.Client.Bind(_rxEndpoint)
        _rx.JoinMulticastGroup(_MulticastIP)
        ListenThread.Start()
        LastGoodImageSave = [COLOR=#2b91af]DateTime[/COLOR].Now
        LastImageSave = [COLOR=#2b91af]DateTime[/COLOR].Now
        Timer_SaveImageCheck.Interval = 1000
        Timer_SaveImageCheck.Enabled = [COLOR=blue]True[/COLOR]
        _isCapturing = [COLOR=blue]True[/COLOR]
I read on the net the following:

from: How do I re-open the Visual Studio Immediate Window? - Stack Overflow
Mike G Reply:
I had the same issue on a windows failover cluster... Multiple nics....
I ended up opening a case with Micorsoft as I thought it was an OS issue.
It wasn't.
You need to specify the IP of the interface you whant to use to create a IPEndpoint. THen use that endpoint when creating the socket instead of IPAddress.any
That solved the problem for me.
Hope it helps even if it is late.

Dave's Reply:
Mike G is correct. One of the constructors for the UDPClient class takes an IPEndPoint as an argument. If the IPEndPoint is set to the IP address of a local interface, then that is the interface that the UDPClient and underlying socket will use so yes, you can have two UDP clients bound to the same port on a a machine as long as they are on seperate local IP interfaces (i.e. multi-homed or multi-NIC).
so as you see from the code above i set the IPEndPoint to the NIC Address (_NICIPaddress), in my case the NIC IP address is 172.16.0.25, rather than IPAddress.Any

The network cards IP addresses are set as below:

Cable IdentNetwork ConnectionIP Address
1To Switch 1172.16.0.25
2To Switch 2192.168.2.19
4Data Download192.168.0.4
3Expansion192.168.1.4


The PC sending the UDP Data has an IP of 172.16.0.42 and this is connected via network Switch 1 to the NIC with IP 172.16.0.25.

Hopefully what i have done makes sense, if i have missed any infor that would be useful let me know.

Finally i found on the WSE7 system if i disconnect the network cables from all other NIC then the app starts recieving the packets ok, and then if i plug the network cables back in the app keeps receiveing the packets, until i restart the system.

My questions are as follows:

Has anyone else experienced something like this?

Does anyone know a way to get it working?

And have i implemented it correctly?

Thanks for any advice/help.

Stu
 
Last edited:

stulish

Well-known member
Joined
Jun 6, 2013
Messages
61
Programming Experience
3-5
Fixed At Last - I hope

I think i have cracked it and it is really simple, i just added the NIC IP address to the JoinMulticastGroup and it seems to work everytime now:

Code:
        _rx.JoinMulticastGroup(_MulticastIP,NICIPaddress)
 

JohnH

VB.NET Forum Moderator
Staff member
Joined
Dec 17, 2005
Messages
15,383
Location
Norway
Programming Experience
10+
I think i have cracked it and it is really simple, i just added the NIC IP address to the JoinMulticastGroup and it seems to work everytime now:

Code:
        _rx.JoinMulticastGroup(_MulticastIP,NICIPaddress)
Good find, it is not documented for JoinMulticastGroup method, but it is at a lower level code, although it is a clue that there exist an overload of the method has a local ip parameter.
I had a look at source code for that method and found that it does Client.SetSocketOption with AddMembership and a MulticastOption with only the multicast ip (local address is here set to IPAddress.Any). And here you can find the "small print": MulticastOption Constructor (IPAddress) (System.Net.Sockets)
For machines with multiple network cards, do not use this constructor. Use the constructor that takes a group and a local IP address.
So when you use the JoinMulticastGroup with both group ip and local ip the correct MulticastOption is also used.
 
Top Bottom