Re: 7.1 & nsd - failed writing to tcp: Permission denied
On 2022-04-22, Laura Smith wrote: > --- Original Message --- > On Friday, April 22nd, 2022 at 18:16, Peter J. Philipp > wrote: > >> So that's weird becuase the 3-way handshake must have completed for nsd to >> reply a query. Meaning there was SYN's and ACK's being exchanged but perhaps >> a PUSH+ACK may not succeed through the pf rules? >> >> Don't post your firewall rules to the list, but study them :-) and correct >> them. > > > Thanks Peter. > > If I understand you correctly, I would need to be messing around with flags > a/b in my PF rules ? > > IIRC I'm not doing that, but I'll go and double check to be sure ! > > Laura I think (though am not 100% sure) that there is a possibility this could happen if the client is extremely slow to respond and the PF state times out.
Re: 7.1 & nsd - failed writing to tcp: Permission denied
Laura, for a first step I would look at pflog(4). As Peter hinted, if you have an obscure pf rule blocking things after the connection sets up, this will point it out. (Make sure you have all the appropriate pflog bits enabled, of course.) If that doesn't work your next step is to fire up tcpdump and see what's actually happening on the wire. Look for a post-connection RST and work back from that. --lyndon
Re: 7.1 & nsd - failed writing to tcp: Permission denied
On Fri, Apr 22, 2022 at 04:03:17PM +, Laura Smith wrote: > Hi, > Am seeing some odd nsd log entries crop up in /var/log/messages.?? Any cause > for concern ? Anyone else seen these ? > > Apr 22 15:08:46 nsd[99760]: failed writing to tcp: Permission denied > > No problems with IPv4 or IPv6 connectivity on this host, I can access the > internet fine both directly on this host and through it (it doubles up as a > firewall). > > Laura Hi Laura, I took a look at the code and it is a writev() or a write() they do on tcp writes. Then I checked the manpage for send because write() on a TCP socket is the same as send() afaik. The manpage says this about your error: [EACCES] The connection was blocked by pf(4), or SO_BROADCAST is not set on the socket and a broadcast address was given as the destination. TCP doesn't do any broadcasting so it was blocked by p(4). So that's weird becuase the 3-way handshake must have completed for nsd to reply a query. Meaning there was SYN's and ACK's being exchanged but perhaps a PUSH+ACK may not succeed through the pf rules? Don't post your firewall rules to the list, but study them :-) and correct them. Best Regards, -peter
