Re: route(8): /prefixlen syntax for -inet6
It's a step in the right direction, but compare this: # route add 5.5.5.1/26 127.0.0.1 add net 5.5.5.1/26: gateway 127.0.0.1 # route delete 5.5.5.1/26 delete net 5.5.5.1/26 ...with this: # route add -inet6 ff55::1/96 ::1 add net ff55::1/96: gateway ::1 # route delete -inet6 ff55::1/96 route: writing to routing socket: No such process delete net ff55::1/96: not in table # route delete -inet6 ff55::/96 delete net ff55::/96 I think the address should be masked in the same way for both v4 and v6.
Re: tinyscheme + mg
Here is an updated diff for mg with tinyscheme integration. It's based on tedu's original diff with various tweaks and changes. For those worried about mg being too bloated, rest assured, it's still small and lean and a big part smaller than vi ;-) It's not fully possible to turn mg into your mail client, but I'd like to commit this diff and work on it futher in tree (not the mail-client thing, that would bloat mg and that's far from desired). Includes some fixes by lum@ and Sunil Nimmagadda too. Diff is also at http://crappydiffs.org/tinyschemg.diff I would appreciate some feedback on the inclusion of this diff in mg since I am unlikely to use tinyscheme myself but can see why others would like it added. Are there are strong feelings about it either way? -lum
Re: tinyscheme + mg
If Jasper is going to take care of it, why not :-) ? I'd like to get the ability to remap keys, without hacking src. (As an mg user) On Thu, Jun 28, 2012 at 2:06 PM, Mark Lumsden m...@showcomplex.com wrote: Here is an updated diff for mg with tinyscheme integration. It's based on tedu's original diff with various tweaks and changes. For those worried about mg being too bloated, rest assured, it's still small and lean and a big part smaller than vi ;-) It's not fully possible to turn mg into your mail client, but I'd like to commit this diff and work on it futher in tree (not the mail-client thing, that would bloat mg and that's far from desired). Includes some fixes by lum@ and Sunil Nimmagadda too. Diff is also at http://crappydiffs.org/tinyschemg.diff I would appreciate some feedback on the inclusion of this diff in mg since I am unlikely to use tinyscheme myself but can see why others would like it added. Are there are strong feelings about it either way? -lum -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light !
Re: tinyscheme + mg
Thoughts, since we have been down this road before. 1. You can remap keys, in your ~/.mg file 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. 3. Why scheme? Yes, emacs uses Lisp. But seriously, so? Why not just add, say, perl bindings? 4. Seriously, please be pedantic about licenses. Part of me dies when we see a new source file without one. I'm all for adding support for scripting into mg, though I would be tempted to rip out all nonessential functionality first (ng? ;) and add it back via the scripting language. I would think the goal should be to make mg significantly *smaller* any such change -kj On Thursday, June 28, 2012, Loganaden Velvindron wrote: If Jasper is going to take care of it, why not :-) ? I'd like to get the ability to remap keys, without hacking src. (As an mg user) On Thu, Jun 28, 2012 at 2:06 PM, Mark Lumsden m...@showcomplex.comjavascript:; wrote: Here is an updated diff for mg with tinyscheme integration. It's based on tedu's original diff with various tweaks and changes. For those worried about mg being too bloated, rest assured, it's still small and lean and a big part smaller than vi ;-) It's not fully possible to turn mg into your mail client, but I'd like to commit this diff and work on it futher in tree (not the mail-client thing, that would bloat mg and that's far from desired). Includes some fixes by lum@ and Sunil Nimmagadda too. Diff is also at http://crappydiffs.org/tinyschemg.diff I would appreciate some feedback on the inclusion of this diff in mg since I am unlikely to use tinyscheme myself but can see why others would like it added. Are there are strong feelings about it either way? -lum -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light !
Re: tinyscheme + mg
I'm all for adding support for scripting into mg, though I would be tempted to rip out all nonessential functionality first (ng? ;) and add it back via the scripting language. I would think the goal should be to make mg significantly *smaller* any such change Could you clarify what you mean by non-essential functionality? mark
Re: tinyscheme + mg
Hi,
Hi.
Here is an updated diff for mg with tinyscheme integration. It's based on
tedu's original diff with various tweaks and changes. For those worried
about
mg being too bloated, rest assured, it's still small and lean and a big
part
smaller than vi ;-)
It's not fully possible to turn mg into your mail client, but I'd like to
commit
this diff and work on it futher in tree (not the mail-client thing, that
would
bloat mg and that's far from desired).
Includes some fixes by lum@ and Sunil Nimmagadda too.
Diff is also at http://crappydiffs.org/tinyschemg.diff
OK?
Well, this is based on source from tinyscheme, where's the full licence?
http://tinyscheme.sourceforge.net/license.txt seems rather strict about
that...
If the licence seems ok, why not just pull a complete tinyscheme instance,
that would then be usable from other applications? (tinyscheme doesn't seem
to
be in ports).
A quick reading makes me wonder about what follows.
[...]
Index: Makefile
===
RCS file: /cvs/src/usr.bin/mg/Makefile,v
retrieving revision 1.27
diff -p -u -r1.27 Makefile
--- Makefile 18 Jun 2012 07:13:26 - 1.27
+++ Makefile 28 Jun 2012 06:28:14 -
@@ -13,7 +13,7 @@ DPADD+= ${LIBCURSES} ${LIBUTIL}
#XKEYS -- use termcap function key definitions.
#note: XKEYS and bsmap mode do _not_ get along.
#
-CFLAGS+=-Wall -DFKEYS -DREGEX -DXKEYS
+CFLAGS+=-Wall -DFKEYS -DREGEX -DXKEYS -O0
SRCS=autoexec.c basic.c buffer.c cinfo.c dir.c display.c \
echo.c extend.c file.c fileio.c funmap.c help.c kbd.c keymap.c \
@@ -26,9 +26,24 @@ SRCS= autoexec.c basic.c buffer.c cinfo.
#
SRCS+= cmode.c cscope.c dired.c grep.c tags.c theo.c
+# Tinyscheme extension
+SRCS+= scheme.c mgscheme.c
+LDADD+= -lm
+DPADD+= ${LIBM}
+
+# No non-ELF arches support shared objects.
+.include bsd.own.mk
+.if ${ELF_TOOLCHAIN} == yes
+CFLAGS+=-DUSE_DL
+SRCS += dynload.c
+.endif
+
afterinstall:
${INSTALL} -d ${DESTDIR}${DOCDIR}/mg
${INSTALL} -m ${DOCMODE} -c ${.CURDIR}/tutorial \
${DESTDIR}${DOCDIR}/mg
+ ${INSTALL} -d ${DESTDIR}${SHAREDIR}/mg
+ ${INSTALL} -m ${SHAREMODE} -c ${.CURDIR}/init.scm \
+ ${DESTDIR}${SHAREDIR}/mg
.include bsd.prog.mk
Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.124
diff -p -u -r1.124 def.h
--- def.h 14 Jun 2012 17:21:22 - 1.124
+++ def.h 28 Jun 2012 06:28:15 -
@@ -534,6 +534,10 @@ int csprevfile(int, int);
int csprevmatch(int, int);
int cscreatelist(int, int);
+
+int mgscheme(int, int);
+
+
/* extend.c X */
int insert(int, int);
int bindtokey(int, int);
Index: dynload.c
===
RCS file: dynload.c
diff -N dynload.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dynload.c 28 Jun 2012 06:28:16 -
@@ -0,0 +1,112 @@
+/* $OpenBSD$ */
+
+/* dynload.c Dynamic Loader for TinyScheme */
+/* Original Copyright (c) 1999 Alexander Shendi */
+/* Modifications for NT and dl_* interface, scm_load_ext: D. Souflis */
+/* Refurbished by Stephen Gildea */
+
+#define _SCHEME_SOURCE
+#include dynload.h
+#include string.h
+#include stdio.h
+#include stdlib.h
+
+#ifndef MAXPATHLEN
+# define MAXPATHLEN 1024
+#endif
What about just pulling sys/param.h?
+
+static void make_filename(const char *name, char *filename);
+static void make_init_fn(const char *name, char *init_fn);
+
+typedef void *HMODULE;
+typedef void (*FARPROC)();
+#define SUN_DL
Hmmm.
+#include dlfcn.h
+
+#if defined(SUN_DL)
Huh? 8)
+
+#include dlfcn.h
+
+#define PREFIX lib
+#define SUFFIX .so
+
+static HMODULE dl_attach(const char *module) {
+ HMODULE so=dlopen(module,RTLD_LAZY);
+ if(!so) {
+fprintf(stderr, Error loading scheme extension \%s\: %s\n, module,
dlerror());
+ }
+ return so;
+}
+
+static FARPROC dl_proc(HMODULE mo, const char *proc) {
+ const char *errmsg;
+ FARPROC fp=(FARPROC)dlsym(mo,proc);
+ if ((errmsg = dlerror()) == 0) {
+return fp;
+ }
+ fprintf(stderr, Error initializing scheme module \%s\: %s\n, proc,
errmsg);
+ return 0;
+}
+
+static void dl_detach(HMODULE mo) {
+ (void)dlclose(mo);
+}
+#endif
+
+pointer scm_load_ext(scheme *sc, pointer args)
+{
+ pointer first_arg;
+ pointer retval;
+ char filename[MAXPATHLEN], init_fn[MAXPATHLEN+6];
+ char *name;
+ HMODULE dll_handle;
+ void (*module_init)(scheme *sc);
+
+ if ((args != sc-NIL) is_string((first_arg = pair_car(args {
+ name = string_value(first_arg);
+ make_filename(name,filename);
+ make_init_fn(name,init_fn);
+ dll_handle = dl_attach(filename);
+ if (dll_handle ==
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote: Thoughts, since we have been down this road before. 1. You can remap keys, in your ~/.mg file 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. 3. Why scheme? Yes, emacs uses Lisp. But seriously, so? Why not just add, say, perl bindings? 4. Seriously, please be pedantic about licenses. Part of me dies when we see a new source file without one. I'm all for adding support for scripting into mg, though I would be tempted to rip out all nonessential functionality first (ng? ;) and add it back via the scripting language. I would think the goal should be to make mg significantly *smaller* any such change -kj Regarding the licenses, Kettenis pointed out I forgot to add the original copyright headers, which I have since added to my local repo. It's reproduced here for reference: Copyright (c) 2000, Dimitrios Souflis All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Dimitrios Souflis nor the names of the contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. I'm totally fine with putting mgscheme.c into the public domain, if tedu agrees too of course. On Thursday, June 28, 2012, Loganaden Velvindron wrote: If Jasper is going to take care of it, why not :-) ? I'd like to get the ability to remap keys, without hacking src. (As an mg user) On Thu, Jun 28, 2012 at 2:06 PM, Mark Lumsden m...@showcomplex.comjavascript:; wrote: Here is an updated diff for mg with tinyscheme integration. It's based on tedu's original diff with various tweaks and changes. For those worried about mg being too bloated, rest assured, it's still small and lean and a big part smaller than vi ;-) It's not fully possible to turn mg into your mail client, but I'd like to commit this diff and work on it futher in tree (not the mail-client thing, that would bloat mg and that's far from desired). Includes some fixes by lum@ and Sunil Nimmagadda too. Diff is also at http://crappydiffs.org/tinyschemg.diff I would appreciate some feedback on the inclusion of this diff in mg since I am unlikely to use tinyscheme myself but can see why others would like it added. Are there are strong feelings about it either way? -lum -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light ! -- Cheers, Jasper Stay Hungry. Stay Foolish
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 15:07, Jérémie Courrèges-Anglas wrote: If the licence seems ok, why not just pull a complete tinyscheme instance, that would then be usable from other applications? (tinyscheme doesn't seem to be in ports). I don't want to be in the business of adding 20 different interpreters to base. If I did, it'd be lua first by a mile. That said, tinyscheme is designed to be directly embedded. If it turns out people are dying to add scheme support to top and systat, we can talk about a shared library, but global changes are way far more involved.
Re: bnx(4) flow control support.
So we have been running with this diff in the office, and it is working
well for us.
bnx0 at pci7 dev 0 function 0 Broadcom BCM5709 rev 0x20: apic 0 int 6
bnx0: address 1c:c1:de:e4:5e:b0
brgphy0 at bnx0 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
As a side note, having TXPAUSE and RXPAUSE enabled, with a seperate
interrupt colascing diff makes a significant speed improvement.
On 2011 Sep 22 (Thu) at 22:00:22 +0200 (+0200), Paul de Weerd wrote:
:An oldie, but I dug it up from the archives to test on my R210 II.
:Diff applies (slightly offset) and works just fine. ifconfig bnx now
:shows:
:
:media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
:
:For the record, this is a Broadcom BCM5716 (see dmesg posted to misc@
:yesterday):
:
:bnx1 at pci1 dev 0 function 1 Broadcom BCM5716 rev 0x20: apic 0 int 17
:
:Paul 'WEiRD' de Weerd
:
:On Mon, Jun 28, 2010 at 03:34:23PM -0400, Brad wrote:
:| Here is an older diff I had to add flow control support to bnx(4)
:| which I have dug out and updated to -current src. I have tested
:| it with the following adapters and could use some testing with a
:| BCM5709 chipset. This supports flow control on all copper adapters
:| and BCM5706 with fiber, but not BCM5708/BCM5709 with fiber yet.
:|
:| bnx0 at pci1 dev 7 function 0 Broadcom BCM5706 rev 0x02: apic 2 int 16
(irq 12)
:| bnx0: address 00:10:18:15:f8:8a
:| brgphy1 at bnx0 phy 1: BCM5706 10/100/1000baseT/SX PHY, rev. 2
:|
:| bnx1 at pci5 dev 0 function 0 Broadcom BCM5708 rev 0x11: apic 2 int 16
(irq 12)
:| bnx1: address 00:10:18:15:fa:3e
:| brgphy2 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 5
:|
:| Please test with any bnx(4) chipsets and provide a dmesg.
:|
:|
:| Index: if_bnx.c
:| ===
:| RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
:| retrieving revision 1.88
:| diff -u -p -r1.88 if_bnx.c
:| --- if_bnx.c 24 May 2010 21:23:23 - 1.88
:| +++ if_bnx.c 28 Jun 2010 19:15:52 -
:| @@ -913,6 +913,9 @@ bnx_attachhook(void *xsc)
:| /* Look for our PHY. */
:| ifmedia_init(sc-bnx_mii.mii_media, 0, bnx_ifmedia_upd,
:| bnx_ifmedia_sts);
:| +if (BNX_CHIP_NUM(sc) == BNX_CHIP_NUM_5706 ||
:| +(!(sc-bnx_phy_flags BNX_PHY_SERDES_FLAG)))
:| +mii_flags |= MIIF_DOPAUSE;
:| if (sc-bnx_phy_flags BNX_PHY_SERDES_FLAG)
:| mii_flags |= MIIF_HAVEFIBER;
:| mii_attach(sc-bnx_dev, sc-bnx_mii, 0x,
:| @@ -1279,6 +1282,7 @@ bnx_miibus_statchg(struct device *dev)
:| {
:| struct bnx_softc*sc = (struct bnx_softc *)dev;
:| struct mii_data *mii = sc-bnx_mii;
:| +u_int32_t rx_mode = sc-rx_mode;
:| int val;
:|
:| val = REG_RD(sc, BNX_EMAC_MODE);
:| @@ -1286,6 +1290,15 @@ bnx_miibus_statchg(struct device *dev)
:| BNX_EMAC_MODE_MAC_LOOP | BNX_EMAC_MODE_FORCE_LINK |
:| BNX_EMAC_MODE_25G);
:|
:| +/*
:| + * Get flow control negotiation result.
:| + */
:| +if (IFM_SUBTYPE(mii-mii_media.ifm_cur-ifm_media) == IFM_AUTO
:| +(mii-mii_media_active IFM_ETH_FMASK) != sc-bnx_flowflags) {
:| +sc-bnx_flowflags = mii-mii_media_active IFM_ETH_FMASK;
:| +mii-mii_media_active = ~IFM_ETH_FMASK;
:| +}
:| +
:| /* Set MII or GMII interface based on the speed
:| * negotiated by the PHY.
:| */
:| @@ -1325,6 +1338,34 @@ bnx_miibus_statchg(struct device *dev)
:| DBPRINT(sc, BNX_INFO, Setting Full-Duplex interface.\n);
:|
:| REG_WR(sc, BNX_EMAC_MODE, val);
:| +
:| +/*
:| + * 802.3x flow control
:| + */
:| +if (sc-bnx_flowflags IFM_ETH_RXPAUSE) {
:| +DBPRINT(sc, BNX_INFO, Enabling RX mode flow control.\n);
:| +rx_mode |= BNX_EMAC_RX_MODE_FLOW_EN;
:| +} else {
:| +DBPRINT(sc, BNX_INFO, Disabling RX mode flow control.\n);
:| +rx_mode = ~BNX_EMAC_RX_MODE_FLOW_EN;
:| +}
:| +
:| +if (sc-bnx_flowflags IFM_ETH_TXPAUSE) {
:| +DBPRINT(sc, BNX_INFO, Enabling TX mode flow control.\n);
:| +BNX_SETBIT(sc, BNX_EMAC_TX_MODE, BNX_EMAC_TX_MODE_FLOW_EN);
:| +} else {
:| +DBPRINT(sc, BNX_INFO, Disabling TX mode flow control.\n);
:| +BNX_CLRBIT(sc, BNX_EMAC_TX_MODE, BNX_EMAC_TX_MODE_FLOW_EN);
:| +}
:| +
:| +/* Only make changes if the recive mode has actually changed. */
:| +if (rx_mode != sc-rx_mode) {
:| +DBPRINT(sc, BNX_VERBOSE, Enabling new receive mode: 0x%08X\n,
:| +rx_mode);
:| +
:| +sc-rx_mode = rx_mode;
:| +REG_WR(sc, BNX_EMAC_RX_MODE, rx_mode);
:| +}
:| }
:|
:|
//
:| @@ -3954,6 +3995,13 @@ bnx_init_rx_context(struct bnx_softc *sc
:| val = BNX_L2CTX_CTX_TYPE_CTX_BD_CHN_TYPE_VALUE |
:| BNX_L2CTX_CTX_TYPE_SIZE_L2 | (0x02 8);
:|
:| +/*
:|
Re: tinyscheme + mg
I don't want to be in the business of adding 20 different interpreters to base. If I did, it'd be lua first by a mile. That said, tinyscheme is designed to be directly embedded. If it turns out people are dying to add scheme support to top and systat, we can talk about a shared library, but global changes are way far more involved. I have no problem with the idea in principle.. HOWEVER: This has the odor of similar things that have been tried in the past. I *could* be wrong but a big diff and lots more code in something for future extensibility because it's designed to be embedded is all fine and good.. *IF SOMEONE IS REALLY GOING TO USE IT TO EXTEND THINGS* - the same can be said for embedding stuff like that in top and systat. I'd be a lot happier voicing an opinion in support of something like this if I also saw diffs and interest in *using* them to extend functionality later or replace some things easier to do with scheme to make the code simpler - something kjell was alluding to. A promise of this is bigger and bloated now but will be really cool in the future isn't so good if the people putting it in see getting scheme integration in as the goal - otherwise, congrats, you've just added another kitchen sink. albeit a small one, if nobody has demonstrable plans to cook with the sink, and cook well, don't bother. So Jasper, I think it's cool too. but a cool kitchen that doesn't get used is a waste. Where's the beef? Right now I'm on the fence for this one. -Bob
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 15:21, Jasper Lievisse Adriaanse wrote: On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote: 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. I think it's reasonable to maintain an ifdef to omit scheme (and theo.c if you like, as I'd probably redo that in scheme) to get pure public domain mg. 3. Why scheme? Yes, emacs uses Lisp. But seriously, so? Why not just add, say, perl bindings? In large part, yes, because emacs uses lisp. I think it's fun. If you need a technical reason, it's because 90% of the mg commands, like copy-region-as-kill, are not legal perl function names. I'm totally fine with putting mgscheme.c into the public domain, if tedu agrees too of course. It's not a big deal, but I'd prefer to keep it BSD. Most of it already has to be, so it seems logical that all scheme extensions are one license.
Re: bnx(4) flow control support.
On Thu, Jun 28, 2012 at 16:07 +0200, Peter Hessler wrote:
So we have been running with this diff in the office, and it is working
well for us.
bnx0 at pci7 dev 0 function 0 Broadcom BCM5709 rev 0x20: apic 0 int 6
bnx0: address 1c:c1:de:e4:5e:b0
brgphy0 at bnx0 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
As a side note, having TXPAUSE and RXPAUSE enabled, with a seperate
interrupt colascing diff makes a significant speed improvement.
the diff makes sense to me, ok mikeb
On 2011 Sep 22 (Thu) at 22:00:22 +0200 (+0200), Paul de Weerd wrote:
:An oldie, but I dug it up from the archives to test on my R210 II.
:Diff applies (slightly offset) and works just fine. ifconfig bnx now
:shows:
:
:media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
:
:For the record, this is a Broadcom BCM5716 (see dmesg posted to misc@
:yesterday):
:
:bnx1 at pci1 dev 0 function 1 Broadcom BCM5716 rev 0x20: apic 0 int 17
:
:Paul 'WEiRD' de Weerd
:
:On Mon, Jun 28, 2010 at 03:34:23PM -0400, Brad wrote:
:| Here is an older diff I had to add flow control support to bnx(4)
:| which I have dug out and updated to -current src. I have tested
:| it with the following adapters and could use some testing with a
:| BCM5709 chipset. This supports flow control on all copper adapters
:| and BCM5706 with fiber, but not BCM5708/BCM5709 with fiber yet.
:|
:| bnx0 at pci1 dev 7 function 0 Broadcom BCM5706 rev 0x02: apic 2 int 16
(irq 12)
:| bnx0: address 00:10:18:15:f8:8a
:| brgphy1 at bnx0 phy 1: BCM5706 10/100/1000baseT/SX PHY, rev. 2
:|
:| bnx1 at pci5 dev 0 function 0 Broadcom BCM5708 rev 0x11: apic 2 int 16
(irq 12)
:| bnx1: address 00:10:18:15:fa:3e
:| brgphy2 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 5
:|
:| Please test with any bnx(4) chipsets and provide a dmesg.
:|
:|
:| Index: if_bnx.c
:| ===
:| RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
:| retrieving revision 1.88
:| diff -u -p -r1.88 if_bnx.c
:| --- if_bnx.c 24 May 2010 21:23:23 - 1.88
:| +++ if_bnx.c 28 Jun 2010 19:15:52 -
:| @@ -913,6 +913,9 @@ bnx_attachhook(void *xsc)
:|/* Look for our PHY. */
:|ifmedia_init(sc-bnx_mii.mii_media, 0, bnx_ifmedia_upd,
:|bnx_ifmedia_sts);
:| + if (BNX_CHIP_NUM(sc) == BNX_CHIP_NUM_5706 ||
:| + (!(sc-bnx_phy_flags BNX_PHY_SERDES_FLAG)))
:| + mii_flags |= MIIF_DOPAUSE;
:|if (sc-bnx_phy_flags BNX_PHY_SERDES_FLAG)
:|mii_flags |= MIIF_HAVEFIBER;
:|mii_attach(sc-bnx_dev, sc-bnx_mii, 0x,
:| @@ -1279,6 +1282,7 @@ bnx_miibus_statchg(struct device *dev)
:| {
:|struct bnx_softc*sc = (struct bnx_softc *)dev;
:|struct mii_data *mii = sc-bnx_mii;
:| + u_int32_t rx_mode = sc-rx_mode;
:|int val;
:|
:|val = REG_RD(sc, BNX_EMAC_MODE);
:| @@ -1286,6 +1290,15 @@ bnx_miibus_statchg(struct device *dev)
:|BNX_EMAC_MODE_MAC_LOOP | BNX_EMAC_MODE_FORCE_LINK |
:|BNX_EMAC_MODE_25G);
:|
:| + /*
:| + * Get flow control negotiation result.
:| + */
:| + if (IFM_SUBTYPE(mii-mii_media.ifm_cur-ifm_media) == IFM_AUTO
:| + (mii-mii_media_active IFM_ETH_FMASK) != sc-bnx_flowflags) {
:| + sc-bnx_flowflags = mii-mii_media_active IFM_ETH_FMASK;
:| + mii-mii_media_active = ~IFM_ETH_FMASK;
:| + }
:| +
:|/* Set MII or GMII interface based on the speed
:| * negotiated by the PHY.
:| */
:| @@ -1325,6 +1338,34 @@ bnx_miibus_statchg(struct device *dev)
:|DBPRINT(sc, BNX_INFO, Setting Full-Duplex interface.\n);
:|
:|REG_WR(sc, BNX_EMAC_MODE, val);
:| +
:| + /*
:| + * 802.3x flow control
:| + */
:| + if (sc-bnx_flowflags IFM_ETH_RXPAUSE) {
:| + DBPRINT(sc, BNX_INFO, Enabling RX mode flow control.\n);
:| + rx_mode |= BNX_EMAC_RX_MODE_FLOW_EN;
:| + } else {
:| + DBPRINT(sc, BNX_INFO, Disabling RX mode flow control.\n);
:| + rx_mode = ~BNX_EMAC_RX_MODE_FLOW_EN;
:| + }
:| +
:| + if (sc-bnx_flowflags IFM_ETH_TXPAUSE) {
:| + DBPRINT(sc, BNX_INFO, Enabling TX mode flow control.\n);
:| + BNX_SETBIT(sc, BNX_EMAC_TX_MODE, BNX_EMAC_TX_MODE_FLOW_EN);
:| + } else {
:| + DBPRINT(sc, BNX_INFO, Disabling TX mode flow control.\n);
:| + BNX_CLRBIT(sc, BNX_EMAC_TX_MODE, BNX_EMAC_TX_MODE_FLOW_EN);
:| + }
:| +
:| + /* Only make changes if the recive mode has actually changed. */
:| + if (rx_mode != sc-rx_mode) {
:| + DBPRINT(sc, BNX_VERBOSE, Enabling new receive mode: 0x%08X\n,
:| + rx_mode);
:| +
:| + sc-rx_mode = rx_mode;
:| + REG_WR(sc, BNX_EMAC_RX_MODE, rx_mode);
:| + }
:| }
:|
:|
//
:| @@ -3954,6 +3995,13 @@ bnx_init_rx_context(struct bnx_softc *sc
:|
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 08:09, Bob Beck wrote: I'd be a lot happier voicing an opinion in support of something like this if I also saw diffs and interest in *using* them to extend functionality later or replace some things easier to do with scheme to make the code simpler - something kjell was alluding to. I think we can work towards that, but there's a bit of chicken and egg problem here. I'm not inclined to do a lot of work if the answer in two months is going to be oh, sorry, perl would have been cooler. The diff will only get larger from here. A promise of this is bigger and bloated now but will be really cool in the future isn't so good if the people putting it in see getting scheme integration in as the goal - otherwise, congrats, you've Integration is one of the goals. I can't predict what extensions you may want to write. I mean, mg already reads a .mg file. If we knew what people were going to put in their .mg files, we could just hard code it in the program and cut out the startup file bloat. That said, some concrete examples would help, both to make sure we're building something useful and to demonstrate that it is useful. Why do people still use emacs and not mg? For text editing not usenet browsing or whatever. I don't want to add some python editor mode just to hear I don't use python.
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote: 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. I'm no developer, but why not create an mg port where various capabilities are added via FLAVORS? diana
Re: tinyscheme + mg
I think the massive mg user base can handle a single flavor. :) On Thu, Jun 28, 2012 at 11:20 AM, Eichert, Diana deic...@sandia.gov wrote: On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote: 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. I'm no developer, but why not create an mg port where various capabilities are added via FLAVORS? diana
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 10:12:38AM -0400, Ted Unangst wrote: On Thu, Jun 28, 2012 at 15:21, Jasper Lievisse Adriaanse wrote: On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote: 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. I think it's reasonable to maintain an ifdef to omit scheme (and theo.c if you like, as I'd probably redo that in scheme) to get pure public domain mg. The cscope.c and ctags.c files are also non-PD at the moment. 3. Why scheme? Yes, emacs uses Lisp. But seriously, so? Why not just add, say, perl bindings? In large part, yes, because emacs uses lisp. I think it's fun. If you need a technical reason, it's because 90% of the mg commands, like copy-region-as-kill, are not legal perl function names. Seconded. I'm totally fine with putting mgscheme.c into the public domain, if tedu agrees too of course. It's not a big deal, but I'd prefer to keep it BSD. Most of it already has to be, so it seems logical that all scheme extensions are one license. -- Cheers, Jasper Stay Hungry. Stay Foolish
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 9:16 AM, Ted Unangst t...@tedunangst.com wrote: Integration is one of the goals. I can't predict what extensions you may want to write. I mean, mg already reads a .mg file. If we knew what people were going to put in their .mg files, we could just hard code it in the program and cut out the startup file bloat. That said, some concrete examples would help, both to make sure we're building something useful and to demonstrate that it is useful. Why do people still use emacs and not mg? For text editing not usenet browsing or whatever. I don't want to add some python editor mode just to hear I don't use python. raises head TCL? BSD, small, fast, been around forever, C like syntax. In base would be awesome... ducks
Re: tinyscheme + mg
I'd be a lot happier voicing an opinion in support of something like this if I also saw diffs and interest in *using* them to extend functionality later or replace some things easier to do with scheme to make the code simpler - something kjell was alluding to. I think we can work towards that, but there's a bit of chicken and egg problem here. I'm not inclined to do a lot of work if the answer in two months is going to be oh, sorry, perl would have been cooler. The diff will only get larger from here. A promise of this is bigger and bloated now but will be really cool in the future isn't so good if the people putting it in see getting scheme integration in as the goal - otherwise, congrats, you've Integration is one of the goals. I can't predict what extensions you may want to write. I mean, mg already reads a .mg file. If we knew what people were going to put in their .mg files, we could just hard code it in the program and cut out the startup file bloat. That said, some concrete examples would help, both to make sure we're building something useful and to demonstrate that it is useful. Why do people still use emacs and not mg? For text editing not usenet browsing or whatever. +1 to somebody providing concrete examples.
tftpd patch
Hi, I have the weird scenario when I try to tftp a file from a remote tftpd that's also openbsd that my pf doesn't keep a state open. This is something I need to fix, however I found this in the logs on the remote tftpd and it's misleading: Jun 28 14:03:21 hostname tftpd[2506]: recv: Connection refused It first boggled my mind what it's trying to recv and then it came to me... the write error message is delayed because of the ICMP port unreachable travel time at which point the descriptor is already blocking in read I guess. So I have changed it to this: Jun 28 14:03:21 hostname tftpd[2506]: sendfile: Connection refused which to me is a lot more explanatory on what it fails on. sendfile is the function not the syscall. I'd rather see send in there than recv. Here is the patch: Index: tftpd.c === RCS file: /cvs/src/libexec/tftpd/tftpd.c,v retrieving revision 1.63 diff -u -r1.63 tftpd.c --- tftpd.c 27 Oct 2009 23:59:32 - 1.63 +++ tftpd.c 28 Jun 2012 18:00:29 - @@ -669,7 +669,10 @@ error = 1; if (errno == EINTR) continue; - syslog(LOG_ERR, recv: %m); + if (errno == ECONNREFUSED) + syslog(LOG_ERR, sendfile: %m); + else + syslog(LOG_ERR, recv: %m); goto abort; } ap-th_opcode = ntohs((u_short)ap-th_opcode); If you think kittens will die because of this patch then don't commit it but otherwise I'm just trying to make sense of this better. Cheers, -peter
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 11:00:24AM -0600, Nick Bender wrote: On Thu, Jun 28, 2012 at 9:16 AM, Ted Unangst t...@tedunangst.com wrote: Integration is one of the goals. ?I can't predict what extensions you may want to write. ?I mean, mg already reads a .mg file. ?If we knew what people were going to put in their .mg files, we could just hard code it in the program and cut out the startup file bloat. That said, some concrete examples would help, both to make sure we're building something useful and to demonstrate that it is useful. Why do people still use emacs and not mg? For text editing not usenet browsing or whatever. I don't want to add some python editor mode just to hear I don't use python. raises head TCL? BSD, small, fast, been around forever, C like syntax. In base would be awesome... ducks How can a language where everything is a string be good? -Otto
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 12:29 PM, Otto Moerbeek o...@drijf.net wrote: On Thu, Jun 28, 2012 at 11:00:24AM -0600, Nick Bender wrote: raises head TCL? BSD, small, fast, been around forever, C like syntax. In base would be awesome... ducks How can a language where everything is a string be good? -Otto While that was true in early versions it is no longer the case. As values are used they are converted to the appropriate representation, e.g.: set x 1; set y 2 set z [expr $x+$y] After assignment x and y are strings. During the evaluation of expr they are converted to integers and z is assigned an integer value. TCL is fairly modern at this point with features such as JIT byte compilation of procs.
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 10:05:49PM +0500, Mark Lumsden wrote: I'd be a lot happier voicing an opinion in support of something like this if I also saw diffs and interest in *using* them to extend functionality later or replace some things easier to do with scheme to make the code simpler - something kjell was alluding to. I think we can work towards that, but there's a bit of chicken and egg problem here. I'm not inclined to do a lot of work if the answer in two months is going to be oh, sorry, perl would have been cooler. The diff will only get larger from here. A promise of this is bigger and bloated now but will be really cool in the future isn't so good if the people putting it in see getting scheme integration in as the goal - otherwise, congrats, you've Integration is one of the goals. I can't predict what extensions you may want to write. I mean, mg already reads a .mg file. If we knew what people were going to put in their .mg files, we could just hard code it in the program and cut out the startup file bloat. That said, some concrete examples would help, both to make sure we're building something useful and to demonstrate that it is useful. Why do people still use emacs and not mg? For text editing not usenet browsing or whatever. +1 to somebody providing concrete examples. Hooks. Inspite of reading jmc@'s request on src@ to check for trailing whitespace in manpages, I happened to send one diff for review which had trailing whitespace. This could be avoided with a before-save-hook that can truncate trailing spaces. Also what if one wants to run something else while C files are being loaded into mg apart from the auto-execute c-mode hack. Here is a diff that adds hooks support I sent sometime ago, but not everyone would like to write their hooks in C. http://marc.info/?l=openbsd-techm=132993761420531w=2 PS: mandoc -Tlint complained but I missed it.
Re: route(8): /prefixlen syntax for -inet6
On Thu, Jun 28, 2012 at 09:55:57AM +0100, Stuart Henderson wrote:
[...]
# route add -inet6 ff55::1/96 ::1
add net ff55::1/96: gateway ::1
# route delete -inet6 ff55::1/96
route: writing to routing socket: No such process
delete net ff55::1/96: not in table
# route delete -inet6 ff55::/96
delete net ff55::/96
I think the address should be masked in the same way for both v4 and v6.
$ sudo ./route add -inet6 ff55::1/96 ::1
add net ff55::1/96: gateway ::1
$ sudo ./route delete -inet6 ff55::1/96
delete net ff55::1/96
However, this remains broken (it's broken for v4 as well):
$ sudo ./route add -inet6 ff55::1 -prefixlen 96 ::1
add net ff55::1: gateway ::1
$ sudo ./route delete -inet6 ff55::1 -prefixlen 96
route: writing to routing socket: No such process
delete net ff55::1: not in table
Index: sbin/route/route.8
===
RCS file: /opt/OpenBSD-CVS/src/sbin/route/route.8,v
retrieving revision 1.69
diff -u -r1.69 route.8
--- sbin/route/route.8 3 Sep 2011 22:59:08 - 1.69
+++ sbin/route/route.8 28 Jun 2012 21:36:58 -
@@ -240,6 +240,13 @@
is the number of bits in the network portion of the address
and is less than 32)
.It
+it is an IPv6 address with a
+.Dq / Ns Em XX
+suffix (where
+.Em XX
+is the number of bits in the network portion of the address
+and is less than 128)
+.It
it is the symbolic name of a network.
.El
.Pp
Index: sbin/route/route.c
===
RCS file: /opt/OpenBSD-CVS/src/sbin/route/route.c,v
retrieving revision 1.156
diff -u -r1.156 route.c
--- sbin/route/route.c 17 Mar 2012 10:16:40 - 1.156
+++ sbin/route/route.c 28 Jun 2012 21:36:58 -
@@ -93,7 +93,7 @@
voidpmsg_addrs(char *, int);
voidbprintf(FILE *, int, char *);
voidmask_addr(union sockunion *, union sockunion *, int);
-int inet6_makenetandmask(struct sockaddr_in6 *);
+int inet6_makenetandmask(struct sockaddr_in6 *, char *);
int getaddr(int, char *, struct hostent **);
voidgetmplslabel(char *, int);
int rtmsg(int, int, int, u_char);
@@ -737,19 +737,23 @@
* XXX the function may need more improvement...
*/
int
-inet6_makenetandmask(struct sockaddr_in6 *sin6)
+inet6_makenetandmask(struct sockaddr_in6 *sin6, char *plen)
{
- char *plen = NULL;
struct in6_addr in6;
+ const char *errstr;
+ int i, len, q, r;
- if (IN6_IS_ADDR_UNSPECIFIED(sin6-sin6_addr)
- sin6-sin6_scope_id == 0) {
- plen = 0;
- } else if ((sin6-sin6_addr.s6_addr[0] 0xe0) == 0x20) {
- /* aggregatable global unicast - RFC2374 */
- memset(in6, 0, sizeof(in6));
- if (!memcmp(sin6-sin6_addr.s6_addr[8], in6.s6_addr[8], 8))
- plen = 64;
+ if (NULL==plen) {
+ if (IN6_IS_ADDR_UNSPECIFIED(sin6-sin6_addr)
+ sin6-sin6_scope_id == 0) {
+ plen = 0;
+ } else if ((sin6-sin6_addr.s6_addr[0] 0xe0) == 0x20) {
+ /* aggregatable global unicast - RFC2374 */
+ memset(in6, 0, sizeof(in6));
+ if (!memcmp(sin6-sin6_addr.s6_addr[8],
+ in6.s6_addr[8], 8))
+ plen = 64;
+ }
}
if (!plen || strcmp(plen, 128) == 0)
@@ -757,6 +761,20 @@
else {
rtm_addrs |= RTA_NETMASK;
prefixlen(plen);
+
+ len = strtonum(plen, 0, 128, errstr);
+ if (errstr)
+ errx(1, prefixlen %s is %s, s, errstr);
+
+ q = (128-len) 3;
+ r = (128-len) 7;
+ i = 15;
+
+ while (q-- 0)
+ sin6-sin6_addr.s6_addr[i--] = 0;
+ if (r 0)
+ sin6-sin6_addr.s6_addr[i] = 0xff r;
+
return (0);
}
}
@@ -824,14 +842,25 @@
case AF_INET6:
{
struct addrinfo hints, *res;
+ charbuf[
+ sizeof(::::::255:255:255:255/128)
+ ];
+ char *sep;
+
+ if (strlcpy(buf, s, sizeof buf) = sizeof buf) {
+ errx(1, %s: bad value, s);
+ }
+ sep = strchr(buf, '/');
+ if (sep != NULL)
+ *sep++ = '\0';
memset(hints, 0, sizeof(hints));
hints.ai_family = afamily; /*AF_INET6*/
hints.ai_flags = AI_NUMERICHOST;
hints.ai_socktype = SOCK_DGRAM; /*dummy*/
- if (getaddrinfo(s, 0, hints, res) != 0) {
+ if (getaddrinfo(buf, 0, hints, res) != 0) {
hints.ai_flags = 0;
- if
Bridge rules
Doc : ifconfig bridge0 rule pass in on fxp0 src 0:de:ad:be:ef:0 tag USER1 Want to do something like ifconfig bridge0 rule pass in on fxp0 src 0:de:ad:*:*:* tag OPENBSDAWESOME or ifconfig bridge0 rule pass in on fxp0 src /\\A00:de:ad:/ tag OPENBSDAWESOME Read Code : found, in if_bridge.c (following SIOCBRDGARL from ifconfig) bcopy(req-ifbr_src, n-brl_src, sizeof(struct ether_addr)); bcopy(req-ifbr_dst, n-brl_dst, sizeof(struct ether_addr)); Search for usage of the (documented) field find /usr/src/ -type f | xargs grep ifbr_src /usr/src/share/man/man4/bridge.4: struct ether_addr ifbr_src; /* source mac */ /usr/src/sbin/ifconfig/brconfig.c: printf( src %s, ether_ntoa(r-ifbr_src)); /usr/src/sbin/ifconfig/brconfig.c: dea = rule.ifbr_src; Now I'm lost - () ascii ribbon campaign - against html e-mail /\
AES-{192,256}-CTR with isakmpd
Is there a particular reason we only support AES-128-CTR (AESCTR)
with isakmpd(8), but not the 192- and 256-bit variants like we do
for AES-CBC and AES-GCM?
If not, and I assume it's just a historic oversight, how about this?
Adds AES-{128,192,256}-CTR to ipsecctl(8) and isakmpd(8).
There is nothing to do for the kernel side and in fact you could
already set up manual SAs with enc aesctr and 192+32 and 256+32
bit keys (but don't ever do that in earnest with counter mode
ciphers!).
Index: sbin/ipsecctl/ike.c
===
RCS file: /cvs/src/sbin/ipsecctl/ike.c,v
retrieving revision 1.70
diff -u -p -r1.70 ike.c
--- sbin/ipsecctl/ike.c 8 Nov 2011 13:26:06 - 1.70
+++ sbin/ipsecctl/ike.c 28 Jun 2012 20:53:19 -
@@ -223,6 +223,15 @@ ike_section_p2(struct ipsec_rule *r, FIL
case ENCXF_AESCTR:
fprintf(fd, AESCTR);
break;
+ case ENCXF_AES_128_CTR:
+ fprintf(fd, AESCTR-128);
+ break;
+ case ENCXF_AES_192_CTR:
+ fprintf(fd, AESCTR-192);
+ break;
+ case ENCXF_AES_256_CTR:
+ fprintf(fd, AESCTR-256);
+ break;
case ENCXF_AES_128_GCM:
fprintf(fd, AESGCM-128);
needauth = 0;
Index: sbin/ipsecctl/ipsec.conf.5
===
RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
retrieving revision 1.137
diff -u -p -r1.137 ipsec.conf.5
--- sbin/ipsecctl/ipsec.conf.5 24 Apr 2012 14:56:09 - 1.137
+++ sbin/ipsecctl/ipsec.conf.5 28 Jun 2012 20:59:29 -
@@ -587,7 +587,7 @@ One practical way of generating keys is
.Xr openssl 1 .
The following generates a 160-bit (20-byte) key:
.Bd -literal -offset indent
-$ openssl rand 20 | hexdump -e '20/1 %02x'
+$ openssl rand -hex 20
.Ed
.Pp
The following authentication types are permitted with the
@@ -615,6 +615,9 @@ keyword:
.It Li aes-192 Ta 192 bits Ta
.It Li aes-256 Ta 256 bits Ta
.It Li aesctr Ta 160 bits Ta [phase 2 only]
+.It Li aes-128-ctr Ta 160 bits Ta [phase 2 only]
+.It Li aes-192-ctr Ta 224 bits Ta [phase 2 only]
+.It Li aes-256-ctr Ta 288 bits Ta [phase 2 only]
.It Li aes-128-gcm Ta 160 bits Ta [phase 2 only]
.It Li aes-192-gcm Ta 224 bits Ta [phase 2 only]
.It Li aes-256-gcm Ta 288 bits Ta [phase 2 only]
Index: sbin/ipsecctl/ipsecctl.h
===
RCS file: /cvs/src/sbin/ipsecctl/ipsecctl.h,v
retrieving revision 1.62
diff -u -p -r1.62 ipsecctl.h
--- sbin/ipsecctl/ipsecctl.h8 Nov 2011 13:26:06 - 1.62
+++ sbin/ipsecctl/ipsecctl.h28 Jun 2012 20:52:05 -
@@ -64,6 +64,7 @@ enum {
enum {
ENCXF_UNKNOWN, ENCXF_NONE, ENCXF_3DES_CBC, ENCXF_DES_CBC, ENCXF_AES,
ENCXF_AES_128, ENCXF_AES_192, ENCXF_AES_256, ENCXF_AESCTR,
+ ENCXF_AES_128_CTR, ENCXF_AES_192_CTR, ENCXF_AES_256_CTR,
ENCXF_AES_128_GCM, ENCXF_AES_192_GCM, ENCXF_AES_256_GCM,
ENCXF_AES_128_GMAC, ENCXF_AES_192_GMAC, ENCXF_AES_256_GMAC,
ENCXF_BLOWFISH, ENCXF_CAST128, ENCXF_NULL
Index: sbin/ipsecctl/parse.y
===
RCS file: /cvs/src/sbin/ipsecctl/parse.y,v
retrieving revision 1.152
diff -u -p -r1.152 parse.y
--- sbin/ipsecctl/parse.y 20 Dec 2011 13:27:51 - 1.152
+++ sbin/ipsecctl/parse.y 28 Jun 2012 20:58:03 -
@@ -107,6 +107,9 @@ const struct ipsec_xf encxfs[] = {
{ aes-192,ENCXF_AES_192, 24, 24, 0 },
{ aes-256,ENCXF_AES_256, 32, 32, 0 },
{ aesctr, ENCXF_AESCTR, 16+4, 32+4, 0 },
+ { aes-128-ctr,ENCXF_AES_128_CTR, 16+4, 16+4, 0 },
+ { aes-192-ctr,ENCXF_AES_192_CTR, 24+4, 24+4, 0 },
+ { aes-256-ctr,ENCXF_AES_256_CTR, 32+4, 32+4, 0 },
{ aes-128-gcm,ENCXF_AES_128_GCM, 16+4, 16+4, 1 },
{ aes-192-gcm,ENCXF_AES_192_GCM, 24+4, 24+4, 1 },
{ aes-256-gcm,ENCXF_AES_256_GCM, 32+4, 32+4, 1 },
Index: sbin/ipsecctl/pfkdump.c
===
RCS file: /cvs/src/sbin/ipsecctl/pfkdump.c,v
retrieving revision 1.30
diff -u -p -r1.30 pfkdump.c
--- sbin/ipsecctl/pfkdump.c 13 Apr 2011 11:31:27 - 1.30
+++ sbin/ipsecctl/pfkdump.c 28 Jun 2012 20:56:46 -
@@ -710,7 +710,17 @@ pfkey_print_sa(struct sadb_msg *msg, int
}
break;
case SADB_X_EALG_AESCTR:
- xfs.encxf =
Re: AES-{192,256}-CTR with isakmpd
On Fri, Jun 29, 2012 at 12:09 AM, Christian Weisgerber
na...@mips.inka.de wrote:
Is there a particular reason we only support AES-128-CTR (AESCTR)
with isakmpd(8), but not the 192- and 256-bit variants like we do
for AES-CBC and AES-GCM?
If not, and I assume it's just a historic oversight, how about this?
Adds AES-{128,192,256}-CTR to ipsecctl(8) and isakmpd(8).
There is nothing to do for the kernel side and in fact you could
already set up manual SAs with enc aesctr and 192+32 and 256+32
bit keys (but don't ever do that in earnest with counter mode
ciphers!).
I see no reason not to implement that, especially given the fact
that RFC 3686 specifies three key sizes. OK mikeb for the diff.
Re: perl 5.16 update / macppc / signal dispatch test failure
It looks like arm and sh are broken too. I've added a regress test to /usr/src/regress/sys/kern/sigpending if anyone wants to try tackling one or more of these broken implementations. On Thu, Jun 28, 2012 at 5:10 PM, Matthew Dempsky matt...@dempsky.org wrote: On Thu, Jun 28, 2012 at 5:09 PM, Matthew Dempsky matt...@dempsky.org wrote: So the sigpending() system call returns the pending signals as an int value via register, but then the libc stub is supposed to take care of storing this as appropriate. If you look at libc/arch/amd64/sys/sigreturn.S, you'll notice there's some followup assembly code for this. It looks like the analogous code is missing from libc/arch/powerpc/sys/sigreturn.S. Er, sigpending.S of course. On Thu, Jun 28, 2012 at 4:12 PM, Stuart Henderson s...@spacehopper.org wrote: I'm doing some test runs with Perl 5.16 for Andrew Fresh and seeing a signal dispatch-related test failure on macppc kern.version=OpenBSD 5.2-beta (GENERIC.MP) #198: Sat Jun 23 11:30:52 MDT 2012 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP t/op/sigdispatch .. # Failed test 8 - sigpending at op/sigdispatch.t line 60 # got 536870912 # expected 0 but true # Failed test 9 - SIGUSR1 is pending at op/sigdispatch.t line 61 # got 0 # expected 1 FAILED at test 8 This is a standard (not threaded) build. I can give files to reproduce etc if wanted but wondered if anyone has ideas. It's not happening on amd64: kern.version=OpenBSD 5.2-beta (GENERIC.MP) #325: Thu Jun 21 10:08:05 MDT 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Tests are around http://perl5.git.perl.org/perl.git/blame/67288365cab33e76a48b697c001c11d4dc5b 1912:/t/op/sigdispatch.t#l60
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 15:07, Jérémie Courrèges-Anglas wrote:
Hi,
+
+typedef void *HMODULE;
+typedef void (*FARPROC)();
+#define SUN_DL
Hmmm.
+#include dlfcn.h
+
+#if defined(SUN_DL)
Huh? 8)
old code is old. :) looks like jasper un-ifdeffed some win32 code,
leaving a few remnants behind.
+static void make_filename(const char *name, char *filename) {
+ (void)strlcpy(filename,name,sizeof(filename));
+ (void)strlcat(filename,SUFFIX,sizeof(filename));
This looks wrong.
indeed, thanks.
Re: nc(1): Report incoming connections on nc -v -l
This looks good to me, can I get another ok ?
On Sun, Jun 24, 2012 at 07:07:29AM -0400, Ricky Zhou wrote:
On 2012-06-16 02:37:27 PM, Christiano F. Haesbaert wrote:
I guess so, I don't use nc too often but it sounds reasonable to me,
your code has a few notes though, please check inline.
(Sorry for the slow response, was travelling last week)
Thanks for looking at the patch - here's a new one with your fixes
included.
Thanks,
Ricky
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.107
diff -u netcat.c
--- netcat.c 1 Apr 2012 02:58:57 - 1.107
+++ netcat.c 24 Jun 2012 09:51:19 -
@@ -106,6 +106,7 @@
int unix_listen(char *);
void set_common_sockopts(int);
int map_tos(char *, int *);
+void report_connect(const struct sockaddr *, socklen_t);
void usage(int);
int
@@ -364,6 +365,9 @@
if (rv 0)
err(1, connect);
+ if (vflag)
+ report_connect((struct sockaddr *)z,
len);
+
readwrite(s);
} else {
len = sizeof(cliaddr);
@@ -371,6 +375,10 @@
len);
if (connfd == -1)
err(1, accept);
+
+ if (vflag)
+ report_connect((struct sockaddr
*)cliaddr, len);
+
readwrite(connfd);
close(connfd);
}
@@ -957,6 +965,32 @@
}
return (0);
+}
+
+void
+report_connect(const struct sockaddr *sa, socklen_t salen)
+{
+ char remote_host[NI_MAXHOST];
+ char remote_port[NI_MAXSERV];
+ int herr;
+ int flags = NI_NUMERICSERV;
+
+ if (nflag)
+ flags |= NI_NUMERICHOST;
+
+ if ((herr = getnameinfo(sa, salen,
+ remote_host, sizeof(remote_host),
+ remote_port, sizeof(remote_port),
+ flags)) != 0) {
+ if (herr == EAI_SYSTEM)
+ err(1, getnameinfo);
+ else
+ errx(1, getnameinfo: %s, gai_strerror(herr));
+ }
+
+ fprintf(stderr,
+ Connection from %s %s
+ received!\n, remote_host, remote_port);
}
void
Re: nc -ul semantics
Although the idea for using -k with -u is a good one, I don't think
it's necessary, I for one think we should change semantics as the
first mail suggested.
The only real for using connected UDP sockets is to get the ICMP async
errors at the socket level, ICMP port unreachable mainly.
I see no reason why not to change the semantics to *not* use connected
UDP sockets, since the server will *never* write anything back to the
client.
On Mon, Jun 25, 2012 at 01:41:48PM +0300, Lazaros Koromilas wrote:
On Sun, Jun 24, 2012 at 11:23:05PM +0200, Ariane van der Steldt wrote:
On Mon, Jun 25, 2012 at 12:09:33AM +0300, dsp wrote:
We observe the following behaviour when running nc -ul.
The server begins on a recvfrom() and when data arrives it
connects() the socket.
When the client dies , the server remains in a connected state
therefore ignoring subsequent data arriving on the port.
Is this really the intended logic for a connectionless protocol like
UDP? We proceeded to comment out the connect statement and we were
able to receive data from multiple *sessions* as expected.
Can you shed some light on the matter???
Reading the man page, I think you want to add the -k option to nc.
The -k option does nothing when used with -u because the readwrite()
session cannot end. Would the following be a reasonable change?
It has the side effect of letting UDP packets to interleave.
Index: nc.1
===
RCS file: /cvs/src/usr.bin/nc/nc.1,v
retrieving revision 1.60
diff -u -p -r1.60 nc.1
--- nc.1 7 Feb 2012 12:11:43 - 1.60
+++ nc.1 25 Jun 2012 10:40:15 -
@@ -119,6 +119,10 @@ is completed.
It is an error to use this option without the
.Fl l
option.
+When used together with the
+.Fl u
+option all UDP datagrams arriving on the port are received;
+not just those sent by the first client to connect.
.It Fl l
Used to specify that
.Nm
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.105
diff -u -p -r1.105 netcat.c
--- netcat.c 9 Feb 2012 06:25:35 - 1.105
+++ netcat.c 25 Jun 2012 10:40:15 -
@@ -364,9 +364,12 @@ main(int argc, char *argv[])
if (rv 0)
err(1, recvfrom);
- rv = connect(s, (struct sockaddr *)z, len);
- if (rv 0)
- err(1, connect);
+ if (!kflag) {
+ rv = connect(s, (struct sockaddr *)z,
+ len);
+ if (rv 0)
+ err(1, connect);
+ }
readwrite(s);
} else {
Re: nc -ul semantics
On Thu, Jun 28, 2012 at 11:44:36PM -0300, Christiano F. Haesbaert wrote:
Although the idea for using -k with -u is a good one, I don't think
it's necessary, I for one think we should change semantics as the
first mail suggested.
The only real for using connected UDP sockets is to get the ICMP async
errors at the socket level, ICMP port unreachable mainly.
I see no reason why not to change the semantics to *not* use connected
UDP sockets, since the server will *never* write anything back to the
client.
But then we would have to drop print connection received from...,
which is being introduced in another diff. Now I'm more inclined in
going for the -k, that way we know when to supress the message.
On Mon, Jun 25, 2012 at 01:41:48PM +0300, Lazaros Koromilas wrote:
On Sun, Jun 24, 2012 at 11:23:05PM +0200, Ariane van der Steldt wrote:
On Mon, Jun 25, 2012 at 12:09:33AM +0300, dsp wrote:
We observe the following behaviour when running nc -ul.
The server begins on a recvfrom() and when data arrives it
connects() the socket.
When the client dies , the server remains in a connected state
therefore ignoring subsequent data arriving on the port.
Is this really the intended logic for a connectionless protocol like
UDP? We proceeded to comment out the connect statement and we were
able to receive data from multiple *sessions* as expected.
Can you shed some light on the matter???
Reading the man page, I think you want to add the -k option to nc.
The -k option does nothing when used with -u because the readwrite()
session cannot end. Would the following be a reasonable change?
It has the side effect of letting UDP packets to interleave.
Index: nc.1
===
RCS file: /cvs/src/usr.bin/nc/nc.1,v
retrieving revision 1.60
diff -u -p -r1.60 nc.1
--- nc.17 Feb 2012 12:11:43 - 1.60
+++ nc.125 Jun 2012 10:40:15 -
@@ -119,6 +119,10 @@ is completed.
It is an error to use this option without the
.Fl l
option.
+When used together with the
+.Fl u
+option all UDP datagrams arriving on the port are received;
+not just those sent by the first client to connect.
.It Fl l
Used to specify that
.Nm
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.105
diff -u -p -r1.105 netcat.c
--- netcat.c9 Feb 2012 06:25:35 - 1.105
+++ netcat.c25 Jun 2012 10:40:15 -
@@ -364,9 +364,12 @@ main(int argc, char *argv[])
if (rv 0)
err(1, recvfrom);
- rv = connect(s, (struct sockaddr *)z, len);
- if (rv 0)
- err(1, connect);
+ if (!kflag) {
+ rv = connect(s, (struct sockaddr *)z,
+ len);
+ if (rv 0)
+ err(1, connect);
+ }
readwrite(s);
} else {
wbsio: Add support for Winbond W83627UHG
This diff adds support for the Winbond W83627UHG chip, as found on the Lanner FW-7539 appliance. This diff was ported from DragonFly BSD: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/245ec76bc1613b22cf282526fa9931e4c16e4237 Here is the sysctl hw.sensors output on that Lanner appliance before the diff: $ sysctl -n kern.version OpenBSD 5.2-beta (GENERIC.MP) #338: Tue Jun 26 22:52:57 MDT 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ sysctl hw.sensors hw.sensors.cpu0.temp0=13.00 degC hw.sensors.cpu1.temp0=13.00 degC And here's the output after the diff is applied: $ sysctl -n kern.version OpenBSD 5.2-beta (GENERIC.MP) #2: Thu Jun 28 16:14:19 EDT 2012 l...@nori.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ sysctl hw.sensors hw.sensors.cpu0.temp0=13.00 degC hw.sensors.cpu1.temp0=13.00 degC hw.sensors.lm1.temp0=36.00 degC hw.sensors.lm1.temp1=29.00 degC hw.sensors.lm1.temp2=36.00 degC hw.sensors.lm1.fan1=4017 RPM hw.sensors.lm1.volt0=1.16 VDC (VCore) hw.sensors.lm1.volt1=4.96 VDC (+12V) hw.sensors.lm1.volt2=2.45 VDC (+3.3V) hw.sensors.lm1.volt3=2.40 VDC (+3.3V) hw.sensors.lm1.volt4=-8.79 VDC (-12V) hw.sensors.lm1.volt5=0.74 VDC hw.sensors.lm1.volt6=0.05 VDC hw.sensors.lm1.volt7=2.45 VDC (3.3VSB) hw.sensors.lm1.volt8=0.79 VDC (VBAT) $ dmesg | grep W83627 wbsio0 at isa0 port 0x2e/2: W83627UHG rev 0x32 lm1 at wbsio0 port 0xa10/8: W83627DHG Full dmesg at http://lteo.net/stuff/fw7539-dmesg.txt I am very new to this part of the code, and would really appreciate a review of the diff to make sure I did not miss anything. Comments and feedback welcome too. Thank you! Lawrence Index: share/man/man4/lm.4 === RCS file: /cvs/src/share/man/man4/lm.4,v retrieving revision 1.23 diff -u -p -r1.23 lm.4 --- share/man/man4/lm.4 7 Dec 2011 14:47:19 - 1.23 +++ share/man/man4/lm.4 28 Jun 2012 21:02:04 - @@ -86,7 +86,7 @@ Nuvoton NCT6776F .It Winbond W83627HF, W83627THF, W83637HF and W83697HF .It -Winbond W83627DHG and W83627EHF +Winbond W83627DHG, W83627UHG and W83627EHF .It Winbond W83781D, W83782D and W83783S .It Index: sys/dev/isa/wbsio.c === RCS file: /cvs/src/sys/dev/isa/wbsio.c,v retrieving revision 1.7 diff -u -p -r1.7 wbsio.c --- sys/dev/isa/wbsio.c 6 Dec 2011 16:06:07 - 1.7 +++ sys/dev/isa/wbsio.c 28 Jun 2012 20:10:43 - @@ -108,6 +108,7 @@ wbsio_probe(struct device *parent, void case WBSIO_ID_W83627EHF: case WBSIO_ID_W83627DHG: case WBSIO_ID_W83627DHGP: + case WBSIO_ID_W83627UHG: case WBSIO_ID_W83637HF: case WBSIO_ID_W83697HF: case WBSIO_ID_NCT6776F: @@ -159,6 +160,9 @@ wbsio_attach(struct device *parent, stru break; case WBSIO_ID_W83627DHGP: printf(: W83627DHG-P); + break; + case WBSIO_ID_W83627UHG: + printf(: W83627UHG); break; case WBSIO_ID_W83637HF: printf(: W83637HF); Index: sys/dev/isa/wbsioreg.h === RCS file: /cvs/src/sys/dev/isa/wbsioreg.h,v retrieving revision 1.2 diff -u -p -r1.2 wbsioreg.h --- sys/dev/isa/wbsioreg.h 7 Dec 2011 12:24:17 - 1.2 +++ sys/dev/isa/wbsioreg.h 28 Jun 2012 20:11:01 - @@ -38,6 +38,7 @@ #define WBSIO_ID_W83627EHF 0x88 #define WBSIO_ID_W83627DHG 0xa0 #define WBSIO_ID_W83627DHGP0xb0 +#define WBSIO_ID_W83627UHG 0xa2 #define WBSIO_ID_W83627SF 0x59 #define WBSIO_ID_W83637HF 0x70 #define WBSIO_ID_W83697HF 0x60
Re: tinyscheme + mg
On Thu, Jun 28, 2012 at 12:40:57PM -0600, Nick Bender wrote: On Thu, Jun 28, 2012 at 12:29 PM, Otto Moerbeek o...@drijf.net wrote: On Thu, Jun 28, 2012 at 11:00:24AM -0600, Nick Bender wrote: raises head TCL? BSD, small, fast, been around forever, C like syntax. In base would be awesome... ducks How can a language where everything is a string be good? ? ? ? ?-Otto While that was true in early versions it is no longer the case. As values are used they are converted to the appropriate representation, e.g.: set x 1; set y 2 set z [expr $x+$y] After assignment x and y are strings. During the evaluation of expr they are converted to integers and z is assigned an integer value. Type unsafeness is staring me in the face. TCL is fairly modern at this point with features such as JIT byte compilation of procs. Having a smart interpreter doesn't make the language better. Anyway, I don't want to go into language wars here. -Otto
