Bug 973348 - socket only listening on ipv6
Summary: socket only listening on ipv6
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rsh (Show other bugs)
(Show other bugs)
Version: 19
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Sekletar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-11 18:31 UTC by Tom Horsley
Modified: 2013-07-05 01:53 UTC (History)
9 users (show)

Fixed In Version: rsh-0.17-72.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-05 01:53:40 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Tom Horsley 2013-06-11 18:31:38 UTC
Description of problem:
I've been trying to get rsh-server to accept connections over the
local network on my fedora 19 beta system.

I do systemctl enable rsh.socket

I setup valid ~/.rhosts entries.

But I can't do something like

rsh f19sysname date

I start poking around and eventually notice in netstat that port 514 is
only listening on tcp6, no prot 514 shows up as tcp.

As an experiment, I change the rsh.socket file to say 0.0.0.0:514
instead of just 514.

After getting everything restarted, rsh now talks to remote systems connecting
vi ipv4.

All the docs I can find claim that it ought to listen on v4 and v6 by default.

Version-Release number of selected component (if applicable):
systemd-204-6.fc19.x86_64
rsh-server-0.17-71.fc19.x86_64


How reproducible:
100%

Steps to Reproduce:
1.see above
2.
3.

Actual results:
Will not accept ipv4 connections (get permission denied).

Expected results:
Ipv4 working.

Additional info:

Comment 1 Zbigniew Jędrzejewski-Szmek 2013-06-11 20:33:09 UTC
(In reply to Tom Horsley from comment #0)
> I start poking around and eventually notice in netstat that port 514 is
> only listening on tcp6, no prot 514 shows up as tcp.
What does 'telnet localhost 514' say (run on that machine)?
What does 'systemctl list-sockets' say?

Comment 2 Tom Horsley 2013-06-12 11:47:27 UTC
First the results with my modified rsh.socket file forced to use IPv4:

[tweety@tomh ~]$ rsh localhost date
connect to address ::1: Connection refused
Trying 127.0.0.1...
Wed Jun 12 07:35:40 EDT 2013
[tweety@tomh ~]$ rsh tomh date
Wed Jun 12 07:35:53 EDT 2013
[tweety@tomh ~]$ telnet localhost 514
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
[tweety@tomh ~]$ systemctl status rsh.socket
rsh.socket - Remote Shell Facilities Activation Socket
       Loaded: loaded (/usr/lib/systemd/system/rsh.socket; enabled)
       Active: active (listening) since Wed 2013-06-12 07:33:00 EDT; 3min 32s ago
       Listen: 0.0.0.0:514 (Stream)
     Accepted: 3; Connected: 0

[tweety@tomh ~]$ systemctl list-sockets 
LISTEN                          UNIT                         ACTIVATES
/dev/initctl                    systemd-initctl.socket       systemd-initctl.ser
/dev/log                        systemd-journald.socket      systemd-journald.se
/run/dmeventd-client            dm-event.socket              dm-event.service
/run/dmeventd-server            dm-event.socket              dm-event.service
/run/lvm/lvmetad.socket         lvm2-lvmetad.socket          lvm2-lvmetad.servic
/run/systemd/journal/socket     systemd-journald.socket      systemd-journald.se
/run/systemd/journal/stdout     systemd-journald.socket      systemd-journald.se
/run/systemd/journal/syslog     syslog.socket                rsyslog.service
/run/systemd/shutdownd          systemd-shutdownd.socket     systemd-shutdownd.s
/run/udev/control               systemd-udevd-control.socket systemd-udevd.servi
/var/run/cups/cups.sock         cups.socket                  cups.service
/var/run/dbus/system_bus_socket dbus.socket                  dbus.service
/var/run/pcscd/pcscd.comm       pcscd.socket                 pcscd.service
/var/run/rpcbind.sock           rpcbind.socket               rpcbind.service
0.0.0.0:514                     rsh.socket                  
@ISCSIADM_ABSTRACT_NAMESPACE    iscsid.socket                iscsid.service
@ISCSID_UIP_ABSTRACT_NAMESPACE  iscsiuio.socket              iscsiuio.service
kobject-uevent 1                systemd-udevd-kernel.socket  systemd-udevd.servi

18 sockets listed.
Pass --all to see loaded but inactive sockets, too.

Now I put back the original rsh.socket and restart things and try again:

[tweety@tomh ~]$ rsh localhost date
Wed Jun 12 07:39:57 EDT 2013
[tweety@tomh ~]$ rsh tomh date
Permission denied.
[tweety@tomh ~]$ telnet localhost 514
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
[tweety@tomh ~]$ telnet tomh 514
Trying 10.134.30.143...
Connected to tomh.
Escape character is '^]'.
Connection closed by foreign host.
[tweety@tomh ~]$ systemctl status rsh.socket
rsh.socket - Remote Shell Facilities Activation Socket
       Loaded: loaded (/usr/lib/systemd/system/rsh.socket; enabled)
       Active: active (listening) since Wed 2013-06-12 07:39:38 EDT; 1min 40s ago
       Listen: [::]:514 (Stream)
     Accepted: 7; Connected: 0

[tweety@tomh ~]$ systemctl list-sockets
LISTEN                          UNIT                         ACTIVATES
/dev/initctl                    systemd-initctl.socket       systemd-initctl.ser
/dev/log                        systemd-journald.socket      systemd-journald.se
/run/dmeventd-client            dm-event.socket              dm-event.service
/run/dmeventd-server            dm-event.socket              dm-event.service
/run/lvm/lvmetad.socket         lvm2-lvmetad.socket          lvm2-lvmetad.servic
/run/systemd/journal/socket     systemd-journald.socket      systemd-journald.se
/run/systemd/journal/stdout     systemd-journald.socket      systemd-journald.se
/run/systemd/journal/syslog     syslog.socket                rsyslog.service
/run/systemd/shutdownd          systemd-shutdownd.socket     systemd-shutdownd.s
/run/udev/control               systemd-udevd-control.socket systemd-udevd.servi
/var/run/cups/cups.sock         cups.socket                  cups.service
/var/run/dbus/system_bus_socket dbus.socket                  dbus.service
/var/run/pcscd/pcscd.comm       pcscd.socket                 pcscd.service
/var/run/rpcbind.sock           rpcbind.socket               rpcbind.service
@ISCSIADM_ABSTRACT_NAMESPACE    iscsid.socket                iscsid.service
@ISCSID_UIP_ABSTRACT_NAMESPACE  iscsiuio.socket              iscsiuio.service
[::]:514                        rsh.socket                  
kobject-uevent 1                systemd-udevd-kernel.socket  systemd-udevd.servi

18 sockets listed.
Pass --all to see loaded but inactive sockets, too.

Also, I tried this on a virtual machine at home where my network gets DHCP
and DNS from a DD-WRT router that doesn't know a thing about IPv6, and I get
different failures. Instead of permission denied, I get errors about host address mismatch (I forget the exact error message). I suspect it is attempting to verify the address it looks up is the one that connected, but the v6 and v4 addresses don't match.

Maybe the rsh.socket file should be constructed like the dovecot.socket file where it explicitly creates two different sockets, one for v4 and one for v6?

Comment 3 Zbigniew Jędrzejewski-Szmek 2013-06-12 13:20:32 UTC
Looks like a rsh problem to me. I certainy *is* listening, and you make a connections, except that rsh service refuses to cooperate.

Comment 4 Tom Horsley 2013-06-12 14:13:08 UTC
But if I make the change to IPv4 only socket then rsh works fine, so perhaps rsh itself doesn't know what to do with IPv6 connections? In which case the socket file really ought to do IPv4 only?

Comment 5 Michal Sekletar 2013-06-13 18:33:02 UTC
Problem is in handling of IPv4-mapped IPv6 addresses.

There are two approached how to solve this. One would be to solve this in rsh.socket, where I can explicitly name two sockets and one would be IPv6 only second second one IPv4 only. 

Another solution which is IMHO better is converting sockaddr_in6 back to sockaddr_in when rsh finds out that connected client actually isn't native IPv6 client.

Comment 6 Michal Sekletar 2013-06-14 16:31:36 UTC
Hi Tom,

could you please download newest packages [1] and try those out. They should fix this bug. 

Feedback is greatly appreciated, thank you.

[1] http://msekleta.fedorapeople.org/rsh/x86_64/

Michal

Comment 7 Tom Horsley 2013-06-14 16:55:00 UTC
I won't be back on my system at work where I initially found this till Monday, but I just tried the new packages on my f19 virtual machine (which also gave errors previously) and it seems to work fine with no configuration fiddling required by me (other than proper ~/.rhosts file entries). Looks fixed to me.

Comment 8 Fedora Update System 2013-06-26 16:47:48 UTC
rsh-0.17-72.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/rsh-0.17-72.fc19

Comment 9 Fedora Update System 2013-06-27 15:46:26 UTC
Package rsh-0.17-72.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rsh-0.17-72.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11824/rsh-0.17-72.fc19
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2013-07-05 01:53:40 UTC
rsh-0.17-72.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.