This is a discussion on TCPIP Services: who gets to the port first ? (SYSLOG vs RSH) - VMS ; SYSLOG uses port 514 on UDP RSH uses port 514 on TCP I reported some time ago that the TCPIP utility corrupts records when you try to create 2 separate entries, one for TCP-514 and one for UDP-514 (you can ...
SYSLOG uses port 514 on UDP
RSH uses port 514 on TCP
I reported some time ago that the TCPIP utility corrupts records when
you try to create 2 separate entries, one for TCP-514 and one for
UDP-514 (you can manually fix this and it then works).
Had to reboot the system for the first time since I had fixed that, (due
to NFS hanging) and I found out that while SYSLOG and RSH started, RSH
just didn't get any calls. Both are started by the kernel (aka: defined
in the TCPIP services database).
shutting down RSH and restarting it made it work.
The SYSLOG code seems to do:
sd_syslog = socket(AF_INET, SOCK_DGRAM, 0);
service_ent = getservbyname("syslog", "udp");
socket_name.sin_family = AF_INET;
socket_name.sin_port = service_ent->s_port;
socket_name.sin_addr.s_addr = 0;
(struct sockaddr *) &socket_name,
sizeof(socket_name)) < 0)
Based on the abbreviated above code, is it correct to assume that
SOCK_DGRAM will only cause that program to listen to UDP calls ?
If the SYSLOG code tried to listen to both UDP and TCP, would the TCPIP
kernel allow RSH to take over 514-TCP or would an error be issued ?
(aka: RSH starts, then SYSLOG starts and "steals" 514-TCP from RSH, and
when you restart RSH, RSH then steals 514-TCP from SYSLOG).
Or is there very strict protection against one service stealing
listening sockets from another ?
Has anyone experienced similar problems in the past ? Once it is started
it seems to work fine.