Re: relayd.conf.5: less SSL
On Tue, Oct 24, 2023 at 06:54:30AM +, Klemens Nanni wrote: > - parse.y still accepting undocumented "ssl" with a warning since 2014 > - more "SSL/TLS" instead of "TLS" in manual and code comments my take would be that while it's fine to streamline the documentation to use the modern terminology, I suspect there may still be ancient configurations out there that use the "ssl" keyword, so removing the last bit of support for that option should be accompanied by or preceded by a warning on relevant mailing lists or at least in the commit message. And I think undeadly.org would be more than happy to help spread the word :) - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: FWD: FWD: Re: Setting personal mailserver
On Fri, Sep 08, 2023 at 11:35:37AM +0200, Sagar Acharya wrote: > Requesting a feature at OpenSMTPD. > Date: 8 Sept 2023, 14:50 > From: sagaracha...@tutanota.com > To: b...@opensmtpd.org > Subject: FWD: Re: Setting personal mailserver > > > > I request a feature from all the devs. > > > > This would enable users of smtpd to host an email server at any port > > instead of standard 25. Unless I read the smtpd.conf man page very wrong (https://man.openbsd.org/smtpd.conf) it is possible, but not recommended, to set up to listen on ports other than the standard ones. To put it bluntly, what you need is not a new smtpd feature. What you need is for you to take the advice given on the opensmptd mailing list: Read the literature others have pointed you at, and please consider one or more of the alternative approaches that have been suggested to you. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: preliminary kabylake support for inteldrm
On 09/27/17 18:41, Peter N. M. Hansteen wrote: > On 09/27/17 00:07, Robert Nagy wrote: >> >> Hi >> >> This is an updated diff for preliminary kabylake support for 6.2, >> this needs extensive testing on all inteldrm variants. >> >> This diff is also in snapshots now so please, test, test test! > > Installed the latest snapshot (OpenBSD 6.2 (GENERIC.MP) #114: Wed Sep 27 > 01:19:45 MDT 2017), now running the machine from > http://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html with no > xorg.conf, and it looks wonderful so far! > > Preserved dmesg and xdpyinfo output: > > https://home.nuug.no/~peter/20170927_dmesg_greyhame.txt > https://home.nuug.no/~peter/20170927_xdpyinfo_greyhame.txt Following up on this, I see that there is a firmware load failure error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/kbl_dmc_ver1.bin (-22) and later, repeated at intervals [Wed Sep 27 21:39:21] peter@greyhame:~/div/hailmary/2016$ grep drm /var/log/messages Sep 27 19:44:35 greyhame /bsd: error: [drm:pid46498:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A Sep 27 21:37:09 greyhame /bsd: error: [drm:pid46498:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A Then again, I'm not sure what if any functionality is impacted here - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: preliminary kabylake support for inteldrm
On 09/27/17 00:07, Robert Nagy wrote: > > Hi > > This is an updated diff for preliminary kabylake support for 6.2, > this needs extensive testing on all inteldrm variants. > > This diff is also in snapshots now so please, test, test test! Installed the latest snapshot (OpenBSD 6.2 (GENERIC.MP) #114: Wed Sep 27 01:19:45 MDT 2017), now running the machine from http://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html with no xorg.conf, and it looks wonderful so far! Preserved dmesg and xdpyinfo output: https://home.nuug.no/~peter/20170927_dmesg_greyhame.txt https://home.nuug.no/~peter/20170927_xdpyinfo_greyhame.txt - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: OpenBSD 5.6 Released
Antoine Jacoutot ajacou...@openbsd.org writes: November 1, 2014. We are pleased to announce the official release of OpenBSD 5.6. This is our 36th release on CD-ROM (and 37th via FTP/HTTP). We remain proud of OpenBSD's record of more than ten years with only two remote holes in the default install. Congratulations on yet another excellent release! - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Packet Filter nat-to issue
On Fri, Feb 28, 2014 at 10:15:15AM +0100, Lo?c Blot wrote:
i encounter a strange problem today on PF. I don't know if this i normal
but the result is illogic.
I have this rule:
pass out quick proto tcp from all_clients_v4 to port { smtp smtps 587
imap imaps pop3 pop3s } nat-to $natto_iface
the problem here is that the interface has several addresses, so you end up with
pass out quick inet6 proto tcp from all_clients_v4 to any port = 465
flags S/SA nat-to __automatic_d309aaac_0 round-robin
an automatically generated table, containing all addresses assigned to the
interface, and the poor thing tries to load balance between them (round-robin).
The most straightforward fix is to change the nat-to so it refers to one
specific
address only, and only applies to inet, something like
natto_addr=192.0.2.198
pass out quick on egress inet proto tcp from all_clients_v4 to port { smtp
smtps 587 \
imap imaps pop3 pop3s } nat-to $natto_addr
as always, a pfctl -vnf on the config file would show all these things expanded
(yes,
I've been bit by the exact same round-robin problem myself)
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
Remember to set the evil bit on all malicious network traffic
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Iso image integrity verification
On Fri, Sep 13, 2013 at 10:32:43AM +0300, Paul Irofti wrote: Yes, the MITM was DPD. Great currier. I recommand it to everyone. NOT! ^courier the two aren't necessarily mutually exclusive ;) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: pfctl / nat / dhcp
On Thu, Feb 07, 2013 at 09:26:03AM -0500, sven falempin wrote: egress, vr0 ext are all the same, arent they ? in your case, it sounds like there would be a full overlap. In general 'egress' is the interface group that contains the interfaces with default routes. As long as egress has only one member, you should be OK. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PF-MIB for snmpd
Joel Knight knight.j...@gmail.com writes: Looks like there's an issue pulling the diff with lynx or curl. If you use Firefox or Chrome it seems to work fine. Not sure what's going on. looks clean when fetched with ftp(1) as well, didn't actually try applying though. it's against a recent -current, right? - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: recent change of nat-to behavior
Ryan McBride mcbr...@openbsd.org writes: Please try a newer snapshot, this bug was fixed in the following commit: Latest snapshot (date Jul 31) still loads match out log on $ext_if inet nat-to ($ext_if) as match out log on xl0 inet all nat-to (xl0) round-robin but NATed traffic is handled correctly AFAICS. So you should consider this bug closeable. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: recent change of nat-to behavior
Ryan McBride mcbr...@openbsd.org writes: match out log on xl0 inet all nat-to (xl0) round-robin This part of the behaviour is normal and has not changed (since the commit below, I believe). On 4.9 I get the following: i386-49$ echo pass out on egress nat-to (egress) | pfctl -vnf - pass out on egress all flags S/SA keep state nat-to (egress) round-robin i386-49$ The interface may have more than one address... That's probably just me not noticing, but the odd part is that while this interface has several addresses, it only has one IPv4 address: peter@skapet:~$ ifconfig xl0 xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:50:da:21:cb:c9 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 213.187.179.198 netmask 0xfffc broadcast 213.187.179.199 inet6 fe80::250:daff:fe21:cbc9%xl0 prefixlen 64 scopeid 0x3 inet6 2001:16d8:ccbc:dead:beef::1 prefixlen 64 But anyway, with this snapshot I don't need to rewrite the NAT parts of my tutorial :) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
recent change of nat-to behavior
I finally got around to upgrading my home gateway from 4.9-current (late snapshot) to 5.0-beta (jul 27 snapshot), and I stumbled across what appears to be a subtle but significant change in nat-to behavior. my $ext_if is xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:50:da:21:cb:c9 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 213.187.179.198 netmask 0xfffc broadcast 213.187.179.199 inet6 fe80::250:daff:fe21:cbc9%xl0 prefixlen 64 scopeid 0x3 inet6 2001:16d8:ccbc:dead:beef::1 prefixlen 64 and the nat-to line was match out log on $ext_if inet nat-to ($ext_if) AFter upgrading, this was loaded as match out log on $ext_if inet nat-to $ext_addr round-robin - meaning that return traffic wasn't necessarily seen. Changing the rule to match out log on $ext_if inet nat-to $ext_addr restored the config to a working state. Does this count as a buglet (or something that should be documented, at least)? - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: recent change of nat-to behavior
Not the most precise description I see - pe...@bsdly.net (Peter N. M. Hansteen) writes: match out log on $ext_if inet nat-to ($ext_if) AFter upgrading, this was loaded as match out log on $ext_if inet nat-to $ext_addr round-robin Actually match out log on $ext_if inet nat-to $ext_if round-robin was the result, but this part is accurate: - meaning that return traffic wasn't necessarily seen. Changing the rule to match out log on $ext_if inet nat-to $ext_addr where $ext_addr is defined as the IPv4 address, restored the config to a working state. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: recent change of nat-to behavior
Ryan McBride mcbr...@openbsd.org writes: Please try a newer snapshot, this bug was fixed in the following commit: Trying a newer snapshot is exactly what I plan to do, no worries - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Troublesome bge variant:
SDRAM non-parity PC2-3200CL5 spdmem1 at iic0 addr 0x52: 512MB DDR2 SDRAM non-parity PC2-3200CL5 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec mtrr: Pentium Pro MTRR support umass0 at uhub0 port 1 configuration 1 interface 0 Kingston DataTraveler 112 rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: Kingston, DataTraveler 112, 1.00 SCSI2 0/direct removable serial.0951162aFB31B6031B7A sd0: 14762MB, 512 bytes/sector, 30233588 sectors vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on wd0a (c45f82cf8c94c709.a) swap on wd0b dump on wd0b - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
EuroBSDCon 2011 - is your proposal in yet?
The 10th European BSD conference will take place in Maarssen, the Netherlands on 6 - 9 October 2011, a fresh website is up at http://2011.eurobsdcon.org/. The call for proposals has been out for a while, with the deadline set at May 15th (will be extended if necessary). I would very much like to see more OpenBSD proposals, please send yours to submiss...@eurobsdcon.org as soon as you have it together (perhaps you have something left over from the partially cancelled AsiaBSDCon earlier this year?). Please help spread the word and make this year's EuroBSDCon an OpenBSD-heavy conference! - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: invalid ata_xfer state 06: Apr 23 snapshot amd64, Lenovo Thinkpad SL500
not configured pcib0 at pci0 dev 31 function 0 Intel 82801IBM LPC rev 0x03 ahci0 at pci0 dev 31 function 2 Intel 82801I AHCI rev 0x03: apic 2 int 19, AHCI 1.2 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD3200BEVS-0, 14.0 SCSI3 0/direct fixed naa.50014ee258d6e95e sd0: 305245MB, 512 bytes/sec, 625142448 sec total cd0 at scsibus0 targ 1 lun 0: HL-DT-ST, DVDRAM GSA-T50N, RE06 ATAPI 5/cdrom removable usb2 at uhci0: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 Intel UHCI root hub rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 mtrr: Pentium Pro MTRR support uvideo0 at uhub1 port 5 configuration 1 interface 0 Chicony Electronics Co., Ltd. CNF7237CNF7238 rev 2.00/9.63 addr 2 video0 at uvideo0 umodem0 at uhub1 port 6 configuration 1 interface 1 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 umodem0: data interface 2, has CM over data, has break umodem0: status change notification available ucom0 at umodem0 umodem1 at uhub1 port 6 configuration 1 interface 3 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 umodem1: data interface 4, has CM over data, has break umodem1: status change notification available ucom1 at umodem1 umodem2 at uhub1 port 6 configuration 1 interface 9 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 umodem2: data interface 12, has CM over data, has break umodem2: no data interface ugen0 at uhub1 port 6 configuration 1 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 ugen1 at uhub4 port 1 Lenovo Computer Corp ThinkPad Bluetooth with Enhanced Data Rate II rev 2.00/3.99 addr 2 ugen2 at uhub4 port 2 TouchStrip Fingerprint Sensor rev 1.00/0.33 addr 3 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root root on sd0a swap on sd0b dump on sd0b -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
invalid ata_xfer state 06: Apr 23 snapshot amd64, Lenovo Thinkpad SL500
dev 0 function 1 Ricoh 5C822 SD/MMC rev 0x22: apic 2 int 17 sdmmc0 at sdhc0 Ricoh 5C843 MMC rev 0x12 at pci5 dev 0 function 2 not configured Ricoh 5C592 Memory Stick rev 0x12 at pci5 dev 0 function 3 not configured Ricoh 5C852 xD rev 0x12 at pci5 dev 0 function 4 not configured pcib0 at pci0 dev 31 function 0 Intel 82801IBM LPC rev 0x03 ahci0 at pci0 dev 31 function 2 Intel 82801I AHCI rev 0x03: apic 2 int 19, AHCI 1.2 ahci0: invalid ata_xfer state 06 in ahci_put_ccb, slot 31 ahci0: invalid ata_xfer state 06 in ahci_put_ccb, slot 31 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD3200BEVS-0, 14.0 SCSI3 0/direct fixed naa.50014ee258d6e95e sd0: 305245MB, 512 bytes/sec, 625142448 sec total cd0 at scsibus0 targ 1 lun 0: HL-DT-ST, DVDRAM GSA-T50N, RE06 ATAPI 5/cdrom removable usb2 at uhci0: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 Intel UHCI root hub rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 mtrr: Pentium Pro MTRR support uvideo0 at uhub1 port 5 configuration 1 interface 0 Chicony Electronics Co., Ltd. CNF7237CNF7238 rev 2.00/9.63 addr 2 video0 at uvideo0 umodem0 at uhub1 port 6 configuration 1 interface 1 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 umodem0: data interface 2, has CM over data, has break umodem0: status change notification available ucom0 at umodem0 umodem1 at uhub1 port 6 configuration 1 interface 3 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 umodem1: data interface 4, has CM over data, has break umodem1: status change notification available ucom1 at umodem1 umodem2 at uhub1 port 6 configuration 1 interface 9 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 umodem2: data interface 12, has CM over data, has break umodem2: no data interface ugen0 at uhub1 port 6 configuration 1 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 3 ugen1 at uhub4 port 1 Lenovo Computer Corp ThinkPad Bluetooth with Enhanced Data Rate II rev 2.00/3.99 addr 2 ugen2 at uhub4 port 2 TouchStrip Fingerprint Sensor rev 1.00/0.33 addr 3 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root root on sd0a swap on sd0b dump on sd0b -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Hello
Stuart Henderson s...@spacehopper.org writes: There's a big problem which makes it not generally useful: if your users have multithreaded downloads/uploads or P2P traffic with many peers, bandwidth will just split across a larger number of sessions. In that case queueing per source address (probably with hfsc linkshare which can reduce the speed of traffic after a certain time) would be a much better idea. hfsc has a lot going for it, true. And there's a number of ways to achieve roughly what Ali is asking for in near-realtime with some scriptery and pfctl output parsing (plus a few other approaches), but for the use case he describes it *might* make sense to have max-src-* state tracking options that trigger on number of bytes or packets passed. We record those per state anyway, so as a gedankenexperiment, say we could implement max-src-bytes B/s and max-src-packets P/s modeled on max-src-conn-rate and have rules like pass proto tcp to $somewhere port $wanted \ keep state (max-src-bytes 15G/86400, \ overload bytehogs flush global) that is, no source address allowed more than 15GB per day, or we bump to table bytehogs for whatever treatment is appropriate or pass proto tcp to $somewhere port $wanted \ keep state (max-src-packets 1G/86400, \ overload packethogs flush global) to trigger on some insane number of packets instead. Not sure if it stands out as a screaming must-have feature, but after about half an hour mulling the idea I kinda like it for now. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Allegations regarding OpenBSD IPSEC
The IPSEC allegations have produced a flurry of blog posts and suchlike, mostly just rehashing the contents of Theo's original message. However, I've found two followups that are interesting for their own separate reasons: in http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd , there appears to be some additional veribage from Gregory Perry, but IMHO it does not really add much in the way of useful information. The other item, http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html is quite a bit more interesting, since it's a public challenge (with a cash bounty) to come up with actual evidence of backdoor code in the relevant parts of OpenBSD. There have been offers to match original 3 * USD 100 bounty, so with a little more circulation the bounty could turn into a good amount. I would say the second post here deserves more attention; if you agree, please make that URL visible via whatever news sites you can think of (yup, it's in the /. submissions queue). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Allegations regarding OpenBSD IPSEC
patrick keshishian pkesh...@gmail.com writes: It is easy to shoot one's mouth off like that about bounty offered, given the ridiculously constrained conditions the bounty is offered under. He might as well offered a million USD. No one will be able to prove this under these restrictions. I won't get into a discussion about DES' stated requirements, but I do think it's a good-faith effort. Then again, as Jason Dixon points out in his blog http://obfuscurity.com/2010/12/Updates-on-the-OpenBSD-IPsec-Gossip , making a donation to the OpenBSD project is likely to give you more bang for the buck. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: end the VOP experiment
Kenneth R Westerback kwesterb...@rogers.com writes: Man, another reason to get my vax up to -current. Sigh. :-) More idle curiosity than anything else (although I occasionally get that question myself), how long does a typical vax 'make build' take? - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
