Re: The dante-1.1.19p0 package is broken on AMD64 because of integer size diff I386-AMD64 by everything I can tell. Also, request for newer Dante version port, 1.1 is from 2006
Hi, very well, so,
Dante is the only SOCKS server for OBSD.
That it's out of order on AMD64 is an issue.
Right off the top of my head I'd believe the error is extremely simple to
fix for the one who's introduced; I'd believe the Dante code uses the wrong
data type for storing a socket (like, an int instead of the socket type or
whatever) and this causes the mismatch that trigs the assertion, and causes
sigsegv if disabling the assertion.
Best regards,
2013/3/24 Mikael More mikael.m...@gmail.com
Dear list,
This configuration is minimalistic and works on OBSD 5.2 I386 (as reported
by vortexx on #obsd freenode, on CC):
internal: lo0 port = 1080
external: axe0
method: username none
user.notprivileged: _sockd
logoutput: stderr
client pass {
from: 127.0.0.0/8 to: 0.0.0.0/0 #internal network
log: connect disconnect
}
pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
command: connect udpassociate
log: connect disconnect
}
On OBSD 5.2 AMD64 though, the dante-1.1.19p0 package produces this error:
Mar 23 22:39:13 (1364078353) sockd[23769]: created new negotiatorchild
Mar 23 22:40:28 (1364078428) sockd[23769]: an internal error was detected
at sockd_negotiate.c:407
value = 0, version = $Id: sockd_negotiate.c,v 1.90 2005/11/08 16:00:21
michaels Exp $: Undefined error: 0 (errno = 0)
Mar 23 22:40:28 (1364078428) sockd[21587]: eof from negotiatorchild 23769
I took the opportunity to check out row 407 there. This row is an assert,
SASSERT(CMSG_TOTLEN(msg) == CMSG_SPACE(sizeof(int) * fdexpect));
what happens on AMD64 is that CMSG_TOTLEN(msg) is 20 and
CMSG_SPACE(sizeof(int) * fdexpect) 24.
It looks like this is the recvmsg handling code for receiving a socket
from the child process that's supposed to handle the socks call (or the
other way around -t his is the child process trying to recvmsg a socket
from the parent process), and it fails to pick up the socket appropriately.
It makes perfect sense that there's an integer size mistake involved here
- the original code was written for I386 and it still works, and now with
different arch some involved variable is of different size, making that
assert fail.
Commenting out the assert causes SIGSEGV:
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-unknown-openbsd5.2...
(gdb) run
Starting program: /home/pop/dante-1.1.19/sockd/sockd
Mar 23 22:47:36 (1364078856) sockd[25622]: socks_seteuid(): old: 0, new:
1016
Mar 23 22:47:36 (1364078856) sockd[25622]: socks_reseteuid(): current:
1016, new: 0
Mar 23 22:47:36 (1364078856) sockd[25622]: fixsettings(): setting the
libwrap uid to 0 is not recommended
[New process 25622]
Mar 23 22:47:36 (1364078856) sockd[5783]: created new negotiatorchild
Mar 23 22:47:36 (1364078856) sockd[26119]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[24308]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[693]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[4811]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[25622]: dante/server v1.1.19 running
Mar 23 22:47:36 (1364078856) sockd[29628]: created new iochild
Just for reference, length is 20 and we expected 24.
- debug print
statement i added, replacing the failing assert
Mar 23 22:47:38 (1364078858) sockd[5783]: pass(1): tcp/accept [:
127.0.0.1.33837 - 127.0.0.1.1080
Just for reference, length is 20 and we expected 24.
Mar 23 22:47:38 (1364078858) sockd[5783]: pass(1): tcp/accept [:
127.0.0.1.42458 - 127.0.0.1.1080
Just for reference, length is 20 and we expected 24.
Mar 23 22:47:38 (1364078858) sockd[5783]: pass(1): tcp/accept [:
127.0.0.1.24579 - 127.0.0.1.1080
Mar 23 22:47:38 (1364078858) sockd[25622]: an internal error was detected
at sockd_request.c:226
value = 0, version = $Id: sockd_request.c,v 1.176 2006/01/07 18:54:07
michaels Exp $: Undefined error: 0 (errno = 0)
Program received signal SIGABRT, Aborted.
0x000206c88bca in kill () from /usr/lib/libc.so.65.0
(gdb) bt
#0 0x000206c88bca in kill () from /usr/lib/libc.so.65.0
#1 0x000206cef791 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2 0x0040d98d in recv_req (s=Variable s is not available.
) at sockd_request.c:226
#3 0x in ?? ()
Now, while Dante 1.1.x seems to be the only one that compiles easily on
OBSD, it is 7 years old and the latest series are 1.4.X . If anyone would
be interested in porting the latest one, would be appreciated :D
It's pretty standard Unix code.
Thanks,
Mikael
subscribe
The dante-1.1.19p0 package is broken on AMD64 because of integer size diff I386-AMD64 by everything I can tell. Also, request for newer Dante version port, 1.1 is from 2006
Dear list,
This configuration is minimalistic and works on OBSD 5.2 I386 (as reported
by vortexx on #obsd freenode, on CC):
internal: lo0 port = 1080
external: axe0
method: username none
user.notprivileged: _sockd
logoutput: stderr
client pass {
from: 127.0.0.0/8 to: 0.0.0.0/0 #internal network
log: connect disconnect
}
pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
command: connect udpassociate
log: connect disconnect
}
On OBSD 5.2 AMD64 though, the dante-1.1.19p0 package produces this error:
Mar 23 22:39:13 (1364078353) sockd[23769]: created new negotiatorchild
Mar 23 22:40:28 (1364078428) sockd[23769]: an internal error was detected
at sockd_negotiate.c:407
value = 0, version = $Id: sockd_negotiate.c,v 1.90 2005/11/08 16:00:21
michaels Exp $: Undefined error: 0 (errno = 0)
Mar 23 22:40:28 (1364078428) sockd[21587]: eof from negotiatorchild 23769
I took the opportunity to check out row 407 there. This row is an assert,
SASSERT(CMSG_TOTLEN(msg) == CMSG_SPACE(sizeof(int) * fdexpect));
what happens on AMD64 is that CMSG_TOTLEN(msg) is 20 and
CMSG_SPACE(sizeof(int) * fdexpect) 24.
It looks like this is the recvmsg handling code for receiving a socket from
the child process that's supposed to handle the socks call (or the other
way around -t his is the child process trying to recvmsg a socket from the
parent process), and it fails to pick up the socket appropriately.
It makes perfect sense that there's an integer size mistake involved here -
the original code was written for I386 and it still works, and now with
different arch some involved variable is of different size, making that
assert fail.
Commenting out the assert causes SIGSEGV:
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-unknown-openbsd5.2...
(gdb) run
Starting program: /home/pop/dante-1.1.19/sockd/sockd
Mar 23 22:47:36 (1364078856) sockd[25622]: socks_seteuid(): old: 0, new:
1016
Mar 23 22:47:36 (1364078856) sockd[25622]: socks_reseteuid(): current:
1016, new: 0
Mar 23 22:47:36 (1364078856) sockd[25622]: fixsettings(): setting the
libwrap uid to 0 is not recommended
[New process 25622]
Mar 23 22:47:36 (1364078856) sockd[5783]: created new negotiatorchild
Mar 23 22:47:36 (1364078856) sockd[26119]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[24308]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[693]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[4811]: created new requestchild
Mar 23 22:47:36 (1364078856) sockd[25622]: dante/server v1.1.19 running
Mar 23 22:47:36 (1364078856) sockd[29628]: created new iochild
Just for reference, length is 20 and we expected 24.
- debug print
statement i added, replacing the failing assert
Mar 23 22:47:38 (1364078858) sockd[5783]: pass(1): tcp/accept [:
127.0.0.1.33837 - 127.0.0.1.1080
Just for reference, length is 20 and we expected 24.
Mar 23 22:47:38 (1364078858) sockd[5783]: pass(1): tcp/accept [:
127.0.0.1.42458 - 127.0.0.1.1080
Just for reference, length is 20 and we expected 24.
Mar 23 22:47:38 (1364078858) sockd[5783]: pass(1): tcp/accept [:
127.0.0.1.24579 - 127.0.0.1.1080
Mar 23 22:47:38 (1364078858) sockd[25622]: an internal error was detected
at sockd_request.c:226
value = 0, version = $Id: sockd_request.c,v 1.176 2006/01/07 18:54:07
michaels Exp $: Undefined error: 0 (errno = 0)
Program received signal SIGABRT, Aborted.
0x000206c88bca in kill () from /usr/lib/libc.so.65.0
(gdb) bt
#0 0x000206c88bca in kill () from /usr/lib/libc.so.65.0
#1 0x000206cef791 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2 0x0040d98d in recv_req (s=Variable s is not available.
) at sockd_request.c:226
#3 0x in ?? ()
Now, while Dante 1.1.x seems to be the only one that compiles easily on
OBSD, it is 7 years old and the latest series are 1.4.X . If anyone would
be interested in porting the latest one, would be appreciated :D
It's pretty standard Unix code.
Thanks,
Mikael
Re: Anyone working on a Fuppes port?
I almost forgot about this until a member on openbsd-ports reminded me. I got fuppes to build, including deps. But it's only on a pretty isolated vmware instance, so I haven't been able to actually test it from my PS3. site: http://dasen.se/software/fuppes/ archive: http://dasen.se/software/fuppes/ports-fuppes-SVN-549.tar.gz README: http://dasen.se/software/fuppes/README Do note that the contents will replace parts of your ports tree including: * graphics/ffmpeg * multimedia/xvidcore So, any PS3, XBox etc users who can try it out? Maybe give some feedback and I'll take the time to actually make this port useful and perhaps even maintain it unless someone else does. Regards, Mikael
Re: Anyone working on a Fuppes port?
On 2/1/08, Jacob Meuser [EMAIL PROTECTED] wrote: On Fri, Feb 01, 2008 at 10:00:38AM +0100, Mikael Fridh wrote: I almost forgot about this until a member on openbsd-ports reminded me. I got fuppes to build, including deps. But it's only on a pretty isolated vmware instance, so I haven't been able to actually test it from my PS3. site: http://dasen.se/software/fuppes/ archive: http://dasen.se/software/fuppes/ports-fuppes-SVN-549.tar.gz README: http://dasen.se/software/fuppes/README Do note that the contents will replace parts of your ports tree including: * graphics/ffmpeg * multimedia/xvidcore why? is it just to update xvidcore and build ffmpeg with xvidcore support? is xvidcore support absolutley necessary? Is it absolutely necessary? No. Why upgrade xvidcore? Because 1.1.3 is a nice bugfix release. I wanted all base stuff to be kosher before fixing ffmpeg. Why upgrade ffmpeg? Because the 4.2-ports ffmpeg didn't support transcoding. Why transcoding? Because at the time I did this, the PS3 did not include xvid support in it's firmware. -- Fridh
Anyone working on a Fuppes port?
Just a quick question to see if anyone's working on or planning on adding Fuppes[1] to ports? I've already done: * ffmpeg: Added graphics/ffmpeg/20071031 (Update 20070501 to 20071031). * ffmpeg: Added xvidcore to the dependencies and made it build with libxvid and xvid support. * xvidcore: Added multimedia/xvidcore/1.1 (Upgrade 1.0.3 to 1.1.3) So, all that's left is Fuppes on top of all this. So before I start I want to see if anyone's already on it! Why I'm working on it? I just got a PS3 and need a Media Server on my OpenBSD. [1] - http://fuppes.ulrich-voelkel.de/ -- Mike
