1. The GNATS problem report database does acknowledge all properly 
submitted reports with an E-mail which includes the assigned PR 
number. If you didn't get such a confirmation, the three most likely 
possibilities are:

1.1. the PR was improperly formatted (e.g. some mailer strip the ">" 
in front of the PR field names)

1.2. the return address on the PR submission E-mail is unreplyable 
(i.e. no A or MX record reachable from gnats.netbsd.org, or a 
firewall in the way). If a host can send E-mail, it must have at 
least an MX record in the public DNS.

1.3. the gnats.netbsd.org host never got the problem report in the 
first place (check your mail system log and the outbound mail queue - 
is the report still in there?)

I can speak with some authority in this matter - I do a lot of the 
NetBSD GNATS PR database administration.

2. As for the relevance of PR kern/7285, I assert it is directly 
germane, because you're reporting an ENOBUFS error and describing 
some of the associated conditions, but we can't tell why that error 
code is being returned because it can be returned for at least two 
different conditions: no mbufs available, or I/F output queue full. 
This is not a matter of how an application invokes this behavior - 
it's a matter of being unable to distinguish between two distinct 
error conditions which an application should likely handle 
differently. It's kernel/userland API problem.

This is why David asked for the output of "netstat -m" - he's trying 
to eliminate the "no mbufs available" case by looking to see if all 
the mbufs are in use.

	Erik <fair@netbsd.org>