Error message "Af_inet In Raw Sendmsg " observed in /var/log/messages logfile
search cancel

Error message "Af_inet In Raw Sendmsg " observed in /var/log/messages logfile


Article ID: 48633


Updated On:


CA Spectrum


In the /var/log/messages logfile, the following entry was observed after a reboot of the server:

Apr 2 08:59:41 sgsi2x0008 kernel: SpectroSERVER forgot to set AF_INET in raw

sendmsg. Fix it!

Mar 6 16:58:03 sgsi2x0009 kernel: SpectroSERVER forgot to set AF_INET in raw


Release: Any Spectrum version installed on Linux


Because of the error message making reference to the SpectroSERVER this error message appears to be a SpectroSERVER problem.

However this is an informational message and should not be considered an error.

We use sendmsg() socket call in Epapi library. From the whole Spectrum, TL1 communication part of Spectrum mostly uses these library calls.

sendmsg(int fd,struct msghdr*,int flags)

  1. fd is the valid file descriptor obtained from the socket call
  2. msgheader which is used to pass the information to kernel like destination address and the buffer
  3. The flags can be passed as 0

For us the most interesting thing is struct msghdr, the msghdr has a pointer to msg_iov which contains the buffer pointer, struct iovec is used for scatter/gather i/o

struct iovec iov;
iov.iov_base = buf ;
iov.iov_len = pkt_len;

Once the struct iovec is initialized it is assigned to the msghdr structure
msg.msg_iov = &iov;

Then msghdr has other fields like msg_name and msg_namelen, which are useto fill the destination address, for inet socket we use struct sockaddr_in to fill the destination address and port.

The msg_name is used when you don't have a valid connection. We have a valid connection so we will set the pointer to NULL.

Because of this, we will not be setting the AF_INET for sendmsg call.

If the customer has any custom apps or integration modules(where they initializing a raw socket without AF_INET) and are making sendmsg calls,this can be lead to this informational/error message. SpectroSERVER is just showing up in the message but is not the culprit.