Tracing dropped UDP packets

Greetings, I would like to know where (in the kernel) UDP packets are dropped. I looked at udp_usrreq.c but is overwhelming for the 1st time. Is it possible to use DTrace to locate where the packets are being dropped? or is there a tool similar to 'dropwatch' which can tell me where in the

Re: Why anyone can read and write to a nobody NFS mounted volume?

On Fri, 15 Apr 2016, Raimundo Santos wrote: i have a strange situation: everyone and not just root can read and write to a NFS mount point whose owner is nobody:nobody. Is this an expected behaviour? FreeBSD 10.2 RELEASE as NFS client. Seagate NAS400 as NFS server. This is, unfortunately,

[Differential] [Commented On] D5872: tcp: Don't prematurely drop receiving-only connections

jtl added a comment. In https://reviews.freebsd.org/D5872#127343, @mike-karels.net wrote: > If we get an ENOBUFS when sending data, we will already be running the retransmit timer. Good point, but see below. > If we drop an ACK on ENOBUFS, either we will receive more data

[Differential] [Commented On] D5872: tcp: Don't prematurely drop receiving-only connections

jtl added a comment. I think something like this code will get you closer to what you want: Index: sys/netinet/tcp_output.c === --- sys/netinet/tcp_output.c(revision 298090) +++ sys/netinet/tcp_output.c

[Differential] [Commented On] D5872: tcp: Don't prematurely drop receiving-only connections

mike-karels.net added a comment. I believe that the original code is wrong, and the change is not sufficient to fix it. The retransmit timer should be running if and only if we have sent data into the receive window and are awaiting an ACK. The persist timer should be running if and

Re: libifconfig: Initial code available, looking for feedback

On Tue, Apr 12, 2016 at 4:23 PM Kristof Provost wrote: > On 12 Apr 2016, at 16:09, Marie Helene Kvello-Aune < > mariehelen...@gmail.com> wrote: > >> >> > Expect the API to break frequently/often for the time being, as it is >> still >> > in very early stages of development. >>

tcp guys: please look at this one

https://reviews.freebsd.org/D5872 This one needs more scrutiny. The cure may be worse than the problem, but it needs more eyes on it.. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe,

Re: Why anyone can read and write to a nobody NFS mounted volume?

Raimundo Santos wrote: > Thank you for your time, Rick! > > I will take a look on the permissions of the dirs I am mounting from the > server, but you clarified a big thing for me: it is up to the server > machine to decide about permissions. > > Am I right? > Generally yes. (Typically an NFS

Re: Why anyone can read and write to a nobody NFS mounted volume?

Thank you for your time, Rick! I will take a look on the permissions of the dirs I am mounting from the server, but you clarified a big thing for me: it is up to the server machine to decide about permissions. Am I right? Thank you, Raimundo Santos On 15 April 2016 at 19:23, Rick Macklem

Re: Why anyone can read and write to a nobody NFS mounted volume?

Well, I suppose it is up to the server implementor. (In your case Seagate...) Normally NFS servers map root->nobody by default, under the assumption that "nobody" is not a real user and is checked via world permissions. --> I'd say a typical server would allow anyone (including "nobody" access)

[Differential] [Updated] D5872: tcp: Don't prematurely drop receiving-only connections

hiren added a comment. In https://reviews.freebsd.org/D5872#127123, @jtl wrote: > > The key feature that makes the retransmit timer inappropriate for an ACK-only case is that it is only stopped when we receive input; however, in the ACK-only case, we really want to stop it

Why anyone can read and write to a nobody NFS mounted volume?

Hello all! i have a strange situation: everyone and not just root can read and write to a NFS mount point whose owner is nobody:nobody. Is this an expected behaviour? FreeBSD 10.2 RELEASE as NFS client. Seagate NAS400 as NFS server. Thank you all, Raimundo Santos

Re: strange nfs/rsync stalls

Hello, sorry for the necromancy here. I had issues with a simples NAS that exports NFS only for "nobody:nobody" as rsync tries to set uid and gid. Just take off this feature with: rsync -a --no-g --no-o and everything went fine. Hope it helps someone. Best regards, Raimundo Santos On 6

[Differential] [Commented On] D5872: tcp: Don't prematurely drop receiving-only connections

jtl added a comment. In https://reviews.freebsd.org/D5872#127063, @jtl wrote: > Doesn't tp->t_rxtshift get updated on a successful send? If not, I think that is what we should be fixing. Of course, tp->t_rxtshift doesn't get updated on a successful send. That's not the way this

[Differential] [Requested Changes To] D5872: tcp: Don't prematurely drop receiving-only connections

jtl requested changes to this revision. jtl added a reviewer: jtl. jtl added a comment. This revision now requires changes to proceed. Doesn't tp->t_rxtshift get updated on a successful send? If not, I think that is what we should be fixing. Personally, I think a connection should drop

[Differential] [Commented On] D5872: tcp: Don't prematurely drop receiving-only connections

sepherosa_gmail.com added a comment. If no objection comes, it will be committed in the middle of next week. REVISION DETAIL https://reviews.freebsd.org/D5872 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, glebius, hiren,

[Differential] [Commented On] D5853: dhclient: Log a warning instead of bailing upon "illegal" options

sepherosa_gmail.com added a comment. If no objection comes, it will be committed in the middle of next week. REVISION DETAIL https://reviews.freebsd.org/D5853 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, secteam,