liblo-devel Mailing List for LibLO

Here is a more complete patch that includes the previous fixes, and addresses the 'dotted-quad' issue described below.

When ENABLE_IPV6 is defined, during lo_address_resolve, we check is the hostname is a dotted-quad, and if it is, prepend ::FFFF: and use the updated hostname as an argument to getaddrinfo.

This has been tested under Mac OS X 10.6.8.
Feel free to send your suggestions.


Cam



On 30 sept. 2011, at 19:35, Camille Troillard wrote:

> Here your patch Stephen !
> It was actually easier to implement than I thought.
> 
> What this patch does:
> 
> 1. Prevent SIGPIPE on Mac OS X.
> 2. Enable dual mode IPv4 + IPv6 listening socket.
> 3. Iterate over addrinfo results.
> 
> One important caveat though:
> 
> When ENABLE_IPV6 is defined, IPv4 addresses must be mapped to IPv6. getadfrinfo does not that automatically.
> 
> For example 127.0.0.1 becomes ::FFFF:127.0.0.1.
> 
> Therefore av 4 OSC URL that looks like this:
> 
> 	osc.udp://192.168.1.82:8000
> 
> Will have to be written this way:
> 
> 	osc.udp://[::FFFF:192.168.1.82]:8000
> 
> I think that this is not a big deal.
> We can add some code that automatically detected IP address with dotted notation, and prepend the v6 mapping before passing the host string to getaddrinfo.

Here your patch Stephen !
It was actually easier to implement than I thought.

What this patch does:

1. Prevent SIGPIPE on Mac OS X.
2. Enable dual mode IPv4 + IPv6 listening socket.
3. Iterate over addrinfo results.

One important caveat though:

When ENABLE_IPV6 is defined, IPv4 addresses must be mapped to IPv6. getadfrinfo does not that automatically.

For example 127.0.0.1 becomes ::FFFF:127.0.0.1.

Therefore av 4 OSC URL that looks like this:

	osc.udp://192.168.1.82:8000

Will have to be written this way:

	osc.udp://[::FFFF:192.168.1.82]:8000

I think that this is not a big deal.
We can add some code that automatically detected IP address with dotted notation, and prepend the v6 mapping before passing the host string to getaddrinfo.


Best,
Cam


On 30 sept. 2011, at 19:25, Stephen Sinclair wrote:

> On Fri, Sep 30, 2011 at 11:56 AM, Camille Troillard
> <ca...@os...> wrote:
>> 
>> On 30 sept. 2011, at 17:46, Stephen Sinclair wrote:
>> 
>>> I see.  Since this is a mac-specific problem, apparently a solution on
>>> OS X is to set the SO_NOSIGPIPE socket option.
>>> 
>>> http://stackoverflow.com/questions/108183/how-to-prevent-sigpipes-or-handle-them-properly
>>> 
>>> I believe this would be preferable to creating a process-wide signal handler.
>> 
>> Awesome, this would be a great addition to liblo.
>> Would you like me to send a proposed implementation?
>> I guess adding this socket option would not be a lot of work.
> 
> I don't mind doing it but it's always faster if other people can
> contribute patches. :)
> 
> Steve
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Fri, Sep 30, 2011 at 11:56 AM, Camille Troillard
<ca...@os...> wrote:
>
> On 30 sept. 2011, at 17:46, Stephen Sinclair wrote:
>
>> I see.  Since this is a mac-specific problem, apparently a solution on
>> OS X is to set the SO_NOSIGPIPE socket option.
>>
>> http://stackoverflow.com/questions/108183/how-to-prevent-sigpipes-or-handle-them-properly
>>
>> I believe this would be preferable to creating a process-wide signal handler.
>
> Awesome, this would be a great addition to liblo.
> Would you like me to send a proposed implementation?
> I guess adding this socket option would not be a lot of work.

I don't mind doing it but it's always faster if other people can
contribute patches. :)

Steve

Hi,


On 28 sept. 2011, at 20:19, Camille Troillard wrote:

> On 28 sept. 2011, at 20:12, Camille Troillard wrote:
> 
>> In server.c at line 318:
>> hints.ai_family = PF_INET6;
>> 
>> 
>> In server.c at line 367:
>> 
>> #ifdef ENABLE_IPV6
>> 	unsigned int v6only_off = 0;
>> 	if (setsockopt(s->sockets[0].fd, IPPROTO_IPV6, IPV6_V6ONLY, &v6only_off, sizeof(v6only_off)) < 0) {
>>           int err = geterror();
>>           lo_throw(s, err, strerror(err), "setsockopt(IPV6_V6ONLY)");
>>           lo_server_free(s);
>>           return NULL;
>>       }
>> #endif
> 
> I think I spoke a bit too quickly.
> Doing this effectively creates a server that listens on both protocols, but for some reason I can't send OSC messages on IPv4 even though server and clients should be totally unrelated.
> 
> I will investigate a bit more on that side.

Here is what I found so far:

I still don't understand why setting an option on a server socket would have an interaction on other client sockets.  Anyway, when dealing with IPv6 settings I guess the IP stack has to run one defined "mode", and that the IPV6_V6ONLY option has a global side-effect.  I'm no socket programming expert, so please take the last statement lightly.

While running liblo with the IPV6_V6ONLY option off, I managed to receive data from IPv4 and IPv6 protocols.  But I was unable to send messages on IPv4, only IPv6.

The reason I think is because of the way getaddrinfo is used.  This call returns multiple results in the form of a linked list of addrinfo, which should be iterated until send or sendto does not fails.

I understand that this is not what happens in send.c at line 440.  Only the first item of the addrinfo structure is used.

I have not tested yet if iterating over the getaddrinfo results would solve the problem, but I have the feeling that it would be a great test for a start.

Stephen, do you have any recommendation regarding how I can implement this?
It seems the result from getaddrinfo is stored in lo_address, so I guess it should be easy to implement the iteration.


Best,
Cam

On 30 sept. 2011, at 17:46, Stephen Sinclair wrote:

> I see.  Since this is a mac-specific problem, apparently a solution on
> OS X is to set the SO_NOSIGPIPE socket option.
> 
> http://stackoverflow.com/questions/108183/how-to-prevent-sigpipes-or-handle-them-properly
> 
> I believe this would be preferable to creating a process-wide signal handler.

Awesome, this would be a great addition to liblo.
Would you like me to send a proposed implementation?
I guess adding this socket option would not be a lot of work.


Cam

Hey Stephen,


On 30 sept. 2011, at 17:42, Stephen Sinclair wrote:

> The server definitely does keep a list of sockets for incoming TCP
> connections.  I added this functionality so that connections could be
> persistent, since previously they had to be closed and opened for
> every OSC packet.

That is good and works fine.


> The address has one socket, and it may keep the socket open if it
> doesn't notice yet that the other side is closed.

This is the problem.
What is weird though, is that this client socket prevents a server socket from being opened on the same machine.


> There are often weird issues with waiting for sockets to time out.  I don't know if
> this is such a case.  I don't know whether the address keeping the
> socket open would stop a server from being able to bind that port for
> receiving.  Will have to test.

OK, thank you very much Stephen.
If you need more detail from me, please feel free to ask.


>> Consider this scenario:
>> 
>> - Client sends to Server
>> - Server is closed
>> - Client tried to lo_send -> results in an error.
>> 
>> Now I can opened a new server on the same port.
> 
> So you are saying that the address's socket is only closed when it
> tries to send and notices that there is no longer a receiver-side
> socket connected?

Yes, this is what I see.
I don't think this behavior is terribly wrong, it's just that I can't bind a server socket to the "hanging" port.


>> Does it suggest that I should get rid of the lo_address every time a message has been sent?  My application keeps track of lo_addresses and reuse them.
> 
> That is the desired behaviour, hopefully you don't need to change your
> application. :)
> 
> In the above you describe that the lo_send fails when the server was
> closed, wouldn't that imply that you only need to re-create the
> lo_address only when lo_send fails, not every time you send a message?

I don't even need to recreate a lo_address, it seems the socket is re-opened automatically by liblo, which is great.


> In any case, I will try to review the retry logic in address.c.
> Should it retry to open the connection at least once before reporting
> failure, or is failure on connection closed a reasonable behaviour?

No, unless it is required to solve the former problem.


Best,
Cam

I see.  Since this is a mac-specific problem, apparently a solution on
OS X is to set the SO_NOSIGPIPE socket option.

http://stackoverflow.com/questions/108183/how-to-prevent-sigpipes-or-handle-them-properly

I believe this would be preferable to creating a process-wide signal handler.

Steve

On Wed, Sep 28, 2011 at 1:43 PM, Camille Troillard
<ca...@os...> wrote:
> Hi dear list,
>
> I was surprised to learn that on Mac OS X, MSG_NOSIGNAL is ignored.
> The code in send.c at lines 419, 439 and 442 — typically something like
>
>        ret = send(sock, data, data_len, MSG_NOSIGNAL);
>
> — causes a SIGPIPE, ultimately crashing the application.  The solution I found, is to either block or implement a handler for the SIGPIPE signal, for example:
>
>        signal(SIGPIPE, SIG_IGN);
>
>
> All the best,
> Cam
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

On Fri, Sep 30, 2011 at 9:59 AM, Camille Troillard
<ca...@os...> wrote:
> I think I understand the problem:
>
> As long as the client has instances of lo_address and that lo_send has not encountered any error, the socket is bound in some way, which prevents any new server to be opened on the same port.

The server definitely does keep a list of sockets for incoming TCP
connections.  I added this functionality so that connections could be
persistent, since previously they had to be closed and opened for
every OSC packet.

The address has one socket, and it may keep the socket open if it
doesn't notice yet that the other side is closed.  There are often
weird issues with waiting for sockets to time out.  I don't know if
this is such a case.  I don't know whether the address keeping the
socket open would stop a server from being able to bind that port for
receiving.  Will have to test.

> Consider this scenario:
>
> - Client sends to Server
> - Server is closed
> - Client tried to lo_send -> results in an error.
>
> Now I can opened a new server on the same port.

So you are saying that the address's socket is only closed when it
tries to send and notices that there is no longer a receiver-side
socket connected?

> Does it suggest that I should get rid of the lo_address every time a message has been sent?  My application keeps track of lo_addresses and reuse them.

That is the desired behaviour, hopefully you don't need to change your
application. :)

In the above you describe that the lo_send fails when the server was
closed, wouldn't that imply that you only need to re-create the
lo_address only when lo_send fails, not every time you send a message?

In any case, I will try to review the retry logic in address.c.
Should it retry to open the connection at least once before reporting
failure, or is failure on connection closed a reasonable behaviour?

> Thanks for any pointers, I'd love to have this TCP layer working robustly.

Me too! Thanks (again) for the great bug report!

Steve

Hello,


On 28 sept. 2011, at 19:46, Camille Troillard wrote:

> I was testing TCP and found something that looks like a problem, at least, I'm not sure how to solve it.
> 
> The way to reproduce it is easy:
> - start a OSC TCP server on port 8000.
> - send messages from a client on the server.
> - close the server.
> - try start the server again, it won't because the socket is already in use.
> 
> It looks like the client got hold of the socket and the server can no more bind to it.  I think there must be a problem in Liblo, can you please tell me if you can reproduce that issue, and perhaps help me find a solution?

I think I understand the problem:

As long as the client has instances of lo_address and that lo_send has not encountered any error, the socket is bound in some way, which prevents any new server to be opened on the same port.

Consider this scenario:

- Client sends to Server
- Server is closed
- Client tried to lo_send -> results in an error.

Now I can opened a new server on the same port.

Does it suggest that I should get rid of the lo_address every time a message has been sent?  My application keeps track of lo_addresses and reuse them.

Thanks for any pointers, I'd love to have this TCP layer working robustly.


Best,
Cam

On 28 sept. 2011, at 20:12, Camille Troillard wrote:

> In server.c at line 318:
> hints.ai_family = PF_INET6;
> 
> 
> In server.c at line 367:
> 
> #ifdef ENABLE_IPV6
> 	unsigned int v6only_off = 0;
> 	if (setsockopt(s->sockets[0].fd, IPPROTO_IPV6, IPV6_V6ONLY, &v6only_off, sizeof(v6only_off)) < 0) {
>            int err = geterror();
>            lo_throw(s, err, strerror(err), "setsockopt(IPV6_V6ONLY)");
>            lo_server_free(s);
>            return NULL;
>        }
> #endif
> 
> 
> That works for me.

I think I spoke a bit too quickly.
Doing this effectively creates a server that listens on both protocols, but for some reason I can't send OSC messages on IPv4 even though server and clients should be totally unrelated.

I will investigate a bit more on that side.


Best,
Cam

Hi Stephen,


On 28 sept. 2011, at 18:39, Stephen Sinclair wrote:

> I believe the problem is actually a long-standing issue with IPv6
> support, which is that there is no way to specify that a server should
> bind to an IPv6 socket.  When you create a server with --enable-ipv6,
> it specifies PF_UNSPEC for the requested socket family.  So the
> operating system decides whether it is IPv4 or IPv6, which I guess on
> Linux defaults to IPv4.
> 
> Changing line 318 of server.c from:
> 
> hints.ai_family = PF_UNSPEC;
> 
> to
> 
> hints.ai_family = PF_INET6;

Ah yes, that solves the problem for me too.


> fixes the problem for me.  What is needed is a way to specify this via
> an API call.  I can't think of a way to do this and maintain backwards
> compatibility without adding yet another form for server_new (e.g.
> lo_server_new_with_family), so maybe that's what we'll have to do.

I think the solution is given here:
http://stackoverflow.com/questions/1618240/how-to-support-both-ipv4-and-ipv6-connections

The idea is to turn off the socket option IPV6_V6ONLY.  However, that is not supported on Windows XP, where you need to create two sockets, and therefore reverting to the solution of having an API for this.

So the changes are:

In server.c at line 318:
hints.ai_family = PF_INET6;


In server.c at line 367:

#ifdef ENABLE_IPV6
	unsigned int v6only_off = 0;
	if (setsockopt(s->sockets[0].fd, IPPROTO_IPV6, IPV6_V6ONLY, &v6only_off, sizeof(v6only_off)) < 0) {
            int err = geterror();
            lo_throw(s, err, strerror(err), "setsockopt(IPV6_V6ONLY)");
            lo_server_free(s);
            return NULL;
        }
#endif


That works for me.



> Maybe it would be nice to allow liblo to
> wait on multiple sockets.. (it would also be nice to be able to wait
> on multiple lo_servers with a single select())

That would be nice, but would require a serious change to the API, don't you think?

One thing I have noticed while reading the code:
Passing a NULL port to lo_server_new allows to automatically let liblo find a free port.  It looks like this is implemented by picking a random number and then trying every possible port number until one is free.

I think the system can do that for you -- at least, I got it working on Mac OS X and Windows, if you are interested I can search how it was done, I think it was very easy.

The added bonus is that it works for both UDP and TCP.


Best,
Cam

Hi Stephen,
Hi everybody reading the list,

I was testing TCP and found something that looks like a problem, at least, I'm not sure how to solve it.

The way to reproduce it is easy:
- start a OSC TCP server on port 8000.
- send messages from a client on the server.
- close the server.
- try start the server again, it won't because the socket is already in use.

It looks like the client got hold of the socket and the server can no more bind to it.  I think there must be a problem in Liblo, can you please tell me if you can reproduce that issue, and perhaps help me find a solution?


Thanks,
Cam

Hi dear list,

I was surprised to learn that on Mac OS X, MSG_NOSIGNAL is ignored.
The code in send.c at lines 419, 439 and 442 — typically something like

	ret = send(sock, data, data_len, MSG_NOSIGNAL);

— causes a SIGPIPE, ultimately crashing the application.  The solution I found, is to either block or implement a handler for the SIGPIPE signal, for example:

	signal(SIGPIPE, SIG_IGN);


All the best,
Cam

I believe the problem is actually a long-standing issue with IPv6
support, which is that there is no way to specify that a server should
bind to an IPv6 socket.  When you create a server with --enable-ipv6,
it specifies PF_UNSPEC for the requested socket family.  So the
operating system decides whether it is IPv4 or IPv6, which I guess on
Linux defaults to IPv4.

Changing line 318 of server.c from:

hints.ai_family = PF_UNSPEC;

to

hints.ai_family = PF_INET6;

fixes the problem for me.  What is needed is a way to specify this via
an API call.  I can't think of a way to do this and maintain backwards
compatibility without adding yet another form for server_new (e.g.
lo_server_new_with_family), so maybe that's what we'll have to do.

I guess it's not possible to create a socket that waits on both IPv4
and IPv6 simultaneously?  Maybe it would be nice to allow liblo to
wait on multiple sockets.. (it would also be nice to be able to wait
on multiple lo_servers with a single select())

Steve


On Wed, Sep 28, 2011 at 6:48 AM, Camille Troillard
<ca...@os...> wrote:
> Hello,
>
> I am running Mac OS X 10.6.8, liblo from trunk repository configured with IPv6 enabled.
> "ping6 ::1" works on my machine, so I believe it is reachable.
>
> I can't manage to send and receive OSC messages using IPv6 in my application.
> sendto fails with errno 22 "Invalid argument".
>
> I also tried oscsend and oscdump, but specifying an IPv6 address in oscsend results in nothing in oscdump.
>
> Is there anything I should be aware of when trying liblo and IPv6?
> Is it working or should I pass for now?
>
>
> Thanks!
>
> Best,
> Cam
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hi,

Okay, great that it works.  Looking back through the history, there
was a patch r176 by Camille Troillard:

"Fixes a bug with LO_MARKER_A/_B on 64-bit platforms."

That sounds like it is most likely what fixed your problem.  Sorry, I
did forget to mention that autogen.sh runs configure for you.

Steve


On Tue, Sep 27, 2011 at 11:25 PM, Tim Barrass <bar...@gm...> wrote:
> Hi Steve,
> the git "mainline" version works.
> autogen.sh said "now type make" so I didn't use the configure command at
> all.
> When I configured with 0.26 I didn't use any options, just ./configure.
>
> gcc -version
> i686-apple-darwin11-llvm-gcc-4.2
>
> It's a 64 bit cpu and os
>
> tim
>
>
>
> On 28 September 2011 10:55, Stephen Sinclair <rad...@gm...> wrote:
>>
>> Hi,
>>
>> Is there any way I could persuade you to try the svn version as well,
>> for comparison?  I can't think of anything off-hand that would have
>> changed in regards to this since 0.26, but it would be worth knowing
>> if there's a difference.  The only thing that changes is you must run
>> autogen.sh before configure.  My hunch is that this could be related
>> to machine bit width.
>>
>> Other information that could help:
>>
>> Is your CPU (and operating system) 32- or 64-bit?
>>
>> Are you configuring with or without --enable-ipv6?  What's your
>> configure command?
>>
>> output of "gcc --version"
>>
>> thanks,
>> Steve
>>
>>
>> On Tue, Sep 27, 2011 at 7:31 PM, Tim Barrass <bar...@gm...> wrote:
>> > Hi Steve,
>> > thanks for responding.  It's the 0.26 release version.  Do you need any
>> > more
>> > info?
>> > tim
>> >
>> > On 28 September 2011 02:27, Stephen Sinclair <rad...@gm...>
>> > wrote:
>> >>
>> >> Hi Tim,
>> >>
>> >> I don't have a 10.7 machine to test, but is this with the svn version
>> >> or the 0.26 release version?
>> >>
>> >> Steve
>> >>
>> >> On Mon, Sep 26, 2011 at 9:46 PM, Tim Barrass <bar...@gm...>
>> >> wrote:
>> >> > Hello,
>> >> > I'm having trouble with liblo on OSX 10.7
>> >> > this is what I get when I try testlo:
>> >> >
>> >> > ./testlo
>> >> > .......ends up with........
>> >> > passed test_varargs(a, "/lotsofformats", "fisbmhtdSccTFNI",
>> >> > 0.12345678f,
>> >> > 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999,
>> >> > "sym",
>> >> > 'X',
>> >> > 'Y', LO_ARGS_END) == 0
>> >> > path: </bar>
>> >> > liblo error: lo_send, lo_message_add, or lo_message_add_varargs
>> >> > called
>> >> > with
>> >> > mismatching types and data at
>> >> > testlo.c:943, exiting.
>> >> > arg 0 'f' 0.123457
>> >> > lo_message_add_varargs returned -2
>> >> > arg 1 'f' passed test_varargs(a, "/lotsofformats", "f", 0.12345678f,
>> >> > 123,
>> >> > "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym",
>> >> > 'X',
>> >> > 'Y',
>> >> > LO_ARGS_END) != 0
>> >> > inf
>> >> >
>> >> > Segmentation fault: 11
>> >> >
>> >> > I appreciate any help or clues.
>> >> > Thanks
>> >> > Tim
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > All the data continuously generated in your IT infrastructure
>> >> > contains a
>> >> > definitive record of customers, application performance, security
>> >> > threats, fraudulent activity and more. Splunk takes this data and
>> >> > makes
>> >> > sense of it. Business sense. IT sense. Common sense.
>> >> > http://p.sf.net/sfu/splunk-d2dcopy1
>> >> > _______________________________________________
>> >> > liblo-devel mailing list
>> >> > lib...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> All the data continuously generated in your IT infrastructure contains
>> >> a
>> >> definitive record of customers, application performance, security
>> >> threats, fraudulent activity and more. Splunk takes this data and makes
>> >> sense of it. Business sense. IT sense. Common sense.
>> >> http://p.sf.net/sfu/splunk-d2dcopy1
>> >> _______________________________________________
>> >> liblo-devel mailing list
>> >> lib...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > All the data continuously generated in your IT infrastructure contains a
>> > definitive record of customers, application performance, security
>> > threats, fraudulent activity and more. Splunk takes this data and makes
>> > sense of it. Business sense. IT sense. Common sense.
>> > http://p.sf.net/sfu/splunk-d2dcopy1
>> > _______________________________________________
>> > liblo-devel mailing list
>> > lib...@li...
>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hello,

I am running Mac OS X 10.6.8, liblo from trunk repository configured with IPv6 enabled.
"ping6 ::1" works on my machine, so I believe it is reachable.

I can't manage to send and receive OSC messages using IPv6 in my application.
sendto fails with errno 22 "Invalid argument".

I also tried oscsend and oscdump, but specifying an IPv6 address in oscsend results in nothing in oscdump.

Is there anything I should be aware of when trying liblo and IPv6?
Is it working or should I pass for now?


Thanks!

Best,
Cam

Hi Steve,
the git "mainline" version works.
autogen.sh said "now type make" so I didn't use the configure command at
all.
When I configured with 0.26 I didn't use any options, just ./configure.

gcc -version
i686-apple-darwin11-llvm-gcc-4.2

It's a 64 bit cpu and os

tim



On 28 September 2011 10:55, Stephen Sinclair <rad...@gm...> wrote:

> Hi,
>
> Is there any way I could persuade you to try the svn version as well,
> for comparison?  I can't think of anything off-hand that would have
> changed in regards to this since 0.26, but it would be worth knowing
> if there's a difference.  The only thing that changes is you must run
> autogen.sh before configure.  My hunch is that this could be related
> to machine bit width.
>
> Other information that could help:
>
> Is your CPU (and operating system) 32- or 64-bit?
>
> Are you configuring with or without --enable-ipv6?  What's your
> configure command?
>
> output of "gcc --version"
>
> thanks,
> Steve
>
>
> On Tue, Sep 27, 2011 at 7:31 PM, Tim Barrass <bar...@gm...> wrote:
> > Hi Steve,
> > thanks for responding.  It's the 0.26 release version.  Do you need any
> more
> > info?
> > tim
> >
> > On 28 September 2011 02:27, Stephen Sinclair <rad...@gm...>
> wrote:
> >>
> >> Hi Tim,
> >>
> >> I don't have a 10.7 machine to test, but is this with the svn version
> >> or the 0.26 release version?
> >>
> >> Steve
> >>
> >> On Mon, Sep 26, 2011 at 9:46 PM, Tim Barrass <bar...@gm...>
> wrote:
> >> > Hello,
> >> > I'm having trouble with liblo on OSX 10.7
> >> > this is what I get when I try testlo:
> >> >
> >> > ./testlo
> >> > .......ends up with........
> >> > passed test_varargs(a, "/lotsofformats", "fisbmhtdSccTFNI",
> 0.12345678f,
> >> > 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999,
> "sym",
> >> > 'X',
> >> > 'Y', LO_ARGS_END) == 0
> >> > path: </bar>
> >> > liblo error: lo_send, lo_message_add, or lo_message_add_varargs called
> >> > with
> >> > mismatching types and data at
> >> > testlo.c:943, exiting.
> >> > arg 0 'f' 0.123457
> >> > lo_message_add_varargs returned -2
> >> > arg 1 'f' passed test_varargs(a, "/lotsofformats", "f", 0.12345678f,
> >> > 123,
> >> > "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym",
> 'X',
> >> > 'Y',
> >> > LO_ARGS_END) != 0
> >> > inf
> >> >
> >> > Segmentation fault: 11
> >> >
> >> > I appreciate any help or clues.
> >> > Thanks
> >> > Tim
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > All the data continuously generated in your IT infrastructure contains
> a
> >> > definitive record of customers, application performance, security
> >> > threats, fraudulent activity and more. Splunk takes this data and
> makes
> >> > sense of it. Business sense. IT sense. Common sense.
> >> > http://p.sf.net/sfu/splunk-d2dcopy1
> >> > _______________________________________________
> >> > liblo-devel mailing list
> >> > lib...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure contains a
> >> definitive record of customers, application performance, security
> >> threats, fraudulent activity and more. Splunk takes this data and makes
> >> sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> liblo-devel mailing list
> >> lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi,

Is there any way I could persuade you to try the svn version as well,
for comparison?  I can't think of anything off-hand that would have
changed in regards to this since 0.26, but it would be worth knowing
if there's a difference.  The only thing that changes is you must run
autogen.sh before configure.  My hunch is that this could be related
to machine bit width.

Other information that could help:

Is your CPU (and operating system) 32- or 64-bit?

Are you configuring with or without --enable-ipv6?  What's your
configure command?

output of "gcc --version"

thanks,
Steve


On Tue, Sep 27, 2011 at 7:31 PM, Tim Barrass <bar...@gm...> wrote:
> Hi Steve,
> thanks for responding.  It's the 0.26 release version.  Do you need any more
> info?
> tim
>
> On 28 September 2011 02:27, Stephen Sinclair <rad...@gm...> wrote:
>>
>> Hi Tim,
>>
>> I don't have a 10.7 machine to test, but is this with the svn version
>> or the 0.26 release version?
>>
>> Steve
>>
>> On Mon, Sep 26, 2011 at 9:46 PM, Tim Barrass <bar...@gm...> wrote:
>> > Hello,
>> > I'm having trouble with liblo on OSX 10.7
>> > this is what I get when I try testlo:
>> >
>> > ./testlo
>> > .......ends up with........
>> > passed test_varargs(a, "/lotsofformats", "fisbmhtdSccTFNI", 0.12345678f,
>> > 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym",
>> > 'X',
>> > 'Y', LO_ARGS_END) == 0
>> > path: </bar>
>> > liblo error: lo_send, lo_message_add, or lo_message_add_varargs called
>> > with
>> > mismatching types and data at
>> > testlo.c:943, exiting.
>> > arg 0 'f' 0.123457
>> > lo_message_add_varargs returned -2
>> > arg 1 'f' passed test_varargs(a, "/lotsofformats", "f", 0.12345678f,
>> > 123,
>> > "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X',
>> > 'Y',
>> > LO_ARGS_END) != 0
>> > inf
>> >
>> > Segmentation fault: 11
>> >
>> > I appreciate any help or clues.
>> > Thanks
>> > Tim
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > All the data continuously generated in your IT infrastructure contains a
>> > definitive record of customers, application performance, security
>> > threats, fraudulent activity and more. Splunk takes this data and makes
>> > sense of it. Business sense. IT sense. Common sense.
>> > http://p.sf.net/sfu/splunk-d2dcopy1
>> > _______________________________________________
>> > liblo-devel mailing list
>> > lib...@li...
>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hi Steve,
thanks for responding.  It's the 0.26 release version.  Do you need any more
info?
tim

On 28 September 2011 02:27, Stephen Sinclair <rad...@gm...> wrote:

> Hi Tim,
>
> I don't have a 10.7 machine to test, but is this with the svn version
> or the 0.26 release version?
>
> Steve
>
> On Mon, Sep 26, 2011 at 9:46 PM, Tim Barrass <bar...@gm...> wrote:
> > Hello,
> > I'm having trouble with liblo on OSX 10.7
> > this is what I get when I try testlo:
> >
> > ./testlo
> > .......ends up with........
> > passed test_varargs(a, "/lotsofformats", "fisbmhtdSccTFNI", 0.12345678f,
> > 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym",
> 'X',
> > 'Y', LO_ARGS_END) == 0
> > path: </bar>
> > liblo error: lo_send, lo_message_add, or lo_message_add_varargs called
> with
> > mismatching types and data at
> > testlo.c:943, exiting.
> > arg 0 'f' 0.123457
> > lo_message_add_varargs returned -2
> > arg 1 'f' passed test_varargs(a, "/lotsofformats", "f", 0.12345678f, 123,
> > "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X',
> 'Y',
> > LO_ARGS_END) != 0
> > inf
> >
> > Segmentation fault: 11
> >
> > I appreciate any help or clues.
> > Thanks
> > Tim
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi Tim,

I don't have a 10.7 machine to test, but is this with the svn version
or the 0.26 release version?

Steve

On Mon, Sep 26, 2011 at 9:46 PM, Tim Barrass <bar...@gm...> wrote:
> Hello,
> I'm having trouble with liblo on OSX 10.7
> this is what I get when I try testlo:
>
> ./testlo
> .......ends up with........
> passed test_varargs(a, "/lotsofformats", "fisbmhtdSccTFNI", 0.12345678f,
> 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X',
> 'Y', LO_ARGS_END) == 0
> path: </bar>
> liblo error: lo_send, lo_message_add, or lo_message_add_varargs called with
> mismatching types and data at
> testlo.c:943, exiting.
> arg 0 'f' 0.123457
> lo_message_add_varargs returned -2
> arg 1 'f' passed test_varargs(a, "/lotsofformats", "f", 0.12345678f, 123,
> "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X', 'Y',
> LO_ARGS_END) != 0
> inf
>
> Segmentation fault: 11
>
> I appreciate any help or clues.
> Thanks
> Tim
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hello,
I'm having trouble with liblo on OSX 10.7
this is what I get when I try testlo:

./testlo
.......ends up with........
passed test_varargs(a, "/lotsofformats", "fisbmhtdSccTFNI", 0.12345678f,
123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X',
'Y', LO_ARGS_END) == 0
path: </bar>
liblo error: lo_send, lo_message_add, or lo_message_add_varargs called with
mismatching types and data at
testlo.c:943, exiting.
arg 0 'f' 0.123457
lo_message_add_varargs returned -2
arg 1 'f' passed test_varargs(a, "/lotsofformats", "f", 0.12345678f, 123,
"123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X', 'Y',
LO_ARGS_END) != 0
inf

Segmentation fault: 11

I appreciate any help or clues.
Thanks
Tim