Re: Folks thanks to all who attended P2k23 Hackathon in Dublin
Folks, thanks to all who submitted undeadly reports on p2k23 hackathon to undeadly, if anyone else would like to send a rough list of cool stuff they were working on to me Ill submit an update to undeadly also, I appreciate all the time you folks put into the hackathon and Hope you enjoyed it as much as I enjoyed hosting you good folks, all the best, Tom Smyth On Fri, 8 Sept 2023 at 18:20, Tom Smyth wrote: > > Folks > thanks to all who attended P2k23 Hackathon in Dublin > > if any of you would like to email me off list what you managed to > achieve/ or increse understanding of or any interesting ideas > collaborations that happened during the week > > please feel free to email me them and Ill include them in an undeadly > hackathon report.. > > It was a real pleasure to host you all and learn from the hackathon > hallway track :) > > Thanks > Tom Smyth > > -- > Kindest regards, > Tom Smyth. -- Kindest regards, Tom Smyth.
Folks thanks to all who attended P2k23 Hackathon in Dublin
Folks thanks to all who attended P2k23 Hackathon in Dublin if any of you would like to email me off list what you managed to achieve/ or increse understanding of or any interesting ideas collaborations that happened during the week please feel free to email me them and Ill include them in an undeadly hackathon report.. It was a real pleasure to host you all and learn from the hackathon hallway track :) Thanks Tom Smyth -- Kindest regards, Tom Smyth.
Re: 443 udp for /etc/services
... If IANA say it (and Stuart says it) ... then .. Im not going to contradict :) (or at least persist in contradicting Stuart :) Thanks for the clarificaiton... On Thu, 25 May 2023 at 10:38, Stuart Henderson wrote: > > On 2023/05/25 10:29, Tom Smyth wrote: > > Folks, > > > > Can I suggest calling it quic as opposed to https > > I think it should follow the name in the IANA registry which uses https. > > > do we want PF Firewal to match https for TCP and UDP (for traditional) > > servers that only require https TCP ... > > PF requires that the protocol is specified, it doesn't assume TCP or UDP > based on the /etc/services entry. > -- Kindest regards, Tom Smyth.
Re: 443 udp for /etc/services
Folks, Can I suggest calling it quic as opposed to https do we want PF Firewal to match https for TCP and UDP (for traditional) servers that only require https TCP ... Just a thought On Thu, 25 May 2023 at 10:27, Stuart Henderson wrote: > > - Forwarded message from Renaud Allard - > > From: Renaud Allard > Date: Thu, 25 May 2023 10:48:24 +0200 > To: po...@openbsd.org > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 > Thunderbird/102.9.0 > Subject: Re: http3 in nginx > > > > On 5/24/23 18:01, Theo Buehler wrote: > > This isn't intended for commit, but if anyone wants to play with quic > > in nginx, this diff is all that's needed. Build, then install the main > > package. The config is documented here: > > > > https://nginx.org/en/docs/http/ngx_http_v3_module.html > > > > Works for me. > > > > It might be a good idea to add this to /etc/services too > > https 443udphttp protocol over TLS/SSL > > - - > > while I would not use quite that description (it comes from the > IANA registry, but afaik there is no way this is going to work over > anything old enough to be called SSL), I think it is correct to add > this, we do want it populated in net.inet.udp.baddynamic. > > https://www.rfc-editor.org/rfc/rfc9110.html > > ok? > > > Index: services > === > RCS file: /cvs/src/etc/services,v > retrieving revision 1.104 > diff -u -p -r1.104 services > --- services2 Mar 2022 11:43:52 - 1.104 > +++ services25 May 2023 09:14:49 - > @@ -118,6 +118,7 @@ svrloc 427/tcp # > Server Location > svrloc 427/udp > nnsp 433/tcp usenet # Network News Transfer > https 443/tcp # secure http (TLS) > +https 443/udp # secure http (TLS) > snpp 444/tcp # Simple Network Paging > Protocol > microsoft-ds 445/tcp # Microsoft-DS > microsoft-ds 445/udp # Microsoft-DS > -- Kindest regards, Tom Smyth.
Re: Questions about the code review process in OpenBSD
IIO7 It would be best that you Check out the commit logs and look at marc.info (archives of mailing lists) ...( at the historical discussions on features / issues of interest to you .. ) it would be better that you do that rather than diverting developers resources from what they do best... you can view old talks from various developers on youtube (EuroBSD Con) BSDCAN and AsiaBSDCon attend BSD conferences and listen to the talks and arguments On Sun, 6 Nov 2022 at 20:36, wrote: > Nov 6, 2022, 20:16 by dera...@openbsd.org: > > > Mr iio7, > > > > Your persistant questions as to our processes are pointless. > > > > You are asking these questions in this way to interfere. > > > > That is a dickhead move. > > > > Everyone can see it. > > > Well, then everyone needs glasses because I am NOT asking to > interfere, I am asking in order to understand. > > I am the sysadmin at our company responsible for the OpenBSD > based projects. When I read about the problems at FreeBSD, after > which I wrote to their list, I was sure that the process was different > in OpenBSD, to which several users on FreeBSD replied, that > OpenBSD doesn't do code review on each commit, yada yada. > > I wanted to make sure that I did carry any misinformation. > > I am sorry if my level of understanding and asking questions doesn't > meet your requirements to be taken serious such that you feel they > deserve to be called dickhead moves. > > -- Kindest regards, Tom Smyth.
Re: missing warning in wireguard manual page
For what It is worth I think the proposed ammendment makes sense. On Mon, 25 Jul 2022 at 17:23, Theo de Raadt wrote: > I've been watching conversation on a mailing list, and it leads me to > wonder if we should inform the userbase better. > > > Index: wg.4 > === > RCS file: /cvs/src/share/man/man4/wg.4,v > retrieving revision 1.10 > diff -u -r1.10 wg.4 > --- wg.414 Mar 2021 10:08:38 - 1.10 > +++ wg.425 Jul 2022 16:18:24 - > @@ -213,6 +213,12 @@ > .Nm > driver first appeared in > .Ox 6.8 . > +.Sh CAVEATS > +WireGuard uses uncertified cryptographic algorithms and uncertified random > +number generators, so the security properties cannot be gauranteed. > +Consider using > +.Xr ipsec 4 > +instead, where certified cryptographic algorithms are the norm. > .Sh AUTHORS > .An -nosplit > The > > -- Kindest regards, Tom Smyth.
Re: allow 240/4 in various network daemons
82,7 @@ inet_valid_subnet(u_int32_t nsubnet, u_i
> (subnet & 0xff00) == 0x7f00 ||
> (subnet & 0xff00) == 0x) return (FALSE);
> }
> -else if (IN_CLASSD(subnet) || IN_BADCLASS(subnet)) {
> +else if (IN_CLASSD(subnet)) {
> /* Above Class C address space */
> return (FALSE);
> }
> Index: usr.sbin/ospfd/kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
> retrieving revision 1.114
> diff -u -p -r1.114 kroute.c
> --- usr.sbin/ospfd/kroute.c 20 Aug 2020 03:09:28 - 1.114
> +++ usr.sbin/ospfd/kroute.c 5 May 2022 08:54:30 -
> @@ -565,12 +565,11 @@ kr_redist_eval(struct kroute *kr, struct
> goto dont_redistribute;
>
> /*
> -* We consider the loopback net, multicast and experimental addresses
> +* We consider the loopback net and multicast addresses
> * as not redistributable.
> */
> a = ntohl(kr->prefix.s_addr);
> - if (IN_MULTICAST(a) || IN_BADCLASS(a) ||
> - (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
> + if (IN_MULTICAST(a) || (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
> goto dont_redistribute;
> /*
> * Consider networks with nexthop loopback as not redistributable
> Index: usr.sbin/pppd/auth.c
> ===
> RCS file: /cvs/src/usr.sbin/pppd/auth.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 auth.c
> --- usr.sbin/pppd/auth.c17 Nov 2017 20:48:30 - 1.39
> +++ usr.sbin/pppd/auth.c5 May 2022 09:01:51 -
> @@ -1120,7 +1120,7 @@ bad_ip_adrs(addr)
> {
> addr = ntohl(addr);
> return (addr >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET
> - || IN_MULTICAST(addr) || IN_BADCLASS(addr);
> + || IN_MULTICAST(addr);
> }
>
> /*
> Index: usr.sbin/ripd/kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/ripd/kroute.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 kroute.c
> --- usr.sbin/ripd/kroute.c 11 Dec 2019 21:04:59 - 1.34
> +++ usr.sbin/ripd/kroute.c 5 May 2022 08:54:46 -
> @@ -357,12 +357,11 @@ dont_redistribute:
> return;
>
> /*
> -* We consider the loopback net, multicast and experimental addresses
> +* We consider the loopback net and multicast addresses
> * as not redistributable.
> */
> a = ntohl(kr->prefix.s_addr);
> - if (IN_MULTICAST(a) || IN_BADCLASS(a) ||
> - (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
> + if (IN_MULTICAST(a) || (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
> return;
> /*
> * Consider networks with nexthop loopback as not redistributable
>
--
Kindest regards,
Tom Smyth.
Re: [patch] traceroute timeouts
hi Stuart , all, Thanks for that idea i had not thought of shell aliases in that case... that would work just fine for my use case / preference .. cheers... On Fri 20 Aug 2021, 17:43 Stuart Henderson, wrote: > Shell aliases are good for that. > > I think I'd be happy with 3 seconds by default. 2 feels a bit short on > overloaded links, GPRS, and some round-the-world packet trips > > -- > Sent from a phone, apologies for poor formatting. > > > On 20 August 2021 16:30:24 Tom Smyth wrote: > > Hello all,, >> would it make sense >> to have the value as a sysctl option or an environment variable ? >> so that it can be tailored for users /admins needs, >> >> >> >> On Fri 20 Aug 2021, 12:22 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.811 Feb 2020 18:41:39 >>>>> >>>> - 1.69 >>> >>>> +++ usr.sbin/traceroute/traceroute.820 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.c12 Jul 2021 15:09:21 >>>>> >>>> - 1.164 >>> >>>> +++ usr.sbin/traceroute/traceroute.c20 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, >>>>> >>>> &errstr); >>> >>>> + conf->waittime = strtonum(optarg, 1, INT_MAX, >>>>> >>>> &errstr); >>> >>>> 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. >>>> >>>> >>>> >>> >>> >
Re: [patch] traceroute timeouts
Hello all,, would it make sense to have the value as a sysctl option or an environment variable ? so that it can be tailored for users /admins needs, On Fri 20 Aug 2021, 12:22 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.811 Feb 2020 18:41:39 > - 1.69 > > > +++ usr.sbin/traceroute/traceroute.820 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.c12 Jul 2021 15:09:21 > - 1.164 > > > +++ usr.sbin/traceroute/traceroute.c20 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, > &errstr); > > > + conf->waittime = strtonum(optarg, 1, INT_MAX, > &errstr); > > > 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. > > > > > >
Re: Thunderbolt(/USB4) followup & I'm happy to donate some hardware Re: Feature request: Use the PCIe devices on Thunderbolt (aka PCIe hotplug?)
Hi Joseph,All There are some PCI-E attack surfaces that might need to be considered... perhaps the availability of more devices with thunderbolt connections make PCI-E / DMA Attacks more viable and hence more prevalent. https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-934.pdf I did come across intel SGX when configuring the bios / firmware on my lenovo laptop which mentioned Thunderbolt / PCI-E attacks. But mitigating this risk could yield security benefits for people who use PCI-E pass through / SR-IOV in Virtualized environments. I hope this helps, Tom Smyth On Mon, 26 Oct 2020 at 12:06, Joseph Mayer wrote: > > (If this one belongs on misc@ please say.) > > Hi tech@, > > If anyone is interested in implementing Thunderbolt support for > OpenBSD, I'd like to donate some PCIe expansion Thunderbolt 3 enclosure > and M.2 NVMe SSD Thunderbolt 3 enclosure as appropriate, if so please > let me know. > > BSDCan 2020 presentation by Scott Long of FreeBSD Thunderbolt support > here: https://youtu.be/VbAJf2PBE-M?t=802 > (https://www.bsdcan.org/events/bsdcan_2020/schedule/session/27-thunderbolt-on-freebsd/). > He mentions there that the sources are in > "rc/sys/dev/thunderbolt" but they appear to not have been merged yet. > > Thunderbolt in essence is a hotplugged PCIv3 x4 interface, useful when > a machine especially a laptop lacks other ways to plug in SSD, NIC, > AMDGPU. Not sure how clean the licensing situation is and how bloated > it is. (Note USB4 and Thunderbolt 4 are Thunderbolt 3 but with PCIe > data increased from 22gbps to 32gbps.) > > Apparently Thunderbolt is incorporated in the USB4 spec and this way > will be more ubiquitous and come to more architectures, ref. > https://www.phoronix.com/scan.php?page=news_item&px=Arm-Thunderbolt-Works , > https://lwn.net/Articles/802961/ . > > Within Linux there's seemingly unending amounts of patches and more: > https://github.com/torvalds/linux/tree/master/drivers/thunderbolt , > Intel devs unhelpful https://lore.kernel.org/patchwork/patch/983864/ , > https://lwn.net/Search/DoSearch?words=thunderbolt , search "thunderbolt > site:lkml.iu.edu/hypermail/linux/kernel/". > > Joseph > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, 24 March 2020 01:45, John-Mark Gurney wrote: > > > Joseph Mayer wrote this message on Sat, Mar 21, 2020 at 02:57 +: > > > > > Thunderbolt support would be awesome. Especially it would allow the use > > > of additional M.2 NVMe SSD:s on a laptop at full performance. > > > Thunderbolt support would also allow the use of an AMDGPU via a PCIe > > > chassi, as well as enable the use of 10gbps Ethernet on laptops [1]. > > > While I like to use Thunderbolt for this pragmatic reason, also Intel > > > apparently promises license etc. generosity to computer makers, which > > > certainly does not hurt. [2] > > > FreeBSD has Thunderbolt support. It appears to me that they call it > > > "PCIe Hot plug". [3] > > > > From my understanding, Thunderbolt is different from PCIe Hot Plug... > > > > PCIe the spec itself has hot plug capabilities, and this is what is > > used for laptops w/ ExpressCards and some servers... > > > > Thunderbolt from my understanding is more complicated due to > > display routing and other related features and FreeBSD does NOT > > yet have support for it. > > > > > It was implemented 2015 by John-Mark Gurney j...@freebsd.org. > > > > John Baldwin,j...@freebsd.org ended up implementing it differently > > and not using the code I had written, so he is probably a better > > person to ask on the current state of the code.. > > > > This was done via: > > https://reviews.freebsd.org/D6136?id=15683 > > > > I have heard that there may be a proper ThunderBolt support coming > > to FreeBSD in the near future, but not sure exactly when... > > > > > Not sure if a TB device must be attached on boot and cannot be > > > detached, anyhow if that is the case then still totally fine. > > > > The devctl command can detach a device. This allows ejecting > > devices w/o crashing the system for removal, or allowing you to detach > > a device and pass it through to a bhyve vm, etc. Not all drivers are > > written to allow detaching... > > > > > NetBSD appears to have support also but I don't find details. > > > Security-wise Thunderbolt without IOMMU is correlated with physical > > > break-in attack vectors, anyhow that is commonly fine. [4] > > > > From my understanding, all PCIe switches have a built in IOMMU, so > > this shouldn't be a major se
Re: silicom X710 ixl, unable to query phy types, no sff
pci1 dev 28 function 1 "Intel 8 Series PCIE" rev 0xd5: msi > pci9 at ppb7 bus 8 > em1 at pci9 dev 0 function 0 "Intel I210" rev 0x03: msi, address > ac:1f:6b:6a:88:65 > ppb8 at pci1 dev 28 function 3 "Intel 8 Series PCIE" rev 0xd5: msi > pci10 at ppb8 bus 9 > ppb9 at pci10 dev 0 function 0 "ASPEED Technology AST1150 PCI" rev 0x03 > pci11 at ppb9 bus 10 > vga1 at pci11 dev 0 function 0 "ASPEED Technology AST2000" rev 0x30 > wsdisplay at vga1 not configured > ppb10 at pci1 dev 28 function 4 "Intel 8 Series PCIE" rev 0xd5: msi > pci12 at ppb10 bus 11 > em2 at pci12 dev 0 function 0 "Intel I350" rev 0x01: msi, address > ac:1f:6b:6a:88:66 > em3 at pci12 dev 0 function 1 "Intel I350" rev 0x01: msi, address > ac:1f:6b:6a:88:67 > em4 at pci12 dev 0 function 2 "Intel I350" rev 0x01: msi, address > ac:1f:6b:6a:88:68 > em5 at pci12 dev 0 function 3 "Intel I350" rev 0x01: msi, address > ac:1f:6b:6a:88:69 > ehci1 at pci1 dev 29 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int > 18 > usb2 at ehci1: USB revision 2.0 > uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev > 2.00/1.00 addr 1 > pcib0 at pci1 dev 31 function 0 "Intel C224 LPC" rev 0x05 > ahci0 at pci1 dev 31 function 2 "Intel 8 Series AHCI" rev 0x05: msi, AHCI > 1.3 > ahci0: port 4: 6.0Gb/s > scsibus1 at ahci0: 32 targets > sd0 at scsibus1 targ 4 lun 0: > naa.50023031011e8059 > sd0: 122104MB, 512 bytes/sector, 250069680 sectors, thin > ichiic0 at pci1 dev 31 function 3 "Intel 8 Series SMBus" rev 0x05: apic 8 > int 18 > iic0 at ichiic0 > "Intel 8 Series Thermal" rev 0x05 at pci1 dev 31 function 6 not configured > isa0 at pcib0 > isadma0 at isa0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com0: console > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > vmm0 at mainbus0: VMX/EPT > uhub3 at uhub0 port 3 configuration 1 interface 0 "Genesys Logic USB2.0 > Hub" rev 2.00/32.98 addr 2 > uhub4 at uhub3 port 2 configuration 1 interface 0 "Genesys Logic USB2.0 > Hub" rev 2.00/32.98 addr 3 > uhub5 at uhub0 port 4 configuration 1 interface 0 "ATEN International > product 0x7000" rev 2.00/0.00 addr 4 > uhidev0 at uhub5 port 1 configuration 1 interface 0 "ATEN International > product 0x2419" rev 1.10/1.00 addr 5 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd0 at ukbd0 mux 1 > uhidev1 at uhub5 port 1 configuration 1 interface 1 "ATEN International > product 0x2419" rev 1.10/1.00 addr 5 > uhidev1: iclass 3/1 > ums0 at uhidev1: 3 buttons, Z dir > wsmouse0 at ums0 mux 0 > uhub6 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching > Hub" rev 2.00/0.05 addr 2 > uhub7 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching > Hub" rev 2.00/0.05 addr 2 > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > root on sd0a (ece891224464e50c.a) swap on sd0b dump on sd0b > > -- Kindest regards, Tom Smyth.
Re: Donation of Power PC Based boards RB800 I have 5x if they are any use for training / testing
Hello Devs, Thanks again for all your work on OpenBSD 6.7 just checking if any of you would need / want RB800s, as per mail below, I also have 2x RB600s which at one stage did run OpenBSD PPC edition if any dev want them contact me off list and Ill have them shipped to you Thanks and stay safe people ... 1 person non dev expressed an interest in them but I would like to give preference to those who work on hardware dev testing in OpenBSD ... if the boards were in fact useful Thanks Tom Smyth On Tue, 12 May 2020 at 21:12, Tom Smyth wrote: > > Hello > does any OpenBSD Developer want some Power PC SBC the specs > > > Product code RB800 > CPU MPC8533EVTALF > CPU core count 1 > CPU nominal frequency800 MHz > RAM 256MB > onboard NAND storage 512MB > > there are 4x Mini PCI slots > and 1x PCI-E > and 1 Compact Flash slots > 3x 1Gb/s Ports > > > they have a wide input voltage range for powering and can be powered via POE > > I have atleast 5x in stock and will ship them to any interested Developer ? > > https://mikrotik.com/product/RB800#fndtn-specifications > > -- > Kindest regards, > Tom Smyth. -- Kindest regards, Tom Smyth.
Donation of Power PC Based boards RB800 I have 5x if they are any use for training / testing
Hello does any OpenBSD Developer want some Power PC SBC the specs Product code RB800 CPU MPC8533EVTALF CPU core count 1 CPU nominal frequency800 MHz RAM 256MB onboard NAND storage 512MB there are 4x Mini PCI slots and 1x PCI-E and 1 Compact Flash slots 3x 1Gb/s Ports they have a wide input voltage range for powering and can be powered via POE I have atleast 5x in stock and will ship them to any interested Developer ? https://mikrotik.com/product/RB800#fndtn-specifications -- Kindest regards, Tom Smyth.
Re: ADMtec aue(4) interface supporting VLAN_MTU ?
Ok thanks for the info i always find mtu confusing as i thought generally it was referring to ip mtu. while layer2 headers vlans and layer 2.5 headers such as mpls labels cw etc...would be outside the ip mtu... Thanks again On Wednesday, 22 April 2020, Chris Cappuccio wrote: > Tom Smyth [tom.sm...@wirelessconnect.eu] wrote: > > Hi Chrisz, > > > > 4 bytes for the vlan header .. have you tried increasing the parent > > intetface mtu by 4bytes > > > > IFCAP_VLAN_MTU is a direct bypass for this. "hardmtu" on the parent > interface > is perhaps more interesting as it will limit everything including these > encapsulations > > -- Kindest regards, Tom Smyth.
Re: ADMtec aue(4) interface supporting VLAN_MTU ?
Hi Chrisz, 4 bytes for the vlan header .. have you tried increasing the parent intetface mtu by 4bytes So for vlan of 1500 mtu set parent interface mtu to 1504 bytes If you are doing q in q vlan nesting Then the parent interface should be 1500bytes +4× number of levels of nesting eg 1 vlan nested inside another vlan (2 levels ov vlans 1500+(4×2) for parent physical interface The first ( outer vlan should be 1500+4 bytes mtu) Innerclan can be 1500 mtu Hope this helps On Tuesday, 21 April 2020, Christopher Zimmermann wrote: > On Sun, Jul 07, 2019 at 01:26:55PM -0700, Chris Cappuccio wrote: > >> Christopher Zimmermann [chr...@openbsd.org] wrote: >> >>> This works: >>> >>> doas ifconfig vlan67 mtu 1496 >>> >>> this doesn't: >>> >>> doas ifconfig vlan67 mtu 1497 >>> >>> >>> Should we therefore disable VLAN_MTU on this chipset? >>> >>> - ifp->if_capabilities = IFCAP_VLAN_MTU; >>> - >>> >> >> >> Yes absolutely. If IFCAP_VLAN_MTU actually worked for some chip versions, >> more work is needed to distinguish the working chipsets. >> > > Hi, > > I'm looking for reponts of aue(4) chipsets actually supporting VLAN_MTU. > Mine does not. It identifies as: > > aue0 at uhub9 port 5 configuration 1 interface 0 "ADMtek USB To LAN > Converter" rev 2.00/1.01 addr 5 > aue0: address 00:05:1b:b2:96:02 > ukphy0 at aue0 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI > 0x000749, model 0x0001 > > In case there are none, I would like to drop above mentioned > IFCAP_VLAN_MTU flag for the aue(4) driver and look for OKs. > > > Christopher > > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1 > > -- Kindest regards, Tom Smyth.
Unix Hardware Givaway Sun Sparc Vax etc...
Hello All, Just to let you know that someone has posted on twitter in German that they are giving away aload of Unix Gear, some Sun Sparc stuff in there that may be of use to people who are supporting or trying to do builds it was re-tweeted by Philip Jocks, and it is in German, but you can make out specs It may be of help for maintaining / supporting the other platforms you run your code / develop your code on I hope this helps https://twitter.com/NikTheDusky/status/1219770675247886337 -- Kindest regards, Tom Smyth.
Re: bgpd reset idle hold values on neighbor clear
+1 from a lowly user :)
On Mon, 12 Aug 2019 at 15:43, Stuart Henderson wrote:
>
> On 2019/08/12 16:18, Claudio Jeker wrote:
> > I just changed the way IdleHold time is reset to the default values.
> > Another place I think it makes sense to reset these backoff values is
> > when an admin issues a bgpctl nei 192.0.2.2 clear or up.
> >
> > This should help bringing sessions up between systems after instabilities
> > (or in my case when testing too much and therefor reseting the session
> > over and over again).
> >
> > OK?
>
> Been there done that - yes please! OK.
>
> > --
> > :wq Claudio
> >
> > Index: control.c
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
> > retrieving revision 1.98
> > diff -u -p -r1.98 control.c
> > --- control.c 8 Aug 2019 20:06:29 - 1.98
> > +++ control.c 12 Aug 2019 14:11:12 -
> > @@ -376,6 +376,9 @@ control_dispatch_msg(struct pollfd *pfd,
> > bgp_fsm(p, EVNT_START);
> > p->conf.down = 0;
> > p->conf.shutcomm[0] = '\0';
> > + p->IdleHoldTime =
> > + INTERVAL_IDLE_HOLD_INITIAL;
> > + p->errcnt = 0;
> > control_result(c, CTL_RES_OK);
> > break;
> > case IMSG_CTL_NEIGHBOR_DOWN:
> > @@ -390,6 +393,9 @@ control_dispatch_msg(struct pollfd *pfd,
> > strlcpy(p->conf.shutcomm,
> > neighbor->shutcomm,
> > sizeof(neighbor->shutcomm));
> > + p->IdleHoldTime =
> > + INTERVAL_IDLE_HOLD_INITIAL;
> > + p->errcnt = 0;
> > if (!p->conf.down) {
> > session_stop(p,
> > ERR_CEASE_ADMIN_RESET);
> >
>
--
Kindest regards,
Tom Smyth.
amd64 Qemu Machine type and vmx(4) driver stability on QEMU Q35 machine vs QEMU i440fx machines
si0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (fb044f9fda06d052.a) swap on sd0b dump on sd0b vmx0: device timeout vmx0: device timeout vmx0: device timeout Domain /dev/pci0: 0:0:0: Intel 82G33 Host 0:1:0: Bochs VGA 0:26:0: Intel 82801I USB 0:26:1: Intel 82801I USB 0:26:2: Intel 82801I USB 0:26:7: Intel 82801I USB 0:27:0: Intel 82801I HD Audio 0:28:0: Red Hat unknown 0:28:1: Red Hat unknown 0:28:2: Red Hat unknown 0:28:3: Red Hat unknown 0:29:0: Intel 82801I USB 0:29:1: Intel 82801I USB 0:29:2: Intel 82801I USB 0:29:7: Intel 82801I USB 0:30:0: Intel 82801BA Hub-to-PCI 0:31:0: Intel 82801IB LPC 0:31:2: Intel 82801I AHCI 0:31:3: Intel 82801I SMBus 5:1:0: Red Hat Qemu PCI-PCI 5:2:0: Red Hat Qemu PCI-PCI 5:3:0: Red Hat Qemu PCI-PCI 5:4:0: Red Hat Qemu PCI-PCI 6:5:0: Qumranet Virtio SCSI 6:18:0: VMware VMXNET3 6:18:0: VMware VMXNET3 0x: Vendor ID: 15ad, Product ID: 07b0 0x0004: Command: 0107, Status: 0018 0x0008: Class: 02 Network, Subclass: 00 Ethernet, Interface: 00, Revision: 01 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0xfde43000/0x1000 0x0014: BAR mem 32bit addr: 0xfde44000/0x1000 0x0018: BAR mem 32bit addr: 0xfde4/0x2000 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 15ad Product ID: 07b0 0x0030: Expansion ROM Base Address: fde0 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x009c: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) Enabled: no; table size 25 (BAR 2:0) 0x0084: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: no -- Kindest regards, Tom Smyth.
amd64 Qemu Machine type and re(4) driver stability on QEMU Q35 machine vs QEMU i440fx machines
Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92 pci5 at ppb4 bus 5 ppb5 at pci5 dev 1 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci6 at ppb5 bus 6 virtio0 at pci6 dev 5 function 0 "Qumranet Virtio SCSI" rev 0x00 vioscsi0 at virtio0: qsize 128 scsibus1 at vioscsi0: 255 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 24576MB, 512 bytes/sector, 50331648 sectors, thin virtio0: msix shared re0 at pci6 dev 18 function 0 "Realtek 8139" rev 0x20: RTL8139C+ (0x7480), apic 0 int 10, address d2:03:bd:96:f0:8c rlphy0 at re0 phy 0: RTL internal PHY ppb6 at pci5 dev 2 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci7 at ppb6 bus 7 ppb7 at pci5 dev 3 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci8 at ppb7 bus 8 ppb8 at pci5 dev 4 function 0 "Red Hat Qemu PCI-PCI" rev 0x00 pci9 at ppb8 bus 9 pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0 ahci0: port 1: 1.5Gb/s scsibus2 at ahci0: 32 targets cd0 at scsibus2 targ 1 lun 0: ATAPI 5/cdrom removable ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int 10 iic0 at ichiic0 usb2 at uhci0: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (fb044f9fda06d052.a) swap on sd0b dump on sd0b re0: watchdog timeout re0: watchdog timeout Domain /dev/pci0: 0:0:0: Intel 82G33 Host 0:1:0: Bochs VGA 0:26:0: Intel 82801I USB 0:26:1: Intel 82801I USB 0:26:2: Intel 82801I USB 0:26:7: Intel 82801I USB 0:27:0: Intel 82801I HD Audio 0:28:0: Red Hat unknown 0:28:1: Red Hat unknown 0:28:2: Red Hat unknown 0:28:3: Red Hat unknown 0:29:0: Intel 82801I USB 0:29:1: Intel 82801I USB 0:29:2: Intel 82801I USB 0:29:7: Intel 82801I USB 0:30:0: Intel 82801BA Hub-to-PCI 0:31:0: Intel 82801IB LPC 0:31:2: Intel 82801I AHCI 0:31:3: Intel 82801I SMBus 5:1:0: Red Hat Qemu PCI-PCI 5:2:0: Red Hat Qemu PCI-PCI 5:3:0: Red Hat Qemu PCI-PCI 5:4:0: Red Hat Qemu PCI-PCI 6:5:0: Qumranet Virtio SCSI 6:18:0: Realtek 8139 6:18:0: Realtek 8139 0x: Vendor ID: 10ec, Product ID: 8139 0x0004: Command: 0107, Status: 0008 0x0008: Class: 02 Network, Subclass: 00 Ethernet, Interface: 00, Revision: 20 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR io addr: 0x4000/0x0100 0x0014: BAR mem 32bit addr: 0xfde41000/0x0100 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1af4 Product ID: 1100 0x0030: Expansion ROM Base Address: fde0 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 -- Kindest regards, Tom Smyth.
amd64 Qemu Machine type and em(4) driver stability on QEMU Q35 machine vs QEMU i440fx machines
I USB 0:27:0: Intel 82801I HD Audio 0:28:0: Red Hat unknown 0:28:1: Red Hat unknown 0:28:2: Red Hat unknown 0:28:3: Red Hat unknown 0:29:0: Intel 82801I USB 0:29:1: Intel 82801I USB 0:29:2: Intel 82801I USB 0:29:7: Intel 82801I USB 0:30:0: Intel 82801BA Hub-to-PCI 0:31:0: Intel 82801IB LPC 0:31:2: Intel 82801I AHCI 0:31:3: Intel 82801I SMBus 5:1:0: Red Hat Qemu PCI-PCI 5:2:0: Red Hat Qemu PCI-PCI 5:3:0: Red Hat Qemu PCI-PCI 5:4:0: Red Hat Qemu PCI-PCI 6:5:0: Qumranet Virtio SCSI 6:18:0: Intel 82540EM obsdcur20190802# pcidump -v 6:18:0 6:18:0: Intel 82540EM 0x: Vendor ID: 8086, Product ID: 100e 0x0004: Command: 0107, Status: 0x0008: Class: 02 Network, Subclass: 00 Ethernet, Interface: 00, Revision: 03 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 32bit addr: 0xfde4/0x0002 0x0014: BAR io addr: 0x4040/0x0040 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1af4 Product ID: 1100 0x0030: Expansion ROM Base Address: fde0 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 -- Kindest regards, Tom Smyth.
Re: Removing PF
Yeah... i would love you all to give affect to that... +1 from me claudioabout time!... Thanks for articulating what i have been thinking all this time... 1/4/2019 will be a historic turning point for us On Monday, 1 April 2019, Claudio Jeker wrote: > There have been internal discussions about OpenBSD also removing the pf > packet filter after the upcoming 6.5 release. Instead a switch to > using David Gwynne's new bpf filter will happen. > The benefits outweigh the drawbacks and the missing features will be > readily implemented in time for the 6.6 release. > > -- > :wq Claudio > > -- Kindest regards, Tom Smyth The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
63 bit certificate ID is libressl affected?
Hello all, Just saw the flllowing article and i was wondering if libressl Might be affected by the bug also Top bit being set to 0 always making an effective 63 bits rather than 64 bits https://www.theregister.co.uk/2019/03/13/tls_cert_revoke_ejbca_config/ Hope this helps Tom -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Idea forOpenBGPD RDE MP ... would this work to make RDE MP safe ?
Hello, before I begin... im just a sysadmin not a programmer I appreciate the work you are doing on OpenBGPd :) and I use it and im very happy I saw Claudes presentation on openBGPd recently and how there was some work on MP for BGPd.. and I was wondering about an idea (I thought it was a simple thing which may be too simple ... please bear in mind Im not a professional programmer, basically I was wondering could there be a simple way of removing risk of having an MP RDE, from my understanding, one of the concerns about RDE being MP is a withdraw being received on process running on a busy processor , and a subsequent announce being received by a process running on a lighty loaded processor .. the announce being processed first and then the withdraw being processed afterwards... (there by withdrawing the route even though the announce was received after the withdraw) there are probably others... To get around the concern above.. could the Ip space be carved up between different processes so it is always the same process dealing with all messages to do with an address space) lets say with 2 core and 4 core Box for example Could you split the RDE into 2 RDE processes which would only process half of the IP space ? so for ip v4 0.0.0.0/0 (route decision engine on a single core (current setup) on a 2 core system 0.0.0.0/1 would be managed by RDE0 128.0.0.0/1 would be managed by RDE1 on a 4 core system 0.0.0.0/2 RDE0 64.0.0.0/2RDE1 128.0.0.0/2 RDE2 192.0.0.0/2 RDE3 on an 8 core system 0.0.0.0/3 RDE0 32.0.0.0/3 RDE1 64.0.0.0/3 RDE2 96.0.0.0/3 RDE3 128.0.0.0/3RDE4 160.0.0.0/3 RDE5 192.0.0.0/3 RDE6 224.0.0.0/3 RDE7 you can use the spare cycles on this one to generate your favourite concurrency or help SETI :P or something :) so each process may not be equally loaded but they would be faster over all with the increased parallelism ... and because each RDE is operating on prefixes that are only in a certain range that doesn't overlap other RDE Process work ... there would never be a race condition or nasty MP introduced bugs also there would need to be some work on the session engine to pass theBGP messages to the correct RDE process easily (the decision process would be similar to a routing decision in the kernel LPM with 2 or 4 or 8 routes ) IPv6 I get would need a more nuanced approach as in split the subset 2000::/3 as opposed to 0:0/128 It would be a long time before I would be able to submit a patch worthy of consideration... but is this Idea worth pursuing ? is there a fundamental flaw in this idea / approach Thanks for your time and consideration... Tom Smyth
Re: 6.4 openBGPD Segfault caused by filters referencing undeclared prefix-set
Hello Stuart Thanks for the helpful advice on giving a better crash report i will do that going forward... On Sun 18 Nov 2018, 10:50 Stuart Henderson On 2018/11/18 08:58, Tom Smyth wrote: > > I have attached the coredump > > Generally the coredump by itself isn't that useful to others as it > needs the right binary to go with it, a backtrace is usually better: > > gdb /usr/sbin/bgpd /path/to/bgpd.core > bt > > For reference, in some cases multiple processes will crash, because > the filenames are all "bgpd.core" they can overwrite each other. > See the bottom of the sysctl manpage for a way around that. > >
Re: 6.4 openBGPD Segfault caused by filters referencing undeclared prefix-set
just to confim
im running 6.4 GENERIC.MP#364 amd64
On Sun, 18 Nov 2018 at 08:58, Tom Smyth wrote:
>
> Hello,
> I was configuring an openbsd 6.4 bgpd router using the
> /etc/examples/bgpd.conf as a template
>
> If you comment out the prefix-set mynetworks
> # list of networks that may be originated by our ASN
> #prefix-set mynetworks {\
> #192.0.2.0/24\
> #2001:db8:abcd::/48\
> #}
>
> and leave filters that depend on the prefix-set
> in the bgpd.conf file
>
> bgpd segfaults on startup as shown below
>
> corertfw2# bgpd -dv
> startup
> rereading config
> session engine ready
> ASN = "62129"
> peer closed imsg connection
> Segmentation fault (core dumped)
> SE: Lost connection to parent
> session engine exiting
> corertfw2# route decision engine ready
> peer closed imsg connection
> fatal in RDE: Lost connection to parent
>
>
> I have attached the coredump
>
> Removing filters that reference undeclared prefix-set mynetworks
> resolved the issue ...
>
> --
> Kindest regards,
> Tom Smyth
Re: 6.4 - RX not working on new supported BCM574xx (bnxt)
Does That card need specific firmware loaded? like the older bnx cards ? I dont see a reference to it in the bnxt man page... On Sat, 10 Nov 2018 at 05:10, David Gwynne wrote: > > > > > On 10 Nov 2018, at 12:22 pm, Jonathan Matthew wrote: > > > > On Fri, Nov 09, 2018 at 04:35:38AM -0700, Luthing wrote: > >> Hello there, > >> > >> I am facing an issue with a Broadcom NIC (specs here > >> https://www.broadcom.com/products/ethernet-connectivity/controllers/bcm57416/#specifications). > >> > >> After some troubleshooting, I am not able to resolve listen ARP request > >> from > >> my connected switch. > >> The NIC has negociated 10G with auto neg enabled on the switch. > >> > >> The switch is able to see mac address on the port where the BCM NIC is > >> connected to. The switch can see ARP request going though him from the NIC. > >> But, my OBSD cannot receive packets. > >> > >> I checked with a tcpdump -i bnxt0, and I see that I am sending ARP > >> requests, > >> but not receiving any response. > > > > Send the full dmesg from your machine, output of 'ifconfig bnxt', 'vmstat > > -zi' and > > probably some tcpdump output if anything shows up there. > > > > Have you tried both ports, or just bnxt0? > > > >> > >> A arp -a shows an incomplete mac address. > >> > >> > >> "dmesg | grep bn" output is : > >> bnxt0 at pci6 dev 0 function 0 "Broadcom BCM57416" rev 0x01: fw ver > >> 20.8.163, apic 10 int 2, address 01:23:45:67:89 > >> bnxt1 at pci6 dev 0 function 0 "Broadcom BCM57416" rev 0x01: fw ver > >> 20.8.163, apic 10 int 5, address 01:23:45:67:8a > >> bnxt0 at pci6 dev 0 function 0 "Broadcom BCM57416" rev 0x01: fw ver > >> 20.8.163, apic 10 int 2, address 01:23:45:67:89 > >> bnxt1 at pci6 dev 0 function 0 "Broadcom BCM57416" rev 0x01: fw ver > >> 20.8.163, apic 10 int 5, address 01:23:45:67:8a > > > > Are those the real mac addresses? They don't look real. > > the low bit of the first byte is especially concerning, as that bit indicates > the address is multicast. definitely looks like a placeholder value though, > esp as it used on all ports. > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: diff: Fix send(2) EACCES mistake
yeah I agree with Jason, grammar would dictate that if you want to form a sentance with "a" followed by word beginning a vowel or having a silent consonant between the a and the vowel then an n would be inserted after the a would be inserted to make the sentence easier to pronounce ... but host ... the consonant is not silent ... so adding the n doesnt make it easier to say infact it makes it difficult... it was a while since I learned that one .. so forgive any (minor) inaccuracies (and slam me if there is a major inaccuracy in what I said ) Peace out ... Tom On Sun, 28 Oct 2018 at 23:05, Jason McIntyre wrote: > > On Sun, Oct 28, 2018 at 09:40:33PM +0100, Jan Klemkow wrote: > > Hi, > > > > Unlike the manpage saids or one might think , sendto(2) sets errno to > > EHOSTUNREACH instead of EACCES in cases of blocking by pf(4) or not > > enabled broadcasts. Finally I ran into both cases and think, its time > > to fix this issue. The diff suggests a new explanation that should > > cover all error cases. > > > > Bye, > > Jan > > > > Index: /usr/src/lib/libc/sys/send.2 > > === > > RCS file: /cvs/src/lib/libc/sys/send.2,v > > retrieving revision 1.32 > > diff -u -p -r1.32 send.2 > > --- /usr/src/lib/libc/sys/send.2 5 Oct 2017 12:30:16 - 1.32 > > +++ /usr/src/lib/libc/sys/send.2 28 Oct 2018 20:16:20 - > > @@ -161,13 +161,13 @@ The operation may succeed when buffers b > > The output queue for a network interface was full. > > This generally indicates that the interface has stopped sending, > > but may be caused by transient congestion. > > -.It Bq Er EACCES > > -The > > -.Dv SO_BROADCAST > > -option is not set on the socket, and a broadcast address > > -was given as the destination. > > .It Bq Er EHOSTUNREACH > > -The destination address specified an unreachable host. > > +The destination address specified an host that is unreachable, > > unless you're going for humour, "a host" rather than "an host". > > i can;t comment on the accuracy, but the rest of the diff reads ok. > jmc > > > +blocked by > > +.Xr pf 4 > > +or is broadcast communication which was not enabled > > +via the socket option > > +.Dv SO_BROADCAST . > > .It Bq Er EINVAL > > The > > .Fa flags > > >
Re: bgplg: allow neighbors with space in name
Hello Denis, Stuart, all, I think what Stuart is saying regarding double quotes makes sense we try to avoid spaces where possible makes life easier ... Thanks Tom Smyth On Thu, 25 Oct 2018 at 14:06, Stuart Henderson wrote: > > On 2018/10/24 17:38, Denis Fondras wrote: > > I have peers with description containing spaces but bgplg won't accept that > > by > > default. > > > > I'd like some comments on that diff. > > It is OK for bgplgsh (show ip bgp in "Peer 1" feels OK) but not for bgplg > > as I > > have to quote the peer description in the input box (feels rather > > unnatural). > > it feels like allowing " in allowed characters for the CGI is starting > to open a can of worms.. > > personally I think I'd change the descriptions to avoid spaces. > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: 802.1q with 0 tag
Hello Rivo,
Im not sure what benefit if any this would be,
I have seen both tagged and untagged frames on ports in"general" mode
would it not be better to have the priority set on the DSCP / TOS
ie determining the priority against a field that you know exists...as opposed
as opposed to making priority decisions from a phantom vlan tag with
an id of 0 which may
or may not exist,
when the os / sys admin managing the host is probably not expecting
this behaviour ?
correct me if im wrong, but are vlan priorities usualy set from reading DSCP
/TOS.
also once the traffic is leaving the switch on an untagged / accessport
would the vlan prioirty be irrelevant, and the IP TOS / DSCP priority be read
by the os just as easily ?
I just dont get the benefit of this
Tom Smyth
On Fri, 12 Oct 2018 at 17:49, Rivo Nurges wrote:
>
> Hi!
>
> I'll look into the problems(vlan interface with 0 tag and issues
> priority differeces) you mentioned. I tested your idea of having vlan
> interface without tag and IP on top of physical interface, but IP
> traffic doesn't get picked up by parent.
>
> Extreme(Brocade) SLX does it. Depending on the ingress port
> configuration packets on egress can be with or without dot1q header.
> Seems, it doesn't cause issues with other operating systems.
>
> Rivo
>
> On Fri, 2018-10-12 at 13:38 +1000, David Gwynne wrote:
> > Hi Rivo,
> >
> > vlan(4) can be configured to receive (and send) packets with 0 as the
> > tag on the wire, which this diff will break.
> >
> > I'm pretty confident you can leave an IP configured on the physical
> > network interface, and create and configure a vlan interface on it
> > without setting a VLAN id. The untagged frames should be received as
> > normal on the parent, and the tagged frames with the priority will
> > come in on the vlan interface but still get accepted for IP on the
> > parent.
> >
> > Note that the default priority of packets in the OpenBSD kernel is 3,
> > which might be higher than what you expect an untagged packets
> > priority to be. The default 802.1q priority is 1 iirc.
> >
> > I'm curious as to where you see both tagged and untagged frames at
> > the same time.
> >
> > dlg
> >
> > > On 11 Oct 2018, at 7:20 pm, Rivo Nurges
> > > wrote:
> > >
> > > Hi!
> > >
> > > In theory 802.1q header with vlan tag 0 can be used to just signal
> > > priority. Now I'm seeing this in the wild. On a untagged port some
> > > packets are coming with dotq header and some without. Currently we
> > > drop
> > > all the packets with dotq header and vlan tag 0.
> > >
> > > Following patch fixes this by recording the priority and removing
> > > the
> > > header, so existing code to handle the packet. At least NetBSD does
> > > something similar.
> > >
> > > Rivo
> > >
> > > diff --git sys/net/if_ethersubr.c sys/net/if_ethersubr.c
> > > index 76f6c3147e0..68f5b03b4f4 100644
> > > --- sys/net/if_ethersubr.c
> > > +++ sys/net/if_ethersubr.c
> > > @@ -362,6 +362,22 @@ ether_input(struct ifnet *ifp, struct mbuf *m,
> > > void *cookie)
> > >
> > > etype = ntohs(eh->ether_type);
> > >
> > > + /*
> > > +* 802.1Q header with a tag of 0 can be used to store priority.
> > > +*/
> > > + if (etype == ETHERTYPE_VLAN) {
> > > + struct ether_vlan_header *evl = (void *)eh;
> > > + if (EVL_VLANOFTAG(evl->evl_tag) == EVL_VLID_NULL) {
> > > + etype = ntohs(evl->evl_proto);
> > > + m->m_pkthdr.pf.prio = EVL_PRIOFTAG(evl-
> > > >evl_tag);
> > > + /* IEEE 802.1p has prio 0 and 1 swapped */
> > > + if (m->m_pkthdr.pf.prio <= 1)
> > > + m->m_pkthdr.pf.prio = !m-
> > > >m_pkthdr.pf.prio;
> > > + memmove((char *)eh + EVL_ENCAPLEN, eh,
> > > sizeof(*eh));
> > > + m_adj(m, EVL_ENCAPLEN);
> > > + }
> > > + }
> > > +
> > > switch (etype) {
> > > case ETHERTYPE_IP:
> > > input = ipv4_input;
> > >
>
--
Kindest regards,
Tom Smyth
Mobile: +353 87 6193172
The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.
Re: OpenBGPd Feature Request / Question if the Feature Request
Hello Gregory ,please find my responses in line On Tue 25 Sep 2018, 15:54 Gregory Edigarov, wrote: > > > the whole discussion here reminds me somewhat about my idea I wanted to > realize some time ago: > suppose we have an imaginary "fast" router, which does hardware > assisted forwarding, and an OpenBGP(on a different host) lets call it > RDE, where it will provide routes for this fast router, to be put into > forwarding engine. > then we would have the following advantages: > 1. nice way to configure whatever we need in BGP (because we all know > that bgpd.conf is a very nice thing) > Openbgpd in nice for a control plane 2. real packet forwarding will take place on the hardware, specifically > built for this purpose. > Standard l3 switches can do this as long as they have 1. Sufficient cam /asic memory to accomodate the routes you intend to load into switch forwarding plane 2. The switch os needs to support bgp and have sufficent memory + cpu to allow some route filtering between rib and fib on the switch 3. Probably ospf also would be neededon the switch 3. if somebody would manufacture such say "dumb" forwarding planes, they > would definitely cost less then a fully featured router. > Yeah i think a decent l3 switch (broadcom trident ii ) or better would do what you are asking for > > is this a feasible idea or am I thinking completely wrong I dont think u need a special manufacturer for what im proposing .
Re: OpenBGPd Feature Request / Question if the Feature Request
Hello Stuart, Thanks for the feedback , I have responded to your feedback in line, On Sat, 22 Sep 2018 at 10:07, Stuart Henderson wrote: > > > Interesting idea but I think the method you're suggesting puts you at > higher risk of things *not* reaching their destination - if you have > good and not-so-good transits, the diffs are likely to be things you > don't want anyway and could interfere with correct routing. I see your point I had not considered that failure mode. > > Some providers have a bit of a problem with "stuck" routes (if there's > a stuck more-specific route at one provider, that will be a difference, > and you'll send traffic there on a road to nowhere instead of to a valid > less-specific). I get what you are saying however this would still be a problem if I had full views (if I understand your point correctly, any more specific network that is invalid would still blackhole traffic in the case where we have full tables ) also with that risk in mind I (think) such a setup would be better than defaulting to a transit provider who has sent a withdraw message on a prefix > > Another issue is that a good provider may have filtered a dubious > announcement (hijack attempt), a less fastidious one might not. > > If I wanted to identify *whether* a transit provider is sending such > routes, analysing a diff of the announcements between them and another > provider is quite a good way to find them. > I agree with you ... there would have to be some steady state comparison between the two (or more) Transit providers in normal conditions... the usual threats (hijacks etc would have to be dealt with with the usual IRR filtersetc > My suggestion if you're trying to use the hardware in this way: only use > transit providers who can be trusted to generally provide good transit > (which rules out a few ;) and just use defaults plus maybe allow some > extra through filters to encourage certain traffic to go a certain way, > or to balance load if your ports are hot. Yeah ... that would be the (rough) plan .. .or build workaround filters on the less well configured transit providers, there are other things to consider which makes it a tough(er) problem to solve what happens when your default provider looses connectivity with (most) of its peers then it would be better to swap the default route to the other transit provider and install exception routes (if any) Thanks for your feedback and time Tom Smyth
Re: OpenBGPd Feature Request / Question if the Feature Request
Hello Remi, Thanks for that, I saw a presentation from Paulo Lucende about this. for us as an eyeball ISP, my request is slightly simpler, because I can Advertise my routes to all peers / transit so my downloads will happen, to sort the upload I need to learn and install the routes. (content providers need to use netflow to learn which prefixes should be installed on the switch to deliver content to the users) I like the NFsen idea, however I think for a simple eyeball ISP we could be able to achieve it by adding a default + exceptions summarisation to openBGPd ( I would rather not create more dependencies on our BGP ) I want to install the minimum number of routes for transit so that I am confident the packet will reach the intended destination and then leave the rest of the switch CAM for Prefixes learned on a local internet exchange. Thanks for the feedback on the Spotify Use case... On Sat, 22 Sep 2018 at 09:11, Remi Locherer wrote: > > On Sat, Sep 22, 2018 at 08:22:52AM +0100, Tom Smyth wrote: > > OpenBGPd Feature Request / Question if the Feature Request > > is something the community would use ? > > > > Background, > > Ideally we would run full tables so that we have visibility > > on reachibility of a prefix via a transit provider, > > > > Problem: routers that support this functionality Reliably > > are quite expensive, (or inexpensive and unreliable) > > Workaround: > > so many people accept default over BGP from transit and > > then peer locally on the exchange > > Issue with this is that you lose visibility of wheather > > an ip is actually reachable via your transit provider > > > > > > Question: > > is it feasible to have a hybrid between a default route > > for transit and bgp full views of transit? > > Is it feasible to: > > a) take two or more full bgp feeds from transit, > > b) diff them continuously on a software route server, > > c) install a default route to your preferred transit provider > > on your lower cost L3 Switches / Routers > > d) install differences in prefix reachibilitity to the > > appropiate transit provider (which would otherwise not > > be reachable via your preferred transit provider) > > > > > > Why am I asking this ? > > I want to have the advantages of full views of internet > > but I want the simplicity of a single default route + > > any exceptions. and use more cost effective hardware > > > > Im asking this in the context of an ISP which is not > > proividing transit to other ISPs > > > > I ideally would like to run multihop BGP to my transit > > providers, > > and then use a L3 switch for forwarding in hardware > > (something like an arista / Broadcom Trident II ) > > which can take up to around 128k routes on its asics > > > > If it is feasible to do what is involved in adding it > > to OpenBGPd and is this something the wider community > > would use / enjoy ? > > > > Your feedback would be really appreciated... > > Yes, it is feasible. Spotify is doing something like this. > https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html > > In short: analyse where 80% of your traffic goes to (nfsen) and write a > filter to only install those prefixes in addition to the default route. > > A year ago I did this analysis for the network I operate: > 80% of our Internet traffic went to 20 ASs and was covered by ~9k prefixes. > > Cheers, > Remi
OpenBGPd Feature Request / Question if the Feature Request
OpenBGPd Feature Request / Question if the Feature Request is something the community would use ? Background, Ideally we would run full tables so that we have visibility on reachibility of a prefix via a transit provider, Problem: routers that support this functionality Reliably are quite expensive, (or inexpensive and unreliable) Workaround: so many people accept default over BGP from transit and then peer locally on the exchange Issue with this is that you lose visibility of wheather an ip is actually reachable via your transit provider Question: is it feasible to have a hybrid between a default route for transit and bgp full views of transit? Is it feasible to: a) take two or more full bgp feeds from transit, b) diff them continuously on a software route server, c) install a default route to your preferred transit provider on your lower cost L3 Switches / Routers d) install differences in prefix reachibilitity to the appropiate transit provider (which would otherwise not be reachable via your preferred transit provider) Why am I asking this ? I want to have the advantages of full views of internet but I want the simplicity of a single default route + any exceptions. and use more cost effective hardware Im asking this in the context of an ISP which is not proividing transit to other ISPs I ideally would like to run multihop BGP to my transit providers, and then use a L3 switch for forwarding in hardware (something like an arista / Broadcom Trident II ) which can take up to around 128k routes on its asics If it is feasible to do what is involved in adding it to OpenBGPd and is this something the wider community would use / enjoy ? Your feedback would be really appreciated... Tom Smyth
Increase the number of supported rdomains supported in the generic OpenBSD Kernels
Hello, I was wondering what is the impact of increasing the number of VRFs / Rdomains that the generic kernels are capable of supporting, I believe it is a constant determined prior to compile, I was just wondering if it could be increased from 256 to 65536 ? what is the impact on kernel memory usage ? -- Kindest regards, Tom Smyth
Re: Add 6to4 anycast prefixes to examples/bgpd.conf
Sorry... i meant to say I typically reject prefixes on my ebgp routers if the prefix has an as path length > 40 Thanks Tom Smyth On Thu 21 Jun 2018, 17:39 Tom Smyth, wrote: > Hello Job, > > Im happy with that, (not that i have a say either way ;) ) > > I was wondering would it be worth while to add rule to limit on the > aspath length that would be accepted in the examples/ > bgpd.conf file also > > I typically reject prefixes on my ebgp routers if the prefix has an as > path length > > > I was just wondering if you / the community think there is any value to > that being added to examples ... > > Or am i being overly restrictive ? > > > On Thu 21 Jun 2018, 16:52 Job Snijders, wrote: > >> Hi, >> >> Globally anycasted 6to4 has outlived its usefulness. >> Operational discussion: http://seclists.org/nanog/2018/Jun/268 >> >> Kind regards, >> >> Job >> >> diff --git etc/examples/bgpd.conf etc/examples/bgpd.conf >> index a5fa7234a3c..77f610b9a06 100644 >> --- etc/examples/bgpd.conf >> +++ etc/examples/bgpd.conf >> @@ -118,6 +118,7 @@ deny from any prefix 127.0.0.0/8 prefixlen >= 8 >> # localhost [RFC1122] >> deny from any prefix 169.254.0.0/16 prefixlen >= 16# link local >> [RFC3927] >> deny from any prefix 172.16.0.0/12 prefixlen >= 12 # private space >> [RFC1918] >> deny from any prefix 192.0.2.0/24 prefixlen >= 24 # TEST-NET-1 >> [RFC5737] >> +deny from any prefix 192.88.99.0/24 prefixlen >= 24# 6to4 anycast >> [RFC7526] >> deny from any prefix 192.168.0.0/16 prefixlen >= 16# private space >> [RFC1918] >> deny from any prefix 198.18.0.0/15 prefixlen >= 15 # benchmarking >> [RFC2544] >> deny from any prefix 198.51.100.0/24 prefixlen >= 24 # TEST-NET-2 >> [RFC5737] >> @@ -131,6 +132,7 @@ deny from any prefix 0100::/64 prefixlen >= 64 >> # Discard-Only [RFC] >> deny from any prefix 2001:2::/48 prefixlen >= 48 # BMWG [RFC5180] >> deny from any prefix 2001:10::/28 prefixlen >= 28 # ORCHID [RFC4843] >> deny from any prefix 2001:db8::/32 prefixlen >= 32 # docu range >> [RFC3849] >> +deny from any prefix 2002::/16 prefixlen >= 16 # 6to4 anycast >> [RFC7526] >> deny from any prefix 3ffe::/16 prefixlen >= 16 # old 6bone >> deny from any prefix fc00::/7 prefixlen >= 7 # unique local >> unicast >> deny from any prefix fe80::/10 prefixlen >= 10 # link local >> unicast >> >>
Re: Add 6to4 anycast prefixes to examples/bgpd.conf
Hello Job, Im happy with that, (not that i have a say either way ;) ) I was wondering would it be worth while to add rule to limit on the aspath length that would be accepted in the examples/ bgpd.conf file also I typically reject prefixes on my ebgp routers if the prefix has an as path length > I was just wondering if you / the community think there is any value to that being added to examples ... Or am i being overly restrictive ? On Thu 21 Jun 2018, 16:52 Job Snijders, wrote: > Hi, > > Globally anycasted 6to4 has outlived its usefulness. > Operational discussion: http://seclists.org/nanog/2018/Jun/268 > > Kind regards, > > Job > > diff --git etc/examples/bgpd.conf etc/examples/bgpd.conf > index a5fa7234a3c..77f610b9a06 100644 > --- etc/examples/bgpd.conf > +++ etc/examples/bgpd.conf > @@ -118,6 +118,7 @@ deny from any prefix 127.0.0.0/8 prefixlen >= 8 # > localhost [RFC1122] > deny from any prefix 169.254.0.0/16 prefixlen >= 16# link local > [RFC3927] > deny from any prefix 172.16.0.0/12 prefixlen >= 12 # private space > [RFC1918] > deny from any prefix 192.0.2.0/24 prefixlen >= 24 # TEST-NET-1 > [RFC5737] > +deny from any prefix 192.88.99.0/24 prefixlen >= 24# 6to4 anycast > [RFC7526] > deny from any prefix 192.168.0.0/16 prefixlen >= 16# private space > [RFC1918] > deny from any prefix 198.18.0.0/15 prefixlen >= 15 # benchmarking > [RFC2544] > deny from any prefix 198.51.100.0/24 prefixlen >= 24 # TEST-NET-2 > [RFC5737] > @@ -131,6 +132,7 @@ deny from any prefix 0100::/64 prefixlen >= 64 > # Discard-Only [RFC] > deny from any prefix 2001:2::/48 prefixlen >= 48 # BMWG [RFC5180] > deny from any prefix 2001:10::/28 prefixlen >= 28 # ORCHID [RFC4843] > deny from any prefix 2001:db8::/32 prefixlen >= 32 # docu range > [RFC3849] > +deny from any prefix 2002::/16 prefixlen >= 16 # 6to4 anycast > [RFC7526] > deny from any prefix 3ffe::/16 prefixlen >= 16 # old 6bone > deny from any prefix fc00::/7 prefixlen >= 7 # unique local > unicast > deny from any prefix fe80::/10 prefixlen >= 10 # link local > unicast > >
Re: ping.c minor bug discrepancy between reported size of icmp packet
Hello Paul, All,
Thanks for your clarification,
I appreciate your help on this please find my reponses in line
On 9 June 2018 at 09:40, Paul de Weerd wrote:
> Hi Tom,
>
> This is documented in ping(8):
>
> -s packetsize
> Specify the number of data bytes to be sent. The default
> is 56, which translates into 64 ICMP data bytes when
> combined with the 8 bytes of ICMP header data. The
> maximum packet size is 65467 for IPv4 and 65527 for IPv6.
>
> You can play around with the 56 bytes, but those 8 are non-negotiable:
> they're always added.
I get you ... the ICMP data bytes can be adjusted but not the ICMP
header bytes,
Note that it says 56 *data* bytes versus 64
> (total) bytes.
the issue I was highlighting is that when the user specifies
a certain size in the command , the command says
sending 1000 bytes
but then says the reply 1008 bytes
I think this is confusing to the user of the system.
also I think the total bytes is incorrect because it only takes
account of the ICMP header and not the IP header,
Perhaps the Approach I should take to fix this (my confusion)
( and possibly future users confusion)
would be to make the displayed values consistent and the
displayed label consistent
>
> You seem to be misunderstanding the format string passed that you
> found. %d is part of a format string, see printf(3). The "%"
> indicates a conversion specification, the "d" indicates the type of
> conversion, in this case a signed integer. The arguments following
> the format string are filled in where a conversion specification is
> given in the format string, in the order given. So in this example:
>
> #include ;
>
> int main() {
> int number;
> const char* test;
>
> text = "Hi Tom!";
> number = 42;
>
> printf("string: %s\nnumber: %d\n", string, number)
> return 0;
> }
>
> The printf(3) function gets called with three arguments. The first is
> the format string: "string: %s\nnumber: %d\n". As you can see,
> there's two conversion specifications in there, "%s" and "%d". "%s"
> is for a "char*" argument, it gets replaced with the second argument
> to the function (the variable 'string', which we gave the value "Hi
> Tom!"). "%d" is for the integer argument, it gets replaced with a
> decimal representation of the value of the third argument to the
> function (the variable 'number', which we gave the value 42).
>
Thanks for your help on printf(3) :) Ill work on this
> Applying this knowledge to the three lines you found in the ping
> source:
> In line 760, %d gets the value from variable 'datalen'.
> In lines 1248 and 1292, %d gets the value from variable 'cc'.
>
> Note that 'cc' could be changed between those two lines, so the value
> printed in the end doesn't *have* to be the same - that depends on the
> rest of the code.
I think we could display (datalen+8) bytes in line 760
or
preferably display (cc -8) bytes in lines 1248 and 1292
and do a ping man page update based on the agreed approach
thanks for your help and input
Tom Smyth
>
> Cheers,
>
> Paul
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
--
Kindest regards,
Tom Smyth
ping.c minor bug discrepancy between reported size of icmp packet
Hello I see a small discrepancy between the measurement
of sent and received packets as displayed by ping command
on the wire the sent and received packets are the same size
I had a brief go
foo# ping 5.134.88.1
PING 5.134.88.1 (5.134.88.1): 56 data bytes
64 bytes from 5.134.88.1: icmp_seq=0 ttl=53 time=91.719 ms
it would appear that one measurement is the ICMP Payload only
and the other is the ICMP payload + ICMP header (8 byte difference)
foo# grep -n " data bytes" /root/ping.c
760:printf("%s): %d data bytes\n", pr_addr(dst, dst->sa_len), datalen);
foo# grep -n " bytes from" /root/ping.c
1248: printf("%d bytes from %s: icmp_seq=%u", cc,
1292: printf("%d bytes from %s: ", cc, pr_addr(from, fromlen));
looking at the source code it looks like the size = %d but %d is presenting
different values
I didnt see where %d was being changed between line 760 and line 1248
It has been a while since I looked at C programming in anger and im a bit
rusty...
any pointers on where i should be looking so that I can submit a patch
--
Kindest regards,
Tom Smyth
Re: ifconfig: add -rdomain option
Hi Ayaka, All, the diff from a user experience point of view :) ... ill stop right there... I was going to ask another slightly related question regarding ifconfig output consistency would there be a way to display the rdomain of interfaces that are in the default rdomain , as rdomain just wondering ... as it would be handy and consistent (when running multiple rdomains on a router ..) or perhaps display rdomain of all interfaces once one interface has a non rdomain set Im not asking you to code this to my preference for a second.. .but I was wondering what you and other Developers / Admins on list thought ? Thanks Tom Smyth On 21 February 2018 at 14:42, Sebastian Benoit wrote: > Ayaka Koshibe(akosh...@openbsd.org) on 2018.02.20 21:20:20 -0800: >> On Tue, Feb 20, 2018 at 4:48 AM, Reyk Floeter wrote: >> > >> >> Am 20.02.2018 um 11:15 schrieb Klemens Nanni : >> >> >> >>> On Mon, Feb 19, 2018 at 05:09:58PM -0800, Ayaka Koshibe wrote: >> >>> This diff would allow saying 'ifconfig foo -rdomain' instead of >> >>> 'ifconfig foo rdomain 0'. >> >> I can see where you're coming from but this breaks semantics: `-option' >> >> clears an optional parameter or deconfigures functionality whereas >> >> `rdomain' is mandatory (defaulting to 0), every interface is attached >> >> to exactly one routing domain all the time. >> >> >> > >> > I would rather say that -option resets it to the default non-specific >> > option. For example, -mode doesn???t remove all wireless modes. >> >> This was also my interpretation of -option -- a way to reset to the >> default, which happens to be a value of 0 for this case. >> >> > I think -rdomain is a good addition and the diff looks fine. >> > >> > Reyk > > i'm ok with the diff as well, but i want to remind you that rdomain is > special, because it also removes all ip configuration from the interface. > I.e. -rdomain does more than the other -options. > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: Anyone can suggest a BitCoin processor to the OpenBSD Foundation? BitPay has become terrible
Hi Bob, I know one or 2 people who have moved a reasonable amount of money through kraken.com In my humble experience Kraken have been ok to deal with ... and seem cost effective enough compared to coinbase... they were faster to process verification than Bitstamp.. in our humble experience I hope this helps Tom Smyth On 16 February 2018 at 14:53, Bob Beck wrote: > So, as some of you may know, the OpenBSD Foundation has accepted BitCoin > donations > for some time via BitPay.com > > BitPay was convenient for us since they will sell the BTC donations > immediately, and > convert to Canadian Dollars. We then periodically get bank transfers of > the balance, > and this works great. > > Obviously, for money laundering rules, we do need to provide them with some > documentation to prove the foundation's legitimacy, which we have > repatedly, and > this used to be not a problem. > > Lately they seem to have decided in spite of being in posession of > 1) A copy of two of our personal passports > 2) A copy of the Canadian Federal Incorporation documents for a not for > profit > 3) A copy of the Electric Bill for the address of record > 4) A copy of an invoice sent to the foundation at the address of record > 5) A copy of a bank statement from the foundation > > That they seem to be suspending our access to BitPay - this in spite of this > being the only documents they request from us and then they seem to say > they won't work - because apparently they don't understand Canada our > countries outside of the USA. > > So in short, bitPay has always been a bit of a pain for us, but now seems > to be > unable to be used by us. > > So, what I'm looking for is opinions on an online processor. Yes I am > aware they > charge fees, I am looking for convenience, basically, the ability to put a > button > on the foundation donation page that links to them. which will take a > donation > in BTC, convert it for us, and get it to us at a Canadian bank. What are > all you people using? > > For a number of reasons, we do *not* want to hold a bitCoin wallet > ourselves, and > be in the business of selling bitcoins, so please don't suggest this, and > No, we can't > have a bank account outside of Canada, so please don't suggest that either > :) -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: route socket filter on priority
Nice feature
lots of real world use cases.
On 10 Feb 2018 9:19 AM, "Sebastian Benoit" wrote:
>
>
> - add ROUTE_PRIOFILTER
> - it has one argument that is interpreted as a route priority
> - all route updates with prio lower or equal will pass the filter,
> all with higher priority value will be filtered.
> - example use in ospfd
>
> comments/oks?
>
> (benno_ospfd_route_priofilter_1.diff)
>
> diff --git sys/net/route.h sys/net/route.h
> index 1ca0a22c45f..7a4008b7ac1 100644
> --- sys/net/route.h
> +++ sys/net/route.h
> @@ -298,6 +298,9 @@ struct rt_msghdr {
> #define ROUTE_TABLEFILTER 2/* change routing table the socket is
> listening
>on, RTABLE_ANY listens on all tables. */
>
> +#define ROUTE_PRIOFILTER 3 /* change routing table the socket is
> listening
> + on, RTABLE_ANY listens on all tables. */
> +
> #define ROUTE_FILTER(m)(1 << (m))
> #define RTABLE_ANY 0x
>
> diff --git sys/net/rtsock.c sys/net/rtsock.c
> index 35bdd09d143..5f4244e6057 100644
> --- sys/net/rtsock.c
> +++ sys/net/rtsock.c
> @@ -141,6 +141,7 @@ struct routecb {
> unsigned intmsgfilter;
> unsigned intflags;
> u_int rtableid;
> + u_char priority;
> };
> #definesotoroutecb(so) ((struct routecb *)(so)->so_pcb)
>
> @@ -309,6 +310,7 @@ route_ctloutput(int op, struct socket *so, int level,
> int optname,
> struct routecb *rop = sotoroutecb(so);
> int error = 0;
> unsigned int tid;
> + u_char prio;
>
> if (level != AF_ROUTE)
> return (EINVAL);
> @@ -333,6 +335,17 @@ route_ctloutput(int op, struct socket *so, int level,
> int optname,
> else
> rop->rtableid = tid;
> break;
> + case ROUTE_PRIOFILTER:
> + if (m == NULL || m->m_len != sizeof(u_char)) {
> + error = EINVAL;
> + break;
> + }
> + prio = *mtod(m, u_char *);
> + if (prio > RTP_MAX)
> + error = EINVAL;
> + else
> + rop->priority = prio;
> + break;
> default:
> error = ENOPROTOOPT;
> break;
> @@ -348,6 +361,10 @@ route_ctloutput(int op, struct socket *so, int level,
> int optname,
> m->m_len = sizeof(unsigned int);
> *mtod(m, unsigned int *) = rop->rtableid;
> break;
> + case ROUTE_PRIOFILTER:
> + m->m_len = sizeof(u_char);
> + *mtod(m, u_char *) = rop->priority;
> + break;
> default:
> error = ENOPROTOOPT;
> break;
> @@ -431,6 +448,8 @@ route_input(struct mbuf *m0, struct socket *so,
> sa_family_t sa_family)
> if (rtm->rtm_type != RTM_DESYNC && rop->msgfilter != 0 &&
> !(rop->msgfilter & (1 << rtm->rtm_type)))
> continue;
> + if (rop->priority != 0 && rop->priority <
> rtm->rtm_priority)
> + continue;
> switch (rtm->rtm_type) {
> case RTM_IFANNOUNCE:
> case RTM_DESYNC:
> diff --git usr.sbin/ospfd/kroute.c usr.sbin/ospfd/kroute.c
> index 17febefbdcb..a5c069aa540 100644
> --- usr.sbin/ospfd/kroute.c
> +++ usr.sbin/ospfd/kroute.c
> @@ -127,10 +127,11 @@ kif_init(void)
> }
>
> int
> -kr_init(int fs, u_int rdomain)
> +kr_init(int fs, u_int rdomain, u_int8_t redis_label_or_prefix)
> {
> int opt = 0, rcvbuf, default_rcvbuf;
> socklen_t optlen;
> + u_char filter_prio = RTP_OSPF;
>
> kr_state.fib_sync = fs;
> kr_state.rdomain = rdomain;
> @@ -146,6 +147,14 @@ kr_init(int fs, u_int rdomain)
> &opt, sizeof(opt)) == -1)
> log_warn("kr_init: setsockopt");/* not fatal */
>
> + if (redis_label_or_prefix)
> + filter_prio = 0;
> + if (setsockopt(kr_state.fd, AF_ROUTE, ROUTE_PRIOFILTER,
> &filter_prio,
> + sizeof(filter_prio)) == -1) {
> + log_warn("%s: setsockopt AF_ROUTE ROUTE_PRIOFILTER",
> __func__);
> + return (-1);
> + }
> +
> /* grow receive buffer, don't wanna miss messages */
> optlen = sizeof(default_rcvbuf);
> if (getsockopt(kr_state.fd, SOL_SOCKET, SO_RCVBUF,
> diff --git usr.sbin/ospfd/ospfd.c usr.sbin/ospfd/ospfd.c
> index 3c5057ae04e..0e91819f673 100644
> --- usr.sbin/ospfd/ospfd.c
> +++ usr.sbin/ospfd/ospfd.c
> @@ -265,7 +265,7 @@ main(int argc, char *argv[])
> event_add(&iev_r
Re: bridge(4): protected interface (port)
On 31 January 2018 at 16:21, Martin Pieuchot wrote:
> Thanks for all the feedbacks I received. Diff below addresses multiple
> points after discussion with dlg@ and martijn@:
>
> - Stop using the word 'group' which confuse people. Instead talk of
> 'protected domain'. Interfaces that are part of such domain cannot
> send traffic to each others.
>
> - Allows interface to be part of multiple protected domains. I'm
> using bits for that, meaning that we have a maximum of 31 domains.
>
> In the example below we have to protected domains { em0, em2 } and
> { em1 , em2 }.
>
> bridge0: flags=41
> index 9 llprio 3
> groups: bridge
> priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
> designated: id 00:00:00:00:00:00 priority 0
> em0 flags=3
> port 6 ifpriority 0 ifcost 0 protected 11
> em1 flags=3
> port 7 ifpriority 0 ifcost 0 protected 2,11
> em2 flags=3
> port 8 ifpriority 0 ifcost 0 protected 2
>
>
> Comments, oks?
I agree with the comments about Group terminology being confusing ...
> - Allows interface to be part of multiple protected domains. I'm
> using bits for that, meaning that we have a maximum of 31 domains.
That is smart ... so you can have more granularity on what interfaces
can communicate
or not communicate with each other... It would be a superior
implementation to what I have
seen in other Systems / Switches in the Wild ...
Thanks Martin , martin@ , dlg@ and Remi
Re: bridge(4): protected interface (port)
Hello Remi, Regarding your query, >Wouldn't this duplicate BUM traffic? In this situation I would try a setup with >trunk(4) for the uplinks. At least the failover mode should work if your >switches have a limited feature set. Yes the scenario where you put 2 uplinks into a bridge would potentially duplicate Broadcast, Unknown Unicast, & Multicast Traffic, as per a standard Layer2 switch, but you have the advantage, that if a port goes down and the mac is removed from the bridge Fib, the frame is briefly flooded until the mac is learned via the other layer2 path, so Unknown Unicast is the exception rather than the rule (thankfully) Broadcast / Multicast Traffic is usually small Conversely if you use a Trunk in fail over mode it will favor the primary interface until it goes down,so the primary would be used as-long as the interface is up even if the switch that primary is attached to has lost its up-link, All that being said the Feature that MPI (thanks for putting the time into) improves security and ease of configuration of Protected ports in a Bridge. and it in its self will actually Limit Broadcast / Multicast / unknown Unicast flooding in most cases (except for a Redundant Layer 2 Uplinks into the same Bridge) I Hope this helps Tom Smyth
Re: bridge(4): protected interface (port)
bif_statebif_stp->bp_state
>> Index: sys/sys/sockio.h
>> ===
>> RCS file: /cvs/src/sys/sys/sockio.h,v
>> retrieving revision 1.72
>> diff -u -p -r1.72 sockio.h
>> --- sys/sys/sockio.h 24 Oct 2017 09:36:13 - 1.72
>> +++ sys/sys/sockio.h 22 Jan 2018 14:09:09 -
>> @@ -89,6 +89,7 @@
>> #define SIOCBRDGDADDR_IOW('i', 71, struct ifbareq) /* delete addr
>> */
>> #define SIOCBRDGFLUSH_IOW('i', 72, struct ifbreq) /* flush addr
>> cache */
>> #define SIOCBRDGADDL _IOW('i', 73, struct ifbreq) /* add local
>> port */
>> +#define SIOCBRDGSIFPROT _IOW('i', 74, struct ifbreq) /* set
>> protected grp */
>>
>> #define SIOCBRDGARL _IOW('i', 77, struct ifbrlreq) /* add bridge rule */
>> #define SIOCBRDGFRL _IOW('i', 78, struct ifbrlreq) /* flush brdg rules */
>> Index: sbin/ifconfig/brconfig.c
>> ===
>> RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
>> retrieving revision 1.16
>> diff -u -p -r1.16 brconfig.c
>> --- sbin/ifconfig/brconfig.c 31 Jul 2017 02:32:11 - 1.16
>> +++ sbin/ifconfig/brconfig.c 22 Jan 2018 14:30:38 -
>> @@ -336,6 +336,8 @@ bridge_list(char *delim)
>> printf("port %u ifpriority %u ifcost %u",
>> reqp->ifbr_portno, reqp->ifbr_priority,
>> reqp->ifbr_path_cost);
>> + if (reqp->ifbr_protected)
>> + printf(" protected %u", reqp->ifbr_protected);
>> if (reqp->ifbr_ifsflags & IFBIF_STP)
>> printf(" %s role %s",
>> stpstates[reqp->ifbr_state],
>> @@ -452,6 +454,41 @@ bridge_priority(const char *arg, int d)
>> bp.ifbrp_prio = v;
>> if (ioctl(s, SIOCBRDGSPRI, (caddr_t)&bp) < 0)
>> err(1, "%s", name);
>> +}
>> +
>> +void
>> +bridge_protect(const char *ifname, const char *val)
>> +{
>> + struct ifbreq breq;
>> + unsigned long v;
>> + char *endptr;
>> +
>> + strlcpy(breq.ifbr_name, name, sizeof(breq.ifbr_name));
>> + strlcpy(breq.ifbr_ifsname, ifname, sizeof(breq.ifbr_ifsname));
>> +
>> + errno = 0;
>> + v = strtoul(val, &endptr, 0);
>> + if (val[0] == '\0' || endptr[0] != '\0' || v == 0 || v > UINT32_MAX ||
>> + (errno == ERANGE && v == ULONG_MAX))
>> + err(1, "invalid arg for protected group: %s", val);
>> + breq.ifbr_protected = v;
>> +
>> + if (ioctl(s, SIOCBRDGSIFPROT, (caddr_t)&breq) < 0)
>> + err(1, "%s: %s", name, val);
>> +}
>> +
>> +void
>> +bridge_unprotect(const char *ifname, int d)
>> +{
>> + struct ifbreq breq;
>> +
>> + strlcpy(breq.ifbr_name, name, sizeof(breq.ifbr_name));
>> + strlcpy(breq.ifbr_ifsname, ifname, sizeof(breq.ifbr_ifsname));
>> +
>> + breq.ifbr_protected = 0;
>> +
>> + if (ioctl(s, SIOCBRDGSIFPROT, (caddr_t)&breq) < 0)
>> + err(1, "%s: %d", name, 0);
>> }
>>
>> void
>> Index: sbin/ifconfig/brconfig.h
>> ===
>> RCS file: /cvs/src/sbin/ifconfig/brconfig.h,v
>> retrieving revision 1.12
>> diff -u -p -r1.12 brconfig.h
>> --- sbin/ifconfig/brconfig.h 16 Jan 2018 10:33:55 - 1.12
>> +++ sbin/ifconfig/brconfig.h 22 Jan 2018 14:12:39 -
>> @@ -52,6 +52,8 @@ void bridge_addrs(const char *, int);
>> void bridge_hellotime(const char *, int);
>> void bridge_fwddelay(const char *, int);
>> void bridge_maxage(const char *, int);
>> +void bridge_protect(const char *, const char *);
>> +void bridge_unprotect(const char *, int);
>> void bridge_proto(const char *, int);
>> void bridge_ifprio(const char *, const char *);
>> void bridge_ifcost(const char *, const char *);
>> Index: sbin/ifconfig/ifconfig.8
>> ===
>> RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
>> retrieving revision 1.292
>> diff -u -p -r1.292 ifconfig.8
>> --- sbin/ifconfig/ifconfig.8 16 Jan 2018 10:33:55 - 1.292
>> +++ sbin/ifconfig/ifconfig.8 22 Jan 2018 15:11:32 -
>> @@ -662,6
Re: /etc/rc: fsck -y
Hi All, For what its worth.. if they are devices that are regularly rebooted without proper shutdown,( you may be better off avoiding the situation where FSCK has to run) I have found As Otto has pointed out fsck and all the way doesn't work so well in some cases. The most risk adverse way I have found for Routers / firewalls in the field was to use mfs memory backed file systems where there are regular changes (/var /tmp) and use default ffs (with noatime mount option ) for everything else, it reduces the probability of FSCK having to run due to a write / incomplete write during loss of power ... in the event of some other issue (hardware failure) well MFS wont help in that case, I hope this helps Peace out Tom Smyth On 18 January 2018 at 11:30, Artturi Alm wrote: > On Thu, Jan 18, 2018 at 12:13:54PM +0100, Otto Moerbeek wrote: >> On Thu, Jan 18, 2018 at 12:12:39PM +0200, Artturi Alm wrote: >> >> > Hi, >> > >> > i think i've never answered "n" to fsck, so to me the lack of -y does >> > mean unnecessary work/boards/VMs left waiting for the F.. >> > >> > i would use something like this if it was there: >> > >> > diff --git a/etc/rc b/etc/rc >> > index c88e13ce7ab..e3a269be818 100644 >> > --- a/etc/rc >> > +++ b/etc/rc >> > @@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then >> > echo "Fast boot: skipping disk checks." >> > elif [[ $1 == autoboot ]]; then >> > echo "Automatic boot in progress: starting file system checks." >> > - do_fsck >> > + if [[ -e /failboot ]]; then >> > + do_fsck >> > + else >> > + do_fsck -y >> > + fi >> > fi >> > >> > # From now on, allow user to interrupt (^C) the boot process. >> > >> > >> > but the one below is what i believe should fit&go w/modern sane defaults >> > (think terabytes). >> > no man page diffs, as i guess this won't fly (w/o bikeshedding atleast). >> > -Artturi >> > >> > >> > diff --git a/etc/rc b/etc/rc >> > index c88e13ce7ab..e3a269be818 100644 >> > --- a/etc/rc >> > +++ b/etc/rc >> > @@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then >> > echo "Fast boot: skipping disk checks." >> > elif [[ $1 == autoboot ]]; then >> > echo "Automatic boot in progress: starting file system checks." >> > - do_fsck >> > + if [[ -e /failboot ]]; then >> > + do_fsck >> > + else >> > + do_fsck -y >> > + fi >> > fi >> > >> > # From now on, allow user to interrupt (^C) the boot process. >> >> This has come up before and is not ok. >> It is dangerous becuase it might make things worse. >> >> I want to have a chanche to e.g. save an image or chack cabling. >> >> Again, no. >> >> -Otto > > Ok, anyway the first diff was supposed to be this: > > diff --git a/etc/rc b/etc/rc > index c88e13ce7ab..c8a25da7b42 100644 > --- a/etc/rc > +++ b/etc/rc > @@ -349,7 +349,11 @@ if [[ -e /fastboot ]]; then > echo "Fast boot: skipping disk checks." > elif [[ $1 == autoboot ]]; then > echo "Automatic boot in progress: starting file system checks." > - do_fsck > + if [[ -e /forceboot ]]; then > + do_fsck -y > + else > + do_fsck > + fi > fi > > # From now on, allow user to interrupt (^C) the boot process. > > > so only giving user the choice of not editing /etc/rc. > fwiw. i heard FreeBSD has variable named "fsck_y_enable", > but i'm useless w/shell scripts, so i chose above.. > -Artturi >
Re: Intel CPU Security Flaw Kernel Memory Leak (no microcode update) SW workarounds only
Hello all, there are 2 papers on the following site discussing the CPU Security Flaws https://spectreattack.com/ I hope this helps Tom Smyth
Intel CPU Security Flaw Kernel Memory Leak (no microcode update) SW workarounds only
Hello all, Thought I might mention this CPU Flaw that apparently allows unauthorised viewing of kernel Memory https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ apparently there is no microcode update to fix it, and that software only workarounds with heavy performance penalties are the only security fixes available I hope this helps Tom Smyth
Re: [patch] hostname.if5 additional info on point to point addressing
Hi Ingo, First of all thanks for the feedback it is appreciated, especially when you think the thread is a waste of time. so rather than look for feedback on another patch for now If you could bear with me and let me outline why I think this thread is important important enough to be my first proper attempt at a patch submission :) what Im trying to document is point to point addressing similar to serial links /PPP /PPPoE links There are a couple of advantages in these systems a) in that it there is no arp on the link b) it can save the number of addresses used by linking routers together I must say point to point addressing /ip unnumbered is widely deployed in networks in the wild and is supported on other vendors, and in order for me to integrate OpenBSD Routers / firewalls into those networks, we use the point to point addressing feature (ip un numbered) to achieve this. In a nut shell there is a feature that is useful in OpenBSD in use in the Wild, that I found difficult to get working because it was not documented (adequately) in the manual. The only way I could get it to work was internet searching and finding a Tedu blog post I think this feature is useful and functional and should be documented and I want to help with the documentation based on my experience. If you / the community agree with my intention can you point me in a direction where I can document this feature in a useful manner for the OpenBSD Users. Perhaps it needs its own manual page ? Perhaps a manual page explaining all the ways we can set an Ip address on an interface would be helpful ? Maybe hostname.if.5 is not the place for it ? Any ideas and pointers that would allow me to submit a useful doc patch would be greatly appreciated Thanks for your Time and consideration Tom Smyth P.S. I absolutely hate /31 addressing I prefer having a link with 2 x /32 ip addresses is easier for me to digest than the 2 ip addresses occupying the reserved network and Broadcast addresses in /31 addressing
Re: [patch] hostname.if5 additional info on point to point addressing
Hello Stuart, all, Thanks for the corrections Stuart, I have corrected the patch to take into account your suggestions and I hope this proposed patch is more correct and useful Index: src/share/man/man5/hostname.if.5 === RCS file: /cvs/src/share/man/man5/hostname.if.5,v retrieving revision 1.65 diff -u -p -u -r1.65 hostname.if.5 --- src/share/man/man5/hostname.if.510 Mar 2017 18:28:11 - 1.65 +++ src/share/man/man5/hostname.if.512 Oct 2017 00:06:15 - @@ -91,6 +91,16 @@ Regular IPv4 network setup: .Va dest_addr .Ed .Pp +Point to Point IPv4 network setup: +.Bd -ragged -offset indent +.Li inet +.Op Li alias +.Va addr +.Va netmask +.Va network_addr +.Va options +.Ed +.Pp Regular IPv6 network setup: .Bd -ragged -offset indent .Li inet6 @@ -122,6 +132,15 @@ inet6 alias fec0::1 64 inet6 alias fec0::2 64 anycast !route add 65.65.65.65 10.0.1.13 up +.Ed +.Pp +Point to point IP addresses or IP unnumbered addresses +can also be applied to an interface iff it is a tunnel or serial interface +such as; gif(4), gre(4), pppoe(4), ppp(4), sppp(4). +For example: +.Bd -literal -offset 1n +inet 10.64.100.2 0x 10.64.80.25 +#local_addr /32_netmask remote_addr .Ed .Pp The above formats have the following field values: On 2 October 2017 at 11:33, Stuart Henderson wrote: > On 2017/10/02 03:04, Tom Smyth wrote: >> Hello, >> >> But the Ip configuration syntax in hostname.if is the same. > > For a /31 you just use e.g. "inet 192.0.2.100/31" (and it works properly > in other parts of the system, e.g. ospfd). > >> Is there anything specifically wrong in the proposed patch ? > > This configuration only works on actual point-to-point interfaces (gif, gre, > tun). Without further explanation people might expect it to work on ethernet > like interfaces, and the "endpoint" address (10.64.80.25 in your example) > doesn't do anything there. > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: [patch] hostname.if5 additional info on point to point addressing
Hello, But the Ip configuration syntax in hostname.if is the same. (appart from a /31 having a sequential ip address pair that starts on an even numbered ip) while a point to point / ip unumbered setup would have any arbitary pair of ips on the interface. Is there anything specifically wrong in the proposed patch ? thanks for the update on ip unumbered (i didnt know about that term for point to point addressing) Tom Smyth On 1 October 2017 at 23:42, Stuart Henderson wrote: > On 2017/10/01 19:18, Tom Smyth wrote: >> so the point to point addressing scheme is for saving ips sometimes >> it can be referred to incorrectly in my opinion as /31 addressing > > It's totally different to /31. > >> (well it is more like 2x /32 addresses) but it can be a > > What you're suggesting is more commonly known as "ip unnumbered", the gateway > uses an address shared between multiple downstreams. It was originally common > for PPP links but low-budget VPS providers started doing this on ethernet too. > >> it is described on the following rfc >> https://tools.ietf.org/html/rfc3021 > > No, that describes standard /31 use. > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: [patch] hostname.if5 additional info on point to point addressing
Hello Lads and ladies I had a number of discussions with some devs about this patch and there seems to be a lack of confidence in what I wrote :) and one person used the word suspicious to describe the patch :) so the point to point addressing scheme is for saving ips sometimes it can be referred to incorrectly in my opinion as /31 addressing (well it is more like 2x /32 addresses) but it can be a (summary /31 network if they are sequential and the first ip is an even number) it is described on the following rfc https://tools.ietf.org/html/rfc3021 it is used to save IP allocations rather than using a standard broadcast network allocation for giving an ip to a client which would require /30 network (4 Ips in total ) so an ascii diagram of what im trying to document is as follows inet 10.3.4.5 0x 10.1.2.3 + | +-+ | +--+ | Router A | v |Router B | | +-++--+ | +-+ ^ +--+ | | inet 10.1.2.3 0x 10.3.4.5 so in point to point addressing an interface on your router you put ip address of your router interface after inet you set the subnet mask to /32 (255.255.255.255) and you put the other router ip address after the subnetmask, then on the other router you do swap the ips in the hostname.if file and hey presto your link works comments suggestions and criticisms welcome Thanks On 24 September 2017 at 13:12, Tom Smyth wrote: > Hello lads, and ladies, > I have included some extra info on point to point addressing on > interfaces in OpenBSD thanks @tedu for the blog post that helpd me > learn how to do point to point addressing (non Broadcast) on Openbsd > and @theo @ingo for pointing me in the right direction on man page > contributions earlier in the year, > patch is below I hope it helps > > Index: src/share/man/man5/hostname.if.5 > === > RCS file: /cvs/src/share/man/man5/hostname.if.5,v > retrieving revision 1.65 > diff -u -p -u -r1.65 hostname.if.5 > --- src/share/man/man5/hostname.if.510 Mar 2017 18:28:11 -1.65 > +++ src/share/man/man5/hostname.if.523 Sep 2017 11:50:49 - > @@ -91,6 +91,16 @@ Regular IPv4 network setup: > .Va dest_addr > .Ed > .Pp > +Point to Point IPv4 network setup: > +.Bd -ragged -offset indent > +.Li inet > +.Op Li alias > +.Va addr > +.Va netmask > +.Va network_addr > +.Va options > +.Ed > +.Pp > Regular IPv6 network setup: > .Bd -ragged -offset indent > .Li inet6 > @@ -122,6 +132,13 @@ inet6 alias fec0::1 64 > inet6 alias fec0::2 64 anycast > !route add 65.65.65.65 10.0.1.13 > up > +.Ed > +.Pp > +Point to point ip addressing can also be applied to an interface > +for example: > +.Bd -literal -offset 1n > +inet 10.64.100.2 0x 10.64.80.25 > +#host_addr /32_netmask network_addr > .Ed > .Pp > The above formats have the following field values:
ASCII Drawings in Manual Pages ?
Hello Lads, Ladies what is the consensus about ascii drawings for Manual pages ? eg for point to point adddressing could we include inet 10.3.4.5 0x 10.1.2.3 + | +-+ | +--+ | Router A | v |Router B | | +-++--+ | +-+ ^ +--+ | | inet 10.1.2.3 0x 10.3.4.5 or is the view dependent on users chosen terminal font so you don't bother with them ? Thanks Tom smyth
Re: hostname.if5 patch
Please Disgrgard this patch request I have sent an alternate non Mime Formatted one Thanks On 23 September 2017 at 14:16, Tom Smyth wrote: > Hello Lads, > > I have submitted a proposed patch for hostname.if5 to show a user how > to do Point to Point Addressing on an interface (thanks to @Tedu for > publishing the correct syntax which helped me. > > So I (tried to ) show syntax for that case on the hostname.if manual file > Thanks to Nikolai for helping me with the patch generation
[patch] hostname.if5 additional info on point to point addressing
Hello lads, and ladies, I have included some extra info on point to point addressing on interfaces in OpenBSD thanks @tedu for the blog post that helpd me learn how to do point to point addressing (non Broadcast) on Openbsd and @theo @ingo for pointing me in the right direction on man page contributions earlier in the year, patch is below I hope it helps Index: src/share/man/man5/hostname.if.5 === RCS file: /cvs/src/share/man/man5/hostname.if.5,v retrieving revision 1.65 diff -u -p -u -r1.65 hostname.if.5 --- src/share/man/man5/hostname.if.510 Mar 2017 18:28:11 -1.65 +++ src/share/man/man5/hostname.if.523 Sep 2017 11:50:49 - @@ -91,6 +91,16 @@ Regular IPv4 network setup: .Va dest_addr .Ed .Pp +Point to Point IPv4 network setup: +.Bd -ragged -offset indent +.Li inet +.Op Li alias +.Va addr +.Va netmask +.Va network_addr +.Va options +.Ed +.Pp Regular IPv6 network setup: .Bd -ragged -offset indent .Li inet6 @@ -122,6 +132,13 @@ inet6 alias fec0::1 64 inet6 alias fec0::2 64 anycast !route add 65.65.65.65 10.0.1.13 up +.Ed +.Pp +Point to point ip addressing can also be applied to an interface +for example: +.Bd -literal -offset 1n +inet 10.64.100.2 0x 10.64.80.25 +#host_addr /32_netmask network_addr .Ed .Pp The above formats have the following field values:
hostname.if5 patch
Hello Lads, I have submitted a proposed patch for hostname.if5 to show a user how to do Point to Point Addressing on an interface (thanks to @Tedu for publishing the correct syntax which helped me. So I (tried to ) show syntax for that case on the hostname.if manual file Thanks to Nikolai for helping me with the patch generation hostname.if.5patch Description: Binary data
Re: man page update for bgpctl
Thank you Jason, Denis, I will learn how to generate proper patches, thanks for your patience and help Appreciated, will submit more and better ones in future Thanks Tom Smyth On 21 September 2017 at 13:07, Tom Smyth wrote: > Hello > minor Grammar Correction on manual page for bgpctl > > - line144 > Take the BGP session to the specified neighbor up. > +line144 > Bring the BGP session to the specified neighbor up.
man page update for bgpctl
Hello minor Grammar Correction on manual page for bgpctl - line144 Take the BGP session to the specified neighbor up. +line144 Bring the BGP session to the specified neighbor up. bgpctl.8 Description: Binary data
If devs need any old Dell spares
Hello if devs need some spares for older dell systems / hp systems let me know and Ill see if I have the parts. DRAC Cards, PERC Controlers Power Supplies Let me know and Ill ship them to you Thanks Tom Smyth
Re: want some working PCI-e 4Port Nics Atheros Chipset
sorry forgot to mention these are copper RJ45 cards (not sfp) Thanks On 6 September 2017 at 19:29, Tom Smyth wrote: > > Hello lads & Ladies > > I have a few Port Gb/s PCI-E (X4) Cards > from a few systems Im retiring > > Product name Mikrotik RB44Ge > Chipset Atheros AR8131/M > PCIe 4X > Formfactor Full / Half Height half Lenghth > > i have fullheight brackets on them and Ill > try to root out the half height brackets if I can if required > > Im willing to ship them to Developers / porters > if they think they would help them > > > -- > Kindest regards, > Tom Smyth >
Need Hotswap Seagate 300GB 10K U320 SCSI Drives ?
Hello Lads & Ladies 8x working Ultra U320 10K 300G Seagate Cheetah ST337LC I have a few 15K 73GB Ultra 320 Drives also not super awesome but may help for spares for aging systems that you want to test on Im willing to ship them to Developers / porters if they think they would help them -- Kindest regards, Tom Smyth
want some working PCI-e 4Port Nics Atheros Chipset
Hello lads & Ladies I have a few Port Gb/s PCI-E (X4) Cards from a few systems Im retiring Product name Mikrotik RB44Ge Chipset Atheros AR8131/M PCIe 4X Formfactor Full / Half Height half Lenghth i have fullheight brackets on them and Ill try to root out the half height brackets if I can if required Im willing to ship them to Developers / porters if they think they would help them -- Kindest regards, Tom Smyth
Re: Intel I/O Module for Intel Server Boards Up for Grabs (for Free)
Hi Lads that is still up for grabs.. On 31 July 2017 at 12:00, Tom Smyth wrote: > Hello Lads and Ladies, > > If any of you have an Intel Server I have a Copper(RJ45 dual port > 10G I/O module that I cant use (because I only have SFP+ Based > 10G Switches) > Intel AXX10GBTWLIOM Dual 10GB Copper Module > > > (It is for e5 - 4600/ 2600 or 2400) based Intel servers > https://www.intel.com/content/dam/support/us/en/documents/motherboards/server/sb/g30021004_io_module_hardware_specification_r1_4.pdf > > It works as far as I know .. (I Haven't Used it ) > > and maybe it will benefit some of you fine OpenBSD Devs > want it ... Let me know. > Thanks > > Tom Smyth
Intel I/O Module for Intel Server Boards Up for Grabs (for Free)
Hello Lads and Ladies, If any of you have an Intel Server I have a Copper(RJ45 dual port 10G I/O module that I cant use (because I only have SFP+ Based 10G Switches) Intel AXX10GBTWLIOM Dual 10GB Copper Module (It is for e5 - 4600/ 2600 or 2400) based Intel servers https://www.intel.com/content/dam/support/us/en/documents/motherboards/server/sb/g30021004_io_module_hardware_specification_r1_4.pdf It works as far as I know .. (I Haven't Used it ) and maybe it will benefit some of you fine OpenBSD Devs want it ... Let me know. Thanks Tom Smyth
Intel Microcode bug on Xeon e5V2 when hyperthreading enabled
ed by microcode updates issued in early April/2017. Based on this date range, microcode revision 0x5d/0x5e (and higher) for Kaby Lake processors with signatures 0x806e9 and 0x906e9 *might* fix the issue. We do not have confirmation about which microcode revision fixes Kaby Lake at this time. Related processor signatures and microcode revisions: Skylake : 0x406e3, 0x506e3 (fixed in revision 0xb9/0xba and later, public fix in linux microcode 20170511) Skylake : 0x50654 (no information, erratum listed) Kaby Lake : 0x806e9, 0x906e9 (defect still exists in revision 0x48, fix available as a BIOS/UEFI update) References: https://caml.inria.fr/mantis/view.php?id=7452 http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog https://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v6-spec-update.html https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v5-spec-update.html https://www.intel.com/content/www/us/en/products/processors/core/6th-gen-x-series-spec-update.html [1] iucode_tool -S will output your processor signature. This tool is available in the *contrib* repository, package "iucode-tool". -- Henrique Holschuh -- Kindest regards, Tom Smyth
pf.conf Example Suggested Modify to X11 protection
Hello, I had a client that had a service running on TCP port 6001 behind an OpenBSD router the port was blocked because of the X11 firewall Rule that protects X11, I think that the rule (even though it is an example rule) could be made more specific to prevent the example rules from blocking traffic through a Router un-intentionally following rule on line 34 of the example Firewall config /etc/examples/pf.conf # By default, do not permit remote connections to X11 -block return in on ! lo0 proto tcp to port 6000:6010 +block return in on ! lo0 proto tcp to self port 6000:6010 I hope this helps -- Kindest regards, Tom Smyth
Re: OpenBSD 6.0 relayd TLS Loadbalancer failing SSL Lab tests (Cipher Support)
Joel,
Thanks for that ... your mail was most helpful I tried the suggested
setting
"HIGH:!aNULL"
It worked perfect
so the config now looks like this
http protocol https {
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
match request header append "X-Forwarded-Proto" value "https"
match request header set "Connection" value "close"
tls { no tlsv1.0, ciphers "HIGH:!aNULL" }
}
and the tests returned an A grade after that,
Thanks for the detailed follow up information also it is much appreciated,
I owe you a pint or 2 for that :)
Tom smyth
On Thu, Apr 6, 2017 at 11:45 PM, Joel Sing wrote:
> On Thursday 06 April 2017 16:38:26 Tom Smyth wrote:
> > Hello all,
> >
> > I was installing relayd as a loadbalancer (and ssl terminator) on
> > OpenBSD6.0
> > amd64 base install,
> >
> > I used the following configuration for my /etc/relayd.conf file
> >
> > http protocol https {
> > match request header append "X-Forwarded-For" value
> "$REMOTE_ADDR"
> > match request header append "X-Forwarded-By" \
> > value "$SERVER_ADDR:$SERVER_PORT"
> > match request header append "X-Forwarded-Proto" value "https"
> > match request header set "Connection" value "close"
> > tls { no tlsv1.0, ciphers HIGH }
> > }
> >
> > The Site I used to test was
> > https://www.ssllabs.com/ssltest/
> >
> > according to qualys the result for my site was a fail (F)
> > due to the following ciphers being supported by relayd / LibreTLS
>
> The relayd cipher string is passed through to libssl, hence you'll get
> whatever you specify. There are potential use cases for anonymous ciphers
> and
> for various historical reasons OpenSSL includes (almost) everything by
> default. What you want is "HIGH:!aNULL", rather than just "HIGH" which
> includes aNULL (null authentication/anonymous) ciphers.
>
> You can check what ciphers you're actually specifying via openssl(1):
>
> $ openssl ciphers HIGH:aNULL
>
> As an aside, if you did not specify your own ciphers and used the relayd
> defaults, you would get an appropriate/correct configuration.
>
> If you want something that is even more secure use the libtls default of
> "TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE", which will give you TLSv1.2 only
> cipher
> suites with AEAD and PFS.
>
> > TLS_ECDH_anon_WITH_AES_256_CBC_SHA (0xc019) INSECURE 256
> > TLS_ECDH_anon_WITH_AES_128_CBC_SHA (0xc018) INSECURE 128
> > TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA (0xc017) INSECURE 112
> >
> > I was wondering if these ciphers could be disabled by default
> > in the upcoming release (if not already done so) I will investigate
> > selecting ciphers manually to exclude those ciphers in the mean time.
> >
> > Thanks for your Time,
>
>
--
Kindest regards,
Tom Smyth
Mobile: +353 87 6193172
-
PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL
This email contains information which may be confidential or privileged.
The information is intended solely for the use of the individual or entity
named above. If you are not the intended recipient, be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic
transmission in error, please notify me by telephone or by electronic mail
immediately. Any opinions expressed are those of the author, not the
company's .This email does not constitute either offer or acceptance of
any contractually binding agreement. Such offer or acceptance must be
communicated in
writing. You are requested to carry out your own virus check before opening
any attachment. Thomas Smyth accepts no liability for any loss or damage
which may be caused by malicious software or attachments.
OpenBSD 6.0 relayd TLS Loadbalancer failing SSL Lab tests (Cipher Support)
Hello all,
I was installing relayd as a loadbalancer (and ssl terminator) on
OpenBSD6.0
amd64 base install,
I used the following configuration for my /etc/relayd.conf file
http protocol https {
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
match request header append "X-Forwarded-Proto" value "https"
match request header set "Connection" value "close"
tls { no tlsv1.0, ciphers HIGH }
}
The Site I used to test was
https://www.ssllabs.com/ssltest/
according to qualys the result for my site was a fail (F)
due to the following ciphers being supported by relayd / LibreTLS
TLS_ECDH_anon_WITH_AES_256_CBC_SHA (0xc019) INSECURE 256
TLS_ECDH_anon_WITH_AES_128_CBC_SHA (0xc018) INSECURE 128
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA (0xc017) INSECURE 112
I was wondering if these ciphers could be disabled by default
in the upcoming release (if not already done so) I will investigate
selecting ciphers manually to exclude those ciphers in the mean time.
Thanks for your Time,
Re: Is it worth considering changing the installer default offset from 64 to a higher value?
Thanks Stuart, you went further than I Did :)
On Wed, Feb 15, 2017 at 11:39 PM, Stuart Henderson wrote:
> On 2017/02/15 23:22, Tom Smyth wrote:
>> Hello,
>>
>> I have been installing OpenBSD quite a bit in a virtualization
>> environment and the
>> underlying storage has been formatted in 1MB blocks, and most other
>> operating
>> systems have recommended for best performance to align the partition on a 1MB
>> Offset rather than a smaller value.
>>
>> the reasoning behind this is that if you have files that are around
>> than 1MB in size
>> and they are stored in the file system it is likely that they will
>> cross a block boundary and while OpenBSD only wants to read the file,
>> the underlying storage system
>> will have to retrieve 2 blocks and this is wasteful on resources.
>>
>> If the offset was set to 2048 sectors (at 1MB in my case) the disk
>> performance of OpenBSD on my underlying system would be improved.
>> I have been setting the value of the initial offset to 2048 and I have
>> used exact sizes in-terms of sector count to keep my subsequent
>> partitions aligned with the 1M offset,
>> I have not noticed any ill affect on my installs (for the past 2
>> years) and I think it
>> would be worth considering this as a suggested default when installing
>> OpenBSD
>>
>> Any comments suggestions insights welcome, as my experience on
>> virtualization
>> has been Vmware Based. But I would imagine most modern enterprise
>> storage systems are using larger block sizes... and by setting it to a
>> 1MB or perhaps a larger value (as long as the value ends on a 1MB
>> Boundary eg 2MB or 4MB) depending on other users experience
>>
>
> I've been doing similar for installs on SSDs with their large erase blocks.
> And this is common on other OS these days.
>
> As you say, it's not just the starting point of the OpenBSD part of the disk,
> care must be taken with the disklabel partitions too.
>
> I have an old tree that has this diff in, I don't remember if it was quite
> enough for disklabel as-is, but it might be enough of a starting point to
> save time tracking things down.
>
> Index: fdisk/mbr.c
> ===
> RCS file: /cvs/src/sbin/fdisk/mbr.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 mbr.c
> --- fdisk/mbr.c 1 Sep 2016 16:17:46 - 1.67
> +++ fdisk/mbr.c 15 Feb 2017 23:36:29 -
> @@ -144,8 +144,11 @@ MBR_init(struct mbr *mbr)
> }
> #endif
>
> - /* Start OpenBSD MBR partition on a power of 2 block number. */
> - i = 1;
> + /*
> +* Start OpenBSD MBR partition on a power of 2 block number
> +* with a minimum 2048-block alignment.
> +*/
> + i = 2048;
> while (i < DL_SECTOBLK(&dl, mbr->part[3].bs))
> i *= 2;
> adj = DL_BLKTOSEC(&dl, i) - mbr->part[3].bs;
> Index: disklabel/editor.c
> ===
> RCS file: /cvs/src/sbin/disklabel/editor.c,v
> retrieving revision 1.304
> diff -u -p -r1.304 editor.c
> --- disklabel/editor.c 6 Oct 2016 13:02:31 - 1.304
> +++ disklabel/editor.c 15 Feb 2017 23:36:29 -
> @@ -2092,8 +2092,7 @@ align:
> orig_size = DL_GETPSIZE(pp);
> orig_offset = DL_GETPOFFSET(pp);
>
> - bsize = (DISKLABELV1_FFS_FRAG(pp->p_fragblock) *
> - DISKLABELV1_FFS_FSIZE(pp->p_fragblock)) / lp->d_secsize;
> + bsize = 2048;
> if (DL_GETPOFFSET(pp) != starting_sector) {
> /* Can't change offset of first partition. */
> adj = bsize - (DL_GETPOFFSET(pp) % bsize);
>
Is it worth considering changing the installer default offset from 64 to a higher value?
Hello, I have been installing OpenBSD quite a bit in a virtualization environment and the underlying storage has been formatted in 1MB blocks, and most other operating systems have recommended for best performance to align the partition on a 1MB Offset rather than a smaller value. the reasoning behind this is that if you have files that are around than 1MB in size and they are stored in the file system it is likely that they will cross a block boundary and while OpenBSD only wants to read the file, the underlying storage system will have to retrieve 2 blocks and this is wasteful on resources. If the offset was set to 2048 sectors (at 1MB in my case) the disk performance of OpenBSD on my underlying system would be improved. I have been setting the value of the initial offset to 2048 and I have used exact sizes in-terms of sector count to keep my subsequent partitions aligned with the 1M offset, I have not noticed any ill affect on my installs (for the past 2 years) and I think it would be worth considering this as a suggested default when installing OpenBSD Any comments suggestions insights welcome, as my experience on virtualization has been Vmware Based. But I would imagine most modern enterprise storage systems are using larger block sizes... and by setting it to a 1MB or perhaps a larger value (as long as the value ends on a 1MB Boundary eg 2MB or 4MB) depending on other users experience Thanks for your Time, Tom Smyth
OpenBSD or OpenBSD projects Mirroring/ hosting in Ireland ?
Hi Lads, What requirements do you have for mirrors, I would like to help, we have 2 upstream providers on... and multiple peerings on our local exchange.. If you think this is useful or helpful... you are welcome to talk about your requirements and I will try to deliver on those.. -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 - PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments.
Re: Microsoft Now OpenBSD Foundation Gold Contributor
Congratulatons Lads, On your new sponsorship It is good news for the OpenBSD usercommunity, great for funding of existing great initiatives or other new initiatives, It is good news for Microsoft users if Microsoft chooses to implement great stable software such as open SSH and Libre SSL in their own product offerings, Microsoft users can benefit making software from the good quality audited code that you guys produce. I also think it is cool that Microsoft supported the foundation in such public manner... it is cool that they recognise in some way your contibution to computer users the world over... and it is cool that they showed it in cash :) PS I do hope they use Open SSH in Power Shell, :) and use Libre SSL in software that presents SSL encrytped Services ... As a user of both Microsoft and Open BSD ( I use each in very differing circumstances) Im pleased with the news... best of luck to the core developers and the guys working hard in the open BSD foundation keep up the great work, well done Sorry for writing this on Tech Mailing list :/ but felt I had to reply... -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 - PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments.
