Re: rpki-client: check fflush on output files
On Fri, Mar 06 2020, "Theo de Raadt" wrote:
>> Jeremie Courreges-Anglas wrote:
>> >
>> >
>> > Checking the return value of fprintf is good but not enough to ensure
>> > that data has properly been written to the file without an error. To do
>> > that we can use fflush(3) in a single place.
[redacted]
>> How about checking the return value of fclose() in output_finish() instead?
> Oh you want to reach the error-reporting code...
And the cleanup-on-error code. Doing it here looks more appealing than
adding
if (fflush(out) != 0)
return -1;
at the end of all the output_* functions.
If you're careful about write errors you can avoid feeding an
incomplete/garbage file to your BGP daemon. The code was already
careful, but did not account for buffering. This is what this patch
tries to address.
>> > Build-tested only. ok?
>> >
>> > Bonus: in output_finish(), "out = NULL;" is pointless, so zap it.
>> > I suspect it's a remnant from a time where the output FILE * was
>> > a global. That would be a separate commit.
Diff below again for convenience,
Index: output.c
===
RCS file: /d/cvs/src/usr.sbin/rpki-client/output.c,v
retrieving revision 1.6
diff -u -p -p -u -r1.6 output.c
--- output.c6 Mar 2020 17:36:42 - 1.6
+++ output.c6 Mar 2020 23:04:18 -
@@ -71,7 +71,7 @@ outputfiles(struct vrp_tree *v)
rc = 1;
continue;
}
- if ((*outputs[i].fn)(fout, v) != 0) {
+ if ((*outputs[i].fn)(fout, v) != 0 || fflush(fout) != 0) {
logx("output for %s format failed", outputs[i].name);
fclose(fout);
output_cleantmp();
@@ -112,8 +112,6 @@ void
output_finish(FILE *out)
{
fclose(out);
- out = NULL;
-
rename(output_tmpname, output_name);
output_tmpname[0] = '\0';
}
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: arm64 rpi3b install method
On Fri, Mar 06, 2020 at 11:29:57PM +, Stuart Henderson wrote: > I've finally managed to get openbsd installed on an rpi3b (need > something to run signify/pkg_sign and this is what I have). Thought I'd > write up the install method because there are no useful docs at the > moment and it's a bit fiddly. (Note that only rpi3b works - 3b+ has no > network/usb, the 32-bit ones are unsupported, 4 is unsupported). > > - boot linux, set the otp bit to permanently enable booting from usb (set > "program_usb_boot_mode=1" in /boot/config.txt and reboot) You don't need to boot linux for that. Just boot with rpi firmware. 3b+ can boot off usb by default. And if you don't want to blow the fuse the sd card can be left in and boot_targets set in the U-Boot environment as mentioned on arm64.html. > > - write miniroot64.fs to an SD card (I tried 6.3 up to 6.6 and -current, > that's the only one where I get any console output) Are you using pins 8 (tx) and 10 (rx)? With the Ethernet port facing towards you numbering is 1 2 3 4 5 6 7 8 9 10 After 6.6 the uart is now the more capable pl011 by default. > > - write whatever version miniroot to a USB stick (I have a -current one) Above you said the 6.4 miniroot, which is it? > > - ttl cable on standard pins on the pinout.xyz connector 115200 > > - boot it. if you just leave it to itself you get > > ## Starting EFI application at 0008 ... > >> OpenBSD/arm64 BOOTAA64 0.13 > boot> > kcannot open sd0a:/etc/random.seed: No such file or directory > booting sd0a:/bsd: 2696864+410652+8951776+739752=0xf3e4c8 > "Synchronous Abort" handler, esr 0x0200 > > instead you have to do "machine exit" (thanks aalm for the tip) > and then it boots the installer. U-Boot packages on build machines are infrequently updated and going by your dmesg it is still 2019.10. Does anything change if you take the rpi3 u-boot.bin from u-boot-aarch64 2020.01 and replace it? > > ## Starting EFI application at 0008 ... > >> OpenBSD/arm64 BOOTAA64 0.13 > boot> machine exit > ## Application terminated, r = 0 > EFI LOAD FAILED: continuing... > > Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Fit > Type: Removable Hard Disk > Capacity: 29340.0 MB = 28.6 GB (60088320 x 512) > ... is now current device > Scanning usb 0:1... > Found EFI removable media binary efi/boot/bootaa64.efi > FDT memrsv map 0: Failed to add to map > 168758 bytes read in 112 ms (1.4 MiB/s) > FDT memrsv map 0: Failed to add to map > ## Starting EFI application at 0008 ... > disks: sd0* sd1 > >> OpenBSD/arm64 BOOTAA64 0.20 > boot> > cannot open sd0a:/etc/random.seed: No such file or directory > booting sd0a:/bsd: 2258968+636456+8767192+739512 > [182308+109+529152+204440]=0xff0d80 > type 0x0 pa 0x0 va 0x0 pages 0x1 attr 0x8 > type 0x7 pa 0x1000 va 0x0 pages 0x1ff attr 0x8 > [...] > > after it has installed, remove the SD and just leave the USB drive, > cross fingers, and hopefully it will boot automatically. > > dmesg currently looks like: > > OpenBSD 6.6-current (GENERIC.MP) #486: Thu Mar 5 23:22:04 MST 2020 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 958996480 (914MB) > avail mem = 899473408 (857MB) > mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2 > cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 > cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu0: 512KB 64b/line 16-way L2 cache > efi0 at mainbus0: UEFI 2.8 > efi0: Das U-Boot rev 0x20191000 > apm0 at mainbus0 > simplefb0 at mainbus0: 656x416, 32bpp > wsdisplay0 at simplefb0 mux 1 > wsdisplay0: screen 0-5 added (std, vt100 emulation) > "system" at mainbus0 not configured > "axi" at mainbus0 not configured > "thermal-zones" at mainbus0 not configured > simplebus0 at mainbus0: "soc" > "dma" at simplebus0 not configured > bcmdog0 at simplebus0 > "cprman" at simplebus0 not configured > bcmrng0 at simplebus0 > "mailbox" at simplebus0 not configured > "gpio" at simplebus0 not configured > pluart0 at simplebus0: console > "mmc" at simplebus0 not configured > "dsi" at simplebus0 not configured > bcmaux0 at simplebus0 > dwctwo0 at simplebus0 > bcmintc0 at simplebus0 > bcmtemp0 at simplebus0 > "local_intc" at simplebus0 not configured > "mmcnr" at simplebus0 not configured > simplebus1 at simplebus0: "firmware" > "expgpio" at simplebus1 not configured > "power" at simplebus0 not configured > "mailbox" at simplebus0 not configured > "gpiomem" at simplebus0 not configured > "fb" at simplebus0 not configured > "vcsm" at simplebus0 not configured > "virtgpio" at simplebus0 not configured > simplebus2 at mainbus0: "clocks" > "clock" at simplebus2 not configured > "clock" at simplebus2 not configured > "phy" at mainbus0 not configured > "arm-pmu" at mainbus0 not configured > agtimer0 at mainbus0: tick rate 19200 KHz > "__overrides__" at mainbus0 not configured > "leds" at mainbus0 not configured > "fixedregulator_3v3" at mainbus0 not configured > "fixedregulator_5v0"
Re: arm64 rpi3b install method
Thanks for your write-up, Stuart! I just wanted to add that people can get it working on the RPi 3B+ with some extra work: - Put the package sets on the installation drive since network access doesn't exist by default as you pointed out. - Buy a supported USB network interface. I've used a wireless one for awhile and needed to download the necessary firmware from a mirror. I waited until after first boot and used fw_update(1) to install the firmware I downloaded to my drive. I also recently acquired a USB wired ethernet interface that should work with it during installation in theory, but I haven't tested it. I've had weird USB bugs with the RPi 3B+ that I've been meaning to report for awhile but haven't had the time to completely investigate them. As you implied, I think most people should default to the model you have to get the best support. Tim
Re: arm64 rpi3b install method
On 2020/03/06 23:29, Stuart Henderson wrote: > (need > something to run signify/pkg_sign and this is what I have). oh, that's not going to work anyway. seabios still needs gcc/ld.bfd (and I guess cross-compiling is going to be a pain).
arm64 rpi3b install method
I've finally managed to get openbsd installed on an rpi3b (need something to run signify/pkg_sign and this is what I have). Thought I'd write up the install method because there are no useful docs at the moment and it's a bit fiddly. (Note that only rpi3b works - 3b+ has no network/usb, the 32-bit ones are unsupported, 4 is unsupported). - boot linux, set the otp bit to permanently enable booting from usb (set "program_usb_boot_mode=1" in /boot/config.txt and reboot) - write miniroot64.fs to an SD card (I tried 6.3 up to 6.6 and -current, that's the only one where I get any console output) - write whatever version miniroot to a USB stick (I have a -current one) - ttl cable on standard pins on the pinout.xyz connector 115200 - boot it. if you just leave it to itself you get ## Starting EFI application at 0008 ... >> OpenBSD/arm64 BOOTAA64 0.13 boot> kcannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:/bsd: 2696864+410652+8951776+739752=0xf3e4c8 "Synchronous Abort" handler, esr 0x0200 instead you have to do "machine exit" (thanks aalm for the tip) and then it boots the installer. ## Starting EFI application at 0008 ... >> OpenBSD/arm64 BOOTAA64 0.13 boot> machine exit ## Application terminated, r = 0 EFI LOAD FAILED: continuing... Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra Fit Type: Removable Hard Disk Capacity: 29340.0 MB = 28.6 GB (60088320 x 512) ... is now current device Scanning usb 0:1... Found EFI removable media binary efi/boot/bootaa64.efi FDT memrsv map 0: Failed to add to map 168758 bytes read in 112 ms (1.4 MiB/s) FDT memrsv map 0: Failed to add to map ## Starting EFI application at 0008 ... disks: sd0* sd1 >> OpenBSD/arm64 BOOTAA64 0.20 boot> cannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:/bsd: 2258968+636456+8767192+739512 [182308+109+529152+204440]=0xff0d80 type 0x0 pa 0x0 va 0x0 pages 0x1 attr 0x8 type 0x7 pa 0x1000 va 0x0 pages 0x1ff attr 0x8 [...] after it has installed, remove the SD and just leave the USB drive, cross fingers, and hopefully it will boot automatically. dmesg currently looks like: OpenBSD 6.6-current (GENERIC.MP) #486: Thu Mar 5 23:22:04 MST 2020 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 958996480 (914MB) avail mem = 899473408 (857MB) mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20191000 apm0 at mainbus0 simplefb0 at mainbus0: 656x416, 32bpp wsdisplay0 at simplefb0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) "system" at mainbus0 not configured "axi" at mainbus0 not configured "thermal-zones" at mainbus0 not configured simplebus0 at mainbus0: "soc" "dma" at simplebus0 not configured bcmdog0 at simplebus0 "cprman" at simplebus0 not configured bcmrng0 at simplebus0 "mailbox" at simplebus0 not configured "gpio" at simplebus0 not configured pluart0 at simplebus0: console "mmc" at simplebus0 not configured "dsi" at simplebus0 not configured bcmaux0 at simplebus0 dwctwo0 at simplebus0 bcmintc0 at simplebus0 bcmtemp0 at simplebus0 "local_intc" at simplebus0 not configured "mmcnr" at simplebus0 not configured simplebus1 at simplebus0: "firmware" "expgpio" at simplebus1 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "virtgpio" at simplebus0 not configured simplebus2 at mainbus0: "clocks" "clock" at simplebus2 not configured "clock" at simplebus2 not configured "phy" at mainbus0 not configured "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: tick rate 19200 KHz "__overrides__" at mainbus0 not configured "leds" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured "__symbols__" at mainbus0 not configured cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 512KB 64b/line 16-way L2 cache cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu2: 512KB 64b/line 16-way L2 cache cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu3: 512KB 64b/line 16-way L2 cache usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev 2.00/1.00 addr 1 uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems product 0x9514" rev 2.00/2.00 addr 2 smsc0 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems SMSC9512/14" rev 2.00/2.00 addr 3 smsc0: address b8:27:eb:5d:c0:5e ukphy0 at smsc0 phy 1: Generic IEEE 802.3u media interf
Re: diff: init efifb even if VGA is probed.
On Sun, Mar 1, 2020 at 10:41 PM YASUOKA Masahiko wrote: > > Hi, > > The problems you are pointing seem to be the same problem. > > > I'll try to test this diff next week if I can schedule some downtime. > > Test is appreciated. > > Also I'd like to know the result of > > hexdump -C /var/db/acpi/FACP.1 > > when "Load Legacy Video Option ROM" setting is disabled. I just tested a -current kernel built yesterday with that diff (your post on Feb. 20), but unfortunately it does not fix the issue on my hardware. As before, if "Load Legacy Video Option ROM" is disabled, output is squished to a purple line and when devices are initialized, vga1 is the wsdisplay0 device: vga1 at pci7 dev 0 function 0 "Matrox MGA G200eR" rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) efifb0 at mainbus0: 1280x1024, 32bpp wsdisplay at efifb0 not configured vs. with the legacy video ROM setting: "Matrox MGA G200eR" rev 0x01 at pci7 dev 0 function 0 not configured efifb0 at mainbus0: 1024x768, 32bpp wsdisplay0 at efifb0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) I'm using a serial console, if it matters. Hmm... I just noticed that with the legacy ROM setting disabled, both wsdisplay0 at vga1 mux 1/wskbd0 at ukbd0 *and* com1 claim to be the console. With the setting enabled (and efifb working), only com1 is listed as console. I haven't tried any of the later diffs as I'm not sure which are still recommended. The FACP.1 table does not change when the "Load Legacy Video Option ROM" setting is changed. Here is its hexdump: andrew@gsc-lb1:~/acpidump$ hexdump -C legacy-2.8.1/FACP.1 46 41 43 50 0c 01 00 00 05 62 44 45 4c 4c 20 20 |FACP.bDELL | 0010 50 45 5f 53 43 33 20 20 00 00 00 00 44 45 4c 4c |PE_SC3 DELL| 0020 01 00 00 00 00 30 f8 8e 00 b0 fc 8e 00 04 09 00 |.0..| 0030 b2 00 00 00 f0 f1 f2 00 00 18 00 00 00 00 00 00 || 0040 04 18 00 00 00 00 00 00 50 18 00 00 08 18 00 00 |P...| 0050 80 18 00 00 00 00 00 00 04 02 01 04 20 00 10 00 | ...| 0060 65 00 e9 03 00 00 00 00 01 03 0d 00 32 11 00 00 |e...2...| 0070 a5 86 00 00 01 08 00 01 f9 0c 00 00 00 00 00 00 || 0080 06 00 00 00 00 00 00 00 00 00 00 00 00 b0 fc 8e || 0090 00 00 00 00 01 20 00 02 00 18 00 00 00 00 00 00 |. ..| 00a0 01 00 00 02 00 00 00 00 00 00 00 00 01 10 00 02 || 00b0 04 18 00 00 00 00 00 00 01 00 00 02 00 00 00 00 || 00c0 00 00 00 00 01 08 00 01 50 18 00 00 00 00 00 00 |P...| 00d0 01 20 00 03 08 18 00 00 00 00 00 00 01 00 00 01 |. ..| 00e0 80 18 00 00 00 00 00 00 01 00 00 01 00 00 00 00 || 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0100 00 00 00 00 00 00 00 00 00 00 00 00 || 010c The only ACPI change made by toggling that option is the DMAR.25 table. Here are both versions: Legacy Video ROM enabled: 44 4d 41 52 90 00 00 00 01 83 49 4e 54 45 4c 20 |DMAR..INTEL | 0010 47 4e 4c 52 00 00 00 00 01 00 00 00 49 4e 54 4c |GNLRINTL| 0020 01 00 00 00 26 01 00 00 00 00 00 00 00 00 00 00 |&...| 0030 00 00 20 00 01 00 00 00 00 00 d9 fe 00 00 00 00 |.. .| 0040 03 08 00 00 02 f0 1f 00 04 08 00 00 00 00 1f 00 || 0050 01 00 20 00 00 00 00 00 00 b0 ba 7c 00 00 00 00 |.. || 0060 ff 2f bb 84 00 00 00 00 01 08 00 00 00 01 00 00 |./..| 0070 01 00 20 00 00 00 00 00 00 10 31 8e 00 00 00 00 |.. ...1.| 0080 ff 0f 33 8e 00 00 00 00 01 08 00 00 00 00 14 00 |..3.| 0090 and disabled: 44 4d 41 52 90 00 00 00 01 05 49 4e 54 45 4c 20 |DMAR..INTEL | 0010 47 4e 4c 52 00 00 00 00 01 00 00 00 49 4e 54 4c |GNLRINTL| 0020 01 00 00 00 26 01 00 00 00 00 00 00 00 00 00 00 |&...| 0030 00 00 20 00 01 00 00 00 00 00 d9 fe 00 00 00 00 |.. .| 0040 03 08 00 00 02 f0 1f 00 04 08 00 00 00 00 1f 00 || 0050 01 00 20 00 00 00 00 00 00 c0 e9 7c 00 00 00 00 |.. || 0060 ff 3f ea 84 00 00 00 00 01 08 00 00 00 01 00 00 |.?..| 0070 01 00 20 00 00 00 00 00 00 10 31 8e 00 00 00 00 |.. ...1.| 0080 ff 0f 33 8e 00 00 00 00 01 08 00 00 00 00 14 00 |..3.| 0090 I've attached full dmesgs for both legacy video ROM enabled and disabled. The system is currently on 6.5, but the efifb/wsdisplay/etc. messages are the same in -current. Thanks for trying to figure this out! -Andrew OpenBSD 6.5 (GENERIC.MP) #8: Tue Jan 14 23:16:33 MST 2020 t...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8394772480 (8005MB) avail
Re: regress: bgpd: config: Fix attribute ordering
On Fri, Mar 06, 2020 at 06:51:16PM +0100, Sebastian Benoit wrote:
> I dont see that here.
> Sure that you have an up-to-date tree?
> And no diff in there?
I think the problem is big-endian vs little-endian.
I need to think about how and if this should be fixed.
> Klemens Nanni(k...@openbsd.org) on 2020.03.05 23:39:20 +0100:
> >
> > I ran bgpd to test diffs and stumbled across what looks like simple
> > disorder in the config checks.
> >
> > bgpd must have changed in how it orders attributes within `set { ... }'
> > blocks; breaking the sets into multiple lines and diffing line-wise
> > instead of word-wise shows that the printed config indeed only differs
> > in the way set attributes from the config appear in bgpd output.
> >
> > Still, I'd like any of the bgpd hackers to verify before I "fix" regress.
> >
> > OK?
> >
> >
> > Index: regress/usr.sbin/bgpd/config/bgpd.conf.10.ok
> > ===
> > RCS file: /cvs/src/regress/usr.sbin/bgpd/config/bgpd.conf.10.ok,v
> > retrieving revision 1.6
> > diff -u -p -r1.6 bgpd.conf.10.ok
> > --- regress/usr.sbin/bgpd/config/bgpd.conf.10.ok17 Jul 2019 10:27:50
> > - 1.6
> > +++ regress/usr.sbin/bgpd/config/bgpd.conf.10.ok5 Mar 2020 22:32:53
> > -
> > @@ -40,4 +40,4 @@ match from any large-community 1234:5678
> > match from any large-community 1234:5678:1 large-community 1234:5678:2
> > large-community 1234:5678:3
> > match from any community 1234:1 large-community 1234:5678:1
> > match from any large-community 1234:5678:1 community 1234:1
> > -match from any set { community delete 1234:5678 community delete 1234:*
> > community delete *:5678 community delete local-as:5678 community delete
> > local-as:neighbor-as large-community delete 1234:15:5678 large-community
> > delete *:15:5678 large-community delete local-as:15:5678 large-community
> > delete local-as:15:* large-community delete local-as:15:neighbor-as
> > large-community delete local-as:*:* community 1234:5678 community
> > local-as:5678 community local-as:neighbor-as large-community 1234:15:5678
> > large-community local-as:15:5678 large-community local-as:15:neighbor-as }
> > +match from any set { community delete 1234:5678 large-community delete
> > 1234:15:5678 community delete *:5678 large-community delete *:15:5678
> > community delete local-as:5678 large-community delete local-as:15:5678
> > community delete 1234:* community delete local-as:neighbor-as
> > large-community delete local-as:15:* large-community delete local-as:*:*
> > large-community delete local-as:15:neighbor-as community 1234:5678
> > large-community 1234:15:5678 community local-as:5678 large-community
> > local-as:15:5678 community local-as:neighbor-as large-community
> > local-as:15:neighbor-as }
> > Index: regress/usr.sbin/bgpd/config/bgpd.conf.11.ok
> > ===
> > RCS file: /cvs/src/regress/usr.sbin/bgpd/config/bgpd.conf.11.ok,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 bgpd.conf.11.ok
> > --- regress/usr.sbin/bgpd/config/bgpd.conf.11.ok17 Jul 2019 10:27:50
> > - 1.5
> > +++ regress/usr.sbin/bgpd/config/bgpd.conf.11.ok5 Mar 2020 22:35:04
> > -
> > @@ -33,7 +33,7 @@ match from any ext-community ovs invalid
> > match from any ext-community ovs not-found
> > match from any ext-community rt 64496:201 ext-community soo 64496:202
> > match from any ext-community rt 64496:301 ext-community soo 420001:302
> > ext-community odi 127.0.0.1:303
> > -match from any set { ext-community delete ovs valid ext-community delete
> > odi 127.0.0.1:6003 ext-community delete soo 420001:6002 ext-community
> > delete ort 0x123456789abf ext-community delete rt 64496:6001 ext-community
> > ovs valid ext-community odi 127.0.0.1:5003 ext-community soo
> > 420001:5002 ext-community ort 0x123456789abc ext-community rt
> > 64496:5001 }
> > +match from any set { ext-community delete ovs valid ext-community delete
> > ort 0x123456789abf ext-community delete rt 64496:6001 ext-community delete
> > odi 127.0.0.1:6003 ext-community delete soo 420001:6002 ext-community
> > ovs valid ext-community ort 0x123456789abc ext-community rt 64496:5001
> > ext-community odi 127.0.0.1:5003 ext-community soo 420001:5002 }
> > match from any ext-community * *
> > match from any ext-community rt *
> > match from any ext-community soo *
> > @@ -47,7 +47,7 @@ match from any ext-community rt 127.0.0.
> > match from any ext-community soo 64496:*
> > match from any ext-community soo 420001:*
> > match from any ext-community soo 127.0.0.1:*
> > -match from any set { ext-community delete odi 127.0.0.1:* ext-community
> > delete soo 420001:* ext-community delete rt 64496:* ext-community
> > delete mac-mob * ext-community delete ovs * ext-community delete rt *
> > ext-community delete soo * ext-community delete odi * ext-community delet
Re: ldapd: fix return values for illegal passwords
Hi,
sorry, I simply forgot ldap_auth_sasl.
LDAP_OTHER is a good return code for imsg failure and I really like the
idea of using the LDAP return codes right away instead of the extra
mapping.
Your patch however doesn't work for SASL authentication (and
ldapsearch gives some strange messages), because
sent_auth_request *never* returns LDAP_SUCCESS (this happens via imsg)
but LDAP_SASL_BIND_IN_PROGRESS. See comment inline.
After changing the one line bind with SASL works, too.
All tests using ldap_auth_simple worked ok.
Best regards
Robert
On Tue, 3 Mar 2020 20:33:41 +0100
Martijn van Duren wrote:
> I agree that returning Operations Error is the wrong return value.
> I don't agree that we should *always* return invalidCredentials,
> however, acting like the other LDAP servers on an invalid entry seems
> reasonable to me. One option I do see is if we can't create an imsg
> to the parent process handling a BSDAUTH request, this clearly is an
> internal error.
>
> Also, you missed the case for ldap_auth_sasl.
>
> Diff below should change this, but it's compile tested only.
>
> martijn@
>
> On 3/1/20 5:24 PM, Robert Klein wrote:
> > Hi,
> >
> > When trying to bind to ldapd using a dn which has an invalid
> > userPassword entry, e.eg. a “defective” SHA valus like “{SHA}alpha”,
> > ldapd currently returns 1 (Operations Error).
> >
> > The patch below changes this to 49 (Invalid Credentials).
> >
> > There are basically two reasons for this:
> >
> > 1. The userPassword is a multi-valued attribute, i.e. there can be
> > more than one in an ldap entry. Now when you have a valid and a
> > defective entry and the binding user supplies a password which does
> > not match the valid entry you get different results whether the
> > defective entry comes last (return value 1) or not (return value
> > 49). When the supplied password matches the valid entry the bind
> > succeeds independent of order.
> >
> >A change to return value 49 gets consistent results.
> >
> >For a single userPassword entry 49 also is not wrong, as the
> > supplied password still doesn't match the entry (even if it is
> > defective).
> >
> > 2. RFC 4511 defines the result code “Operations Error” as follows:
> >
> > “operationsError (1)
> >
> > Indicates that the operation is not properly sequenced
> > with relation to other operations (of same or different type).
> >
> > For example, this code is returned if the client attempts
> > to StartTLS [RFC4346] while there are other uncompleted
> > operations or if a TLS layer was already installed.”
> >
> >A defective password entry in no way is an operations error of
> > the ldapd server. Also I don't think it is the server's job to
> > take care of the correctness of password entries. There is no
> > provision in the LDAP RFCs to stop one from entering an incorrect
> > entry. I checked this with other directory servers: 389, apache
> > ds, and openldap. All three accept incorrect entries and all three
> > return 49 (Invalid Credentials) on bind attempts.
> >
> > Best regards
> > Robert
> >
> >
> Index: auth.c
> ===
> RCS file: /cvs/src/usr.sbin/ldapd/auth.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 auth.c
> --- auth.c24 Oct 2019 12:39:26 - 1.14
> +++ auth.c3 Mar 2020 19:31:41 -
> @@ -179,33 +179,34 @@ send_auth_request(struct request *req, c
> const char *password)
> {
> struct auth_req auth_req;
> + int ret = LDAP_SASL_BIND_IN_PROGRESS;
>
> memset(&auth_req, 0, sizeof(auth_req));
> if (strlcpy(auth_req.name, username,
> - sizeof(auth_req.name)) >= sizeof(auth_req.name))
> + sizeof(auth_req.name)) >= sizeof(auth_req.name)) {
> + ret = LDAP_INVALID_CREDENTIALS;
> goto fail;
> + }
> if (strlcpy(auth_req.password, password,
> - sizeof(auth_req.password)) >= sizeof(auth_req.password))
> + sizeof(auth_req.password)) >= sizeof(auth_req.password))
> {
> + ret = LDAP_INVALID_CREDENTIALS;
> goto fail;
> + }
> auth_req.fd = req->conn->fd;
> auth_req.msgid = req->msgid;
>
> if (imsgev_compose(iev_ldapd, IMSG_LDAPD_AUTH, 0, 0, -1,
> &auth_req,
> - sizeof(auth_req)) == -1)
> + sizeof(auth_req)) == -1) {
> + ret = LDAP_OTHER;
> goto fail;
> + }
>
> req->conn->bind_req = req;
> - return 0;
> -
> fail:
> memset(&auth_req, 0, sizeof(auth_req));
> - return -1;
> + return ret;
> }
>
> -/*
> - * Check password. Returns 1 if password matches, 2 if password
> matching
> - * is in progress, 0 on mismatch and -1 on error.
> - */
> static int
> check_password(struct request *req, const char *stored_passwd,
> const char *passwd)
> @@ -218,37 +219,39 @@ check_password(struct request *req, cons
> int sz;
Re: rpki-client: check fflush on output files
Oh you want to reach the error-reporting code...
> How about checking the return value of fclose() in output_finish() instead?
>
> Jeremie Courreges-Anglas wrote:
> >
> >
> > Checking the return value of fprintf is good but not enough to ensure
> > that data has properly been written to the file without an error. To do
> > that we can use fflush(3) in a single place.
> >
> > Build-tested only. ok?
> >
> > Bonus: in output_finish(), "out = NULL;" is pointless, so zap it.
> > I suspect it's a remnant from a time where the output FILE * was
> > a global. That would be a separate commit.
> >
> >
> > Index: output.c
> > ===
> > RCS file: /d/cvs/src/usr.sbin/rpki-client/output.c,v
> > retrieving revision 1.6
> > diff -u -p -p -u -r1.6 output.c
> > --- output.c6 Mar 2020 17:36:42 - 1.6
> > +++ output.c6 Mar 2020 19:09:13 -
> > @@ -71,7 +71,7 @@ outputfiles(struct vrp_tree *v)
> > rc = 1;
> > continue;
> > }
> > - if ((*outputs[i].fn)(fout, v) != 0) {
> > + if ((*outputs[i].fn)(fout, v) != 0 || fflush(fout) != 0) {
> > logx("output for %s format failed", outputs[i].name);
> > fclose(fout);
> > output_cleantmp();
> > @@ -112,8 +112,6 @@ void
> > output_finish(FILE *out)
> > {
> > fclose(out);
> > - out = NULL;
> > -
> > rename(output_tmpname, output_name);
> > output_tmpname[0] = '\0';
> > }
> >
> >
> >
> > --
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> >
>
Re: rpki-client: check fflush on output files
How about checking the return value of fclose() in output_finish() instead?
Jeremie Courreges-Anglas wrote:
>
>
> Checking the return value of fprintf is good but not enough to ensure
> that data has properly been written to the file without an error. To do
> that we can use fflush(3) in a single place.
>
> Build-tested only. ok?
>
> Bonus: in output_finish(), "out = NULL;" is pointless, so zap it.
> I suspect it's a remnant from a time where the output FILE * was
> a global. That would be a separate commit.
>
>
> Index: output.c
> ===
> RCS file: /d/cvs/src/usr.sbin/rpki-client/output.c,v
> retrieving revision 1.6
> diff -u -p -p -u -r1.6 output.c
> --- output.c 6 Mar 2020 17:36:42 - 1.6
> +++ output.c 6 Mar 2020 19:09:13 -
> @@ -71,7 +71,7 @@ outputfiles(struct vrp_tree *v)
> rc = 1;
> continue;
> }
> - if ((*outputs[i].fn)(fout, v) != 0) {
> + if ((*outputs[i].fn)(fout, v) != 0 || fflush(fout) != 0) {
> logx("output for %s format failed", outputs[i].name);
> fclose(fout);
> output_cleantmp();
> @@ -112,8 +112,6 @@ void
> output_finish(FILE *out)
> {
> fclose(out);
> - out = NULL;
> -
> rename(output_tmpname, output_name);
> output_tmpname[0] = '\0';
> }
>
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
rpki-client: check fflush on output files
Checking the return value of fprintf is good but not enough to ensure
that data has properly been written to the file without an error. To do
that we can use fflush(3) in a single place.
Build-tested only. ok?
Bonus: in output_finish(), "out = NULL;" is pointless, so zap it.
I suspect it's a remnant from a time where the output FILE * was
a global. That would be a separate commit.
Index: output.c
===
RCS file: /d/cvs/src/usr.sbin/rpki-client/output.c,v
retrieving revision 1.6
diff -u -p -p -u -r1.6 output.c
--- output.c6 Mar 2020 17:36:42 - 1.6
+++ output.c6 Mar 2020 19:09:13 -
@@ -71,7 +71,7 @@ outputfiles(struct vrp_tree *v)
rc = 1;
continue;
}
- if ((*outputs[i].fn)(fout, v) != 0) {
+ if ((*outputs[i].fn)(fout, v) != 0 || fflush(fout) != 0) {
logx("output for %s format failed", outputs[i].name);
fclose(fout);
output_cleantmp();
@@ -112,8 +112,6 @@ void
output_finish(FILE *out)
{
fclose(out);
- out = NULL;
-
rename(output_tmpname, output_name);
output_tmpname[0] = '\0';
}
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: BIRD 1.x/2.x support at rpki-client
On Fri, Mar 06 2020, Sebastian Benoit wrote: > Job Snijders(j...@openbsd.org) on 2020.03.06 17:31:13 +: >> I have a small suggestion, in some deployments I saw the convention to >> name it as following so it is clear the data came from user provided >> data rather than internal bird structures >> >> I tested Benno's patch against BIRD 1.6.6 - wfm. > > thanks. > > I did not commit this bit, and i have not substantiated opinion on it. > If thats how bird users do it, commit it ;) I guess the manpage needs an update (-T tablename). >> >> Index: main.c >> === >> RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v >> retrieving revision 1.58 >> diff -u -p -r1.58 main.c >> --- main.c 11 Feb 2020 18:41:39 - 1.58 >> +++ main.c 6 Mar 2020 17:25:56 - >> @@ -156,7 +156,7 @@ static void build_chain(const struct aut >> static void build_crls(const struct auth *, struct crl_tree *, >> STACK_OF(X509_CRL) **); >> >> -const char *bird_tablename = "roa"; >> +const char *bird_tablename = "ROAS"; >> >> int verbose; >> >> > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: regress: bgpd: config: Fix attribute ordering
On Fri, Mar 06, 2020 at 06:51:16PM +0100, Sebastian Benoit wrote: > I dont see that here. > Sure that you have an up-to-date tree? > And no diff in there? I run regress on sparc64 with a -CURRENT /usr/src tree; latest bgpd is installed from source, but the machine is currently running a snapshot from early february. Neither do I see this difference on a recent amd64 snapshot, so either running -CURRENT bgpd on a month old snapshot on sparc64 is the issue or there's a fundemantal difference between amd64 and sparc64. Will investigate further and upgrade sparc64 to the latest snapshot soon, but perhaps someone else on sparc64 can test as well?
Re: BIRD 1.x/2.x support at rpki-client
On Fri, Mar 06, 2020 at 07:11:56PM +0100, Robert Scheck wrote: > On Fri, 06 Mar 2020, Sebastian Benoit wrote: > > Note that I haven't tried this with bird 1 or 2 yet ;) > > comments, oks? > > I did not try it yet, but I think BIRD 1 also needs something like "define > force_roa_table_update = %lld;" and maybe some table definition. I will try > BIRD 1 and 2 during the weekend explicitly and provide specific feedback or > suggest diffs. BIRD 1 doesn't need such a define, the mechanism is somewhat less sexy, on BIRD 1.6.x you have to issue the following to make a new staticly configured ROAS definition be applied: birdc configure # load new config birdc flush roa # throw away old stuff birdc reload all# apply new stuff to all protocols The table is defined by declaring (and populating) the table as the -current rpki-client does for BIRD v1. Kind regards, Job
Re: BIRD 1.x/2.x support at rpki-client
On Fri, 06 Mar 2020, Sebastian Benoit wrote: > Note that I haven't tried this with bird 1 or 2 yet ;) > comments, oks? I did not try it yet, but I think BIRD 1 also needs something like "define force_roa_table_update = %lld;" and maybe some table definition. I will try BIRD 1 and 2 during the weekend explicitly and provide specific feedback or suggest diffs. Regards, Robert
Re: regress: bgpd: config: Fix attribute ordering
I dont see that here.
Sure that you have an up-to-date tree?
And no diff in there?
Klemens Nanni(k...@openbsd.org) on 2020.03.05 23:39:20 +0100:
>
> I ran bgpd to test diffs and stumbled across what looks like simple
> disorder in the config checks.
>
> bgpd must have changed in how it orders attributes within `set { ... }'
> blocks; breaking the sets into multiple lines and diffing line-wise
> instead of word-wise shows that the printed config indeed only differs
> in the way set attributes from the config appear in bgpd output.
>
> Still, I'd like any of the bgpd hackers to verify before I "fix" regress.
>
> OK?
>
>
> Index: regress/usr.sbin/bgpd/config/bgpd.conf.10.ok
> ===
> RCS file: /cvs/src/regress/usr.sbin/bgpd/config/bgpd.conf.10.ok,v
> retrieving revision 1.6
> diff -u -p -r1.6 bgpd.conf.10.ok
> --- regress/usr.sbin/bgpd/config/bgpd.conf.10.ok 17 Jul 2019 10:27:50
> - 1.6
> +++ regress/usr.sbin/bgpd/config/bgpd.conf.10.ok 5 Mar 2020 22:32:53
> -
> @@ -40,4 +40,4 @@ match from any large-community 1234:5678
> match from any large-community 1234:5678:1 large-community 1234:5678:2
> large-community 1234:5678:3
> match from any community 1234:1 large-community 1234:5678:1
> match from any large-community 1234:5678:1 community 1234:1
> -match from any set { community delete 1234:5678 community delete 1234:*
> community delete *:5678 community delete local-as:5678 community delete
> local-as:neighbor-as large-community delete 1234:15:5678 large-community
> delete *:15:5678 large-community delete local-as:15:5678 large-community
> delete local-as:15:* large-community delete local-as:15:neighbor-as
> large-community delete local-as:*:* community 1234:5678 community
> local-as:5678 community local-as:neighbor-as large-community 1234:15:5678
> large-community local-as:15:5678 large-community local-as:15:neighbor-as }
> +match from any set { community delete 1234:5678 large-community delete
> 1234:15:5678 community delete *:5678 large-community delete *:15:5678
> community delete local-as:5678 large-community delete local-as:15:5678
> community delete 1234:* community delete local-as:neighbor-as large-community
> delete local-as:15:* large-community delete local-as:*:* large-community
> delete local-as:15:neighbor-as community 1234:5678 large-community
> 1234:15:5678 community local-as:5678 large-community local-as:15:5678
> community local-as:neighbor-as large-community local-as:15:neighbor-as }
> Index: regress/usr.sbin/bgpd/config/bgpd.conf.11.ok
> ===
> RCS file: /cvs/src/regress/usr.sbin/bgpd/config/bgpd.conf.11.ok,v
> retrieving revision 1.5
> diff -u -p -r1.5 bgpd.conf.11.ok
> --- regress/usr.sbin/bgpd/config/bgpd.conf.11.ok 17 Jul 2019 10:27:50
> - 1.5
> +++ regress/usr.sbin/bgpd/config/bgpd.conf.11.ok 5 Mar 2020 22:35:04
> -
> @@ -33,7 +33,7 @@ match from any ext-community ovs invalid
> match from any ext-community ovs not-found
> match from any ext-community rt 64496:201 ext-community soo 64496:202
> match from any ext-community rt 64496:301 ext-community soo 420001:302
> ext-community odi 127.0.0.1:303
> -match from any set { ext-community delete ovs valid ext-community delete odi
> 127.0.0.1:6003 ext-community delete soo 420001:6002 ext-community delete
> ort 0x123456789abf ext-community delete rt 64496:6001 ext-community ovs valid
> ext-community odi 127.0.0.1:5003 ext-community soo 420001:5002
> ext-community ort 0x123456789abc ext-community rt 64496:5001 }
> +match from any set { ext-community delete ovs valid ext-community delete ort
> 0x123456789abf ext-community delete rt 64496:6001 ext-community delete odi
> 127.0.0.1:6003 ext-community delete soo 420001:6002 ext-community ovs
> valid ext-community ort 0x123456789abc ext-community rt 64496:5001
> ext-community odi 127.0.0.1:5003 ext-community soo 420001:5002 }
> match from any ext-community * *
> match from any ext-community rt *
> match from any ext-community soo *
> @@ -47,7 +47,7 @@ match from any ext-community rt 127.0.0.
> match from any ext-community soo 64496:*
> match from any ext-community soo 420001:*
> match from any ext-community soo 127.0.0.1:*
> -match from any set { ext-community delete odi 127.0.0.1:* ext-community
> delete soo 420001:* ext-community delete rt 64496:* ext-community delete
> mac-mob * ext-community delete ovs * ext-community delete rt * ext-community
> delete soo * ext-community delete odi * ext-community delete ort * }
> +match from any set { ext-community delete ort * ext-community delete mac-mob
> * ext-community delete ovs * ext-community delete rt * ext-community delete
> soo * ext-community delete odi * ext-community delete rt 64496:*
> ext-community delete odi 127.0.0.1:* ext-community delete soo 420001:* }
> match from any ext-comm
Re: BIRD 1.x/2.x support at rpki-client
Robert Scheck(rob...@fedoraproject.org) on 2020.03.06 14:02:26 +0100: > On Fri, 06 Mar 2020, Job Snijders wrote: > > I believe Robert is referring to this snippet of code: > > > > > > https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch Thanks for the patch. I commited it with the function moved into output-bird.c If you have more (feature) diffs, send them to tech@ too. /Benno
Re: BIRD 1.x/2.x support at rpki-client
Job Snijders(j...@openbsd.org) on 2020.03.06 17:31:13 +: > I have a small suggestion, in some deployments I saw the convention to > name it as following so it is clear the data came from user provided > data rather than internal bird structures > > I tested Benno's patch against BIRD 1.6.6 - wfm. thanks. I did not commit this bit, and i have not substantiated opinion on it. If thats how bird users do it, commit it ;) > > Index: main.c > === > RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v > retrieving revision 1.58 > diff -u -p -r1.58 main.c > --- main.c11 Feb 2020 18:41:39 - 1.58 > +++ main.c6 Mar 2020 17:25:56 - > @@ -156,7 +156,7 @@ static void build_chain(const struct aut > static void build_crls(const struct auth *, struct crl_tree *, > STACK_OF(X509_CRL) **); > > -const char *bird_tablename = "roa"; > +const char *bird_tablename = "ROAS"; > > int verbose; > >
Re: BIRD 1.x/2.x support at rpki-client
I have a small suggestion, in some deployments I saw the convention to name it as following so it is clear the data came from user provided data rather than internal bird structures I tested Benno's patch against BIRD 1.6.6 - wfm. Index: main.c === RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v retrieving revision 1.58 diff -u -p -r1.58 main.c --- main.c 11 Feb 2020 18:41:39 - 1.58 +++ main.c 6 Mar 2020 17:25:56 - @@ -156,7 +156,7 @@ static void build_chain(const struct aut static voidbuild_crls(const struct auth *, struct crl_tree *, STACK_OF(X509_CRL) **); -const char *bird_tablename = "roa"; +const char *bird_tablename = "ROAS"; int verbose;
Re: BIRD 1.x/2.x support at rpki-client
On Fri, Mar 06, 2020 at 05:53:59PM +0100, Sebastian Benoit wrote:
> Hi,
>
> generate 3 different outputs for BIRD:
> - bird v1 with IPv4 routes
> - bird v1 with IPv6 routes
> - bird v2
> when using command line option -B.
> BIRD v2 output from Robert Scheck, robert AT fedoraproject DOT org
>
>
> Note that I haven't tried this with bird 1 or 2 yet ;)
> comments, oks?
>
>
> (benno_rpki_bird.diff)
>
> diff --git usr.sbin/rpki-client/extern.h usr.sbin/rpki-client/extern.h
> index 127db60fa37..6592ea83b5e 100644
> --- usr.sbin/rpki-client/extern.h
> +++ usr.sbin/rpki-client/extern.h
> @@ -374,7 +374,9 @@ FILE *output_createtmp(char *);
> void output_cleantmp(void);
> void output_finish(FILE *);
> int output_bgpd(FILE *, struct vrp_tree *);
> -int output_bird(FILE *, struct vrp_tree *);
> +int output_bird1v4(FILE *, struct vrp_tree *);
> +int output_bird1v6(FILE *, struct vrp_tree *);
> +int output_bird2(FILE *, struct vrp_tree *);
> int output_csv(FILE *, struct vrp_tree *);
> int output_json(FILE *, struct vrp_tree *);
>
> diff --git usr.sbin/rpki-client/output-bird.c
> usr.sbin/rpki-client/output-bird.c
> index a15faa69164..0299018f8af 100644
> --- usr.sbin/rpki-client/output-bird.c
> +++ usr.sbin/rpki-client/output-bird.c
> @@ -1,6 +1,7 @@
> /* $OpenBSD: output-bird.c,v 1.6 2019/12/04 23:03:05 benno Exp $ */
> /*
> * Copyright (c) 2019 Claudio Jeker
> + * Copyright (c) 2020 Robert Scheck
> *
> * Permission to use, copy, modify, and distribute this software for any
> * purpose with or without fee is hereby granted, provided that the above
> @@ -21,7 +22,7 @@
> #include "extern.h"
>
> int
> -output_bird(FILE *out, struct vrp_tree *vrps)
> +output_bird1v4(FILE *out, struct vrp_tree *vrps)
> {
> extern const char *bird_tablename;
> char buf[64];
> @@ -31,10 +32,78 @@ output_bird(FILE *out, struct vrp_tree *vrps)
> return -1;
>
> RB_FOREACH(v, vrp_tree, vrps) {
> - ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
> - if (fprintf(out, "\troa %s max %u as %u;\n", buf, v->maxlength,
> - v->asid) < 0)
> + if (v->afi == AFI_IPV4) {
> + ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
> + if (fprintf(out, "\troa %s max %u as %u;\n", buf,
> + v->maxlength, v->asid) < 0)
> + return -1;
> + }
> + }
> +
> + if (fprintf(out, "}\n") < 0)
> return -1;
> + return 0;
> +}
> +
> +int
> +output_bird1v6(FILE *out, struct vrp_tree *vrps)
> +{
> + extern const char *bird_tablename;
> + char buf[64];
> + struct vrp *v;
> +
> + if (fprintf(out, "roa table %s {\n", bird_tablename) < 0)
> + return -1;
> +
> + RB_FOREACH(v, vrp_tree, vrps) {
> + if (v->afi == AFI_IPV6) {
> + ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
> + if (fprintf(out, "\troa %s max %u as %u;\n", buf,
> + v->maxlength, v->asid) < 0)
> + return -1;
> + }
> + }
> +
> + if (fprintf(out, "}\n") < 0)
> + return -1;
> + return 0;
> +}
> +
> +int
> +output_bird2(FILE *out, struct vrp_tree *vrps)
> +{
> + extern const char *bird_tablename;
> + char buf[64];
> + struct vrp *v;
> + time_t now = time(NULL);
> +
> + if (fprintf(out, "define force_roa_table_update = %lld;\n\n"
> + "roa4 table %s4;\nroa6 table %s6;\n\n"
> + "protocol static {\n\troa4 { table %s4; };\n\n",
> + (long long) now, bird_tablename, bird_tablename,
> + bird_tablename) < 0)
> + return -1;
> +
> + RB_FOREACH(v, vrp_tree, vrps) {
> + if (v->afi == AFI_IPV4) {
> + ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
> + if (fprintf(out, "\troute %s max %u as %u;\n", buf,
> + v->maxlength, v->asid) < 0)
> + return -1;
> + }
> + }
> +
> + if (fprintf(out, "}\n\nprotocol static {\n\troa6 { table %s6; };\n\n",
> + bird_tablename) < 0)
> + return -1;
> +
> + RB_FOREACH(v, vrp_tree, vrps) {
> + if (v->afi == AFI_IPV6) {
> + ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
> + if (fprintf(out, "\troute %s max %u as %u;\n", buf,
> + v->maxlength, v->asid) < 0)
> + return -1;
> + }
> }
>
> if (fprintf(out, "}\n") < 0)
> diff --git usr.sbin/rpki-client/output.c usr.sbin/rpki-client/output.c
> index adafc5c0b53..b26b964eeaa 100644
> --- usr.sbin/rpki-client/output.c
> +++ usr.s
Re: BIRD 1.x/2.x support at rpki-client
Hi,
generate 3 different outputs for BIRD:
- bird v1 with IPv4 routes
- bird v1 with IPv6 routes
- bird v2
when using command line option -B.
BIRD v2 output from Robert Scheck, robert AT fedoraproject DOT org
Note that I haven't tried this with bird 1 or 2 yet ;)
comments, oks?
(benno_rpki_bird.diff)
diff --git usr.sbin/rpki-client/extern.h usr.sbin/rpki-client/extern.h
index 127db60fa37..6592ea83b5e 100644
--- usr.sbin/rpki-client/extern.h
+++ usr.sbin/rpki-client/extern.h
@@ -374,7 +374,9 @@ FILE*output_createtmp(char *);
voidoutput_cleantmp(void);
voidoutput_finish(FILE *);
int output_bgpd(FILE *, struct vrp_tree *);
-int output_bird(FILE *, struct vrp_tree *);
+int output_bird1v4(FILE *, struct vrp_tree *);
+int output_bird1v6(FILE *, struct vrp_tree *);
+int output_bird2(FILE *, struct vrp_tree *);
int output_csv(FILE *, struct vrp_tree *);
int output_json(FILE *, struct vrp_tree *);
diff --git usr.sbin/rpki-client/output-bird.c usr.sbin/rpki-client/output-bird.c
index a15faa69164..0299018f8af 100644
--- usr.sbin/rpki-client/output-bird.c
+++ usr.sbin/rpki-client/output-bird.c
@@ -1,6 +1,7 @@
/* $OpenBSD: output-bird.c,v 1.6 2019/12/04 23:03:05 benno Exp $ */
/*
* Copyright (c) 2019 Claudio Jeker
+ * Copyright (c) 2020 Robert Scheck
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -21,7 +22,7 @@
#include "extern.h"
int
-output_bird(FILE *out, struct vrp_tree *vrps)
+output_bird1v4(FILE *out, struct vrp_tree *vrps)
{
extern const char *bird_tablename;
char buf[64];
@@ -31,10 +32,78 @@ output_bird(FILE *out, struct vrp_tree *vrps)
return -1;
RB_FOREACH(v, vrp_tree, vrps) {
- ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
- if (fprintf(out, "\troa %s max %u as %u;\n", buf, v->maxlength,
- v->asid) < 0)
+ if (v->afi == AFI_IPV4) {
+ ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
+ if (fprintf(out, "\troa %s max %u as %u;\n", buf,
+ v->maxlength, v->asid) < 0)
+ return -1;
+ }
+ }
+
+ if (fprintf(out, "}\n") < 0)
return -1;
+ return 0;
+}
+
+int
+output_bird1v6(FILE *out, struct vrp_tree *vrps)
+{
+ extern const char *bird_tablename;
+ char buf[64];
+ struct vrp *v;
+
+ if (fprintf(out, "roa table %s {\n", bird_tablename) < 0)
+ return -1;
+
+ RB_FOREACH(v, vrp_tree, vrps) {
+ if (v->afi == AFI_IPV6) {
+ ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
+ if (fprintf(out, "\troa %s max %u as %u;\n", buf,
+ v->maxlength, v->asid) < 0)
+ return -1;
+ }
+ }
+
+ if (fprintf(out, "}\n") < 0)
+ return -1;
+ return 0;
+}
+
+int
+output_bird2(FILE *out, struct vrp_tree *vrps)
+{
+ extern const char *bird_tablename;
+ char buf[64];
+ struct vrp *v;
+ time_t now = time(NULL);
+
+ if (fprintf(out, "define force_roa_table_update = %lld;\n\n"
+ "roa4 table %s4;\nroa6 table %s6;\n\n"
+ "protocol static {\n\troa4 { table %s4; };\n\n",
+ (long long) now, bird_tablename, bird_tablename,
+ bird_tablename) < 0)
+ return -1;
+
+ RB_FOREACH(v, vrp_tree, vrps) {
+ if (v->afi == AFI_IPV4) {
+ ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
+ if (fprintf(out, "\troute %s max %u as %u;\n", buf,
+ v->maxlength, v->asid) < 0)
+ return -1;
+ }
+ }
+
+ if (fprintf(out, "}\n\nprotocol static {\n\troa6 { table %s6; };\n\n",
+ bird_tablename) < 0)
+ return -1;
+
+ RB_FOREACH(v, vrp_tree, vrps) {
+ if (v->afi == AFI_IPV6) {
+ ip_addr_print(&v->addr, v->afi, buf, sizeof(buf));
+ if (fprintf(out, "\troute %s max %u as %u;\n", buf,
+ v->maxlength, v->asid) < 0)
+ return -1;
+ }
}
if (fprintf(out, "}\n") < 0)
diff --git usr.sbin/rpki-client/output.c usr.sbin/rpki-client/output.c
index adafc5c0b53..b26b964eeaa 100644
--- usr.sbin/rpki-client/output.c
+++ usr.sbin/rpki-client/output.c
@@ -39,10 +39,12 @@ struct outputs {
char*name;
int (*fn)(FILE *, struct vrp_tree *);
} outputs[] = {
- { FORMAT_OPENBGPD, "openbgpd", output
Re: rnd: initialize 'timespec ts'
OK deraadt, sort of.
While I'm here I'd like to point out that a hilarious discussion in
regards to glibc's 64-bit time_t support, which is adding manual pads
the middle of standardized structs leading to mis-initialization.
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#struct_timespec
Anyways I think it is better if you use this format:
enqueue_randomness(u_int val)
{
struct rand_event *rep;
struct timespec ts;
u_int qlen;
+ timespecclear(&ts);
if (timeout_initialized(&rnd_timeout))
Tobias Heider wrote:
> Hi,
>
> if timeout_initialized() returns 0, enqueue_randomness() may use 'ts'
> uninitialized. This is not really a problem because the value is
> blended with other collected entropy. To make things clearer
> I would still prefer to always initialize 'ts'.
>
> ok?
>
> Index: rnd.c
> ===
> RCS file: /cvs/src/sys/dev/rnd.c,v
> retrieving revision 1.203
> diff -u -p -r1.203 rnd.c
> --- rnd.c 2 Mar 2020 22:27:50 - 1.203
> +++ rnd.c 6 Mar 2020 14:57:20 -
> @@ -296,7 +296,7 @@ void
> enqueue_randomness(u_int val)
> {
> struct rand_event *rep;
> - struct timespec ts;
> + struct timespec ts = { 0, 0 };
> u_int qlen;
>
> if (timeout_initialized(&rnd_timeout))
rnd: initialize 'timespec ts'
Hi,
if timeout_initialized() returns 0, enqueue_randomness() may use 'ts'
uninitialized. This is not really a problem because the value is
blended with other collected entropy. To make things clearer
I would still prefer to always initialize 'ts'.
ok?
Index: rnd.c
===
RCS file: /cvs/src/sys/dev/rnd.c,v
retrieving revision 1.203
diff -u -p -r1.203 rnd.c
--- rnd.c 2 Mar 2020 22:27:50 - 1.203
+++ rnd.c 6 Mar 2020 14:57:20 -
@@ -296,7 +296,7 @@ void
enqueue_randomness(u_int val)
{
struct rand_event *rep;
- struct timespec ts;
+ struct timespec ts = { 0, 0 };
u_int qlen;
if (timeout_initialized(&rnd_timeout))
Re: BIRD 1.x/2.x support at rpki-client
On Fri, Mar 06 2020, Sebastian Benoit wrote:
> Robert Scheck(rob...@fedoraproject.org) on 2020.03.06 14:02:26 +0100:
>> On Fri, 06 Mar 2020, Job Snijders wrote:
>> > I believe Robert is referring to this snippet of code:
>> >
>> >
>> > https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch
>>
>> Exactly.
>
> Ah, i thought it was some diff to bird! Thanks, i'll tkae care of it.
One tweak, fwiw:
--8<--
if (fprintf(out, "define force_roa_table_update = %ld;\n\n"
"roa4 table %s4;\nroa6 table %s6;\n\n"
"protocol static {\n\troa4 { table %s4; };\n\n",
(long) now, bird_tablename, bird_tablename, bird_tablename) < 0)
return -1;
-->8--
The pattern to print time_t is to use %lld and a (long long) cast.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: BIRD 1.x/2.x support at rpki-client
Robert Scheck(rob...@fedoraproject.org) on 2020.03.06 14:02:26 +0100: > On Fri, 06 Mar 2020, Job Snijders wrote: > > I believe Robert is referring to this snippet of code: > > > > > > https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch > > Exactly. Ah, i thought it was some diff to bird! Thanks, i'll tkae care of it. /Benno
Re: BIRD 1.x/2.x support at rpki-client
On Fri, 06 Mar 2020, Job Snijders wrote: > I believe Robert is referring to this snippet of code: > > > https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch Exactly. Regards, Robert
Re: BIRD 1.x/2.x support at rpki-client
On Fri, Mar 06, 2020 at 12:24:18PM +0100, Sebastian Benoit wrote: > Robert Scheck(rob...@fedoraproject.org) on 2020.03.03 01:20:24 +0100: > > job@ suggested to move this from GitHub to tech@ list (as upstream): > > > > 1. Currently, BIRD 1.x support in rpki-client seems to be broken: As per > >BIRD upstream the "combined format" produced by rpki-client can't be > >used as-is with BIRD 1.x due to separated daemons (and configuration > >files) for IPv4 and IPv6. > > 2. Lack of BIRD 2.x support in rpki-client, which requires a different > >output/configuration format (semi-finished pull request at GitHub). > > Hi, can you point me to that pull request, i could not find it. I believe Robert is referring to this snippet of code: https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch Kind regards, Job
Re: Compiler warning in ctype.h
Hello, I was using base gcc but switching to base clang fixes the warnings on -current at least. Is base gcc not supported anymore ? Sorry for the noise. Cheers, Le jeu. 5 mars 2020 à 16:59, Theo de Raadt a écrit : > > Todd C. Miller wrote: > > > On Thu, 05 Mar 2020 16:07:48 +0100, Thomas de Grivel wrote: > > > > > Actually I see the same problem on 6.6-stable : > > > including readline/readline.h produces warnings. > > > > > > Any -Werror hope some day ? > > > > You still haven't bothered to include: > > > > 1) the compiler you are using > > 2) the compiler flags to reproduce the problem > > 3) a sample program to reproduce the problem > > > > The _l parameter in those inline functions already has the __unused__ > > attribute set which is supposed to suppress those warnings. > > > > I can't reproduce this using clang (base or ports) or gcc (base or > > ports) using -Wall, -Wextra and -Wunused-parameter. But since you > > haven't provided any details, we just have to guess at what you are > > doing. > > Or not guess, but simply delete the mail -- Thomas de Grivel kmx.io
Re: BIRD 1.x/2.x support at rpki-client
Robert Scheck(rob...@fedoraproject.org) on 2020.03.03 01:20:24 +0100: > Hi, > > job@ suggested to move this from GitHub to tech@ list (as upstream): > > 1. Currently, BIRD 1.x support in rpki-client seems to be broken: As per >BIRD upstream the "combined format" produced by rpki-client can't be >used as-is with BIRD 1.x due to separated daemons (and configuration >files) for IPv4 and IPv6. > 2. Lack of BIRD 2.x support in rpki-client, which requires a different >output/configuration format (semi-finished pull request at GitHub). Hi, can you point me to that pull request, i could not find it. /Benno > > To cover this, job@ suggested to maybe generate bird1-ipv6, bird1-ipv4 and > bird2 when using -B option. The option currently leads to "bird" file with > BIRD 1.x support only. > > However, I'm not sure if the current options -B, -c, -j and -o are that > great. Maybe something like "-o " would be > more powerful and more flexible? > > Opinions? > > > Regards, > Robert >
Re: net80211: properly wrap sequence numbers on increment
On Fri, Mar 06, 2020 at 10:47:44AM +0100, Stefan Sperling wrote:
> 802.11 frame sequence numbers are in the range 0x0 - 0xfff.
>
> Don't let internal representations of sequence numbers grow beyond 0xfff.
>
> ok?
>
> diff 582540bcd55abf4efa3abe8c23ebc7f3c247245d
> ba499e0f51b139f9ad6d4b4ea18cbf56bd93
> blob - 808b6e1f46b777ea408561c0fbf511e79d477c54
> blob + 6c8057426973640ab03af4ec061adfa1d3c695bf
> --- sys/net80211/ieee80211_output.c
> +++ sys/net80211/ieee80211_output.c
> @@ -190,7 +190,7 @@ ieee80211_mgmt_output(struct ifnet *ifp, struct ieee80
> *(u_int16_t *)&wh->i_dur[0] = 0;
> *(u_int16_t *)&wh->i_seq[0] =
> htole16(ni->ni_txseq << IEEE80211_SEQ_SEQ_SHIFT);
> - ni->ni_txseq++;
> + ni->ni_txseq = (ni->ni_txseq + 1) & 0xfff;
> IEEE80211_ADDR_COPY(wh->i_addr1, ni->ni_macaddr);
> IEEE80211_ADDR_COPY(wh->i_addr2, ic->ic_myaddr);
> IEEE80211_ADDR_COPY(wh->i_addr3, ni->ni_bssid);
> @@ -623,11 +623,11 @@ ieee80211_encap(struct ifnet *ifp, struct mbuf *m, str
> *(u_int16_t *)qwh->i_qos = htole16(qos);
> *(u_int16_t *)qwh->i_seq =
> htole16(ni->ni_qos_txseqs[tid] << IEEE80211_SEQ_SEQ_SHIFT);
> - ni->ni_qos_txseqs[tid]++;
> + ni->ni_qos_txseqs[tid] = (ni->ni_qos_txseqs[tid] + 1) & 0xfff;
> } else {
> *(u_int16_t *)&wh->i_seq[0] =
> htole16(ni->ni_txseq << IEEE80211_SEQ_SEQ_SHIFT);
> - ni->ni_txseq++;
> + ni->ni_txseq = (ni->ni_txseq + 1) & 0xfff;
> }
> switch (ic->ic_opmode) {
> case IEEE80211_M_STA:
>
Makes sense. ok tobhe@
net80211: properly wrap sequence numbers on increment
802.11 frame sequence numbers are in the range 0x0 - 0xfff.
Don't let internal representations of sequence numbers grow beyond 0xfff.
ok?
diff 582540bcd55abf4efa3abe8c23ebc7f3c247245d
ba499e0f51b139f9ad6d4b4ea18cbf56bd93
blob - 808b6e1f46b777ea408561c0fbf511e79d477c54
blob + 6c8057426973640ab03af4ec061adfa1d3c695bf
--- sys/net80211/ieee80211_output.c
+++ sys/net80211/ieee80211_output.c
@@ -190,7 +190,7 @@ ieee80211_mgmt_output(struct ifnet *ifp, struct ieee80
*(u_int16_t *)&wh->i_dur[0] = 0;
*(u_int16_t *)&wh->i_seq[0] =
htole16(ni->ni_txseq << IEEE80211_SEQ_SEQ_SHIFT);
- ni->ni_txseq++;
+ ni->ni_txseq = (ni->ni_txseq + 1) & 0xfff;
IEEE80211_ADDR_COPY(wh->i_addr1, ni->ni_macaddr);
IEEE80211_ADDR_COPY(wh->i_addr2, ic->ic_myaddr);
IEEE80211_ADDR_COPY(wh->i_addr3, ni->ni_bssid);
@@ -623,11 +623,11 @@ ieee80211_encap(struct ifnet *ifp, struct mbuf *m, str
*(u_int16_t *)qwh->i_qos = htole16(qos);
*(u_int16_t *)qwh->i_seq =
htole16(ni->ni_qos_txseqs[tid] << IEEE80211_SEQ_SEQ_SHIFT);
- ni->ni_qos_txseqs[tid]++;
+ ni->ni_qos_txseqs[tid] = (ni->ni_qos_txseqs[tid] + 1) & 0xfff;
} else {
*(u_int16_t *)&wh->i_seq[0] =
htole16(ni->ni_txseq << IEEE80211_SEQ_SEQ_SHIFT);
- ni->ni_txseq++;
+ ni->ni_txseq = (ni->ni_txseq + 1) & 0xfff;
}
switch (ic->ic_opmode) {
case IEEE80211_M_STA:
