Anti-hacker security restrictions on UDP?

I was just about to try controlling some musical instruments with OSC, which uses UDP for communications. I loaded up CLUDP, and it fails to load the support library it depends on, but no error or warning message was issued until I actually tried testing the UDP channel. REGISTER-MODULE does not properly record the pathname to the library, unlike all other support libs in use. And so the FLI fails on an unregistered entry point when actually called.

So I’m wondering if all the security restrictions being imposed on the Mac might somehow have spotted the use of UDP primitives in that support library and the OS X may be prohibiting its loading? Anyone else running into UDP problems? The support library for CLUPD is stupid simple. I can’t swear to it, but I’m pretty sure it used to work a few years ago. No changes have been made to the code. But I have migrated my OS X to Sierra from Yosemite.

eh?

- DM

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: Anti-hacker security restrictions on UDP?

UDP is a supported "socket" API on OSX.

Your problem could conceivably be security related, but not about UDP 
per se.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: Anti-hacker security restrictions on UDP?

… sorry for the noise… I found the problems in CLUDP itself.

1. For support function access - you need to ensure that the dylib is compiled with extern “C” around all the utility functions in the .c and .h source files. This so that the C++ compile won’t mangle the names on you.

2. For library loading, there was an EVAL-WHEN in the main source code of CLUDP that attempts to perform a REGISTER-MODULE on its own, overriding my own ad-hoc attempt in the FLI interface code. The original source looks to be from Linux, and wanted a .so module name in the same directory as the other CLUDP code. Fix that to point to the Lib64 repository and it now works okay.

- DM

> On Oct 1, 2017, at 08:12, Christopher Stacy <cstacy@dtpq.com> wrote:
> 
> UDP is a supported "socket" API on OSX.
> 
> Your problem could conceivably be security related, but not about UDP per se.
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
> 

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: Anti-hacker security restrictions on UDP?

Oh! Thanks for pointing that out. That’s new in LW 7.0. I have been using LW for so long that I was just accustomed to its relatively few deficiencies. It just keeps getting better all the time.

And thanks for pointing to that OSC lib. UDP is always a more natural choice in real time signal processing. If things don’t get done, just drop it on the floor and continue running. TCP/IP presents the (unlikely) possibility that things will hang waiting on some comm.

Anyway, I’ll certainly have a look at that OSC lib. I’m trying to interface across the lab to a computer running a Kyma system. I would think that I must use the same protocol (IP or UDP) as the listening Pacarana box. ( http://kyma.symbolicsound.com )

- DM

On Oct 1, 2017, at 22:36, Erik Ronström <erik.ronstrom@doremir.com> wrote:

UDP is supported natively by LispWorks, at least in LW 7.0:
http://www.lispworks.com/documentation/lw70/LW/html/lw-178.htm

Of course, if you want it portable, an external module could still be preferred.

As a side note, we’ve successfully been using the OSC protocol via TCP/IP for some time (using the osc lib found at https://github.com/zzkt/osc), although UDP is perhaps a more obvious choice.

Erik

1 okt. 2017 kl. 17:26 skrev David McClain <dbm@refined-audiometrics.com>:

… sorry for the noise… I found the problems in CLUDP itself.

1. For support function access - you need to ensure that the dylib is compiled with extern “C” around all the utility functions in the .c and .h source files. This so that the C++ compile won’t mangle the names on you.

2. For library loading, there was an EVAL-WHEN in the main source code of CLUDP that attempts to perform a REGISTER-MODULE on its own, overriding my own ad-hoc attempt in the FLI interface code. The original source looks to be from Linux, and wanted a .so module name in the same directory as the other CLUDP code. Fix that to point to the Lib64 repository and it now works okay.

- DM

On Oct 1, 2017, at 08:12, Christopher Stacy <cstacy@dtpq.com> wrote:

UDP is a supported "socket" API on OSX.

Your problem could conceivably be security related, but not about UDP per se.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: Anti-hacker security restrictions on UDP?

Hey David,

Shameless plug: one fancy thing you could toy with is to discover the presence of the Pacarana using Bonjour.

Checkout my project made for LispWorks: https://github.com/tuscland/lw-dns-sd

Full documentation is in the doc directory.

It think it is quite easy to use, but ask if you have any question.

Best,

Cam

On 2 Oct 2017, at 15:41, David McClain <dbm@refined-audiometrics.com> wrote:

Oh! Thanks for pointing that out. That’s new in LW 7.0. I have been using LW for so long that I was just accustomed to its relatively few deficiencies. It just keeps getting better all the time.

And thanks for pointing to that OSC lib. UDP is always a more natural choice in real time signal processing. If things don’t get done, just drop it on the floor and continue running. TCP/IP presents the (unlikely) possibility that things will hang waiting on some comm.

Anyway, I’ll certainly have a look at that OSC lib. I’m trying to interface across the lab to a computer running a Kyma system. I would think that I must use the same protocol (IP or UDP) as the listening Pacarana box. ( http://kyma.symbolicsound.com )

- DM

On Oct 1, 2017, at 22:36, Erik Ronström <erik.ronstrom@doremir.com> wrote:

UDP is supported natively by LispWorks, at least in LW 7.0:
http://www.lispworks.com/documentation/lw70/LW/html/lw-178.htm

Of course, if you want it portable, an external module could still be preferred.

As a side note, we’ve successfully been using the OSC protocol via TCP/IP for some time (using the osc lib found at https://github.com/zzkt/osc), although UDP is perhaps a more obvious choice.

Erik

1 okt. 2017 kl. 17:26 skrev David McClain <dbm@refined-audiometrics.com>:

… sorry for the noise… I found the problems in CLUDP itself.

1. For support function access - you need to ensure that the dylib is compiled with extern “C” around all the utility functions in the .c and .h source files. This so that the C++ compile won’t mangle the names on you.

2. For library loading, there was an EVAL-WHEN in the main source code of CLUDP that attempts to perform a REGISTER-MODULE on its own, overriding my own ad-hoc attempt in the FLI interface code. The original source looks to be from Linux, and wanted a .so module name in the same directory as the other CLUDP code. Fix that to point to the Lib64 repository and it now works okay.

- DM

On Oct 1, 2017, at 08:12, Christopher Stacy <cstacy@dtpq.com> wrote:

UDP is a supported "socket" API on OSX.

Your problem could conceivably be security related, but not about UDP per se.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: Anti-hacker security restrictions on UDP?

I never heard "CLUDP", but my LispWorks-UDP project [1] was used by IRCAM in their OMAX music-related software [2], its public available OMax 3.0 sources still contains old version of my code. Whenever the specific UDP protocol contains a sequential number indicating the order of packets, my package has the ability to automatic retransmit lost UDP packets using a TCP-like RTT algorithm (this part is not ported to USOCKET [3], which provides synchronized LispWorks/UDP API).

[1] https://github.com/binghe/lispworks-udp

[2] http://repmus.ircam.fr/omax/home

[3] https://common-lisp.net/project/usocket/

On 2 October 2017 at 15:41, David McClain <dbm@refined-audiometrics.com> wrote:

Oh! Thanks for pointing that out. That’s new in LW 7.0. I have been using LW for so long that I was just accustomed to its relatively few deficiencies. It just keeps getting better all the time.

And thanks for pointing to that OSC lib. UDP is always a more natural choice in real time signal processing. If things don’t get done, just drop it on the floor and continue running. TCP/IP presents the (unlikely) possibility that things will hang waiting on some comm.

Anyway, I’ll certainly have a look at that OSC lib. I’m trying to interface across the lab to a computer running a Kyma system. I would think that I must use the same protocol (IP or UDP) as the listening Pacarana box. ( http://kyma.symbolicsound.com )

- DM

On Oct 1, 2017, at 22:36, Erik Ronström <erik.ronstrom@doremir.com> wrote:

UDP is supported natively by LispWorks, at least in LW 7.0:
http://www.lispworks.com/documentation/lw70/LW/html/lw-178.htm

Of course, if you want it portable, an external module could still be preferred.

As a side note, we’ve successfully been using the OSC protocol via TCP/IP for some time (using the osc lib found at https://github.com/zzkt/osc), although UDP is perhaps a more obvious choice.

Erik

1 okt. 2017 kl. 17:26 skrev David McClain <dbm@refined-audiometrics.com>:

… sorry for the noise… I found the problems in CLUDP itself.

1. For support function access - you need to ensure that the dylib is compiled with extern “C” around all the utility functions in the .c and .h source files. This so that the C++ compile won’t mangle the names on you.

2. For library loading, there was an EVAL-WHEN in the main source code of CLUDP that attempts to perform a REGISTER-MODULE on its own, overriding my own ad-hoc attempt in the FLI interface code. The original source looks to be from Linux, and wanted a .so module name in the same directory as the other CLUDP code. Fix that to point to the Lib64 repository and it now works okay.

- DM

On Oct 1, 2017, at 08:12, Christopher Stacy <cstacy@dtpq.com> wrote:

UDP is a supported "socket" API on OSX.

Your problem could conceivably be security related, but not about UDP per se.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Chun Tian (binghe)

University of Bologna (Italy)

Re: Anti-hacker security restrictions on UDP?

Hi binghe,

That sounds very interesting… but I’m curious about why you want to reinvent the reliability of TCP/IP using UDP? If you need this kind of reliability then why not just use TCP/IP? And how could you possibly re-transmit a lost packet unless the sender were informed of this loss - which is part of the protocol embedded in TCP/IP?

- DM

On Oct 3, 2017, at 05:43, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:

I never heard "CLUDP", but my LispWorks-UDP project [1] was used by IRCAM in their OMAX music-related software [2], its public available OMax 3.0 sources still contains old version of my code. Whenever the specific UDP protocol contains a sequential number indicating the order of packets, my package has the ability to automatic retransmit lost UDP packets using a TCP-like RTT algorithm (this part is not ported to USOCKET [3], which provides synchronized LispWorks/UDP API).

[1] https://github.com/binghe/lispworks-udp
[2] http://repmus.ircam.fr/omax/home
[3] https://common-lisp.net/project/usocket/

On 2 October 2017 at 15:41, David McClain <dbm@refined-audiometrics.com> wrote:
Oh! Thanks for pointing that out. That’s new in LW 7.0. I have been using LW for so long that I was just accustomed to its relatively few deficiencies. It just keeps getting better all the time.

And thanks for pointing to that OSC lib. UDP is always a more natural choice in real time signal processing. If things don’t get done, just drop it on the floor and continue running. TCP/IP presents the (unlikely) possibility that things will hang waiting on some comm.

Anyway, I’ll certainly have a look at that OSC lib. I’m trying to interface across the lab to a computer running a Kyma system. I would think that I must use the same protocol (IP or UDP) as the listening Pacarana box. ( http://kyma.symbolicsound.com )

- DM

On Oct 1, 2017, at 22:36, Erik Ronström <erik.ronstrom@doremir.com> wrote:

UDP is supported natively by LispWorks, at least in LW 7.0:
http://www.lispworks.com/documentation/lw70/LW/html/lw-178.htm

Of course, if you want it portable, an external module could still be preferred.

As a side note, we’ve successfully been using the OSC protocol via TCP/IP for some time (using the osc lib found at https://github.com/zzkt/osc), although UDP is perhaps a more obvious choice.

Erik

1 okt. 2017 kl. 17:26 skrev David McClain <dbm@refined-audiometrics.com>:

… sorry for the noise… I found the problems in CLUDP itself.

1. For support function access - you need to ensure that the dylib is compiled with extern “C” around all the utility functions in the ..c and .h source files. This so that the C++ compile won’t mangle the names on you.

2. For library loading, there was an EVAL-WHEN in the main source code of CLUDP that attempts to perform a REGISTER-MODULE on its own, overriding my own ad-hoc attempt in the FLI interface code. The original source looks to be from Linux, and wanted a .so module name in the same directory as the other CLUDP code. Fix that to point to the Lib64 repository and it now works okay.

- DM

On Oct 1, 2017, at 08:12, Christopher Stacy <cstacy@dtpq.com> wrote:

UDP is a supported "socket" API on OSX.

Your problem could conceivably be security related, but not about UDP per se.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

--
Chun Tian (binghe)
University of Bologna (Italy)

Re: Anti-hacker security restrictions on UDP?

… this immediately brings to mind, the “Two Generals” problem, which I wrestled with several years ago in my distributed Okeanos database system. https://en.wikipedia.org/wiki/Two_Generals%27_Problem

I wrestled with this, as must TCP/IP. I finally had to conclude that there can be no absolute reliability, that the deep problem had to be (hopefully) statistically insignificant, but that in the end there can be no alternative to manual intervention. Deep programming philosophy here…

- DM

On Oct 3, 2017, at 07:26, David McClain <dbm@refined-audiometrics.com> wrote:

Hi binghe,

That sounds very interesting… but I’m curious about why you want to reinvent the reliability of TCP/IP using UDP? If you need this kind of reliability then why not just use TCP/IP? And how could you possibly re-transmit a lost packet unless the sender were informed of this loss - which is part of the protocol embedded in TCP/IP?

- DM

On Oct 3, 2017, at 05:43, Chun Tian (binghe) <binghe.lisp@gmail.com> wrote:

I never heard "CLUDP", but my LispWorks-UDP project [1] was used by IRCAM in their OMAX music-related software [2], its public available OMax 3.0 sources still contains old version of my code. Whenever the specific UDP protocol contains a sequential number indicating the order of packets, my package has the ability to automatic retransmit lost UDP packets using a TCP-like RTT algorithm (this part is not ported to USOCKET [3], which provides synchronized LispWorks/UDP API).

[1] https://github.com/binghe/lispworks-udp
[2] http://repmus.ircam.fr/omax/home
[3] https://common-lisp.net/project/usocket/

On 2 October 2017 at 15:41, David McClain <dbm@refined-audiometrics.com> wrote:
Oh! Thanks for pointing that out. That’s new in LW 7.0. I have been using LW for so long that I was just accustomed to its relatively few deficiencies. It just keeps getting better all the time.

And thanks for pointing to that OSC lib. UDP is always a more natural choice in real time signal processing. If things don’t get done, just drop it on the floor and continue running. TCP/IP presents the (unlikely) possibility that things will hang waiting on some comm.

Anyway, I’ll certainly have a look at that OSC lib. I’m trying to interface across the lab to a computer running a Kyma system. I would think that I must use the same protocol (IP or UDP) as the listening Pacarana box. ( http://kyma.symbolicsound.com )

- DM

On Oct 1, 2017, at 22:36, Erik Ronström <erik.ronstrom@doremir.com> wrote:

UDP is supported natively by LispWorks, at least in LW 7.0:
http://www.lispworks.com/documentation/lw70/LW/html/lw-178.htm

Of course, if you want it portable, an external module could still be preferred.

As a side note, we’ve successfully been using the OSC protocol via TCP/IP for some time (using the osc lib found at https://github.com/zzkt/osc), although UDP is perhaps a more obvious choice.

Erik

1 okt. 2017 kl. 17:26 skrev David McClain <dbm@refined-audiometrics.com>:

… sorry for the noise… I found the problems in CLUDP itself.

1. For support function access - you need to ensure that the dylib is compiled with extern “C” around all the utility functions in the ..c and .h source files. This so that the C++ compile won’t mangle the names on you.

2. For library loading, there was an EVAL-WHEN in the main source code of CLUDP that attempts to perform a REGISTER-MODULE on its own, overriding my own ad-hoc attempt in the FLI interface code. The original source looks to be from Linux, and wanted a .so module name in the same directory as the other CLUDP code. Fix that to point to the Lib64 repository and it now works okay.

- DM

On Oct 1, 2017, at 08:12, Christopher Stacy <cstacy@dtpq.com> wrote:

UDP is a supported "socket" API on OSX.

Your problem could conceivably be security related, but not about UDP per se.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

--
Chun Tian (binghe)
University of Bologna (Italy)