Read and Safely Audit /etc/protocols with getent

Get a protocol number wrong in a script and you can send packets under the wrong label, which is a quietly miserable thing to debug. This guide gets you inspecting the Linux protocol-name database safely, looking up names and numbers through the system's configured name service, and knowing when local data needs a second look. The examples use the protocols(5) manpage from Linux man-pages 6.7, installed here from package manpages 6.7-2.

Allow about ten minutes. You need a shell and an ordinary account. This guide only reads configuration and performs lookups. It does not edit /etc/protocols, reload networking or send packets, so none of it needs sudo.

1. Confirm the file and the installed contract

Start by checking the file exists and reading the local manual, rather than assuming a different Unix implementation uses the same format:

$ command -v getent
/usr/bin/getent
$ dpkg-query -W -f='${Package} ${Version}\n' manpages
manpages 6.7-2
$ man 5 protocols

The manual describes /etc/protocols as a plain ASCII file listing the protocols available to the TCP/IP subsystem. Its entries supply protocol information used in IP headers. It is not a firewall policy and it does not enable or disable a protocol, no matter how tempting that reading is.

2. Inspect entries without changing them

Read the file as an unprivileged user. The first field is the native protocol name, the second its official number, and later fields are optional aliases:

$ sed -n '1,18p' /etc/protocols
# Internet (IP) protocols
#
# Updated from http://www.iana.org/assignments/protocol-numbers and other
...
icmp    1    ICMP    # internet control message protocol
tcp     6    TCP     # transmission control protocol
udp     17   UDP     # user datagram protocol

Your header and spacing may differ. Empty lines are ignored, and a hash mark starts a comment, so the comment text is never part of the protocol name, number or aliases. Spaces and tabs separate fields; do not treat the columns as fixed-width.

Filter for one family of entries when that is all you need:

$ awk '!/^([[:space:]]*#|[[:space:]]*$)/ && ($1 == "icmp" || $1 == "tcp" || $1 == "udp")' /etc/protocols
icmp    1    ICMP    # internet control message protocol
tcp     6    TCP     # transmission control protocol
udp     17   UDP     # user datagram protocol

This only prints matching lines. It does not confirm a number is currently assigned by IANA, and it says nothing about whether another machine carries the same file.

3. Query the configured protocols database

For a program-facing check, use getent. It asks the Name Service Switch for the protocols database, which commonly includes /etc/protocols but can be configured differently. Query by name:

$ getent protocols tcp
tcp                   6 TCP
$ getent protocols udp
udp                   17 UDP
$ getent protocols icmp
icmp                  1 ICMP

Column spacing is presentation, not a value to parse by character position. The useful fields are the name, decimal number and aliases, and the exact output can vary with the configured NSS sources.

Numbers work here too:

$ getent protocols 6
tcp                   6 TCP
$ getent protocols 17
udp                   17 UDP

Check the exit status when scripting, rather than trusting the displayed text:

$ if getent protocols tcp >/dev/null; then
>     echo 'tcp is resolvable'
> else
>     echo 'tcp was not found' >&2
>     exit 1
> fi
tcp is resolvable

4. Distinguish local data from an authoritative assignment

The local file is operational input for name lookups, but protocol numbers themselves are assigned by IANA. A local line can be stale, customised or present for a kernel-specific reason. The IANA registry, in turn, can hold assignments never copied into this host's file. Compare the decimal number and keyword against the IANA Protocol Numbers registry whenever you are reviewing a discrepancy.

Do not swap a local name for a number just because both look familiar. The number is what actually appears in the IP header; the name and aliases are only the local lookup vocabulary. Applications should use the system lookup interfaces or getent, never a hard-coded guess.

For a quick comparison of common entries:

$ getent protocols tcp udp icmp
tcp                   6 TCP
udp                   17 UDP
icmp                  1 ICMP

If your implementation only accepts one key per invocation, run the three commands separately. Treat an absent result as a lookup failure, never as permission to invent a new number.

5. Do not edit /etc/protocols casually

Before any proposed change, record the current file and identify the application and authoritative source that need it. A privileged edit also needs a maintenance and rollback plan:

$ cp --preserve=all /etc/protocols /path/to/secure-backup/protocols.before-change
$ diff -u /etc/protocols /path/to/proposed-protocols

The first command needs permission to read /etc/protocols and write the chosen backup directory: do not paste that placeholder path as-is. If a change has already caused trouble, restore only a known-good backup after checking its ownership and contents, then rerun the getent checks. Restoring the file does not undo packets already sent or repair applications that cached old results, so restart only the affected application when its own documentation calls for it.

6. Diagnose the usual distractions

• No output. The requested key was not in the configured protocols database. Check spelling, case and the NSS configuration before you blame a different machine.
• Different aliases. Aliases are optional and can differ between distributions. Use the native name and number this host returns when diagnosing local software.
• Unexpected entries. Inspect /etc/protocols and the system's NSS configuration; do not assume getent read only this file.
• Permission errors. Fix the read permission or access path through normal administration. Do not make the file world-writable to make an error go away.

Keep packet capture and firewall testing separate from this file audit. A successful lookup says a name-to-number record is available; it says nothing about routes, sockets, firewall rules or whether a peer even supports the protocol.