Bug 264739 - send(2) doesn't document EAFNOSUPPORT error
Summary: send(2) doesn't document EAFNOSUPPORT error
Status: New
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-17 17:30 UTC by Yuri Victorovich
Modified: 2022-06-30 21:38 UTC (History)
3 users (show)

See Also:

Attachments
patch on port security/suricata (1008 bytes, patch)
2022-06-30 21:38 UTC, Peter Much 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer freebsd_triage 2022-06-17 17:30:30 UTC 
EAFNOSUPPORT can de-facto be returned by sendto() but it isn't documented.

13.1
Comment 1 Pau Amma 2022-06-18 13:42:43 UTC 
(In reply to Yuri Victorovich from comment #0)

In which cases could that happen, both theoretically and (considering that there was no EAFNOSUPPORT error from the socket(2) that presumably happened earlier) in 
 practice? Recipient address/protocol family (implicit in send, explicit in sendto) different from sender address/protocol family?
Comment 2 Yuri Victorovich freebsd_committer freebsd_triage 2022-06-18 13:48:56 UTC 
(In reply to PauAmma from comment #1)

This happens when the address type doesn't match the socket type.
Comment 3 Pau Amma 2022-06-19 11:47:26 UTC 
(In reply to Yuri Victorovich from comment #2)

Unless I misunderstand you, you're saying more tersely the same thing I was reaching for in "Recipient address/protocol family (implicit in send, explicit in sendto) different from sender address/protocol family?". (Perhaps "different from" should be "incompatible with".) I'd use "Destination address family incompatible with protocol set for sending socket" for the error description and, to follow the same order as share/examples/mdoc/example.3, insert it after EMSGSIZE. Does that sound right?
Comment 4 Yuri Victorovich freebsd_committer freebsd_triage 2022-06-19 15:22:21 UTC 
(In reply to PauAmma from comment #3)

I agree. I just accidentally hit this error due to a programming mistake and reported it here as missing in docs.

In my case the address supplied to sendto() was garbage.


Yuri
Comment 5 Peter Much 2022-06-30 21:37:10 UTC 
I was just hit by this bug also, as it crashes my IPS:

suricata[13989]: [105773] <Warning> -- [ERRCODE: SC_WARN_IPFW_XMIT(84)] - Write to ipfw divert socket failed: Address family not supported by protocol family
suricata[13989]: [105588] <Error> -- [ERRCODE: SC_ERR_FATAL(171)] - thread W-8677 failed

This happens every time at the moment when an SMTP connection via IPv6 switches to STARTTLS. (I can do it manually in telnet: the connection builds up normally, and after I type in STARTTLS on the client side, the crash happens.)

I do not see why the protocol family of an active tcp session on port 25 would change when deciding to do TLS.

For now I have changed the IPS to ignore this errorcode, and apparently that helps - a mail went through successfully, with no anomalies visible in tcpdump.

I'll attach my patch on security/suricata
Comment 6 Peter Much 2022-06-30 21:38:40 UTC 
Created attachment 235009 [details]
patch on port security/suricata