On 2014/01/26 14:53, Chris Smith wrote: > On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson <s...@spacehopper.org> > wrote: > > This could be an MTU or RWIN-related issue. > > Could my issue have anything to with the "miscounting bug for inbound > with pf on" mentioned in the following commit? > ======================================== > CVSROOT: /cvs > Module name: src > Changes by: henn...@cvs.openbsd.org 2014/01/23 16:51:29 > > Modified files: > sys/net : if_bridge.c pf.c > sys/netinet : ip_input.c ip_output.c ip_var.h tcp_input.c > tcp_var.h udp_usrreq.c udp_var.h > sys/netinet6 : ip6_output.c > > Log message: > since the cksum rewrite the counters for hardware checksummed packets > are are lie, since the software engine emulates hardware offloading > and that is later indistinguishable. so kill the hw cksummed counters. > introduce software checksummed packet counters instead. > tcp/udp handles ip & ipvshit, ip cksum covered, 6 has no ip layer cksum. > as before we still have a miscounting bug for inbound with pf on, to be > fixed in the next step. > found by, prodding & ok naddy > ======================================== > > And if so was "the next step" taken and is this miscounting bug fixed?
No this is just counting for statistics. > Also recently in an attempt to keep a box at -current there occurred a > kernel/userland mismatch that caused pf not to load on reboot after > installing the kernel (everything was fine after building userland). > I'm fairly certain trying to bring a box dated "OpenBSD 5.4-current > (GENERIC.MP) #5: Wed Jan 1 14:21:45 EST 2014" will have the same > issue. If I attempt to do this remotely will I still be able to shell > in in order to update userland (even though with no pf there is no nat > and therefore access to/from the inside network will not be possible) > after rebooting into the new kernel? Or might it be safe to build > userland before rebooting into the new kernel? > > Thank you, > > Chris See "Upgrading without install kernel" in the faq's upgrade guide. Note the specific order to untar sets. This isn't enough for the 5.4->-current flag day upgrade (which requires rebuilding the password database with new pwd_mkdb, but new pwd_mkdb won't run until you're on a new kernel), but since you have already passed that step, you should be ok. Obviously the install kernel method is safer if you can manage it.
