<20140629194829.GA1994@newbook>
I've been trying to get cups working with a Brother DCP-7065-DN. I still haven't figured out how to get the binary driver going with musl and grsec (though adding eglibc might work...). But Peter de Wacht mentioned a driver that might work with it (brlaser, github.com/pdewacht/brlaser), so I thought I'd try testing it. I've run into several cases of missing dependencies: cups needs cups-filters, a2ps (I think), ghostscript, and ghostscript-fonts. But I ran into another problem: D [29/Jun/2014:08:31:13 +0700] [Job 8] Ghostscript command line: /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -sMediaType=PLAIN -r600x600 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -dcupsBitsPerColor=1 -dcupsColorOrder=0 -dcupsColorSpace=3 -scupsPageSizeName=Letter -I/usr/share/cups/fonts -c '<</.HWMargins[8.000000 8.000000 8.000000 16.000000] /Margins[0 0]>>setpagedevice' -f -_ ... D [29/Jun/2014:08:31:13 +0700] [Job 8] Unknown device: cups Any idea what the issue is here? I can provide the full logs if needed. Thanks, Isaac Dunham --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
<20140630001201.GA14838@newbook>
<20140629194829.GA1994@newbook>
(view parent)
On Sun, Jun 29, 2014 at 12:48:29PM -0700, Isaac Dunham wrote: > I've been trying to get cups working with a Brother DCP-7065-DN. <snip> > I've run into several cases of missing dependencies: cups needs cups-filters, > a2ps (I think), ghostscript, and ghostscript-fonts. But I ran into another > problem: > > D [29/Jun/2014:08:31:13 +0700] [Job 8] Ghostscript command line: > /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE > -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -sMediaType=PLAIN > -r600x600 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 > -dcupsBitsPerColor=1 -dcupsColorOrder=0 -dcupsColorSpace=3 > -scupsPageSizeName=Letter -I/usr/share/cups/fonts > -c '<</.HWMargins[8.000000 8.000000 8.000000 16.000000] > /Margins[0 0]>>setpagedevice' -f -_ > ... > D [29/Jun/2014:08:31:13 +0700] [Job 8] Unknown device: cups And the answer to this is to -add cups-dev to makedepends -change '--with-drivers=FILES' to '--with-drivers=FILES,cups' In addition to this, to get a working cups you need to install: cups cups-filters a2ps ghostscript-fonts ghostscript #the new cups ghostscript and install a driver. In my case, I'm trying to see if the brlaser driver works. Now I hit the next issue: the 'lpd' backend reports 'Unable to reserve port: Invalid argument' And I need to figure out what's causing this--or rather, what the solution is. Right now, I'm stuck (lpd is the main way to access it, and it isn't working). Thanks, Isaac Dunham --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
<20140630012830.GA16088@newbook>
<20140630001201.GA14838@newbook>
(view parent)
On Sun, Jun 29, 2014 at 05:12:01PM -0700, Isaac Dunham wrote: > Now I hit the next issue: the 'lpd' backend reports > 'Unable to reserve port: Invalid argument' > And I need to figure out what's causing this--or rather, what the solution is. > Right now, I'm stuck (lpd is the main way to access it, and it isn't working). OK, now we're in cups-1.7.3/backend/lpd.c: ...the problem is a local implementation of rresvport_af(), trying to reserve a port but failing. And strace -p `pidof lpd` says this: Process 16113 attached restart_syscall(<... resuming interrupted call ...>) = 0 geteuid32() = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 bind(7, {sa_family=AF_INET, sin_port=htons(905), sin_addr=inet_addr("0.0.0.0")}, 256) = -1 EINVAL (Invalid argument) close(7) = 0 writev(2, [{"", 0}, {"DEBUG: Unable to reserve port", 29}], 2) = 29 writev(2, [{"", 0}, {":", 1}], 2) = 1 writev(2, [{"", 0}, {" ", 1}], 2) = 1 writev(2, [{"", 0}, {"Invalid argument", 16}], 2) = 16 writev(2, [{"", 0}, {"\n", 1}], 2) = 1 nanosleep({1, 0}, 0x5d2bcae8) = 0 geteuid32() = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 bind(7, {sa_family=AF_INET, sin_port=htons(904), sin_addr=inet_addr("0.0.0.0")}, 256) = -1 EINVAL (Invalid argument) close(7) = 0 writev(2, [{"", 0}, {"DEBUG: Unable to reserve port", 29}], 2) = 29 writev(2, [{"", 0}, {":", 1}], 2) = 1 writev(2, [{"", 0}, {" ", 1}], 2) = 1 writev(2, [{"", 0}, {"Invalid argument", 16}], 2) = 16 writev(2, [{"", 0}, {"\n", 1}], 2) = 1 nanosleep({1, 0}, 0x5d2bcae8) = 0 geteuid32() = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 bind(7, {sa_family=AF_INET, sin_port=htons(903), sin_addr=inet_addr("0.0.0.0")}, 256) = -1 EINVAL (Invalid argument) close(7) = 0 writev(2, [{"", 0}, {"DEBUG: Unable to reserve port", 29}], 2) = 29 writev(2, [{"", 0}, {":", 1}], 2) = 1 writev(2, [{"", 0}, {" ", 1}], 2) = 1 writev(2, [{"", 0}, {"Invalid argument", 16}], 2) = 16 writev(2, [{"", 0}, {"\n", 1}], 2) = 1 nanosleep({1, 0}, Process 16113 detached <detached ...> Clearly something needs to be adjusted for this to work with musl; I'm not sure what it is. Thanks, Isaac Dunham --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
<20140630043512.GB16088@newbook>
<20140630020311.GD179@brightrain.aerifal.cx>
(view parent)
On Sun, Jun 29, 2014 at 10:03:11PM -0400, Rich Felker wrote: > On Sun, Jun 29, 2014 at 06:28:31PM -0700, Isaac Dunham wrote: > > On Sun, Jun 29, 2014 at 05:12:01PM -0700, Isaac Dunham wrote: > > > Now I hit the next issue: the 'lpd' backend reports > > > 'Unable to reserve port: Invalid argument' > > > And I need to figure out what's causing this--or rather, what the solution is. > > > Right now, I'm stuck (lpd is the main way to access it, and it isn't working). > > OK, now we're in cups-1.7.3/backend/lpd.c: > > > > ....the problem is a local implementation of rresvport_af(), trying to reserve > > a port but failing. > > > > And strace -p `pidof lpd` says this: > > Process 16113 attached > > restart_syscall(<... resuming interrupted call ...>) = 0 > > geteuid32() = 0 > > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 > > bind(7, {sa_family=AF_INET, sin_port=htons(905), sin_addr=inet_addr("0.0.0.0")}, 256) = -1 EINVAL (Invalid argument) > > Where did the value of 256 for socklen_t come from? That's almost > surely the cause of the EINVAL. sockaddr_in should have a length of > 16, not 256. Apparently this: if (!bind(fd, (struct sockaddr *)&addr, sizeof(addr))) return (fd); addr is of type http_addr_t, defined in cups/http.h thus: typedef union _http_addr_u /**** Socket address union, which **** makes using IPv6 and other **** address types easier and **** more portable. @since CUPS 1.2/OS X 10.5@ ****/ { struct sockaddr addr; /* Base structure for family value */ struct sockaddr_in ipv4; /* IPv4 address */ #ifdef AF_INET6 struct sockaddr_in6 ipv6; /* IPv6 address */ #endif /* AF_INET6 */ #ifdef AF_LOCAL struct sockaddr_un un; /* Domain socket file */ #endif /* AF_LOCAL */ char pad[256]; /* Padding to ensure binary compatibility */ } http_addr_t; I'm not sure how to handle this. Thanks, Isaac Dunham --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
<20140630020311.GD179@brightrain.aerifal.cx>
<20140630012830.GA16088@newbook>
(view parent)
On Sun, Jun 29, 2014 at 06:28:31PM -0700, Isaac Dunham wrote: > On Sun, Jun 29, 2014 at 05:12:01PM -0700, Isaac Dunham wrote: > > Now I hit the next issue: the 'lpd' backend reports > > 'Unable to reserve port: Invalid argument' > > And I need to figure out what's causing this--or rather, what the solution is. > > Right now, I'm stuck (lpd is the main way to access it, and it isn't working). > OK, now we're in cups-1.7.3/backend/lpd.c: > > ....the problem is a local implementation of rresvport_af(), trying to reserve > a port but failing. > > And strace -p `pidof lpd` says this: > Process 16113 attached > restart_syscall(<... resuming interrupted call ...>) = 0 > geteuid32() = 0 > socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 > bind(7, {sa_family=AF_INET, sin_port=htons(905), sin_addr=inet_addr("0.0.0.0")}, 256) = -1 EINVAL (Invalid argument) Where did the value of 256 for socklen_t come from? That's almost surely the cause of the EINVAL. sockaddr_in should have a length of 16, not 256. Rich --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
<20140630053426.GC16088@newbook>
<20140630043512.GB16088@newbook>
(view parent)
Thanks to Rich's comment, I've found a solution that works here. The patch doesn't exactly look nice, though. And yes, once I add this patch I can print using Peter De Wachter's brlaser driver (github.com/pdewacht/brlaser). I'll be sending a patch for main/cups to alpine-devel shortly, and probably packaging brlaser for alpine. HTH, Isaac Dunham
<20140630070353.GG179@brightrain.aerifal.cx>
<20140630053426.GC16088@newbook>
(view parent)
On Sun, Jun 29, 2014 at 10:34:27PM -0700, Isaac Dunham wrote: > Thanks to Rich's comment, I've found a solution that works here. > The patch doesn't exactly look nice, though. I agree it's ugly. The clean way to do it would be to use getaddrinfo to request an AI_PASSIVE address for the desired family. Then you get the right sockaddr type and size for free, and you can subsequently fill in the port to try. That wouldn't work for AF_LOCAL (at least not on musl) but this whole function makes no sense for AF_LOCAL. Of course binding a reserved port like this is a serious security smell -- it sounds like they're trying to facilitate port-based authentication, which is unsafe if used for anything except localhost. I would see if it's possible to remove the binding completely and have it work. Remote lpd's would not be able to trust the ldp that omits the bind based on its port, but this kind of trust is fundamentally wrong and insecure anyway. If such a trust relationship is needed, a proper authentication channel must be used. Rich --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---
<20140701161906.3d99b1a9@ncopa-desktop.alpinelinux.org>
<20140630053426.GC16088@newbook>
(view parent)
On Sun, 29 Jun 2014 22:34:27 -0700 Isaac Dunham <ibid.ag@gmail.com> wrote: > Thanks to Rich's comment, I've found a solution that works here. > The patch doesn't exactly look nice, though. > > And yes, once I add this patch I can print using Peter De Wachter's brlaser > driver (github.com/pdewacht/brlaser). > > I'll be sending a patch for main/cups to alpine-devel shortly, > and probably packaging brlaser for alpine. > > HTH, > Isaac Dunham good catch! would be nice to know what upstream says about it. -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---