##########################################################################
# Archer C64 System Log
# Time = 2022-11-02 16:28:38 1073s
# H-Ver = Archer C64 1.0 : S-Ver = 1.11.30 Build 220624 Rel.50807n(5255)
# L = 10.15.17.253 : M = 255.255.255.0
# WAN = DHCP : W = 10.15.17.253 : M = 255.255.255.0 : G = 10.15.17.254
# Cnt = 10624, Free = 10598, Busy = 26
##########################################################################
0days, 00:00:05, [lan]LAN: Set interface br-lan0 ip=192.168.0.254 netmask 255.255.255.0.
0days, 00:00:27, [httpd]Http server start!
0days, 00:00:29, [dhcps]Send OFFER with ip 192.168.0.100.
0days, 00:00:29, [dhcps]Send NAK to 0, lease ip c0a80064.
0days, 00:00:59, [dhcps]IP(A0F1103) not in dhcp pool or equal to server ip, ignore!!!
0days, 00:00:59, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:00:59, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:01:24, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:01:24, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:01:25, [dhcps]Send ACK to 10.15.17.100.
0days, 00:01:25, [inetd]INETD: select error, abort.
0days, 00:01:49, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:02:14, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:02:14, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:02:15, [dhcps]Send ACK to 10.15.17.100.
0days, 00:02:41, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:02:41, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:02:41, [dhcps]Send ACK to 10.15.17.100.
0days, 00:03:05, [inetd]INETD: select error, abort.
0days, 00:03:20, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:03:20, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:03:20, [dhcps]Send ACK to 10.15.17.100.
0days, 00:03:45, [inetd]INETD: select error, abort.
0days, 00:03:46, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:03:46, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:03:47, [dhcps]Send ACK to 10.15.17.100.
0days, 00:04:12, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:04:12, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:04:13, [dhcps]Send ACK to 10.15.17.100.
0days, 00:04:39, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:04:39, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:04:39, [dhcps]Send ACK to 10.15.17.100.
0days, 00:05:05, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:05:05, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:05:05, [dhcps]Send ACK to 10.15.17.100.
0days, 00:05:31, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:05:31, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:05:32, [dhcps]Send ACK to 10.15.17.100.
0days, 00:05:56, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:05:56, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:05:57, [dhcps]Send ACK to 10.15.17.100.
0days, 00:06:24, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:06:45, [inetd]INETD: select error, abort.
0days, 00:06:50, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:06:50, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:06:50, [dhcps]Send ACK to 10.15.17.100.
0days, 00:07:41, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:07:41, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:07:42, [dhcps]Send ACK to 10.15.17.100.
0days, 00:08:05, [inetd]INETD: select error, abort.
0days, 00:08:34, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:08:34, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:08:35, [dhcps]Send ACK to 10.15.17.100.
0days, 00:09:25, [inetd]INETD: select error, abort.
0days, 00:09:53, [dhcps]IP(A0F1103) not in dhcp pool or equal to server ip, ignore!!!
0days, 00:09:54, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:09:54, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:10:17, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:10:17, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:10:18, [dhcps]Send ACK to 10.15.17.100.
0days, 00:10:44, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:10:45, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:10:45, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:10:45, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:10:46, [dhcps]Send ACK to 10.15.17.100.
0days, 00:11:05, [inetd]INETD: select error, abort.
0days, 00:11:10, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:11:10, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:11:11, [dhcps]Send ACK to 10.15.17.100.
0days, 00:11:36, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:11:36, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:11:37, [dhcps]Send ACK to 10.15.17.100.
0days, 00:12:25, [inetd]INETD: select error, abort.
0days, 00:12:29, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:12:30, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:12:30, [dhcps]Send ACK to 10.15.17.100.
0days, 00:12:55, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:13:45, [inetd]INETD: select error, abort.
0days, 00:15:31, [dhcps]IP(A0F1103) not in dhcp pool or equal to server ip, ignore!!!
0days, 00:15:32, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:15:56, [dhcps]Send NAK to 0, lease ip a0f1164.
0days, 00:15:56, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:15:57, [dhcps]Send ACK to 10.15.17.100.
0days, 00:16:45, [inetd]INETD: select error, abort.
0days, 00:17:41, [dhcps]IP(A0F1103) not in dhcp pool or equal to server ip, ignore!!!
0days, 00:17:42, [dhcps]Send OFFER with ip 10.15.17.100.
0days, 00:17:42, [dhcps]Send NAK to 0, lease ip a0f1164.
Название темы: Провайдер отключает интернет
Аппаратная версия устройства: V1
Провайдер: Уфанет
Тип подключения: Dynamic IP
Описание проблемы: Здравствуйте!
Купил роутер после того как провайдер увеличил скорость с 100мбит до 400 мбит.
После установки и настройки прошил до последней версии. Спустя неделю провайдер отключает меня с причиной: «роутер кидает бродкасты в сеть(штормит)», комментарий инженера: «как будто роутер выступает dhcp сервером в сети провайдера и из-за этого ложился интернет у других в сети поблизости». Первоначально думали что это из-за IGMP snooping, но отключив его ничего не поменялось. Роутер сбрасывал, к сожалению логи сохранить никак, роутер был перезагружен после отключения родителями. В чем может быть проблема? Возврат возможен?
UPD: нашел сохраненный лог перед первым отключением(29.01.2022).
##########################################################################
# Archer C80 System Log
# Time = 2022-01-29 15:49:13 314251s
# H-Ver = Archer C80 1.0 : S-Ver = 1.10.0 Build 210716 Rel.51301n(5255)
# L = 192.168.0.1 : M = 255.255.255.0
# WAN = DHCP : W = 0.0.0.0 : M = 0.0.0.0 : G = 0.0.0.0
# Cnt = 10624, Free = 10542, Busy = 82
##########################################################################
0days, 00:00:05, [lan]LAN: Set interface br-lan0 ip=192.168.0.1 netmask 255.255.255.0.
0days, 00:00:27, [httpd]Http server start!
0days, 00:00:31, [wan]Wan ethernet port plug on.
0days, 00:00:32, [dhcpc]Send DISCOVER with unicast flag 0
0days, 00:00:34, [dhcpc]Send DISCOVER with unicast flag 0
0days, 00:00:34, [dhcpc]Recv OFFER from server 100.82.0.1 with ip 100.82.116.152
0days, 00:00:34, [dhcpc]Send REQUEST to server 100.82.0.1 with request ip 100.82.116.152
0days, 00:00:35, [dhcpc]eth0 set ip 100.82.116.152 mask 255.255.128.0 gateway 100.82.0.1
0days, 00:00:35, [wan]advanced ddns -wanChanged
0days, 00:00:35, [wan]systool sntpc -sntpRequest
0days, 00:00:35, [dnsproxy]Register Dns Detect
0days, 00:00:35, [dnsproxy]Register primary = 0x5b2325c, secondary = 0x5c71e51
0days, 00:00:36, [cwmp]cwmp is not start
0days, 00:00:50, [dhcps]Lease host name not found.
0days, 00:20:51, [dhcps]Send OFFER with ip 192.168.0.100.
0days, 00:20:52, [dhcps]Send ACK to 192.168.0.100.
0days, 00:44:44, [dhcps]Send NAK to c0a80065.
0days, 00:44:44, [dhcps]Send OFFER with ip 192.168.0.101.
0days, 00:44:45, [dhcps]Send ACK to 192.168.0.101.
0days, 07:07:41, [dhcps]Send OFFER with ip 192.168.0.101.
0days, 07:07:42, [dhcps]Send ACK to 192.168.0.101.
0days, 10:36:57, [dhcps]Send OFFER with ip 192.168.0.101.
0days, 10:36:58, [dhcps]Send ACK to 192.168.0.101.
0days, 11:24:49, [dhcps]Lease host name not found.
0days, 11:38:02, [dhcps]Send OFFER with ip 192.168.0.102.
0days, 11:38:02, [dhcps]Send OFFER with ip 192.168.0.102.
0days, 11:38:03, [dhcps]Send ACK to 192.168.0.102.
0days, 11:38:03, [dhcps]Send ACK to 192.168.0.102.
0days, 12:24:48, [dhcps]Lease host name not found.
0days, 13:24:47, [dhcps]Lease host name not found.
0days, 14:24:46, [dhcps]Lease host name not found.
0days, 17:48:33, [dhcps]Send OFFER with ip 192.168.0.103.
0days, 17:48:33, [dhcps]Send ACK to 192.168.0.103.
0days, 18:36:36, [dhcps]Send OFFER with ip 192.168.0.104.
0days, 18:36:36, [dhcps]Send ACK to 192.168.0.104.
1days, 07:09:49, [dhcps]Send OFFER with ip 192.168.0.101.
1days, 07:09:50, [dhcps]Send ACK to 192.168.0.101.
1days, 11:44:56, [dhcps]Send OFFER with ip 192.168.0.101.
1days, 11:44:57, [dhcps]Send ACK to 192.168.0.101.
1days, 12:16:32, [dhcps]Lease host name not found.
1days, 13:16:31, [dhcps]Lease host name not found.
1days, 14:16:30, [dhcps]Lease host name not found.
1days, 16:34:52, [dhcps]Lease host name not found.
1days, 17:59:56, [dhcps]Lease host name not found.
1days, 18:59:55, [dhcps]Lease host name not found.
1days, 19:58:05, [dhcps]Send OFFER with ip 192.168.0.104.
1days, 19:58:06, [dhcps]Send ACK to 192.168.0.104.
1days, 19:59:53, [dhcps]Lease host name not found.
1days, 21:58:08, [dhcps]Lease host name not found.
1days, 22:58:07, [dhcps]Lease host name not found.
1days, 23:58:06, [dhcps]Lease host name not found.
2days, 02:01:03, [dhcps]Lease host name not found.
2days, 07:13:57, [dhcps]Send OFFER with ip 192.168.0.101.
2days, 07:13:57, [dhcps]Send ACK to 192.168.0.101.
2days, 10:04:07, [dhcps]Send OFFER with ip 192.168.0.101.
2days, 10:04:07, [dhcps]Send ACK to 192.168.0.101.
2days, 10:19:27, [dhcps]Lease host name not found.
2days, 14:04:13, [dhcps]Send OFFER with ip 192.168.0.101.
2days, 14:04:13, [dhcps]Send OFFER with ip 192.168.0.101.
2days, 14:04:13, [dhcps]Send ACK to 192.168.0.101.
2days, 14:04:13, [dhcps]Send ACK to 192.168.0.101.
2days, 14:46:17, [dhcps]Lease host name not found.
2days, 15:46:16, [dhcps]Lease host name not found.
2days, 15:56:38, [dhcps]Lease host name not found.
2days, 17:47:59, [dhcps]Send OFFER with ip 192.168.0.102.
2days, 17:48:02, [dhcps]Send OFFER with ip 192.168.0.102.
2days, 17:48:11, [dhcps]Send OFFER with ip 192.168.0.102.
2days, 17:48:11, [dhcps]Send ACK to 192.168.0.102.
3days, 10:40:39, [dhcps]Send OFFER with ip 192.168.0.102.
3days, 10:40:39, [dhcps]Send ACK to 192.168.0.102.
3days, 13:10:19, [dhcps]Lease host name not found.
3days, 14:10:18, [dhcps]Lease host name not found.
3days, 14:15:34, [dhcps]Send OFFER with ip 192.168.0.104.
3days, 14:15:34, [dhcps]Send ACK to 192.168.0.104.
3days, 15:11:45, [dhcps]Lease host name not found.
3days, 15:11:45, [inetd]INETD: select error, abort.
3days, 15:11:46, [wan]Wan ethernet port plug off.
3days, 15:11:46, [dnsproxy]Register Dns Detect
3days, 15:11:46, [dnsproxy]register dns server detect error
3days, 15:11:46, [dnsproxy]Register primary = 0x0, secondary = 0x0
3days, 15:11:47, [dhcpc]interface bring down
3days, 15:11:47, [wan]advanced ddns -wanChanged
INETD(8) | FreeBSD System Manager’s Manual | INETD(8) |
NAME
inetd
—
internet “super-server”
SYNOPSIS
inetd |
[-dlWw ] [-a address] [ -C rate] [ -c maximum] [ -p filename] [ -R rate] [ -s maximum] [configuration_file] |
DESCRIPTION
The inetd
utility should be run at boot time by
/etc/rc (see
rc(8)). It
then listens for connections on certain internet sockets. When a connection is
found on one of its sockets, it decides what service the socket corresponds
to, and invokes a program to service the request. The server program is
invoked with the service socket as its standard input, output and error
descriptors. After the program is finished, inetd
continues to listen on the socket (except in some cases which will be
described below). Essentially, inetd
allows running
one daemon to invoke several others, reducing load on the system.
The following options are available:
-a
address- Specify one specific IP address to bind to. Alternatively, a hostname can
be specified, in which case the IPv4 or IPv6 address which corresponds to
that hostname is used. Usually a hostname is specified when
inetd
is run inside a
jail(8),
in which case the hostname corresponds to that of the
jail(8)
environment.When the hostname specification is used and both IPv4 and IPv6
bindings are desired, one entry with the appropriate
protocol type for each binding is required for each
service in /etc/inetd.conf. For example, a
TCP-based service would need two entries, one using “tcp4”
for the protocol and the other using
“tcp6”. See the explanation of the
/etc/inetd.conf protocol field
below. -C
rate- Specify the default maximum number of times a service can be invoked from
a single IP address in one minute; the default is unlimited. May be
overridden on a per-service basis with the
«max-connections-per-ip-per-minute» parameter. -c
maximum- Specify the default maximum number of simultaneous invocations of each
service; the default is unlimited. May be overridden on a per-service
basis with the «max-child» parameter. -d
- Turn on debugging.
-l
- Turn on logging of successful connections.
-p
- Specify an alternate file in which to store the process ID.
-R
rate- Specify the maximum number of times a service can be invoked in one
minute; the default is 256. A rate of 0 allows an unlimited number of
invocations. -s
maximum- Specify the default maximum number of simultaneous invocations of each
service from a single IP address; the default is unlimited. May be
overridden on a per-service basis with the «max-child-per-ip»
parameter. -W
- Turn on TCP Wrapping for internal services which are built in to
inetd
. -w
- Turn on TCP Wrapping for external services. See the
IMPLEMENTATION NOTES
section for more information on TCP Wrappers support.
Upon execution, inetd
reads its
configuration information from a configuration file which, by default, is
/etc/inetd.conf. There must be an entry for each
field of the configuration file, with entries for each field separated by a
tab or a space. Comments are denoted by a “#” at the beginning
of a line. There must be an entry for each field. The fields of the
configuration file are as follows:
service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments
To specify an ONC RPC-based service, the entry would contain these
fields:
service-name/version socket-type rpc/protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments
There are two types of services that inetd
can start: standard and TCPMUX. A standard service has a well-known port
assigned to it; it may be a service that implements an official Internet
standard or is a BSD-specific service. As described
in RFC 1078, TCPMUX services are nonstandard services that do not have a
well-known port assigned to them. They are invoked from
inetd
when a program connects to the
“tcpmux” well-known port and specifies the service name. This
feature is useful for adding locally-developed servers. TCPMUX requests are
only accepted when the multiplexor service itself is enabled, above and
beyond and specific TCPMUX-based servers; see the discussion of internal
services below.
The service-name entry is the name of a valid
service in the file /etc/services, or the
specification of a UNIX domain socket (see below).
For “internal” services (discussed below), the service name
should be the official name of the service (that is, the first entry in
/etc/services). When used to specify an ONC
RPC-based service, this field is a valid RPC service name listed in the file
/etc/rpc. The part on the right of the
“/” is the RPC version number. This can simply be a single
numeric argument or a range of versions. A range is bounded by the low
version to the high version — “rusers/1-3”. For TCPMUX
services, the value of the service-name field consists of
the string “tcpmux” followed by a slash and the locally-chosen
service name. The service names listed in
/etc/services and the name “help” are
reserved. Try to choose unique names for your TCPMUX services by prefixing
them with your organization’s name and suffixing them with a version
number.
The socket-type should be one of
“stream”, “dgram”, “raw”,
“rdm”, or “seqpacket”, depending on whether the
socket is a stream, datagram, raw, reliably delivered message, or sequenced
packet socket. TCPMUX services must use “stream”.
The protocol must be a valid protocol or
“unix”. Examples are “tcp” or
“udp”, both of which imply IPv4 for backward compatibility.
The names “tcp4” and “udp4” specify IPv4 only.
The names “tcp6” and “udp6” specify IPv6 only.
The names “tcp46” and “udp46” specify that the
entry accepts both IPv4 and IPv6 connections via a wildcard
AF_INET6
socket. Rpc based services are specified
with the “rpc/tcp” or “rpc/udp” service type.
One can use specify IPv4 and/or IPv6 with the 4, 6 or 46 suffix, for example
“rpc/tcp6” or “rpc/udp46”. TCPMUX services must
use “tcp”, “tcp4”, “tcp6” or
“tcp46”.
The wait/nowait entry specifies whether the
server that is invoked by inetd
will take over the
socket associated with the service access point, and thus whether
inetd
should wait for the server to exit before
listening for new service requests. Datagram servers must use
“wait”, as they are always invoked with the original datagram
socket bound to the specified service address. These servers must read at
least one datagram from the socket before exiting. If a datagram server
connects to its peer, freeing the socket so inetd
can receive further messages on the socket, it is said to be a
“multi-threaded” server; it should read one datagram from the
socket and create a new socket connected to the peer. It should fork, and
the parent should then exit to allow inetd
to check
for new service requests to spawn new servers. Datagram servers which
process all incoming datagrams on a socket and eventually time out are said
to be “single-threaded”. The
comsat(8)
and
talkd(8)
utilities are examples of the latter type of datagram server. The
tftpd(8)
utility is an example of a multi-threaded datagram server.
Servers using stream sockets generally are multi-threaded and use
the “nowait” entry. Connection requests for these services are
accepted by inetd
, and the server is given only the
newly-accepted socket connected to a client of the service. Most
stream-based services operate in this manner. Stream-based servers that use
“wait” are started with the listening service socket, and must
accept at least one connection request before exiting. Such a server would
normally accept and process incoming connection requests until a timeout.
TCPMUX services must use “nowait”.
The maximum number of outstanding child processes (or
“threads”) for a “nowait” service may be
explicitly specified by appending a “/” followed by the number
to the “nowait” keyword. Normally (or if a value of zero is
specified) there is no maximum. Otherwise, once the maximum is reached,
further connection attempts will be queued up until an existing child
process exits. This also works in the case of “wait” mode,
although a value other than one (the default) might not make sense in some
cases. You can also specify the maximum number of connections per minute for
a given IP address by appending a “/” followed by the number
to the maximum number of outstanding child processes. Once the maximum is
reached, further connections from this IP address will be dropped until the
end of the minute. In addition, you can specify the maximum number of
simultaneous invocations of each service from a single IP address by
appending a “/” followed by the number to the maximum number
of outstanding child processes. Once the maximum is reached, further
connections from this IP address will be dropped.
The user entry should contain the user name of
the user as whom the server should run. This allows for servers to be given
less permission than root. The optional group part
separated by “:” allows a group name other than the default
group for this user to be specified. The optional
login-class part separated by “/” allows
specification of a login class other than the default “daemon”
login class.
The server-program entry should contain the
pathname of the program which is to be executed by
inetd
when a request is found on its socket. If
inetd
provides this service internally, this entry
should be “internal”.
The server-program-arguments entry lists the
arguments to be passed to the server-program, starting
with argv[0], which usually is the name of the program. If the service is
provided internally, the service-name of the service (and
any arguments to it) or the word “internal” should take the
place of this entry.
Currently, the only internal service to take arguments is
“auth”. Without options, the service will always return
“ERROR : HIDDEN-USER”. The available arguments to this
service that alter its behavior are:
-d
fallback- Provide a fallback username. If the real
“auth” service is enabled (with the
-r
option discussed below), return this username
instead of an error when lookups fail for either socket credentials or the
username. If the real “auth” service is disabled, return
this username for every request. This is primarily useful when running
this service on a NAT machine. -F
- Same as
-f
but without the restriction that the
username in .fakeid must not match an existing
user. -f
- If the file .fakeid exists in the home directory
of the identified user, report the username found in that file instead of
the real username. If the username found in
.fakeid is that of an existing user, then the real
username is reported. If the-i
flag is also given
then the username in .fakeid is checked against
existing user IDs instead. -g
- Instead of returning the user’s name to the ident requester, report a
username made up of random alphanumeric characters, e.g.,
“c0c993”. The-g
flag overrides not
only the user names, but also any fallback name,
.fakeid or .noident
files. -i
- Return numeric user IDs instead of usernames.
-n
- If the file .noident exists in the home directory
of the identified user, return “ERROR : HIDDEN-USER”.
This overrides any fakeid file which might
exist. -o
osname- Use osname instead of the name of the system as
reported by
uname(3). -r
- Offer a real “auth” service, as per RFC 1413. All the
remaining flags apply only in this case. -t
sec[.
usec]- Specify a timeout for the service. The default timeout is 10.0
seconds.
The inetd
utility also provides several
other “trivial” services internally by use of routines within
itself. These services are “echo”, “discard”,
“chargen” (character generator), “daytime”
(human readable time), and “time” (machine readable time, in
the form of the number of seconds since midnight, January 1, 1900). All of
these services are available in both TCP and UDP versions; the UDP versions
will refuse service if the request specifies a reply port corresponding to
any internal service. (This is done as a defense against looping attacks;
the remote IP address is logged.) For details of these services, consult the
appropriate RFC document.
The TCPMUX-demultiplexing service is also implemented as an
internal service. For any TCPMUX-based service to function, the following
line must be included in inetd.conf:
tcpmux stream tcp nowait root internal
When given the -l
option
inetd
will log an entry to syslog each time a
connection is accepted, noting the service selected and the IP-number of the
remote requester if available. Unless otherwise specified in the
configuration file, and in the absence of the -W
and
-w
options, inetd
will log
to the “daemon” facility.
The inetd
utility rereads its
configuration file when it receives a hangup signal,
SIGHUP
. Services may be added, deleted or modified
when the configuration file is reread. Except when started in debugging
mode, or configured otherwise with the -p
option,
inetd
records its process ID in the file
/var/run/inetd.pid to assist in reconfiguration.
IMPLEMENTATION
NOTES
TCP
Wrappers
When given the -w
option, inetd
will wrap all services specified as “stream nowait” or
“dgram” except for “internal” services. If the
-W
option is given, such “internal”
services will be wrapped. If both options are given, wrapping for both
internal and external services will be enabled. Either wrapping option will
cause failed connections to be logged to the “auth” syslog
facility. Adding the -l
flag to the wrapping options
will include successful connections in the logging to the “auth”
facility.
Note that inetd
only wraps requests for a
“wait” service while no servers are available to service
requests. Once a connection to such a service has been allowed,
inetd
has no control over subsequent connections to
the service until no more servers are left listening for connection
requests.
When wrapping is enabled, the tcpd daemon
is not required, as that functionality is builtin. For more information on
TCP Wrappers, see the relevant documentation
(hosts_access(5)).
When reading that document, keep in mind that “internal”
services have no associated daemon name. Therefore, the service name as
specified in inetd.conf should be used as the daemon
name for “internal” services.
TCPMUX
RFC 1078 describes the TCPMUX protocol: «A TCP client connects to a foreign
host on TCP port 1. It sends the service name followed by a carriage-return
line-feed <CRLF>. The service name is never case sensitive. The server
replies with a single character indicating positive (+) or negative (-)
acknowledgment, immediately followed by an optional message of explanation,
terminated with a <CRLF>. If the reply was positive, the selected
protocol begins; otherwise the connection is closed.» The program is passed
the TCP connection as file descriptors 0 and 1.
If the TCPMUX service name begins with a “+”,
inetd
returns the positive reply for the program.
This allows you to invoke programs that use stdin/stdout without putting any
special server code in them.
The special service name “help” causes
inetd
to list the TCPMUX services which are enabled
in inetd.conf.
IPsec
The implementation includes a tiny hack to support IPsec policy settings for
each socket. A special form of comment line, starting with
“#@
”, is interpreted as a policy
specifier. Everything after the “#@
”
will be used as an IPsec policy string, as described in
ipsec_set_policy(3).
Each policy specifier is applied to all the following lines in
inetd.conf until the next policy specifier. An empty
policy specifier resets the IPsec policy.
If an invalid IPsec policy specifier appears in
inetd.conf, inetd
will
provide an error message via the
syslog(3)
interface and abort execution.
UNIX Domain Sockets
In addition to running services on IP sockets, inetd
can
also manage UNIX domain sockets. To do this you
specify a protocol of “unix” and specify the
UNIX domain socket as the
service-name. The service-type may be
“stream” or “dgram”. The specification of the
socket must be an absolute path name, optionally prefixed by an owner and mode
of the form :user:group:mode:. The specification:
:news:daemon:220:/var/run/sock
creates a socket owned by user “news” in group
“daemon” with permissions allowing only that user and group to
connect. The default owner is the user that inetd
is
running as. The default mode only allows the socket’s owner to connect.
WARNING: while creating a
UNIX domain socket, inetd
must change the ownership and permissions on the socket. This can only be
done securely if the directory in which the socket is created is writable
only by root. Do NOT use inetd
to
create sockets in world writable directories such as
/tmp; use /var/run or a
similar directory instead.
Internal services may be run on UNIX
domain sockets, in the usual way. In this case the name of the internal
service is determined using the last component of the socket’s pathname. For
example, specifying a socket named /var/run/chargen
would invoke the “chargen” service when a connection is
received on that socket.
FILES
- /etc/inetd.conf
- configuration file
- /etc/netconfig
- network configuration data base
- /etc/rpc
- translation of service names to RPC program numbers
- /etc/services
- translation of service names to port numbers
- /var/run/inetd.pid
- the pid of the currently running
inetd
EXAMPLES
Here are several example service entries for the various types of services:
# The first four launch the relevant daemon when a connection on a port # as defined by /etc/services is opened. ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l ntalk dgram udp wait root /usr/libexec/ntalkd ntalkd telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd shell stream tcp46 nowait root /usr/libexec/rshd rshd # Let the system respond to date requests via tcpmux tcpmux/+date stream tcp nowait guest /bin/date date # Let people access the system phonebook via tcpmux tcpmux/phonebook stream tcp nowait guest /usr/local/bin/phonebook phonebook # Make kernel statistics accessible rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd # Use netcat as a one-shot HTTP proxy with nc (from freebsd-tips fortune) http stream tcp nowait nobody /usr/bin/nc nc -N dest-ip 80 # Set up a unix socket at /var/run/echo that echo's back whatever is written # to it. /var/run/echo stream unix nowait root internal # Run chargen for IPsec Authentication Headers #@ ipsec ah/require chargen stream tcp nowait root internal #@
ERROR
MESSAGES
The inetd
server logs error messages using
syslog(3).
Important error messages and their explanations are:
- service/protocol
server failing (looping), service terminated. - The number of requests for the specified service in the past minute
exceeded the limit. The limit exists to prevent a broken program or a
malicious user from swamping the system. This message may occur for
several reasons:- There are many hosts requesting the service within a short time
period. - A broken client program is requesting the service too frequently.
- A malicious user is running a program to invoke the service in a
denial-of-service attack. - The invoked service program has an error that causes clients to retry
quickly.
Use the
-R
rate
option, as described above, to change the rate limit. Once the limit is
reached, the service will be reenabled automatically in 10 minutes. - There are many hosts requesting the service within a short time
- service/protocol:
No such user user,
service ignored - service/protocol:
getpwnam: user:
No such user - No entry for user exists in the
passwd(5)
database. The first message occurs wheninetd
(re)reads the configuration file. The second message occurs when the
service is invoked. - service: can’t set uid
uid - service: can’t set gid
gid - The user or group ID for the entry’s user field is
invalid. - setsockopt(SO_PRIVSTATE): Operation not supported
- The
inetd
utility attempted to renounce the
privileged state associated with a socket but was unable to. - unknown rpc/udp or
rpc/tcp - No entry was found for either udp or
tcp in the
netconfig(5)
database. - unknown rpc/udp6 or
rpc/tcp6 - No entry was found for either udp6 or
tcp6 in the
netconfig(5)
database.
SEE
ALSO
nc(1),
ipsec_set_policy(3),
hosts_access(5),
hosts_options(5),
login.conf(5),
netconfig(5),
passwd(5),
rpc(5),
services(5),
comsat(8),
fingerd(8),
ftpd(8),
rlogind(8),
rpcbind(8),
rshd(8),
talkd(8),
telnetd(8),
tftpd(8)
Michael C. St. Johns,
Identification Protocol,
RFC1413.
HISTORY
The inetd
utility appeared in
4.3BSD. TCPMUX is based on code and documentation by
Mark Lottor. Support for ONC RPC-based services is modeled after that provided
by SunOS 4.1. The IPsec hack was contributed by the KAME project in 1999. The
FreeBSD TCP Wrappers support first appeared in
FreeBSD 3.2.
Visit the GSP FreeBSD Man Page Interface.
Output converted with ManDoc.
Локальная сеть и интернет: обсуждение/настройка
Автор | Сообщение | ||
---|---|---|---|
|
|||
Member Статус: Не в сети |
Заказал себе TP-Link ARCHER C54 посмотрю как работать будет. |
Реклама | |
Партнер |
S_Snake |
|
Member Статус: Не в сети |
PhenixN70, шикарно работает, лучшая модель за свою стоимость. |
europhase |
|
Member Статус: Не в сети |
Доброго дня. Не знаю правильно ли сюда задавать подобный вопрос, но попробую. Требуется утилита/программа для Win10 с простой функцией отключения и включения сетевого адаптера (подключения). |
S_Snake |
|
Member Статус: Не в сети |
europhase, чем «в самолёте не устраивает»? |
Evil_Side |
|
Member Статус: Не в сети |
смотрим адаптеры Код: netsh interface show interface выбираем нужный и гасим Код: netsh interface set interface “Имя адаптера” disable включаем обратно Код: netsh interface set interface “Имя адаптера” enable Создаем ярлыки батников, в свойствах ярлыка есть пункт «Быстрый вызов» туда назначаем клавишу |
europhase |
|
Member Статус: Не в сети |
S_Snake писал(а): europhase, чем «в самолёте не устраивает»? Нужно именно адаптер отключать. Evil_Side Добавлено спустя 19 минут 19 секунд: Код: netsh interface set interface name=»Подключение по локальной сети» admin=DISABLED Но не могу разобраться как отключить UAC только для этих двух батников? Вроде нашел способ прописать в реестре, все сделал, а нифига не работает… |
KoRn0509 |
|
Member Статус: Не в сети |
Приветствую. Есть vps на котором установлен vpn wireguard. Есть комп, на котором есть только ipv4 соединение PPPoE. Если я подключаюсь через приложение на пк, то у меня работает ipv6 через wireguard. Все супер. Сейчас поставил на свой роутер openwrt, настроил wireguard, все работает но ipv6 нет. Подскажите, как сделать так, чтобы ipv6 заработал. |
Makc1968 |
|
Заблокирован Статус: Не в сети |
KoRn0509 писал(а): поставил на свой роутер openwrt KoRn0509 писал(а): как сделать так, чтобы ipv6 заработал Логично же: задать этот вопрос создателям openwrt или почитать их форумы. |
KoRn0509 |
|
Member Статус: Не в сети |
Makc1968 писал(а): Логично же: задать этот вопрос создателям openwrt или почитать их форумы. Тема называется Локальная сеть и интернет: обсуждение/настройка |
elisei89 |
|
||
Junior Статус: Не в сети |
Кто разбирается,можете глянуть,есть ли проблемы?Обновил роутер,поменял скорость(билайн)был 100 мегабит,поставил 500.Скорость скачки отличная стала,браузеры без проблем,онлайн видео тоже(может на 2-10 секунд подгружать) Извиняюсь(не получилось спойлер закрытый сделат)на 4pda без проблем,тут нет( Archer C80 System Log ##########################################################################
|
Hitechik |
|
Member Статус: Не в сети |
Судя по тому как ты описал проблему между роутером и твоим ПК(коннектора, соединение, кабель, сетевая) Проверяется заменой патчкорда(если роутер далеко, то временно поднести пк) |
elisei89 |
|
Junior Статус: Не в сети |
Hitechik писал(а): Проверяется заменой патчкорда(если роутер далеко, то временно поднести пк) не совсем понял как это сделать? |
Йож |
|
Member Статус: Не в сети |
elisei89 писал(а): от роутера в пк возьми кампутхер и подтащи к раутеру. и соедини нормальным проводом а не тем дерьмом импортозамещением, что сейчас используешь. и что будет. |
elisei89 |
|
Junior Статус: Не в сети |
Йож писал(а): возьми кампутхер и подтащи к раутеру. и соедини нормальным проводом а не тем дерьмом импортозамещением, что сейчас используешь. и что будет. роутер прямо над блоком пк висит,все рядом.. Фото роутера(если поставлю 100 порежет скорость,если 1000 просто не будет соединения интернета)Killer E2500 Gigabit Ethernet Controller—сетевая вот. |
S_Snake |
|
Member Статус: Не в сети |
elisei89 писал(а): был 100 мегабит,поставил 500 такие скорости лучше PON’у доверять, а не меди, тем более неэкранированной. |
Йож |
|
Member Статус: Не в сети |
elisei89 писал(а): 1000 ставишь,тогда билайн не запускает интернет… нашел в потоке мысли информацию. |
elisei89 |
|
Junior Статус: Не в сети |
Йож писал(а): всунуть провод от провайдера в комп без раутера и выставить гигабит руками что будет? гигабит только на роутере доступен,на встроенной максимум 100 в настройках (Speed Duplex)если только менять на внешнюю(которая вставляется)попробую на днях без роутера,если не каких проблем не будет,значит проблема в роутере(прошивки и тд)Я ищу на 4pda информацию какую нить,есть проблемы на билайне( IpoE ,L2TP)что разрывы,теряет скорость..но обсуждения в 20-21 годах.А у меня напрямую динамический IP,вставил в роутер кабель билайна,и все само. |
Hitechik |
|
Member Статус: Не в сети |
elisei89 писал(а): гигабит только на роутере доступен,на встроенной максимум 100 в настройках (Speed Duplex)если только менять на внешнюю(которая вставляется)попробую на днях без роутера,если не каких проблем не будет,значит проблема в роутере(прошивки и тд)Я ищу на 4pda информацию какую нить,есть проблемы на билайне( IpoE ,L2TP)что разрывы,теряет скорость..но обсуждения в 20-21 годах.А у меня напрямую динамический IP,вставил в роутер кабель билайна,и все само. Какой роутер? У билайна до сих пор l2tp? S_Snake писал(а): такие скорости лучше PON’у доверять, а не меди, тем более неэкранированной. Твоего уровня знаний не хватает для этой ветки. Удачи. |
elisei89 |
|
Junior Статус: Не в сети |
Hitechik писал(а): Какой роутер? У билайна до сих пор l2tp? Про l2tp точно не знаю,но наверное кто то использует.У меня динамический стоит.Роутер Tplink archer c80(пишут многие что плохо дружит с билайном)прошивка последняя стоит,кабель интернета целый,обжат(монтажник обжимал под новый тариф) Добавлено спустя 5 часов 19 минут 44 секунды: |
S_Snake |
|
Member Статус: Не в сети |
Hitechik писал(а): Твоего уровня знаний не хватает для этой ветки. Удачи. твоих, видимо, тоже, по этому ты здесь. ты бы, для начала, рассказал какой технологией пользуешься, чтоб понимать что обсуждать. |
—
Кто сейчас на конференции |
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6 |
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
Лаборатория
Новости
Материал из Xgu.ru
Перейти к: навигация, поиск
Не указан параметр (1)
INETD(8) FreeBSD System Manager’s Manual INETD(8)
Содержание
- 1 NAME
- 2 SYNOPSIS
- 3 DESCRIPTION
- 4 IMPLEMENTATION NOTES
- 5 FILES
- 6 EXAMPLES
- 7 ERROR MESSAGES
- 8 SEE ALSO
- 9 HISTORY
[править] NAME
inetd -- internet ``super-server
[править] SYNOPSIS
inetd [-d] [-l] [-w] [-W] [-c maximum] [-C rate] [-a address | hostname] [-p filename] [-R rate] [-s maximum] [configuration file]
[править] DESCRIPTION
The inetd utility should be run at boot time by /etc/rc (see rc(8)). It then listens for connections on certain internet sockets. When a connec- tion is found on one of its sockets, it decides what service the socket corresponds to, and invokes a program to service the request. The server program is invoked with the service socket as its standard input, output and error descriptors. After the program is finished, inetd continues to listen on the socket (except in some cases which will be described below). Essentially, inetd allows running one daemon to invoke several others, reducing load on the system.
The following options are available:
-d Turn on debugging.
-l Turn on logging of successful connections.
-w Turn on TCP Wrapping for external services. See the IMPLEMENTATION NOTES section for more information on TCP Wrappers support.
-W Turn on TCP Wrapping for internal services which are built in to inetd.
-c maximum Specify the default maximum number of simultaneous invocations of each service; the default is unlimited. May be overridden on a per-service basis with the "max-child" parameter.
-C rate Specify the default maximum number of times a service can be invoked from a single IP address in one minute; the default is unlimited. May be overridden on a per-service basis with the "max-connections-per-ip-per-minute" parameter.
-R rate Specify the maximum number of times a service can be invoked in one minute; the default is 256. A rate of 0 allows an unlimited number of invocations.
-s maximum Specify the default maximum number of simultaneous invocations of each service from a single IP address; the default is unlimited. May be overridden on a per-service basis with the "max-child-per- ip" parameter.
-a Specify one specific IP address to bind to. Alternatively, a hostname can be specified, in which case the IPv4 or IPv6 address which corresponds to that hostname is used. Usually a hostname is specified when inetd is run inside a jail(8), in which case the hostname corresponds to that of the jail(8) environment.
When the hostname specification is used and both IPv4 and IPv6 bindings are desired, one entry with the appropriate protocol type for each binding is required for each service in /etc/inetd.conf. For example, a TCP-based service would need two entries, one using ``tcp4 for the protocol and the other using ``tcp6. See the explanation of the /etc/inetd.conf protocol field below.
-p Specify an alternate file in which to store the process ID.
Upon execution, inetd reads its configuration information from a configu- ration file which, by default, is /etc/inetd.conf. There must be an entry for each field of the configuration file, with entries for each field separated by a tab or a space. Comments are denoted by a ``# at the beginning of a line. There must be an entry for each field. The fields of the configuration file are as follows:
service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments
To specify an ONC RPC-based service, the entry would contain these fields:
service-name/version socket-type rpc/protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments
There are two types of services that inetd can start: standard and TCP- MUX. A standard service has a well-known port assigned to it; it may be a service that implements an official Internet standard or is a BSD-specific service. As described in RFC 1078, TCPMUX services are non- standard services that do not have a well-known port assigned to them. They are invoked from inetd when a program connects to the ``tcpmux well-known port and specifies the service name. This feature is useful for adding locally-developed servers. TCPMUX requests are only accepted when the multiplexor service itself is enabled, above and beyond and spe- cific TCPMUX-based servers; see the discussion of internal services below.
The service-name entry is the name of a valid service in the file /etc/services, or the specification of a UNIX domain socket (see below). For ``internal services (discussed below), the service name should be the official name of the service (that is, the first entry in /etc/services). When used to specify an ONC RPC-based service, this field is a valid RPC service name listed in the file /etc/rpc. The part on the right of the ``/ is the RPC version number. This can simply be a single numeric argument or a range of versions. A range is bounded by the low version to the high version - ``rusers/1-3. For TCPMUX ser- vices, the value of the service-name field consists of the string ``tcpmux followed by a slash and the locally-chosen service name. The service names listed in /etc/services and the name ``help are reserved. Try to choose unique names for your TCPMUX services by prefixing them with your organization's name and suffixing them with a version number.
The socket-type should be one of ``stream, ``dgram, ``raw, ``rdm, or ``seqpacket, depending on whether the socket is a stream, datagram, raw, reliably delivered message, or sequenced packet socket. TCPMUX ser- vices must use ``stream.
The protocol must be a valid protocol or ``unix. Examples are ``tcp or ``udp, both of which imply IPv4 for backward compatibility. The names ``tcp4 and ``udp4 specify IPv4 only. The names ``tcp6 and ``udp6 specify IPv6 only. The names ``tcp46 and ``udp46 specify that the entry accepts both IPv4 and IPv6 connections via a wildcard AF_INET6 socket. Rpc based services are specified with the ``rpc/tcp or ``rpc/udp service type. One can use specify IPv4 and/or IPv6 with the 4, 6 or 46 suffix, for example ``rpc/tcp6 or ``rpc/udp46. TCPMUX services must use ``tcp, ``tcp4, ``tcp6 or ``tcp46.
The wait/nowait entry specifies whether the server that is invoked by inetd will take over the socket associated with the service access point, and thus whether inetd should wait for the server to exit before listen- ing for new service requests. Datagram servers must use ``wait, as they are always invoked with the original datagram socket bound to the specified service address. These servers must read at least one datagram from the socket before exiting. If a datagram server connects to its peer, freeing the socket so inetd can receive further messages on the socket, it is said to be a ``multi-threaded server; it should read one datagram from the socket and create a new socket connected to the peer. It should fork, and the parent should then exit to allow inetd to check for new service requests to spawn new servers. Datagram servers which process all incoming datagrams on a socket and eventually time out are said to be ``single-threaded. The comsat(8) and talkd(8) utilities are examples of the latter type of datagram server. The tftpd(8) utility is an example of a multi-threaded datagram server.
Servers using stream sockets generally are multi-threaded and use the ``nowait entry. Connection requests for these services are accepted by inetd, and the server is given only the newly-accepted socket connected to a client of the service. Most stream-based services operate in this manner. Stream-based servers that use ``wait are started with the lis- tening service socket, and must accept at least one connection request before exiting. Such a server would normally accept and process incoming connection requests until a timeout. TCPMUX services must use ``nowait.
The maximum number of outstanding child processes (or ``threads) for a ``nowait service may be explicitly specified by appending a ``/ fol- lowed by the number to the ``nowait keyword. Normally (or if a value of zero is specified) there is no maximum. Otherwise, once the maximum is reached, further connection attempts will be queued up until an exist- ing child process exits. This also works in the case of ``wait mode, although a value other than one (the default) might not make sense in some cases. You can also specify the maximum number of connections per minute for a given IP address by appending a ``/ followed by the number to the maximum number of outstanding child processes. Once the maximum is reached, further connections from this IP address will be dropped until the end of the minute. In addition, you can specify the maximum number of simultaneous invocations of each service from a single IP address by appending a ``/ followed by the number to the maximum number of outstanding child processes. Once the maximum is reached, further connections from this IP address will be dropped.
The user entry should contain the user name of the user as whom the server should run. This allows for servers to be given less permission than root. The optional group part separated by ``: allows a group name other than the default group for this user to be specified. The optional login-class part separated by ``/ allows specification of a login class other than the default ``daemon login class.
The server-program entry should contain the pathname of the program which is to be executed by inetd when a request is found on its socket. If inetd provides this service internally, this entry should be ``internal.
The server-program-arguments entry lists the arguments to be passed to the server-program, starting with argv[0], which usually is the name of the program. If the service is provided internally, the service-name of the service (and any arguments to it) or the word ``internal should take the place of this entry.
Currently, the only internal service to take arguments is ``auth. Without options, the service will always return ``ERROR : HIDDEN-USER. The available arguments to this service that alter its behavior are:
-d fallback Provide a fallback username. If the real ``auth service is enabled (with the -r option discussed below), return this user- name instead of an error when lookups fail for either socket cre- dentials or the username. If the real ``auth service is dis- abled, return this username for every request. This is primarily useful when running this service on a NAT machine.
-g Instead of returning the user's name to the ident requester, report a username made up of random alphanumeric characters, e.g. ``c0c993. The -g flag overrides not only the user names, but also any fallback name, .fakeid or .noident files.
-t sec[.usec] Specify a timeout for the service. The default timeout is 10.0 seconds.
-r Offer a real ``auth service, as per RFC 1413. All the remain- ing flags apply only in this case.
-i Return numeric user IDs instead of usernames.
-f If the file .fakeid exists in the home directory of the identi- fied user, report the username found in that file instead of the real username. If the username found in .fakeid is that of an existing user, then the real username is reported. If the -i flag is also given then the username in .fakeid is checked against existing user IDs instead.
-F same as -f but without the restriction that the username in .fakeid must not match an existing user.
-n If the file .noident exists in the home directory of the identi- fied user, return ``ERROR : HIDDEN-USER. This overrides any fakeid file which might exist.
-o osname Use osname instead of the name of the system as reported by uname(3).
The inetd utility also provides several other ``trivial services inter- nally by use of routines within itself. These services are ``echo, ``discard, ``chargen (character generator), ``daytime (human read- able time), and ``time (machine readable time, in the form of the num- ber of seconds since midnight, January 1, 1900). All of these services are available in both TCP and UDP versions; the UDP versions will refuse service if the request specifies a reply port corresponding to any inter- nal service. (This is done as a defense against looping attacks; the remote IP address is logged.) For details of these services, consult the appropriate RFC document.
The TCPMUX-demultiplexing service is also implemented as an internal ser- vice. For any TCPMUX-based service to function, the following line must be included in inetd.conf:
tcpmux stream tcp nowait root internal
When given the -l option inetd will log an entry to syslog each time a connection is accepted, noting the service selected and the IP-number of the remote requester if available. Unless otherwise specified in the configuration file, and in the absence of the -W and -w options, inetd will log to the ``daemon facility.
The inetd utility rereads its configuration file when it receives a hangup signal, SIGHUP. Services may be added, deleted or modified when the configuration file is reread. Except when started in debugging mode, or configured otherwise with the -p option, inetd records its process ID in the file /var/run/inetd.pid to assist in reconfiguration.
[править] IMPLEMENTATION NOTES
TCP Wrappers When given the -w option, inetd will wrap all services specified as ``stream nowait or ``dgram except for ``internal services. If the -W option is given, such ``internal services will be wrapped. If both options are given, wrapping for both internal and external services will be enabled. Either wrapping option will cause failed connections to be logged to the ``auth syslog facility. Adding the -l flag to the wrap- ping options will include successful connections in the logging to the ``auth facility.
Note that inetd only wraps requests for a ``wait service while no servers are available to service requests. Once a connection to such a service has been allowed, inetd has no control over subsequent connec- tions to the service until no more servers are left listening for connec- tion requests.
When wrapping is enabled, the tcpd daemon is not required, as that func- tionality is builtin. For more information on TCP Wrappers, see the rel- evant documentation (hosts_access(5)). When reading that document, keep in mind that ``internal services have no associated daemon name. Therefore, the service name as specified in inetd.conf should be used as the daemon name for ``internal services.
TCPMUX RFC 1078 describes the TCPMUX protocol: ``A TCP client connects to a for- eign host on TCP port 1. It sends the service name followed by a car- riage-return line-feed <CRLF>. The service name is never case sensitive. The server replies with a single character indicating positive (+) or negative (-) acknowledgment, immediately followed by an optional message of explanation, terminated with a <CRLF>. If the reply was positive, the selected protocol begins; otherwise the connection is closed. The pro- gram is passed the TCP connection as file descriptors 0 and 1.
If the TCPMUX service name begins with a ``+, inetd returns the posi- tive reply for the program. This allows you to invoke programs that use stdin/stdout without putting any special server code in them.
The special service name ``help causes inetd to list the TCPMUX ser- vices which are enabled in inetd.conf.
IPsec The implementation includes a tiny hack to support IPsec policy settings for each socket. A special form of comment line, starting with ``#@, is interpreted as a policy specifier. Everything after the ``#@ will be used as an IPsec policy string, as described in ipsec_set_policy(3). Each policy specifier is applied to all the following lines in inetd.conf until the next policy specifier. An empty policy specifier resets the IPsec policy.
If an invalid IPsec policy specifier appears in inetd.conf, inetd will provide an error message via the syslog(3) interface and abort execution.
UNIX Domain Sockets In addition to running services on IP sockets, inetd can also manage UNIX domain sockets. To do this you specify a protocol of ``unix and spec- ify the UNIX domain socket as the service-name. The service-type may be ``stream or ``dgram. The specification of the socket must be an absolute path name, optionally prefixed by an owner and mode of the form :user:group:mode:. The specification:
:news:daemon:220:/var/run/sock
creates a socket owned by user ``news in group ``daemon with permis- sions allowing only that user and group to connect. The default owner is the user that inetd is running as. The default mode only allows the socket's owner to connect.
WARNING: while creating a UNIX domain socket, inetd must change the own- ership and permissions on the socket. This can only be done securely if the directory in which the socket is created is writable only by root. Do NOT use inetd to create sockets in world writable directories such as /tmp; use /var/run or a similar directory instead.
Internal services may be run on UNIX domain sockets, in the usual way. In this case the name of the internal service is determined using the last component of the socket's pathname. For example, specifying a socket named /var/run/chargen would invoke the ``chargen service when a connection is received on that socket.
[править] FILES
/etc/inetd.conf configuration file /etc/netconfig network configuration data base /etc/rpc translation of service names to RPC program numbers /etc/services translation of service names to port numbers /var/run/inetd.pid the pid of the currently running inetd
[править] EXAMPLES
Here are several example service entries for the various types of ser- vices:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l ntalk dgram udp wait root /usr/libexec/ntalkd ntalkd telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd shell stream tcp46 nowait root /usr/libexec/rshd rshd tcpmux/+date stream tcp nowait guest /bin/date date tcpmux/phonebook stream tcp nowait guest /usr/local/bin/phonebook phonebook rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd /var/run/echo stream unix nowait root internal #@ ipsec ah/require chargen stream tcp nowait root internal #@
[править] ERROR MESSAGES
The inetd server logs error messages using syslog(3). Important error messages and their explanations are:
service/protocol server failing (looping), service terminated. The number of requests for the specified service in the past minute exceeded the limit. The limit exists to prevent a broken program or a malicious user from swamping the system. This message may occur for sev- eral reasons:
1. There are many hosts requesting the service within a short time period.
2. A broken client program is requesting the service too fre- quently.
3. A malicious user is running a program to invoke the service in a denial-of-service attack.
4. The invoked service program has an error that causes clients to retry quickly.
Use the -R rate option, as described above, to change the rate limit. Once the limit is reached, the service will be reenabled automatically in 10 minutes.
service/protocol: No such user user, service ignored service/protocol: getpwnam: user: No such user No entry for user exists in the passwd(5) database. The first message occurs when inetd (re)reads the configuration file. The second message occurs when the service is invoked.
service: can't set uid uid service: can't set gid gid The user or group ID for the entry's user field is invalid.
setsockopt(SO_PRIVSTATE): Operation not supported The inetd utility attempted to renounce the privileged state associated with a socket but was unable to.
unknown rpc/udp or rpc/tcp No entry was found for either udp or tcp in the netconfig(5) database.
unknown rpc/udp6 or rpc/tcp6 No entry was found for either udp6 or tcp6 in the netconfig(5) database.
[править] SEE ALSO
ipsec_set_policy(3), hosts_access(5), hosts_options(5), login.conf(5), netconfig(5), passwd(5), rpc(5), services(5), comsat(8), fingerd(8), ftpd(8), rlogind(8), rpcbind(8), rshd(8), talkd(8), telnetd(8), tftpd(8)
Michael C. St. Johns, Identification Protocol, RFC1413.
[править] HISTORY
The inetd utility appeared in 4.3BSD. TCPMUX is based on code and docu- mentation by Mark Lottor. Support for ONC RPC based services is modeled after that provided by SunOS 4.1. The IPsec hack was contributed by the KAME project in 1999. The FreeBSD TCP Wrappers support first appeared in FreeBSD 3.2.
FreeBSD 9.0 January 12, 2008 FreeBSD 9.0
п·о·р Manual |
|
---|---|
a |
|
b | список |
c |
|
d | * disklabel(8): disklabel • man/disklabel • man/orig/disklabel • Пример использования disklabel |
e | список |
f |
|
g | список |
h | список |
i | список |
j | список |
k | список |
l |
|
m |
|
n |
|
o | список |
p |
|
q | список |
r |
|
s | список |
t | список |
u | список |
v | * vmstat(8): vmstat • man/vmstat • man/orig/vmstat • Пример использования vmstat |
w |
|
x | список |
y | список |
z | список |