Re: Help on helping with virtualization?
AFAIK, the standard procedure is: - you have an itch nobody cared/had time to scratch before. - you study enough to spit at least some lines of code aiming your goals. - you puts(3) your lame-or-not code in-here. - if it's interesting enough, someone will chime in. Regards!!! El mié, 21 sept 2022 a las 14:10, Christoff Humphries () escribió: > > Hello. > > I want to help with the virtualization project to get the things that > are incomplete or missing completed (ie, the "not available at this > time" list on https://www.openbsd.org/faq/faq16.html). > > Is there a point of contact I should direct questions to, as I'll likely > have a lot of questions once start diving in to load it into my brain > and understand the code well enough to do something well and useful. > > Or should I just ask whatever questions I have here? > > Asking as I'm not sure how this project handles that stuff (open list or > pushed more to mentor/owner people for subject areas). > > Thanks! > Christoff Humphries >
Re: [patch] traceroute timeouts
To whom may concern, one of the main spanish ADSL providers (because rural connectivity is mainly ADSL over here) use interleaved FEC on their devices. So expect 120 ms latency just in the last copper mile. Add two poor WiFi hops, and 1 s may be too short at prime time. Yep, my opinion is very biased as a heavy outdoor WiFi user. Regards! El vie, 20 ago 2021 a las 13:29, Florian Obser () escribió: > > I guess I was too optimistic. > I regularly work on machines that are 600-700 ms away and figured an > additional 300 ms is good enough. Maybe not in case of congested links... > > On 20 August 2021 13:17:12 CEST, Mark Kettenis > wrote: > >> From: Florian Obser > >> Date: Fri, 20 Aug 2021 10:46:21 +0200 > >> > >> Makes sense to me, OK florian > > > >Doesn't make sense to me. The RTT for an ICMP packet can be a > >significant part of a second (think Europe-Australia the wrong way > >around cause that is where all the bandwidth is, or when satellites > >are involved). I think this means that a single dropped packet could > >result in a failure to resolve one of the hops on such a path. > > > >I don't necessarily object to giving folks the ammunition to shoot > >themselves into the foot by dropping the minimum value to 1 second. > >But the default should be larger I think. > > > >> On 2021-08-19 23:47 -07, wrote: > >> > The default traceroute timeout of 5 seconds is excruciatingly long > >> > when there are elements of the route that don't respond, and it > >> > wasn't allowed to be set lower than 2 seconds. > >> > > >> > This changes the minimum to 1 second, matching FreeBSD, and also > >> > makes that the default, which should be reasonable for the vast > >> > majority of users today. > >> > > >> > The two awk files in this directory are two decades old, and > >> > not installed anywhere they can be executed as part of a traceroute > >> > pipeline; can they be removed? If the functionality is useful, > >> > implementing mean/median reporting as a new option in C would be > >> > straightforward. > >> > > >> > Index: usr.sbin/traceroute/traceroute.8 > >> > === > >> > RCS file: /cvs/src/usr.sbin/traceroute/traceroute.8,v > >> > retrieving revision 1.69 > >> > diff -u -p -u -r1.69 traceroute.8 > >> > --- usr.sbin/traceroute/traceroute.8 11 Feb 2020 18:41:39 - > >> > 1.69 > >> > +++ usr.sbin/traceroute/traceroute.8 20 Aug 2021 06:33:30 - > >> > @@ -201,7 +201,7 @@ and > >> > are listed. > >> > .It Fl w Ar waittime > >> > Set the time, in seconds, to wait for a response to a probe. > >> > -The default is 5. > >> > +The default is 1. > >> > .It Fl x > >> > Print the ICMP extended headers if available. > >> > This option is not available for IPv6. > >> > Index: usr.sbin/traceroute/traceroute.c > >> > === > >> > RCS file: /cvs/src/usr.sbin/traceroute/traceroute.c,v > >> > retrieving revision 1.164 > >> > diff -u -p -u -r1.164 traceroute.c > >> > --- usr.sbin/traceroute/traceroute.c 12 Jul 2021 15:09:21 - > >> > 1.164 > >> > +++ usr.sbin/traceroute/traceroute.c 20 Aug 2021 06:33:30 - > >> > @@ -351,7 +351,7 @@ main(int argc, char *argv[]) > >> >rcvsock4 = rcvsock6 = sndsock4 = sndsock6 = -1; > >> >v4sock_errno = v6sock_errno = 0; > >> > > >> > - conf->waittime = 5 * 1000; > >> > + conf->waittime = 1000; > >> > > >> >if ((rcvsock6 = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6)) == -1) > >> >v6sock_errno = errno; > >> > @@ -554,9 +554,9 @@ main(int argc, char *argv[]) > >> >err(1, "setsockopt SO_RTABLE"); > >> >break; > >> >case 'w': > >> > - conf->waittime = strtonum(optarg, 2, INT_MAX, > >> > ); > >> > + conf->waittime = strtonum(optarg, 1, INT_MAX, > >> > ); > >> >if (errstr) > >> > - errx(1, "wait must be >1 sec."); > >> > + errx(1, "wait must be >=1 sec."); > >> >conf->waittime *= 1000; > >> >break; > >> >case 'x': > >> > > >> > > >> > >> -- > >> I'm not entirely sure you are real. > >> > >> > > -- > Sent from a mobile device. Please excuse poor formatting. >
Re: ping graphical display
As a WISP manager always experiencing spaced-but-repeated packet-loss
mayhem, I'm loving it.
El vie, 19 feb 2021 a las 16:22, Stuart Henderson
() escribió:
>
> This diff adds something similar to cisco's ping display, giving a
> visual display of good/dropped pings. Any interest in it? Example
> output (with a couple of ^T during the run):
>
> $ ping -g 192.168.41.21
> PING 192.168.41.21 (192.168.41.21): 56 data bytes
> load:
> 0.04 cmd: ping 8312 [running] 0.00u 0.00s 0% 117k
>
> --- 192.168.41.21 ping statistics ---
> 212 packets transmitted, 212 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.342/0.636/28.579/1.940 ms
> .!!...!!!...!.!!!...!!!...!.!!!.....!.!!!.....!.!!!.....!!....!!....!!..!..load:
> 0.00 cmd: ping 8312 [running] 0.00u 0.00s 0% 118k
>
> --- 192.168.41.21 ping statistics ---
> 924 packets transmitted, 800 packets received, 13.4% packet loss
> round-trip min/avg/max/std-dev = 0.304/0.618/41.986/1.933 ms
>
> (and while I'm there, if anyone has an idea why this one machine being
> pinged, which is a 6.8 box with em(4), might periodically stop receiving
> packets from a couple of hosts in the subnet while things are working
> ok for others, I'm all ears ;) no interface errors, netlivelocks, etc.)
>
>
> Index: ping.8
> ===
> RCS file: /cvs/src/sbin/ping/ping.8,v
> retrieving revision 1.63
> diff -u -p -r1.63 ping.8
> --- ping.8 11 Feb 2020 18:41:39 - 1.63
> +++ ping.8 19 Feb 2021 15:11:19 -
> @@ -66,7 +66,7 @@
> .Nd send ICMP ECHO_REQUEST packets to network hosts
> .Sh SYNOPSIS
> .Nm ping
> -.Op Fl DdEefHLnqRv
> +.Op Fl DdEefgHLnqRv
> .Op Fl c Ar count
> .Op Fl I Ar sourceaddr
> .Op Fl i Ar interval
> @@ -79,7 +79,7 @@
> .Op Fl w Ar maxwait
> .Ar host
> .Nm ping6
> -.Op Fl DdEefHLmnqv
> +.Op Fl DdEefgHLmnqv
> .Op Fl c Ar count
> .Op Fl h Ar hoplimit
> .Op Fl I Ar sourceaddr
> @@ -151,6 +151,21 @@ Only the superuser may use this option.
> .Bf -emphasis
> This can be very hard on a network and should be used with caution.
> .Ef
> +.It Fl g
> +Graphic display.
> +This provides a quick visual display of packets received and lost.
> +For every
> +.Dv ECHO_REPLY
> +received, a period
> +.Sq \&.
> +is printed, while for every missed packet an exclamation mark
> +.Sq !
> +is printed.
> +Duplicate and truncated replies are indicated with
> +.Sq D
> +and
> +.Sq T
> +respectively.
> .It Fl H
> Try reverse lookups for addresses.
> .It Fl h Ar hoplimit
> Index: ping.c
> ===
> RCS file: /cvs/src/sbin/ping/ping.c,v
> retrieving revision 1.243
> diff -u -p -r1.243 ping.c
> --- ping.c 29 Dec 2020 16:40:47 - 1.243
> +++ ping.c 19 Feb 2021 15:11:19 -
> @@ -145,7 +145,7 @@ int options;
> #defineF_QUIET 0x0010
> #defineF_RROUTE0x0020
> #defineF_SO_DEBUG 0x0040
> -/* 0x0080 */
> +#defineF_GRAPHIC 0x0080
> #defineF_VERBOSE 0x0100
> /* 0x0200 */
> #defineF_HDRINCL 0x0400
> @@ -297,8 +297,8 @@ main(int argc, char *argv[])
> preload = 0;
> datap = [ECHOLEN + ECHOTMLEN];
> while ((ch = getopt(argc, argv, v6flag ?
> - "c:DdEefHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
> - "DEI:LRS:c:defHi:l:np:qs:T:t:V:vw:")) != -1) {
> + "c:DdEefgHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
> + "DEI:LRS:c:defgHi:l:np:qs:T:t:V:vw:")) != -1) {
> switch(ch) {
> case 'c':
> npackets = strtonum(optarg, 0, INT64_MAX, );
> @@ -326,6 +326,9 @@ main(int argc, char *argv[])
> options |= F_FLOOD;
> setvbuf(stdout, NULL, _IONBF, 0);
> break;
> + case 'g':
> + options |= F_GRAPHIC;
> + break;
> case 'H':
> options |= F_HOSTNAME;
> break;
> @@ -879,6 +882,11 @@ main(int argc, char
Re: energy sensor
Just for completeness, 1 Joule = 1 watt per second, so 3600 Joules = 1
Watt-hour. This may be related to the total amount of energy harvested by
the chip to allow analyze how much power hungry are the CPU for a given
job.
Regards!
El mar., 14 jul. 2020 a las 19:48, Theo de Raadt ()
escribió:
> No harm in adding it.
>
>
> Mark Kettenis wrote:
>
> > The firmware on the POWER9 machines provides an energy sensor. This
> > sensor measures the energy on/in/at the chip. I'm not sure what that
> > actually means. But it is different from the energy content of a
> > battery which is measured in Watthours.
> >
> > Should I add this? Or should I just skip these sensors?
> >
> > Index: sbin/sysctl/sysctl.c
> > ===
> > RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
> > retrieving revision 1.251
> > diff -u -p -r1.251 sysctl.c
> > --- sbin/sysctl/sysctl.c 29 May 2020 04:42:23 - 1.251
> > +++ sbin/sysctl/sysctl.c 14 Jul 2020 17:30:43 -
> > @@ -2759,6 +2759,9 @@ print_sensor(struct sensor *s)
> > case SENSOR_VELOCITY:
> > printf("%4.3f m/s", s->value / 100.0);
> > break;
> > + case SENSOR_ENERGY:
> > + printf("%.2f J", s->value / 100.0);
> > + break;
> > default:
> > printf("unknown");
> > }
> > Index: usr.bin/systat/sensors.c
> > ===
> > RCS file: /cvs/src/usr.bin/systat/sensors.c,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 sensors.c
> > --- usr.bin/systat/sensors.c 10 Dec 2018 13:35:54 - 1.31
> > +++ usr.bin/systat/sensors.c 14 Jul 2020 17:30:43 -
> > @@ -291,6 +291,9 @@ showsensor(struct sensinfo *s)
> > case SENSOR_VELOCITY:
> > tbprintf("%4.3f m/s", s->sn_value / 100.0);
> > break;
> > + case SENSOR_ENERGY:
> > + tbprintf("%.2f J", s->sn_value / 100.0);
> > + break;
> > default:
> > tbprintf("%10lld", s->sn_value);
> > break;
> > Index: sys/sys/sensors.h
> > ===
> > RCS file: /cvs/src/sys/sys/sensors.h,v
> > retrieving revision 1.36
> > diff -u -p -r1.36 sensors.h
> > --- sys/sys/sensors.h 10 Dec 2018 13:35:54 - 1.36
> > +++ sys/sys/sensors.h 14 Jul 2020 17:30:43 -
> > @@ -53,6 +53,7 @@ enum sensor_type {
> > SENSOR_PRESSURE,/* pressure (mPa) */
> > SENSOR_ACCEL, /* acceleration (u m/s^2) */
> > SENSOR_VELOCITY,/* velocity (u m/s) */
> > + SENSOR_ENERGY, /* energy (uJ) */
> > SENSOR_MAX_TYPES
> > };
> >
> > @@ -80,6 +81,7 @@ static const char * const sensor_type_s[
> > "pressure",
> > "acceleration",
> > "velocity",
> > + "energy",
> > "undefined"
> > };
> > #endif /* !_KERNEL */
> >
>
>
Re: acpithinkpad: a fix for the x260
A T460s looking good over here.
Regards!
El jue., 7 mar. 2019 a las 17:05, James Turner
() escribió:
>
> On Thu, Mar 07, 2019 at 01:31:59PM +, Stuart Henderson wrote:
> > On 2019/03/06 20:55, joshua stein wrote:
> > > sthen found that the HKEY version metric failed on the x260 where it
> > > reports version 1 but requires the new ACPI method of changing
> > > backlight.
> > >
> > > This diff tries to do the ACPI method on all machines and falls back
> > > to the CMOS method if that fails.
> > >
> > > Can all those that tried the previous diff (which has been
> > > committed) try this one and make sure nothing broke?
> > >
> > > This also unmasks the microphone mute event which helps mixerctl
> > > stay in sync on the x260 (it has no effect on my x1c6, but probably
> > > can't hurt).
> > >
> > >
>
> X280 is still happy with this diff. The microphone mute button doesn't
> seem to do anything tho.
>
> > > Index: sys/dev/acpi/acpithinkpad.c
> >
> > The patch in the mail doesn't apply cleanly for me due to some
> > whitespace issues, if anyone else is having problems with that here's
> > a regenerated version:
> >
> >
> > Index: acpithinkpad.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
> > retrieving revision 1.63
> > diff -u -p -r1.63 acpithinkpad.c
> > --- acpithinkpad.c6 Mar 2019 15:36:30 - 1.63
> > +++ acpithinkpad.c7 Mar 2019 13:29:46 -
> > @@ -124,6 +124,7 @@
> > #define THINKPAD_ADAPTIVE_MODE_HOME 1
> > #define THINKPAD_ADAPTIVE_MODE_FUNCTION 3
> >
> > +#define THINKPAD_MASK_MIC_MUTE (1 << 14)
> > #define THINKPAD_MASK_BRIGHTNESS_UP (1 << 15)
> > #define THINKPAD_MASK_BRIGHTNESS_DOWN(1 << 16)
> > #define THINKPAD_MASK_KBD_BACKLIGHT (1 << 17)
> > @@ -171,8 +172,8 @@ int thinkpad_get_kbd_backlight(struct ws
> > int thinkpad_set_kbd_backlight(struct wskbd_backlight *);
> > extern int (*wskbd_get_backlight)(struct wskbd_backlight *);
> > extern int (*wskbd_set_backlight)(struct wskbd_backlight *);
> > -void thinkpad_get_brightness(struct acpithinkpad_softc *);
> > -void thinkpad_set_brightness(void *, int);
> > +int thinkpad_get_brightness(struct acpithinkpad_softc *);
> > +int thinkpad_set_brightness(void *, int);
> > int thinkpad_get_param(struct wsdisplay_param *);
> > int thinkpad_set_param(struct wsdisplay_param *);
> > extern int (*ws_get_param)(struct wsdisplay_param *);
> > @@ -345,7 +346,9 @@ thinkpad_enable_events(struct acpithinkp
> > }
> >
> > /* Enable events we need to know about */
> > - mask |= (THINKPAD_MASK_BRIGHTNESS_UP | THINKPAD_MASK_BRIGHTNESS_DOWN |
> > + mask |= (THINKPAD_MASK_MIC_MUTE |
> > + THINKPAD_MASK_BRIGHTNESS_UP |
> > + THINKPAD_MASK_BRIGHTNESS_DOWN |
> > THINKPAD_MASK_KBD_BACKLIGHT);
> >
> > DPRINTF(("%s: setting event mask to 0x%llx\n", DEVNAME(sc), mask));
> > @@ -555,8 +558,7 @@ thinkpad_brightness_up(struct acpithinkp
> > {
> > int b;
> >
> > - if (sc->sc_hkey_version == THINKPAD_HKEY_VERSION2) {
> > - thinkpad_get_brightness(sc);
> > + if (thinkpad_get_brightness(sc) == 0) {
> > b = sc->sc_brightness & 0xff;
> > if (b < ((sc->sc_brightness >> 8) & 0xff)) {
> > sc->sc_brightness = b + 1;
> > @@ -573,8 +575,7 @@ thinkpad_brightness_down(struct acpithin
> > {
> > int b;
> >
> > - if (sc->sc_hkey_version == THINKPAD_HKEY_VERSION2) {
> > - thinkpad_get_brightness(sc);
> > + if (thinkpad_get_brightness(sc) == 0) {
> > b = sc->sc_brightness & 0xff;
> > if (b > 0) {
> > sc->sc_brightness = b - 1;
> > @@ -701,30 +702,39 @@ thinkpad_set_kbd_backlight(struct wskbd_
> > return 0;
> > }
> >
> > -void
> > +int
> > thinkpad_get_brightness(struct acpithinkpad_softc *sc)
> > {
> > - aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> > - "PBLG", 0, NULL, >sc_brightness);
> > + int ret;
> > +
> > + ret = aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "PBLG", 0, NULL,
> > + >sc_brightness);
> >
> > DPRINTF(("%s: %s: 0x%llx\n", DEVNAME(sc), __func__,
> > sc->sc_brightness));
> > +
> > + return ret;
> > }
> >
> > -void
> > +int
> > thinkpad_set_brightness(void *arg0, int arg1)
> > {
> > struct acpithinkpad_softc *sc = arg0;
> > struct aml_value arg;
> > + int ret;
> >
> > DPRINTF(("%s: %s: 0x%llx\n", DEVNAME(sc), __func__,
> > sc->sc_brightness));
> >
> > memset(, 0, sizeof(arg));
> > arg.type = AML_OBJTYPE_INTEGER;
> > arg.v_integer = sc->sc_brightness & 0xff;
> > - aml_evalname(sc->sc_acpi, sc->sc_devnode,
> > - "PBLS", 1, , NULL);
> > + ret = aml_evalname(sc->sc_acpi, sc->sc_devnode, "PBLS", 1, ,
> > NULL);
> > +
> > + if (ret)
> > + return ret;
> >
> > thinkpad_get_brightness(sc);
> > +
> > +
Re: httpd.conf(5) man page
That explains by it is not documented and the somewhat awkward syntax. Will take care with future use cases. Thanks for the info! El sáb., 2 feb. 2019 a las 12:52, Hiltjo Posthuma () escribió: > > On Sat, Feb 02, 2019 at 12:20:03PM +0100, Daniel Gracia wrote: > > Hi there! > > > > httpdd FastCGI interface can connect seamlessly to a local TCP port, > > but this is not documented on the man page. > > > > Went to the source and found the syntax to be a little awkward (maybe > > a quick fix?). Anyway, allowed me running flask/flup/bottle pretty > > straightforward. > > > > Regards! > > > > Index: usr.sbin/httpd/httpd.conf.5 > > === > > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v > > retrieving revision 1.101 > > diff -u -p -u -p -r1.101 httpd.conf.5 > > --- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101 > > +++ usr.sbin/httpd/httpd.conf.5 2 Feb 2019 11:03:48 - > > @@ -278,12 +278,16 @@ will neither display nor generate a dire > > Enable FastCGI instead of serving files. > > The > > .Ar socket > > -is a local path name within the > > +can be a local path name within the > > .Xr chroot 2 > > root directory of > > .Xr httpd 8 > > -and defaults to > > -.Pa /run/slowcgi.sock . > > +(defaults to > > +.Pa /run/slowcgi.sock > > +). Starting with colon, > > +.Ar socket > > +can specify a port number that will connect to INADDR_LOOPBACK > > +address. > > .Pp > > The FastCGI handler will be given the following variables: > > .Pp > > > > Hi, > > Cool, I did not know httpd could do this. The commit (git mirror) says: > > " > commit 2204991274ff67f80cfd592f8470cdaca7a906e9 > Author: reyk > Date: Sat Aug 2 11:52:00 2014 + > > Allow to specify a FastCGI TCP socket on localhost (eg. :9000). Used > for debugging, you should prefer local UNIX sockets, but it helped to > find an issue that will be fixed with the next commit. > " > > CVS server_fci.c rev 1.9: > http://cvsweb.openbsd.org/src/usr.sbin/httpd/server_fcgi.c?rev=1.9=text/x-cvsweb-markup > > So maybe it was a debugging feature. > > -- > Kind regards, > Hiltjo
httpd.conf(5) man page
Hi there! httpdd FastCGI interface can connect seamlessly to a local TCP port, but this is not documented on the man page. Went to the source and found the syntax to be a little awkward (maybe a quick fix?). Anyway, allowed me running flask/flup/bottle pretty straightforward. Regards! Index: usr.sbin/httpd/httpd.conf.5 === RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v retrieving revision 1.101 diff -u -p -u -p -r1.101 httpd.conf.5 --- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101 +++ usr.sbin/httpd/httpd.conf.5 2 Feb 2019 11:03:48 - @@ -278,12 +278,16 @@ will neither display nor generate a dire Enable FastCGI instead of serving files. The .Ar socket -is a local path name within the +can be a local path name within the .Xr chroot 2 root directory of .Xr httpd 8 -and defaults to -.Pa /run/slowcgi.sock . +(defaults to +.Pa /run/slowcgi.sock +). Starting with colon, +.Ar socket +can specify a port number that will connect to INADDR_LOOPBACK +address. .Pp The FastCGI handler will be given the following variables: .Pp
Re: bpe(4): 802.1Q Provider Backbone Bridge edge
Loving it! A nit: s/Etherent/Ethernet El mié., 19 dic. 2018 a las 5:25, David Gwynne () escribió: > > 802.1ah-2008 developed Provider Backbone Bridges, aka, mac-in-mac > support. This was adopted as part of 802.1Q-2011. > > It basically provides Ethernet over Ethernet overlay networking. Unlike > vlan and svlan, the entire ethernet packet is encapsulated in another. > The motivation for this is to avoid the need for intermediate switches > to learn all the "customer" mac addresses, they just need to know about > the PBB endpoints. > > However, like vlan it does have a concept of a vnetid, and has the > ability to store the packet priority. the vnetid is 24 bits and doesn't > appear to have any reserved values. > > Thoughts? > > Index: share/man/man4/Makefile > === > RCS file: /cvs/src/share/man/man4/Makefile,v > retrieving revision 1.697 > diff -u -p -r1.697 Makefile > --- share/man/man4/Makefile 23 Nov 2018 12:38:44 - 1.697 > +++ share/man/man4/Makefile 19 Dec 2018 04:16:07 - > @@ -15,7 +15,7 @@ MAN= aac.4 ac97.4 acphy.4 acrtc.4 \ > auacer.4 audio.4 aue.4 auglx.4 auich.4 auixp.4 autri.4 auvia.4 \ > axe.4 axen.4 axppmic.4 azalia.4 \ > bce.4 bcmaux.4 bcmdog.4 bcmrng.4 bcmtemp.4 berkwdt.4 bge.4 \ > - bgw.4 bio.4 bktr.4 bmtphy.4 bnx.4 bnxt.4 \ > + bgw.4 bio.4 bpe.4 bktr.4 bmtphy.4 bnx.4 bnxt.4 \ > boca.4 bpf.4 brgphy.4 bridge.4 brswphy.4 bwfm.4 bwi.4 bytgpio.4 \ > cac.4 cas.4 cardbus.4 carp.4 ccp.4 ccpmic.4 cd.4 cdce.4 cfxga.4 \ > ch.4 chvgpio.4 ciphy.4 ciss.4 clcs.4 clct.4 cmpci.4 \ > Index: share/man/man4/bpe.4 > === > RCS file: share/man/man4/bpe.4 > diff -N share/man/man4/bpe.4 > --- /dev/null 1 Jan 1970 00:00:00 - > +++ share/man/man4/bpe.419 Dec 2018 04:16:07 - > @@ -0,0 +1,159 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2018 David Gwynne > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate: November 16 2018 $ > +.Dt BPE 4 > +.Os > +.Sh NAME > +.Nm bpe > +.Nd Backbone Provider Edge pseudo-device > +.Sh SYNOPSIS > +.Cd "pseudo-device bpe" > +.Sh DESCRIPTION > +The > +.Nm bpe > +driver allows construction of IEEE 802.1Q Provider Backbone Bridge > +(PBB) networks by acting as a Backbone Edge Bridge (BEB). > +PBB, also known as mac-in-mac, was originally specified in > +IEEE 802.1ah-2008 and became part of IEEE 802.1Q-2011. > +.Pp > +A Provider Backbone Bridge Network (PBBN) consists of BEBs > +interconnected by Backbone Core Bridges (BCBs) to form an Ethernet > +network for the transport of encapsulated Ethernet packets. > +Where VLAN and SVLAN protocols add a shim to differentiate Ethernet > +packets for different networks but retain the Ethernet addresses > +of encapsulated traffic, PBB completely encapsulates Ethernet packets > +for transmission between BEBs on a PBBN. > +This removes the need for intermediate BCB devices on the backbone > +network to learn the Ethernet addresses of devices on the encapsulated > +network, but requires each BEB to maintain a mapping of addresses > +on the encapsulated network to peer BEBs. > +.Pp > +A PBB packet consists of another Ethernet frame containing Ethernet > +addresses for BEBs and the PBB Ethernet protocol type (0x88e7), a > +32-bit Backbone Service Instance Tag (I-TAG), followed by the > +encapsulated Ethernet frame. > +The I-TAG contains a 24-bit Backbone Service Instance Identifiier > +(I-SID) to differentiate different PBBNs on the same backbone network > +.Pp > +IEEE 802.1Q describes Customer VLANs being encapsulated by PBB, > +which in turn uses an S-VLAN service. > +This can be implemented with > +.Xr vlan 4 > +using a > +.Nm bpe > +interface as the parent, > +and with the > +.Nm bpe > +interface using > +.Xr svlan 4 > +as the parent. > +.Nm bpe > +itself does not require this topology, therefore allowing flexible > +deployment and network topologies. > +.Pp > +The > +Nm. bpe > +driver implements a learning bridge on each interface. > +The driver will learn the mapping of BEPs to encapsulated Ethernet > +address based on traffic received from other devices on the backbone > +network. >
Re: Add "Spleen 5x8" font to wsfont
Very nice indeed; this is a real alternative for our current devices with
2x16 serial LCDs.
Regards!
El jue., 20 sept. 2018 a las 21:45, Frederic Cambus ()
escribió:
> Hi tech@,
>
> Here is a diff to add "Spleen 5x8" to wsfont, a font targetted at small
> OLED displays to be used with devices handled by ssdfb(4). It contains
> all printable ASCII characters (96 glyphes).
>
> The font is 2-Clause BSD licensed and is my original creation.
>
> In order to enable and test the font, this option should be added to the
> kernel configuration file: option FONT_SPLEEN5x8
>
> Screenshot: https://www.cambus.net/files/openbsd/dmesg-spleen5x8.png
>
> Comments? OK?
>
> Index: sys/dev/wsfont/wsfont.c
> ===
> RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 wsfont.c
> --- sys/dev/wsfont/wsfont.c 8 Sep 2017 05:36:53 - 1.52
> +++ sys/dev/wsfont/wsfont.c 20 Sep 2018 18:52:29 -
> @@ -43,6 +43,11 @@
>
> #undef HAVE_FONT
>
> +#ifdef FONT_SPLEEN5x8
> +#define HAVE_FONT 1
> +#include
> +#endif
> +
> #ifdef FONT_BOLD8x16
> #define HAVE_FONT 1
> #include
> @@ -105,6 +110,9 @@ static struct font builtin_fonts[] = {
> #endif
> #ifdef FONT_GALLANT12x22
> BUILTIN_FONT(gallant12x22, 3),
> +#endif
> +#ifdef FONT_SPLEEN5x8
> + BUILTIN_FONT(spleen5x8, 4),
> #endif
> #undef BUILTIN_FONT
> };
> Index: sys/dev/wsfont/spleen5x8.h
> ===
> RCS file: sys/dev/wsfont/spleen5x8.h
> diff -N sys/dev/wsfont/spleen5x8.h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ sys/dev/wsfont/spleen5x8.h 20 Sep 2018 18:52:29 -
> @@ -0,0 +1,910 @@
> +/* $OpenBSD$ */
> +
> +/*
> + * Copyright (c) 2018 Frederic Cambus
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. 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.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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.
> + */
> +
> +static u_char spleen5x8_data[];
> +
> +struct wsdisplay_font spleen5x8 = {
> + "Spleen 5x8", /* typeface name */
> + 0, /* index */
> + ' ',/* firstchar */
> + 128 - ' ', /* numchars */
> + WSDISPLAY_FONTENC_ISO, /* encoding */
> + 5, /* width */
> + 8, /* height */
> + 1, /* stride */
> + WSDISPLAY_FONTORDER_L2R,/* bit order */
> + WSDISPLAY_FONTORDER_L2R,/* byte order */
> + NULL, /* cookie */
> + spleen5x8_data /* data */
> +};
> +
> +static u_char spleen5x8_data[] = {
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> +
> + 0x20, /* ..*. */
> + 0x20, /* ..*. */
> + 0x20, /* ..*. */
> + 0x20, /* ..*. */
> + 0x20, /* ..*. */
> + 0x00, /* */
> + 0x20, /* ..*. */
> + 0x00, /* */
> +
> + 0x50, /* .*.* */
> + 0x50, /* .*.* */
> + 0x50, /* .*.* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> + 0x00, /* */
> +
> + 0x00, /* */
> + 0x50, /* .*.* */
> + 0xf8, /* *... */
> + 0x50, /* .*.* */
> + 0x50, /* .*.* */
> +
Re: pcb sip hash keys
+ LIST_ENTRY(inpcb) inp_lhash;/* locol port hash */
Shouldn't this read 'local'?
Regards!
El jue., 13 sept. 2018 a las 23:12, Alexander Bluhm (<
alexander.bl...@gmx.net>) escribió:
> Hi,
>
> In general it is a bad idea to use one random secret for two things.
> The inet PCB uses one hash with local and foreign addresses, and
> one with local port numbers. Give both hashes separate keys. Also
> document the struct fields.
>
> ok?
>
> bluhm
>
> Index: netinet/in_pcb.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/in_pcb.c,v
> retrieving revision 1.244
> diff -u -p -r1.244 in_pcb.c
> --- netinet/in_pcb.c13 Sep 2018 19:53:58 - 1.244
> +++ netinet/in_pcb.c13 Sep 2018 20:53:22 -
> @@ -148,7 +148,7 @@ in_pcblhash(struct inpcbtable *table, in
> SIPHASH_CTX ctx;
> u_int32_t nrdom = htonl(rdom);
>
> - SipHash24_Init(, >inpt_key);
> + SipHash24_Init(, >inpt_lkey);
> SipHash24_Update(, , sizeof(nrdom));
> SipHash24_Update(, , sizeof(lport));
>
> @@ -171,6 +171,7 @@ in_pcbinit(struct inpcbtable *table, int
> table->inpt_count = 0;
> table->inpt_size = hashsize;
> arc4random_buf(>inpt_key, sizeof(table->inpt_key));
> + arc4random_buf(>inpt_lkey, sizeof(table->inpt_lkey));
> }
>
> /*
> @@ -999,6 +1000,7 @@ in_pcbresize(struct inpcbtable *table, i
> table->inpt_lmask = nlmask;
> table->inpt_size = hashsize;
> arc4random_buf(>inpt_key, sizeof(table->inpt_key));
> + arc4random_buf(>inpt_lkey, sizeof(table->inpt_lkey));
>
> TAILQ_FOREACH(inp, >inpt_queue, inp_queue) {
> in_pcbrehash(inp);
> Index: netinet/in_pcb.h
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/in_pcb.h,v
> retrieving revision 1.111
> diff -u -p -r1.111 in_pcb.h
> --- netinet/in_pcb.h13 Sep 2018 19:53:58 - 1.111
> +++ netinet/in_pcb.h13 Sep 2018 21:09:33 -
> @@ -90,10 +90,10 @@ union inpaddru {
> * control block.
> */
> struct inpcb {
> - LIST_ENTRY(inpcb) inp_hash;
> - LIST_ENTRY(inpcb) inp_lhash;/* extra hash for lport */
> - TAILQ_ENTRY(inpcb) inp_queue;
> - structinpcbtable *inp_table;
> + LIST_ENTRY(inpcb) inp_hash; /* local and foreign hash
> */
> + LIST_ENTRY(inpcb) inp_lhash;/* locol port hash */
> + TAILQ_ENTRY(inpcb) inp_queue; /* inet PCB queue */
> + structinpcbtable *inp_table;/* inet queue/hash table */
> union inpaddru inp_faddru; /* Foreign address. */
> union inpaddru inp_laddru; /* Local address. */
> #defineinp_faddr inp_faddru.iau_a4u.inaddr
> @@ -149,11 +149,12 @@ struct inpcb {
> LIST_HEAD(inpcbhead, inpcb);
>
> struct inpcbtable {
> - TAILQ_HEAD(inpthead, inpcb) inpt_queue;
> - struct inpcbhead *inpt_hashtbl, *inpt_lhashtbl;
> - SIPHASH_KEY inpt_key;
> - u_longinpt_mask, inpt_lmask;
> - int inpt_count, inpt_size;
> + TAILQ_HEAD(inpthead, inpcb) inpt_queue; /* inet PCB queue */
> + struct inpcbhead *inpt_hashtbl;/* local and foreign hash
> */
> + struct inpcbhead *inpt_lhashtbl; /* local port hash */
> + SIPHASH_KEY inpt_key, inpt_lkey;/* secrets for hashes */
> + u_long inpt_mask, inpt_lmask; /* hash masks */
> + int inpt_count, inpt_size; /* queue count, hash size
> */
> };
>
> /* flags in inp_flags: */
>
>
Re: [BUG] pfctl(8) silently accept directories as config files
Maybe we can also hardcode the alias rm='rm -i', just in case. Your intentions are nice, but that are too much lines for a naive test that a serious 'root' would have hit with a simple -and mandatory- 'pfctl -s rules'. El 02/01/2012 18:59, Stephane A. Sezer escribis: On Mon, 2 Jan 2012 15:28:48 -0200 Christiano F. Haesbaerthaesba...@haesbaert.org wrote: On 2 January 2012 06:58, Henning Brauerlists-openbsdt...@bsws.de wrote: what next? having pfctl whine about an empty config file? * Stephane A. Sezers...@cd80.net [2012-01-02 09:36]: Hi, I found a strange behavior in pfctl(8) which looks like a bug. When given a directory as input (either with the `-f` flag, or with the `include` directive in a config file), pfctl(8) does not emit any warning and silently accepts the given input. I suppose this is not the intended behavior so here is a patch that fixes the issue. Even if it is the case, testing against directory doesn't seem like the right thing, the test should be done against a regular file, what if you pass a block device ? another check ? I thought it would be valid (for some obscure use cases) to give pfctl(8) a named pipe, or an unix socket as input. Giving a block device or a char device already triggers a warning in most cases but yeah, it makes sense to check them explicitly too. You're only dealing with a very special case here, anyway, I agree with Henning, it seems too much. Lots of config files formats accept the syntax include /some/directory telling the program to include every single file in `/some/directory`. pfctl(8) doesn't. And doesn't even warn about that. Personally, I came across this behavior with a failed tab-completion on `pfctl -f /etc`.
