Re: Is privilege separated TLS protocol handling of interest ?
> Remco wrote: > > The idea is to run the TLS protocol in different processes (tls_client, > > kex helper) by impersonal users. > > > > All TLS/crypto code lives in those processes, the user's application > > doesn't know about TLS/crypto and does not need to be linked against it. > > This doesn't sound very different from stunnel. Or in openbsd, relayd. > > On the client side, it's not always so clear, but there is nc. > > Personally, I think TLS is too complicated, and so it's a good idea to > separate that from other operations. It is possible to hide this behind the > tls API, but many programs aren't going to want that. > > But some diffs to seperate TLS and HTTP into seperate processes in ftp could > be interesting. I also worry about one process that does decapsulation, on behalf of others. Now all the risk is in one place, and an attack against it which can remain persistant is very worrying - it can see all future traffic. Instead, we've designed daemons which use tls in much narrower domain-specific ways. For a good example, see how ntpd has a completely privilege seperated tls speaker for the "constraint" feature. No memory sharing. Furthermore pledge allows that data flow (and interpretation, which is safe) to sit inside a single address space, with very limited system call operations. That process cannot even do fd passing once it gets going.
"send_packet: No route to host" during DHCP request renewal
Greetings,
I recently built up a router based on OBSD 6.0; axe0 is the i/f
connected to the ADSL modem, and it obtains its address from my ISP
through DHCP:
[snip]
root@egeo:[~]> cat /etc/hostname.axe0
# Internet connection
# Pubblic address obtained through ISP DHCP service
dhcp
[snip]
I noticed the following log messages at DHCP request renewal:
[snip]
Jan 9 23:32:28 egeo dhclient[58607]: DHCPREQUEST on axe0 to
10.254.3.253 Jan 9 23:32:28 egeo dhclient[58607]: send_packet: No
route to host Jan 9 23:32:31 egeo dhclient[58607]: DHCPREQUEST on axe0
to 255.255.255.255 Jan 9 23:32:31 egeo dhclient[58607]: DHCPACK from
2.238.176.1 (78:19:f7:45:d7:c1) Jan 9 23:32:31 egeo dhclient[58607]:
bound to 2.238.176.236 -- renewal in 14340 seconds.
[snip]
I do not understand what's happening here; the first request fails with
"No route to host", the second one (which seems to me a broadcast one)
is instead correctly managed.
Does it mean that there is a DHCP server running on 10.254.3.253? This
should be a private network address, but my LAN is on
192.168 (and on the same machine, having internal IP address
192.168.1.1, is indeed running a DHCP service).
Is it a "reject" declaration in dhclient.conf the right way to tackle
this symptom? Or do I need some additional rules in pf.conf?
[snip]
root@egeo:[~]> cat /etc/dhclient.conf
# DHCP service is used on this machine only for ISP
# connection (axe0 i/f)
send host-name "egeo.atlantide.priv";
# Do not overwrite resolv.conf, use local DNS instead
ignore domain-name-servers, domain-name;
[snip]
[snip]
root@egeo:[~]> cat /etc/pf.conf
# $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
# List of internal interfaces
int_if="{ vether0 bce0 ath0 }"
# "egress" keyword chooses the i/f that holds the default route (axe0)
# Non-routable private addresses
table{ \
0.0.0.0/8 \
10.0.0.0/8 \
127.0.0.0/8 \
169.254.0.0/16 \
172.16.0.0/12 \
192.0.0.0/24 \
192.0.2.0/24 \
224.0.0.0/3 \
192.168.0.0/16 \
198.18.0.0/15 \
198.51.100.0/24 \
203.0.113.0/24 \
}
set block-policydrop# Silently drop
rejected packets set loginterface
egress # Enable packet and byte statistics for
axe0 #setskipon lo0 # \
#setskipon enc0 # ) Completely
omit these i/f from packet processing #setskipon
bwi0 # /
# Enable traffic on loopback i/f (very low security risk)
passquick on lo0 all
# Normalize incoming packets and perform NAT
match in all scrub (no-df random-id max-mss
1440) match out on egress inet
from !(egress:network) to any nat-to (egress:0)
# Drop packets coming in on egress if they appear to be from
# non-routable addresses (misconfiguration? spoofing attack?)
# Similarly, clients should not attempt to connect to such
# addresses
block in quickon egress from
to any block return out quickon egress from
anyto
# By default, block all traffic
block all
# Allow outgoing IPv4 traffic from both the router itself
# and the LAN clients
passout quick inet
# Allow all internal LAN traffic
passin on $int_if inet
# Do not permit remote connections to X11
block return in on !lo0 proto tcp to port 6000:6010
# Allow pinging
passinet proto icmp all
icmp-type { echoreq, unreach }
#
# Port forwarding
#
# Note: currently all servers are running on the router itself;
# if that's won't be the case in future, use "rdt-to 192.168.1.x"
#
# Network services, Internet style
passin on egress inet proto { tcp udp } from
anyto (egress) port ssh passin on egress
inet proto { tcp udp } from anyto (egress) port www pass
in on egress inet proto tcp from any
to (egress) port https passin on egress inet
proto { tcp udp } from anyto (egress) port imap pass
in on egress inet proto { tcp udp } from any
to (egress) port imaps passin on egress inet
proto tcp from anyto (egress) port smtp pass
in on egress inet proto { tcp udp } from any
to (egress) port submission
# FTP
passin on egress inet proto tcp from
anyto (egress) port ftp pas
Re: Is privilege separated TLS protocol handling of interest ?
Remco wrote: > The idea is to run the TLS protocol in different processes (tls_client, > kex helper) by impersonal users. > > All TLS/crypto code lives in those processes, the user's application > doesn't know about TLS/crypto and does not need to be linked against it. This doesn't sound very different from stunnel. Or in openbsd, relayd. On the client side, it's not always so clear, but there is nc. Personally, I think TLS is too complicated, and so it's a good idea to separate that from other operations. It is possible to hide this behind the tls API, but many programs aren't going to want that. But some diffs to seperate TLS and HTTP into seperate processes in ftp could be interesting.
Re: Hardware recommendations for compact 1U firewall
On Tue, Jan 10, 2017 at 12:58 PM, Paul Suh wrote: >> On Dec 16, 2016, at 8:32 PM, Predrag Punosevac > wrote: >> >> This is my favorite Ebay seller and they have lots of nice network >> equipment for home, small, and large business. >> >> http://stores.ebay.com/MITXPC/ > > +1 for MITXPC. I've purchased several systems from them over the years and > they've always been responsive and helpful. > > > --Paul > > [demime 1.01d removed an attachment of type application/pkcs7-signature which > had a name of smime.p7s] > I'd do this if it weren't for the fact that shipping their items to Australia costs more than their items themselves... -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: Hardware recommendations for compact 1U firewall
> On Dec 16, 2016, at 8:32 PM, Predrag Punosevac wrote: > > This is my favorite Ebay seller and they have lots of nice network > equipment for home, small, and large business. > > http://stores.ebay.com/MITXPC/ +1 for MITXPC. I've purchased several systems from them over the years and they've always been responsive and helpful. --Paul [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
non-PAP in radiusd
Hello friends, I noticed in the radiusd.conf man page that the bsdauth module only supports PAP: "It only supports PAP, password based authentication." Is there a specific reason as to why CHAP isn't implemented? I am assuming it is due to time / interest constraints but perhaps the quality of CHAP is in question too -- I see in the RFC that MD5 is assigned a specific value, making me wonder if MD5 is the predominant algorithm of CHAP implementations in the wild and perhaps considered insecure by the community. On a side note, does anyone know which algorithms are used in CHAP besides MD5? Thanks, Pete
Re: Hardware recommendations for compact 1U firewall
To answer some of my own questions, and after wise guidance from the list, I have noticed that all our firewall hardware using 'vr' ethernet ports hit a wall somewhere between 65Mbps->69Mbps. This is the case with the Geodes in a net5501 and various VIA x86 CPUs in VIA embedded systems, I am thinking of replacing the motherboard in my Net5501 system with one of the APU2 systems. If anybody has any experience with these, please feel free to share it. That will keep the price down but probably still about twice the level that I think Aaron is trying to achieve. They use an AMD GX-412TC, 1Ghz quad Jaguar core and have 3*1Gbps ethernet (Intel i210AT) ports. The GX-412TC nominally is about 5 times faster than the Geode LX in the Net5501. We need something better than the Soekris Net5501/Geode-LX on the end of an (Optus) cable internet link which we know runs at 110Mbps (raw) and on the end of two symmetric fibre links, both 100Mbps, one Optus and one Telstra. For non-Aussies, Optus and Telstra = ISPs. No, not NBN. Thanks - Damian Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer
Re: Hardware recommendations for compact 1U firewall
On Tue, Jan 10, 2017 at 1:32 AM, Stuart Henderson wrote: > Aaron Mason wrote: >> >> Torn between a Barracuda web filter or a Portwell CAR 3000. The latter >> >> is more expensive but supports 10Gbit, whereas the Barracuda may only >> >> have 10/100. Both Core2Duo based, could probably upgrade to a >> >> Core2Quad or a Xeon with a 771->775 adapter. > > btw, I found some cheap CAR 3000 (this one says "caswell" rather than > portwell and is an oem firewall box), so here's a dmesg in case it's of > interest. sysctl hw follows below. > > Handy to have so many ports for Ł25, but 4x 1u fans (including the one in > the PSU) make it rather noisy. > > OpenBSD 6.0-current (GENERIC.MP) #122: Sun Jan 8 14:53:10 MST 2017 > bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4242145280 (4045MB) > avail mem = 4108922880 (3918MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfbcb0 (45 entries) > bios0: vendor American Megatrends Inc. version "080015" date 12/22/2010 > acpi0 at bios0: rev 0 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP APIC MCFG OEMB SSDT > acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) EUSB(S4) MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz, 2793.39 MHz > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM 2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR > cpu0: 3MB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 265MHz > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz, 2793.00 MHz > cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM 2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR > cpu1: 3MB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 addr 0xe000, bus 0-255 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 7 (P0P1) > acpiprt2 at acpi0: bus 1 (P0P4) > acpiprt3 at acpi0: bus 2 (P0P5) > acpiprt4 at acpi0: bus 3 (P0P6) > acpiprt5 at acpi0: bus 4 (P0P7) > acpiprt6 at acpi0: bus 5 (P0P8) > acpiprt7 at acpi0: bus 6 (P0P9) > acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS > "AWY0001" at acpi0 not configured > "PNP0501" at acpi0 not configured > "PNP0501" at acpi0 not configured > acpibtn0 at acpi0: PWRB > cpu0: Enhanced SpeedStep 2793 MHz: speeds: 2800, 2403, 2136, 1870, 1603 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel G41 Host" rev 0x03 > inteldrm0 at pci0 dev 2 function 0 "Intel G41 Video" rev 0x03 > drm0 at inteldrm0 > intagp0 at inteldrm0 > agp0 at intagp0: aperture at 0xd000, size 0x1000 > inteldrm0: msi > inteldrm0: 1024x768, 32bpp > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi > pci1 at ppb0 bus 1 > em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c4 > ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi > pci2 at ppb1 bus 2 > em1 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c5 > ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: msi > pci3 at ppb2 bus 3 > em2 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c6 > ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: msi > pci4 at ppb3 bus 4 > em3 at pci4 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c7 > ppb4 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: msi > pci5 at ppb4 bus 5 > em4 at pci5 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c8 > ppb5 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: msi > pci6 at ppb5 bus 6 > em5 at pci6 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c9 > uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23 > ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 23 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 > ppb6 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 > pci7 at
Re: [RESOLVED] Re: 6.0 sppp does not answer PPPoE-Discovery code offer
On 2017-01-09, Axel Rau wrote: >> It seems that sppp does not work with vlan pseudi device. > > Anybody fixing that? I'm not running any right now, but I was fairly recently and it worked then. Is your ISP one of those silly ones that requires the priority in the 802.1q header to be 0?
support update
# Marshall M. Midden # Consultant # 9792 Hemlock Lane North # Maple Grove, Minnesota 55369 # Email: marshallmid...@yahoo.com # URL: http://www.umn.edu/~m4/ # Used OpenBSD for many years. In 2001, implemented embedded no-MMU mips port (with # speciality driver help) including fork(). [Not a mistake.] Inexperience with the VM system stopped NFS from # working -- no customer would ever use it [compiling the whole system without an MMU?], but almost everything else # worked! Fixed uclinux port. Used kernel.org linux and put in fork(). Lots more stuff! # # # Mainly change e-mail from yahoo to gmail. # 0 C USA P Minnesota T Maple Grove Z 55369 O Consultant I Marshall M. Midden A 9792 Hemlock Lane North M marshallmid...@gmail.com U http://www.umn.edu/~m4/ B X N Prefer OpenBSD for desktop use. In 2001, implemented embedded no-MMU MIPS port including fork(). [Not a mistake.] Shipped six months in mass produced home networking routers (3 Ethernet mac's). Made kernel.org-2.4 linux port do the same thing.
Is privilege separated TLS protocol handling of interest ?
I'm a bit reluctant here because I don't know what I'm getting myself into and I don't really want to spend more time on this than I already do. Anyway, a couple of years ago I wondered what TLS was all about and I tried to understand it by writing code to do TLS as a hobby project. Trying to play with privilege separation as well, things got kind of out of hand and eventually, more or less by accident, I ended up with something looking like the following, e.g., this is what a connection may look like of someone connecting to a service over TLS: application o-o tls_client o-o network (plaintext)(crypto)(ciphertext) o | key exchange (temporary) o kex helper Example of the accompanying public API: int tls_client_socket_unix(int s, ...); The idea is to run the TLS protocol in different processes (tls_client, kex helper) by impersonal users. All TLS/crypto code lives in those processes, the user's application doesn't know about TLS/crypto and does not need to be linked against it. The user application only needs to be able to talk to a daemon over an UNIX socket to exchange a file descriptor. The user doesn't own any keying material, which is set up per user, per key exchange, per role (client/server), per hostname. Only kex helpers have access on behalf of the user. Roughly every key exchange type has its own handler program. A configuration file is involved, only to be changed by a system administrator. The tls_client_socket_unix function is used as follows: - open an ordinary TCP socket "s". - before exchanging application data, pass this socket to the tls_client_socket_unix function, upon successful return, the socket is protected by the TLS protocol and application data can be sent back and forth as if it were an ordinary socket, upon failure the socket is useless. The tls_client_socket_unix function could also be implemented natively in scripting languages supporting file descriptor transfer over an UNIX socket, e.g. Perl, Python, Ruby, without the need for any TLS/crypto modules. Something similar can be done for a service accepting TLS connections. I think I have this working to some extent for ftp(1), httpd(8) and possibly acme-client(1), as well as simple Perl, Python and Ruby modules. What I did is by no means complete or perfect, or even cryptographically secure, still, would it be useful to have this code available ? It seems like a bit of a waste to just let it sit on my hard drive not really doing anything useful. Regards, Remco
[RESOLVED] Re: 6.0 sppp does not answer PPPoE-Discovery code offer
Updating the firmware of the Vigor130 box from 3.7.9_m7 to 3.7.9.4_m7 solved the problem. > . . . > It seems that sppp does not work with vlan pseudi device. Anybody fixing that? Axel --- PGP-Key:29E99DD6 â computing @ chaos claudius
Re: Non-free firmware without asking the user
Op 09-01-17 om 10:05 schreef Stefan Sperling: > On Mon, Jan 09, 2017 at 01:39:41AM +0100, Martin Hanson wrote: >> On Sun, 8 Jan 2017, Stefan Sperling wrote: >> The above policy applies to the base system code. It does not apply to ports and packages of third party software, i.e. anything listed by pkg_info. >> >>> Perhaps the whole only a misunderstanding of the original poster that >>> could have been clarified with this few lines from the beginning? >>> >>> Rodrigo. >> >> Good point, and yes it would. >> >> However, the above statement that the policy only applies to the base code >> isn't mentioned anywhere in the policy. >> >> Stefan, from where do you get that conclusion? > > You've finally been given an acceptable answer yet you're still asking a > trivia question just to keep this stupid thread going? > Someone asks a question about policy on a list. Now there are two possibilities: A) "You're right, thanks!" which means a valid point was raised B) "You misunderstand" which means "Do some research/think before posting". This thread has a different form: If the reply was (A) then he'd correctly think he was a well thinking person. Now the reply is (B) and he seems to think "Everybody is more stupid then I, because they disagree." when that doesn't work he switches to "See, I am a person who _sounds_ reasonable, (but still I am not wrong...)" So, it looks like he thinks he's either right or else not wrong. A discussion won't help, a link to Sir Karl Popper might. ;-)
Re: https for pkg_add?
On Mon, 09 Jan 2017, Stuart Henderson wrote: > Performance won't be ideal though, there's no pipelining or session > resumption - it needs to do a full TLS negotiation for each package > fetched (note that pkg_add -u fetches at least the start of the tgz > for *every* package which you have installed on the system). Perhaps an index/manifest file, like apt does? http://cdn.debian.net/debian/dists/stable/main/
Re: spamd and network whitelisting
Op Tue, 20 Dec 2016 12:31:05 +0100 schreef Clint Pachl : [...] grep "^GREY" | tr "|" "\t" | [...] I've learned to do all parsing of /var/db/spamd via the interface as the envelope-from sometimes contains a "|" (pipe) character. -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: Hardware recommendations for compact 1U firewall
Aaron Mason wrote: > >> Torn between a Barracuda web filter or a Portwell CAR 3000. The latter > >> is more expensive but supports 10Gbit, whereas the Barracuda may only > >> have 10/100. Both Core2Duo based, could probably upgrade to a > >> Core2Quad or a Xeon with a 771->775 adapter. btw, I found some cheap CAR 3000 (this one says "caswell" rather than portwell and is an oem firewall box), so here's a dmesg in case it's of interest. sysctl hw follows below. Handy to have so many ports for £25, but 4x 1u fans (including the one in the PSU) make it rather noisy. OpenBSD 6.0-current (GENERIC.MP) #122: Sun Jan 8 14:53:10 MST 2017 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4242145280 (4045MB) avail mem = 4108922880 (3918MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfbcb0 (45 entries) bios0: vendor American Megatrends Inc. version "080015" date 12/22/2010 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SSDT acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) EUSB(S4) MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz, 2793.39 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz, 2793.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 7 (P0P1) acpiprt2 at acpi0: bus 1 (P0P4) acpiprt3 at acpi0: bus 2 (P0P5) acpiprt4 at acpi0: bus 3 (P0P6) acpiprt5 at acpi0: bus 4 (P0P7) acpiprt6 at acpi0: bus 5 (P0P8) acpiprt7 at acpi0: bus 6 (P0P9) acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS "AWY0001" at acpi0 not configured "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured acpibtn0 at acpi0: PWRB cpu0: Enhanced SpeedStep 2793 MHz: speeds: 2800, 2403, 2136, 1870, 1603 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel G41 Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel G41 Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0: msi inteldrm0: 1024x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c4 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi pci2 at ppb1 bus 2 em1 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c5 ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: msi pci3 at ppb2 bus 3 em2 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c6 ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: msi pci4 at ppb3 bus 4 em3 at pci4 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c7 ppb4 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: msi pci5 at ppb4 bus 5 em4 at pci5 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c8 ppb5 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: msi pci6 at ppb5 bus 6 em5 at pci6 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 00:90:fb:39:8c:c9 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb6 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 pci7 at ppb6 bus 7 pcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01 pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0
Re: https for pkg_add?
On 2017-01-06, Antoine Jacoutot wrote: > On Thu, Jan 05, 2017 at 06:50:38PM -0800, jungle boogie wrote: >> Hi All, >> >> With all the recent changes to supporting https on the various mirrors, does >> that mean https may also be used with the PKG_PATH variable? > > Yes. It was already possible for those mirrors which supported it. Performance won't be ideal though, there's no pipelining or session resumption - it needs to do a full TLS negotiation for each package fetched (note that pkg_add -u fetches at least the start of the tgz for *every* package which you have installed on the system). If this becomes more popular the 4096-bit keys used on some mirrors may become a bit unwieldy :)
[patch] Enable support for Subpixel Antialiasing / LCD Filter
TL;DR: This patch allows users to use subpixel antialiasing/lcd filter on openbsd, like on FreeBSD/most Linux distributions. It does not change the defaults. For full use, see my other patch at [7]. Dear all, this patch enables subpixel rendering, which is disabled by default in freetype (due to software patents), and enables users to use RGB Antialiasing, which is a big improvements for low-DPI displays (e.g. with a DPI of 96). The current default ist greyscale AA (and no lcd filter), which is not changed by this patch. To use subpixel AA/lcd filter, you have to manually enable it (see my config below). >From [1]: By default, FreeType's scan-line converter returns "gray" sub-pixel images, where for each pixel the color components are equal (this is, R=G=B). The result is visually identical to gray anti-aliasing and cannot infringe any of the ClearType patents. Similarly, the LCD-specific filtering API is disabled by default, which means that it returns an error and doesn't alter sub-pixel images. You can override these limitations by activating option FT_CONFIG_OPTION_SUBPIXEL_RENDERING in FreeType's ftoption.h configuration file, but you should do that at your own risk. Other Linux/BSD systems have this option enabled for a long time now, under them Ubuntu, Debian [2], Freebsd [3], Arch Linux [4] and more. There has been a privious discussion on this list on this topic [5] where tedu@ mentions, that this issue is irrelevant once you get a decent display with a higher DPI (or use bitmap fonts), which is of course true [6]. But at least for me, at work we still have (and buy) new monitors that have a DPI of 96 (e.g. Dell U2412M). On these displays, bitmap fonts are too tiny for me and don't scale well, so subpixel rendering with enabled lcd filter really makes a difference. For this patch, hinting should be set to "slight". This is also upstreams default, but unfortunately, openbsd forgot to merge the relevant changes, so for now, unless the user does not change the settings, it is hintfull. See my patch at [7], which make slight hinting the default. More information from the freetype page at [8]. Once you recompile freetype with the patch, you can enable subpixel hinting by adding the following snipped to your .config/fontconfig/fonts.conf: rgb lcddefault Is there a chance to get this enabled in xenocara? Regards Nils [1] https://www.freetype.org/patents.html [2] http://metadata.ftp-master.debian.org/changelogs/main/f/freetype/freetype_2.5.2-3+deb8u1_changelog [3] http://www.freshports.org/print/freetype2/ [4] https://git.archlinux.org/svntogit/packages.git/tree/trunk/0002-Enable-subpixel-rendering.patch?h=packages/freetype2 [5] http://marc.info/?l=openbsd-misc&m=146065800429682&w=2 [6] http://marc.info/?l=openbsd-misc&m=146315386122046&w=2 [7] http://marc.info/?l=openbsd-tech&m=148353268331986&w=2 [8] https://www.freetype.org/freetype2/docs/text-rendering-general.html#slight-hinting-invokes-the-native-hinter-if-possible Index: lib/freetype/include/freetype/config/ftoption.h === RCS file: /cvs/xenocara/lib/freetype/include/freetype/config/ftoption.h,v retrieving revision 1.19 diff -u -p -r1.19 ftoption.h --- lib/freetype/include/freetype/config/ftoption.h 28 Oct 2016 21:41:15 - 1.19 +++ lib/freetype/include/freetype/config/ftoption.h 9 Jan 2017 13:55:13 - @@ -122,7 +122,7 @@ FT_BEGIN_HEADER /* This is done to allow FreeType clients to run unmodified, forcing */ /* them to display normal gray-level anti-aliased glyphs.*/ /* */ -/* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */ +#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING /*/
Re: NET_LOCK on current
On Mon, Jan 09, 2017 at 11:22:37AM +0200, Kapetanakis Giannis wrote: > Hi, > > I'd like to ask if the NET_LOCK patches have been committed in the current tree or a separate tree? > > best regards, > > G > This was on current. mpi@ made the introductory NET_LOCK commits on the 19th of December and there has been a few follow-up commits since. K [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
NET_LOCK on current
Hi, I'd like to ask if the NET_LOCK patches have been committed in the current tree or a separate tree? best regards, G
Re: Using "Pretty" permalinks with httpd in wordpress
On 06.01.17 15:42, Atanas Vladimirov wrote:
On 06.01.2017 13:35, Jiri B wrote:
On Fri, Jan 06, 2017 at 01:32:10PM +0200, Atanas Vladimirov wrote:
Hi,
I can't figure it out.
Is it possible to use Wordpress with OpenBSD httpd and configure both
for "Pretty" permalinks.
Does anyone have a working setup?
Thanks for your time,
Atanas
Help testing this diff
http://marc.info/?l=openbsd-tech&m=148370177214134&w=2
j.
I know about the diff and I'm testing it right now.
The problem is that I really don't know what to put in
httpd.conf.
I try to "translate" Wordpress .htaccess with no luck:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
^^^ this rule doesn't rewrite index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
^^^ this rule rewrites any single character to /index.php
if %{REQUEST_FILENAME} is not a real file or directory
# END WordPress
Do I read/understand the .htaccess file correctly?
In my httpd.conf:
.
# art-katerina.com
server "art-katerina.com" {
listen on * tls port 443
alias www.art-katerina.com
directory index index.php
root "/domains/art-katerina.com/"
hsts
log {
access "art-katerina-access.log",
error "art-katerina-error.log",
style combined
}
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
tls {
certificate
"/etc/ssl/acme/art-katerina.com/fullchain.pem"
key "/etc/ssl/acme/private/art-katerina.com/privkey.pem"
}
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
location match "(.)" {
pass rewrite "/index.php"
fastcgi socket "/run/php-fpm.sock"
}
you seem to be wrong here. location match "(.)" mean exactly
_ONE_ single character. may be you mean location match "(.+)"
.
Re: Can I run OpenBSD on an ASUS RT-AC88U?
On Sun, Jan 08, 2017 at 04:38:43PM +, Andreas Thulin wrote: > Hi! > > Aplogies in advance if this post comes out as tremendously stupid - I'm not > very experienced. No worries. > I bought an ASUS RT-AC88U wireless router. Performance is great, but I lack > the configurability I'm used to from working with on other boxes. Started > out exploring options for making it a NAS by attaching an external HDD, and > then thought I'd back that up to my friends' NAS nightly. Turns out I need > to install something called optware to be able to install packages on the > (presumed) minix installation, which I can reach by ssh. Minix? I doubt that. I bet this AP is running Linux. > At some point I thought that hey, OpenBSD is great at networking. Could I > install that instead, and work with an environment I know better than a > commersial web interface or crippled terminal? > > So - could I? No, you could not. Your best bet for such devices are OpenWRT and DD-WRT. This page has some links: https://wikidevi.com/wiki/ASUS_RT-AC88U (see the "Forum threads" section there)
Can I run OpenBSD on an ASUS RT-AC88U?
Hi! Aplogies in advance if this post comes out as tremendously stupid - I'm not very experienced. I bought an ASUS RT-AC88U wireless router. Performance is great, but I lack the configurability I'm used to from working with on other boxes. Started out exploring options for making it a NAS by attaching an external HDD, and then thought I'd back that up to my friends' NAS nightly. Turns out I need to install something called optware to be able to install packages on the (presumed) minix installation, which I can reach by ssh. At some point I thought that hey, OpenBSD is great at networking. Could I install that instead, and work with an environment I know better than a commersial web interface or crippled terminal? So - could I? BR Andreas
Re: 6.0 sppp does not answer PPPoE-Discovery code offer
> Am 07.01.2017 um 20:01 schrieb Axel Rau : > > Hi, > > while trying to switch my Vigor130 to pppoe pass through and let my > OpenBSD firewall handle the pppoe stuff, I get: Turning on debug shows: Jan 8 17:48:05 gw1 /bsd: pppoe0 (8863) state=1, session=0x0 output -> ff:ff:ff:ff:ff:ff, len=18 Jan 8 17:48:05 gw1 /bsd: pppoe0: wrong interface, not accepting host unique Jan 8 17:48:05 gw1 /bsd: pppoe: received PADO but could not find request for it Jan 8 17:49:05 gw1 /bsd: pppoe0: timeout Setting pppoedev to a physical device (em5) and let the Vigor 130 do the vlan tagging advances the state to code Request: 18:45:32.630667 00:60:e0:5a:75:45 ff:ff:ff:ff:ff:ff 8863 32: PPPoE-Discovery code Initiation, version 1, type 1, id 0x, length 12 tag Service-Name, length 0 tag Host-Uniq, length 4 \203\017\224\371 18:45:33.674682 00:30:88:1f:18:9a 00:60:e0:5a:75:45 8863 83: PPPoE-Discovery code Offer, version 1, type 1, id 0x, length 63 tag Host-Uniq, length 4 \203\017\224\371 tag AC-Name, length 27 FFMR71-se800-B2224180702381 tag AC-Cookie, length 16 \347\212\027\206\367\214\026\211i\277\311\267\010d!\026 tag Service-Name, length 0 18:45:33.749614 00:60:e0:5a:75:45 00:30:88:1f:18:9a 8863 52: PPPoE-Discovery code Request, version 1, type 1, id 0x, length 32 tag Service-Name, length 0 tag AC-Cookie, length 16 \347\212\027\206\367\214\026\211i\277\311\267\010d!\026 tag Host-Uniq, length 4 \203\017\224\371 18:45:38.840790 00:60:e0:5a:75:45 00:30:88:1f:18:9a 8863 52: PPPoE-Discovery code Request, version 1, type 1, id 0x, length 32 tag Service-Name, length 0 tag AC-Cookie, length 16 \347\212\027\206\367\214\026\211i\277\311\267\010d!\026 tag Host-Uniq, length 4 \203\017\224\371 It seems that sppp does not work with vlan pseudi device. I also tried this on a different hardware box with em5 at pci0 dev 20 function 3 „Intel I354 SGMII“ rev 0x03: \ msi, address 00:60:e0:5a:75:45 instead of em5 at pci5 dev 11 function 0 „Intel 82541GI“ rev 0x05: \ apic 2 int 18, address 00:0f:c9:04:db:87 which made no difference. hostname.pppoe0 in use: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev em5 \ authproto pap \ authname ‚some_u...@t-online.de‘ authkey some_pw up dest 0.0.0.1 debug Anybody using pppoe with 6.0-STABLE? Axel > --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Re: Funding for Skylake support
Guys, what about to look and/or contact http://www.openbsdfoundation.org/index.html and discuss matter with them? On Mon, Jan 9, 2017 at 1:55 AM, Peter Membrey wrote: > Hi, > > I'd also be willing to put funds up front so that good test hardware can be purchased to do the development on. In that case I'd be looking for someone who has had previous success getting their code (ideally in graphics) accepted into the project. I'm also willing to put the funds into escrow if there is a concern about getting paid. > > I'm only an individual, so I don't have corporate level backing or anything, but I am thinking of putting in a decent chunk for this, as in hundreds rather than tens of dollars. Again, I realise that money isn't the driving force here, but my thinking is, if there is someone who does contract coding for example, it might be possible to purchase a block of their time to work on this. > > Cheers, > > Pete > > - Original Message - > From: "Adam Van Ymeren" > To: "misc" > Sent: Monday, 9 January, 2017 05:44:10 > Subject: Re: Funding for Skylake support > > On 1/7/2017 3:19 PM, Peter Membrey wrote: >> Hi all, >> >> I've gotten OpenBSD up and running on a new Intel NUC, but unfortunately Skylake isn't supported. I was able to get X working in software accelerated mode, but it would be great to see true support for the chipset. Unfortunately I don't have the necessary skills to work on this myself, but I am willing to put my money where my mouth is. >> >> I realise that for a lot of people, the issue is time and not money, but that aside, would anybody be interested in focusing on adding support for Skylake? The deliverable would be getting Skylake support merged. >> >> Happy to discuss what sort of funding would be needed. > > I would also be interested in helping fund Skylake support. Happy to > donate some upfront to anyone interested in working on Skylake. > > -Adam
Re: Non-free firmware without asking the user
On Mon, Jan 09, 2017 at 01:39:41AM +0100, Martin Hanson wrote: > On Sun, 8 Jan 2017, Stefan Sperling wrote: > > >> The above policy applies to the base system code. > >> It does not apply to ports and packages of third party software, i.e. > >> anything > >> listed by pkg_info. > > > Perhaps the whole only a misunderstanding of the original poster that > > could have been clarified with this few lines from the beginning? > > > > Rodrigo. > > Good point, and yes it would. > > However, the above statement that the policy only applies to the base code > isn't mentioned anywhere in the policy. > > Stefan, from where do you get that conclusion? You've finally been given an acceptable answer yet you're still asking a trivia question just to keep this stupid thread going?
