message over networks
just in case I made a big mistake…
using udpsend, udpreceive with 127.0.0.1 loopback adress… all is ok.
as soon as I want to use ip adress, it doesn’t work (here)
I have 2 computers which have to communicate.
using wireshark ethernet sniffer on the receiver, I can trace the message sent by the emitter.
but max seems to not catch these messages excepted if I use internal loopback adress (=inside the computer only)
any ideas? ways?
a big trick I missed because I’m too bad …?
is there "a kind of" full-compliance OSC message test under the hood and mine wouldn’t be standard …?
oops, the patch:
[udpreceive 192.168.0.30] —– [print received]
Check any firewall settings – I’ve had a lot of issues with macs (especially on 10.5) that are set up conservatively, and the firewall is blocking MaxMSP.
Als – give [mxj net.maxhole] a quick try (probably the help file is all you need – boot it on both computers). If you can’t get maxhole communicating then it’s probably a network setup issue, rather than a MaxMSP problem.
shutted down it, all the same.
wireshark gets messages… it means the network is ok :-(
trying to troubleshoot that… without any success :-(
Try in terminal ping 192.168.0.30 .
If it’s nothing occurs, ports aren’t fowarded, see your router config.
only a basic LAN with a 24bits mask ip range
ping is ok
For both computers ? ping computer A on your computer B and inverse…
You are in local network ? Are you in automatic ip config ?
Have you indicate the port used to your object udpreceive ? And the ip and the port to your object udpsend ?
no problem for network connectivity.
ip/port on udpsend
port on udpreceive => and this one seems to receive ONLY on the loopback
did you try maxhole? If so – you got nothing?
maxhole are multicast I guess.
it doesn’t fit with my emitter :-(
Which port ?
Post your patch, because that should work without any problem
I’m sending basic osc over udp message from one side (I’m sure of this part because I can trace it on the receiver computer with a basic eth sniffer)
one more thing, the message captured are basically osc/udp standard.
and the patch on the other side is:
----------begin_max5_patcher---------- 272.3ocqRErSDCBD8LMo+Cj47ponaLUu42gYigsftioEZJS0pa7eW5zRsY2C FixAFxadv6wCNlmIf89Aa.j2IePJDGiHBFaDQj.DPidnpVGXhfy9le+Kvl4d jcfX7dSamsxhuZk2FGKD78Tskn2asS5.fbWp2SdG4zMbG39NTWurMzvfQot3 ZXM+.9AyWUbYQB202ftnJrCUIzVMUc.cO+XzWzj3pahaRpJGmK2lV+sghGzj emNIF8y7rwZrr4OGRscnij9PE76h.k5+NC1dEOW9SYPwIYvDOnFcm8wg0Zrw IISv22Ukd8mePkqDzXCD5zD5cqHMdkWy5.ZLVlvxUtAMs9XfNaD4ty7ZdVr7 E7xnk1A -----------end_max5_patcher-----------
one more (so strange) thing:
instancing udpreceive 9999 in max seems to correctly open the port (netstat -ap UDP shows that) BUT the bind s for the 0.0.0.0 address.
nothing for 127. and for my 192.
change the port maybe… plenty of issues with 9999 apparently…
I tested a lot of ports.
when I change the port in the max object, the previous socket seems to be correctly killed (nothing appears in netstat)
all the same.
as I wrote, it is strange.
because 0.0.0.0 means, AFAIK, all the network interfaces.
so it should include listening on my 192.
I am not sure where in the network stack Wireshark operates but it may be possible that your system has a firewall that is blocking your port. It wouldn’t block a packet sent to the loopback address so I would check for a software firewall. What system are you running the server (udpreceive) on?
no firewall for sure.
I found the problem!
I had a DOUBLE persistent route to 0.0.0.0. probably my juniper network connect VPN ssl client :-(
now it is ok.
it was the problem :)
that double route gave problem to bind the port correctly (curious)
I didn’t dig much, because it wasn’t the purpose :)