Re: tcp_respond: let the stack worry about the ksum

2014-01-23 Thread Henning Brauer
sigh. why is it always that you notice you forgot to copy the last iteration of the diff to the mail machine right AFTER hitting send? Index: netinet/tcp_subr.c === RCS file: /cvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.125

tcp_respond: let the stack worry about the ksum

2014-01-23 Thread Henning Brauer
Index: netinet/tcp_subr.c === RCS file: /cvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.125 diff -u -p -r1.125 tcp_subr.c --- netinet/tcp_subr.c 24 Oct 2013 11:31:43 - 1.125 +++ netinet/tcp_subr.c 24 Jan 2014 06:31:2

pf_send_tcp: ask the stack to do the cksum instead of doing it manually

2014-01-23 Thread Henning Brauer
this is used for return-rst for example. not surprisingly just works here. Index: net/pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.866 diff -u -p -r1.866 pf.c --- net/pf.c23 Jan 2014 23:51:29 - 1.866 +

help needed from someone with an sk(4)

2014-01-23 Thread Henning Brauer
i need this tested on an sk(4). I don't have that hardware at all. Index: dev/pci/if_sk.c === RCS file: /cvs/src/sys/dev/pci/if_sk.c,v retrieving revision 1.167 diff -u -p -r1.167 if_sk.c --- dev/pci/if_sk.c 28 Dec 2013 03:36:25 -

_SUM_IN_OK flags

2014-01-23 Thread Henning Brauer
clearing these is now utterly pointless, was only done for statistics before. moreover, clearing these might even lead to a pointless re-check in software in some scenarios. note that these flags have nothing at all to do with the outbound side, i. e. wether we have to checksum the packet. Index:

netinet6/*: delay ICMPv6 checksum calculation

2014-01-23 Thread Christian Weisgerber
Instead of calculating the ICMPv6 checksum here, just set the flag that is needed and the lower parts of the stack will take care of it. I have tested the general ICMPv6, ICMPv6 redirect, and neighbor discovery parts. I have not tested the MLD part. Index: icmp6.c ===

Re: restoring keyboard layout after suspend or hibernate

2014-01-23 Thread patrick keshishian
On 1/23/14, Miod Vallat wrote: >> Something is inconsistent here. Do you mean the uk is not the >> default? Or there is a difference between mux default and new attach >> default? How does one know whether plugging a keyboard in is >> reattaching it or attachning a new one? > > There is a differen

Re: restoring keyboard layout after suspend or hibernate

2014-01-23 Thread Miod Vallat
> Something is inconsistent here. Do you mean the uk is not the > default? Or there is a difference between mux default and new attach > default? How does one know whether plugging a keyboard in is > reattaching it or attachning a new one? There is a difference between a keyboard which can provide

Re: restoring keyboard layout after suspend or hibernate

2014-01-23 Thread Ted Unangst
On Thu, Jan 23, 2014 at 20:57, Miod Vallat wrote: > - when changing the keyboard layout of a particular keyboard with an > ioctl (i.e. using kbd(8) or wsconsctl(8)), the layout will become the > default layout of the mux for new keyboard attachments. > Now I plug a Sun USB keyboard with the uk la

Re: restoring keyboard layout after suspend or hibernate

2014-01-23 Thread Miod Vallat
> Couple of questions: > > 1. What if starting from this state: > $ wsconsctl 2>/dev/null |grep encoding > keyboard.encoding=us > keyboard1.encoding=is > keyboard2.encoding=uk > > you unplug the Icelandic and Sun UK keyboards. Next attach > first the Sun UK keyboard and ne

Re: restoring keyboard layout after suspend or hibernate

2014-01-23 Thread patrick keshishian
On Thu, Jan 23, 2014 at 08:57:43PM +, Miod Vallat wrote: > [cc: tech@, reply-to set to tech@] > > > After suspend or hibernate, I lose my designated console keyboard layout > > (sv) and it reverts to the default (us?) wsconsctl shows that the > > encoding to still be sv, > > > > keyboa

Re: restoring keyboard layout after suspend or hibernate

2014-01-23 Thread Miod Vallat
[cc: tech@, reply-to set to tech@] > After suspend or hibernate, I lose my designated console keyboard layout > (sv) and it reverts to the default (us?) wsconsctl shows that the > encoding to still be sv, > > keyboard.encoding=sv > > What setting(s) am I missing to preserve the designat

Re: signed packages

2014-01-23 Thread Giancarlo Razzolini
Em 23-01-2014 09:33, Kevin Chadwick escreveu: > Why would you have so much trust in the ether unless you have met > someone with say a DNSSEC key or have a web of trust with someone you > have met and that you trust and has met and swapped keys further up > the line. The first key for DNSSEC is alm

Re: pflow(4): pflowproto 9

2014-01-23 Thread Florian Obser
To clarify, since I got a private mail from a v5 user: v5 is going to stay for now. It's beyond repair wrt. 2038 but other than that it's a perfectly fine protocol if you only need to export IPv4 flows. Also it's not in the way of improving v10 like v9 is. So I'm not asking you to migrate from v5

Re: signed packages

2014-01-23 Thread Marc Espie
A huge swath of clean-up has just hit the trees. Most specifically, now that it works, the "signing-only" code has been moved into a separate "pkg_sign" command. This is partly for documentation purpose: it's much simpler to document the parameters to that command separately, instead of as additi

Re: signed packages

2014-01-23 Thread Kevin Chadwick
previously on this list Giancarlo Razzolini contributed: I believe that with the interdiction > programs that NSA has, and maybe also other governments, CD's can not be > entitled with the same trust as before. Why would you have so much trust in the ether unless you have met someone with say a D

pflow(4): pflowproto 9

2014-01-23 Thread Florian Obser
Since we are in -beta you are all starting to test snapshots like crazy, right? Right?! Please do me a favor, if you're using pflow(4) test if your favorite collector works with pflowproto 10. Since the time_t cleanup (rev 1.34 of if_pflow.c) v10 no longer sends insane flows. I know it now works w