assurance-tunnel
assurance-tunnel
assurance-tunnel
assurance-tunnel

OSC listener trouble on high Sierra



  • I had this setup whereby the iphones are sending OSC signals to Isadora and Isadora to iphones. All worked around august 2017. Now I am trying to use the same setup, and my communication is only one-way: I can send osc to iphones, but Iphones messages to Isadora are not reaching out. I can repro this with my c++ osc listener, and a node-red osc listener. The only thing I can think of is that I upgraded to high Sierra.

    Can anybody confirm that high Sierra works/does not work or requires some special permissions setup in order to receive an osc signal from another device? (Everything works fine if I send/receive the OSC signals on apps running on the same computer).

    Thanks.


  • Beta Gold

    @eight

    Silly question that you've no doubt already thought of, but what have you got your ports set to on your devices?

    (I also think it'd be good to have this information, and any other important steps for setting this up, here in case someone else searches the forum in future to solve the same issue.)

    Best wishes,

    Woland 



  • @Woland Thanks, I have set the ports on the devices, tried multiple values, all above 3000 (I know that the ports below 1000 may require special privileges). I also tried broadcasting from iphones and specifying a unique IP of my computer. 

    I just went through this tutorial on setting up TouchOSC https://support.troikatronix.c... TouchOSC's messages are not received by Isadora too. I also used Free Ping, as suggested in the tutorial, to only confirm that ping does reach the Isadora machine.


  • Beta Gold

    @eight

    This is actually very interesting to me, because I've had the opposite problem in the past; being able to send OSC from iPhones via TouchOSC to Isadora, but not from Isadora to TouchOSC. I was trying to make my controls update visually when values were changed in Isadora, but didn't delve too deep into it because it was just a "oh wouldn't it be nice" idea, not a show-critical one.

    Anyway, @bonemap might be able to help you more quickly that I could if I were to sit down and try to figure this out myself. Bonemap has posted some amazing things using OSC on the forum in the past, as well as collaborating on building custom OSC applications and hardware.

    Cheers,

    Woland



  • Hi @eight,

    @Woland said:

    @bonemap might be able to help

    Sorry, I have not installed High Sierra on any of my machines yet. I have always used the default port number for OSC into Isadora ‘1234’ and TouchOSC port number ‘9000’ - these are defaults and I have had no reason to change them.I would be checking the network settings and checking the IP addresses of each device to confirm that they are sending to the correct network ID, host and receiver IP details. The only other thing that has caught me out is the obligatory “/“ required by Isadora and any character spaces in the address strings that need to be deleted from the beginning or end of lines.

    @eight, I know you will be all over this, so you have now got me worried about moving to High Sierra!

    Regards

    Bonemap 


  • Beta Gold

    @bonemap said:

    @eight, I know you will be all over this, so you have now got me worried about moving to High Sierra!
    Regards
    Bonemap 

    Personally, this is one of the reasons why I only ever update my OS to the second most recent iteration. It allows me to never have to deal with issues caused by the OS when it's new(ish), and then by the time I do update to it, its been around so long that people have generally worked out all the kinks and quirks.


  • Tech Staff

    @Woland

    The problem why Touch OSC does not update values Isadora is sending, is a touch OSC problem. A workaround is to change the automatic generated OSC adresses to manual. You can even use the same as the automatic generated one, but it will work now. 

    Best Michel



  • Somebody wrote to me privately that my setup works fully on High Sierra, so that suspect is off the hook. I am looking at blocked ports using this approach, but am not finding anything blocking my ports yet.



  • @eight

    First thing to do: trying using a destination port for Isadora other than 1234. Try 8000 for instance. See if that helps.

    Best Wishes,
    Mark



  • @Michel

    Can you explain the TouchOSC problem you described above in more detail? Are the addresses wrong? Or?

    Best Wishes,
    Mark



  • @mark I have never used the port 1234. Instead I tried 3000, 3001, 10000 and 10001

    and just tried 8000 -- never got the signals on the computer from the phone.


  • Tech Staff

    @mark

    In TouchOSC by default the adressing of buttons or "led's" are set to automatic. This works fine if I use touch OSC to control Isadora, but if I send a value from Isadora to touch OSC to the adress that touch OSC generated automatically, touch OSC does not receive the value. If I deselect "automatic" (I then have to type the address again because touch OSC clears the address field) and type exactly the same address as touch OSC did before it finally works. In the picture below the function is that Isadora labels the buttons automatically with the movie, picture or sound file name, depending what one you have selected on the right. And on the right bottom you see a countdown in seconds how long the movie or audio file will play.


    Best Michel



  • More results of this investigation (apologies for verbosity level, but I think this maybe useful for somebody else, trying to debug a similar problem):

    1. See the state of the udp port 3001 on local machine 192.168.1.34 in question:

    eight_io-MacBook-Pro:~ eight_io$ sudo nmap -sU -p 3001 192.168.1.34

    Password:

    Starting Nmap 7.60 ( https://nmap.org ) at 2017-10-29 19:54 MSK

    Nmap scan report for 192.168.1.34

    Host is up.

    PORT     STATE         SERVICE

    3001/udp open|filtered unknown

    Nmap done: 1 IP address (1 host up) scanned in 2.42 seconds

    eight_io-MacBook-Pro:~ eight_io$ 

    It seems that 3001 is open, but filtered, perhaps by a firewall -- it's inconclusive message, meaning more digging must be done

    Here goes more digging:

    On problematic machine, run the following

    sudo tcpdump -A 'udp and port 3001'

    and then send the osc message to the latter machine. Once the messages start being sent I get the following output of the tcpdump locally:

    eight_io-MacBook-Pro:~ eight_io$ sudo tcpdump -A 'udp and port 3001'

    tcpdump: data link type PKTAP

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

    listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes

    19:46:26.404641 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:27.326753 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:29.271750 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..pz...@.=....$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:30.297793 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p'|..@..5...$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:31.217488 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:32.242078 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:33.265481 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@.+'...$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:33.982378 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 92

    ..............E..x....@......$....'....d../devicestate/1..,sss....background..8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:34.187973 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p:B..@.~o...$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:35.211226 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p#(..@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:36.235224 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:37.259201 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p.;..@..u...$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:38.283181 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:39.307169 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:40.229788 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..pkr..@.M?...$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:41.256772 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..pL...@.l....$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:42.174611 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 92

    ..............E..xqq..@.G8...$....'....d../devicestate/1..,sss....foreground..8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:43.301371 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p.1..@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:44.251092 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@..!...$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    19:46:45.348958 IP 192.168.1.36.ndmp > broadcasthost.redwood-broker: UDP, length 84

    ..............E..p....@......$....'....\../location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36....

    ^C

    20 packets captured

    47 packets received by filter

    0 packets dropped by kernel

    /location/1.,sss....NONE....8508E811-8FC5-4D73-9B73-994EBB74B865....192.168.1.36 corresponds exactly to the OSC message sent by iphone, which contains three values: a string "NONE", a string "8508E811-8FC5-4D73-9B73-994EBB74B865" and device's IP address 192.168.1.36




  • @eight OK, in view of the approaching tech, after trying to set iptables, debugging using different unix tools, I reformatted my macbook pro, and now everything works. Still have no idea what happened.


  • Tech Staff

    @eight
    Glad you got it working. Sometimes you just have to start fresh I guess.


Log in to reply
 

Looks like your connection to TroikaTronix Community Forum was lost, please wait while we try to reconnect.