How do I listen to UDP via WIFI instead of Ethernet?
Dear all,
I have a computer plugged to two networks: one with ethernet, one with wifi. Windows is set up so that the ethernet network is prioritary over the wifi network.
When I try and use udpsend and udpreceive, it seems I can only receive on the ip address of the ethernet network, not if something sends me information on the wifi network (the ip addresses on the wifi and on the ethernet network are different, which I guess is normal).
Is there a way to listen to the data sent on the wifi network with udpreceive?
I can send data on the wifi with udpsend, I just can't receive any...
Thank you,
Laurent
If you know the Wifi IP then surely just using that in the send? Or are you saying that doesn't work? Maybe you can use the hostname instead of IP?
Hi Luke,
Sending works fine, it's receiving that is a problem, because I cannot specify which IP address to listen to, and therefore it seems to listen to the computer's ip address on the ethernet network.
Yeah, but whatever you are sending from you can put the Wifi IP in instead? e.g. Using TouchOSC you can specify the IP you are sending to as the Wifi one instead of the Ethernet one? I guess the question is, what are you sending from?
Oh yes, I see what you meant. I have tried that already. Problem is, I'm sending via wifi using a headtracker that produce its own wifi network. So far, so good. I'm not completely sure if it's a general network limitation (I doubt it) or a limitation due to our security regulations, but it can't send data to the ip addresses of the ehternet network, probably because it's not officially authorized on the ethernet network (since I can send information from my computer to the headtracker)
I'll try and negociate with our IT department, then, it might be the best solution, but a complicated one...
Thank you Luke!
Laurent
You say it is producing its own Wifi network, do you mean it is creating an adhoc wifi network (rather than joining the existing network) which you then join on your computer ? If this is the case it is its own local connection and free from security regulations of the existing network. If you let me know the kit you are using I might be able to help, I often use OSC in a school environment with a tight network.
Hi Luke,
Yes, it's exactly that: it's a NGIMU headtracker and it's producing its own network. On this wifi network, the NGIMU ip address is 192.168.1.1 (classic I imagine) and my computer's is 192.168.1.2 (classic again).
I tried to tell the NGIMU to send either on 192.168.1.2, in which case the NGIMU software receives the information but not max, or on my computer's ip address on the network, in which case nobody seems to receive the headtracker's info anymore...
Here's my code, if it helps
Ahh, the X-io thing from the Bristol guys. So it sounds like you have followed the instructions here: https://github.com/xioTechnologies/NGIMU-MaxMSP-Example, and yes the 192.168.1.2 should be the IP used if you are connected ad-hoc. I would have thought the port is the important thing here, on the patch you have attached it is 8001, whereas on the example at the link above they are using 8000. Are you sure you have the correct receive port set up?
The fact that the NGIMU software is receiving says things are good, check the port settings are the same in Max. There may be ways to forward on to a different port in the software if its still not working, I am not sure.
Yes, I have modified the port because in the NGIMU software, it tells me the NGIMU is sending on the 8001 port and not on the 8000.
So you think I'm not doing things too stupidly wrong, then. I'll contact x-io and see what they say. I thought it was more a max msp and network issue, but maybe they have an idea about what causes the problem.
Thanks a lot!
Yeah, the only other thought I had is if the software lets you forward on the OSC it is receiving then you could send it to localhost on a different port, i.e. 127.0.0.1, I am on a Mac so I can't open the software.
Dear Luke,
Thank you very very much for your help, it showed me the problem was not from the dual network. I have just found the problem: I was running the X-IO software in the background, which prevented max from listening to the port, even if max was saying it was locked to that port. Turning the NGIMU software off before starting max solved the problem.
A huge thanks for your time and help!
Laurent
Interesting, I had considered that and ruled it out because you can use lots of 'UDPreceives' on the same port in Max. Glad you got it sorted!