Re: Requested upstream patch to use OpenBSD's malloc
On Sat, May 31, 2014 at 12:09:09PM -0700, Andrew Fresh wrote: I opened a ticket with upstream to use OpenBSD's malloc by default. https://rt.perl.org/Public/Bug/Display.html?id=122000 Perl was setup to use perl's malloc on OpenBSD by default in 2010. https://rt.perl.org/Public/Bug/Display.html?id=75742 The perl in OpenBSD base has always used OpenBSD's malloc, and I believe that is what OpenBSD users will expect, even building perl themselves. If you have opinions that may sway the perl5-porters, please chime in on the above ticket #122000. It's a bit say they never reacted to my comments in bug 75742. Good you are taking action, -Otto
Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
On Fri, 30 May 2014, Theo de Raadt wrote: Robert [info...@die-optimisten.net] wrote: On Fri, 30 May 2014 12:19:35 -0400 Ted Unangst t...@tedunangst.com wrote: WARNING: Encrypted vnd is insecure. Migrate your data to softraid before 5.7. Will 5.6 softraid support block sizes other than 512 byte? marc.info/?l=openbsd-miscm=139524543706370 There are no plans for it right now. They way I read the original message (and please correct me if this is wrong!), is that something will happen in 5.7 that will disable encrypted vnd. Which means that people with recent internal/external HDs, that use 4k blocks, will have a problem. (Some disks allow you to use jumper settings for 512b, but not all external ones) Wow, don't know where you got that from. Sometimes it is just a simple explanation. Could you please provide a little bit more information? What causes encrypted vnd to be insecure and what will happen to vnd(4) before 5.7 if it isn't removal of crypto? Also, are there any options remaining to encrypt non-512-byte/sector devices, data on NFS filesystems (NAS boxes) and removable/backup media other than hard drives (or that pretend to be hard drives)? Thank you. Regards, David
Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
Could you please provide a little bit more information? What causes encrypted vnd to be insecure Ted went a bit far; it is unusual for him to be melodratic. Basically -- less than state of the art crypto. and what will happen to vnd(4) before 5.7 if it isn't removal of crypto? You persist in reading too much into things.
Re: Requested upstream patch to use OpenBSD's malloc
On Sun, Jun 01, 2014 at 07:11:37PM +0200, Otto Moerbeek wrote: On Sat, May 31, 2014 at 12:09:09PM -0700, Andrew Fresh wrote: I opened a ticket with upstream to use OpenBSD's malloc by default. https://rt.perl.org/Public/Bug/Display.html?id=122000 Perl was setup to use perl's malloc on OpenBSD by default in 2010. https://rt.perl.org/Public/Bug/Display.html?id=75742 The perl in OpenBSD base has always used OpenBSD's malloc, and I believe that is what OpenBSD users will expect, even building perl themselves. If you have opinions that may sway the perl5-porters, please chime in on the above ticket #122000. It's a bit say they never reacted to my comments in bug 75742. Good you are taking action, Actually, the code of perl is slightly annoying, because it doesn't have any emergency memory reserve unless you're using their own malloc... This is something I've wanted to look at, but haven't had the time to do. It means having a bit of leeway when you run out of memory... Might come in handy in order to let pkg_add clean up a wee little bit before crashing...
Re: AR9462 WLAN support
carsten.kunze at arcor.de writes: I'd prefer to extend the athn driver, I'd investigate at first in that. Hi. I've just realized that my laptop has the same chip. Do you have any updates? Maybe I can help somehow? Thanks
Re: netflow srcip and dstip reversed for redirected traffic
On Sat, 31 May 2014 20:01:25 +0200 Sebastian Benoit benoit-li...@fb12.de wrote: The simple answer: It's complicated. The complicated answer: the pf state is used to keep track of both directions of the traffic flow. When the state times out, _two_ flows are created, one for each direction of traffic, you can see this in copy_flow_ipfix_4_data() in /usr/src/sys/net/if_pflow.c. For NAT/RDR its a bit more complicated, so what you are seeing might be 'normal' or a problem. nfdump should be able to show you both directions of this traffic. Please check what in and out interface is recorded for each flow, ie grep for 178.148.77.73 but dont restrict on the interface. Also, please show a dmesg - we need to know what version you are running. /Benno I have enabled pflow for outbound traffic on $int_if and $ext_if first, and it appears that in this setup no redirected traffic is recorded by nfdump, either entering $ext_if and leaving $int_if on arrival, or entering $int_if and leaving $ext_if on return. Other kinds of traffic appear to be recorded correctly by pflow, including NAT traffic. Next, I enabled pflow for one additional inbound redirected rule: pass in on $if_ext inet proto tcp from any to $pub_srv port 1002 \ rdr-to $priv_srv keep state (pflow) In this setup flows appear to be recorded by nfdump fine on $int_if, both leaving it on arrival and entering it on return. Direction is correct. % nfdump -R 2014 -s srcip/bytes 'out if 5 and port 1002' Src IP AddrFlows(%) Packets(%) Bytes(%) 212.200.65.243 3678(34.9)24554(36.0)2.1 M(35.2) 212.200.65.244 2393(22.7)15331(22.5)1.4 M(23.3) 212.200.65.241 2457(23.3)15488(22.7)1.3 M(22.5) 212.200.65.242 2025(19.2)12765(18.7)1.1 M(19.0) % nfdump -R 2014 -s dstip/bytes 'in if 5 and port 1002' Dst IP AddrFlows(%) Packets(%) Bytes(%) 212.200.65.243 3678(34.9)20699(34.9)1.0 M(36.3) 212.200.65.241 2457(23.3)13572(22.9) 638520(22.5) 212.200.65.244 2393(22.7)13590(22.9) 619420(21.9) 212.200.65.242 2025(19.2)11496(19.4) 547616(19.3) However, on external interface the direction appears to be reversed (notice I need to request '$ext_if outbound srcip' in order to get '$ext_if outbound dstip': % nfdump -R 2014 -s srcip/bytes 'out if 4 and port 1002' Src IP AddrFlows(%) Packets(%) Bytes(%) 212.200.65.243 4051(35.0)26862(36.4)2.3 M(35.7) 212.200.65.244 2654(23.0)16771(22.7)1.5 M(23.4) 212.200.65.241 2683(23.2)16731(22.7)1.4 M(22.4) 212.200.65.242 2175(18.8)13475(18.2)1.2 M(18.5) Also I need to request '$ext_if inbound dstip' in order to get '$ext_if inbound srcip': % nfdump -R 2014 -s dstip/bytes 'in if 4 and port 1002' Dst IP AddrFlows(%) Packets(%) Bytes(%) 212.200.65.243 4051(35.0)22767(35.0)1.1 M(36.5) 212.200.65.241 2683(23.2)14756(22.7) 692652(22.4) 212.200.65.244 2654(23.0)15024(23.1) 683824(22.1) 212.200.65.242 2175(18.8)12409(19.1) 586820(19.0) I am using quite recent snapshot: OpenBSD 5.5-current (GENERIC.MP) #150: Mon May 26 11:50:31 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2128887808 (2030MB) avail mem = 2063499264 (1967MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xee000 (69 entries) bios0: vendor HP version P58 date 05/02/2011 bios0: HP ProLiant DL360 G5 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC BERT HEST SSDT acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2500.38 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,DCA,SSE4.1,LONG,LAHF,PERF cpu0: 6MB 64b/line 16-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 333MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2000.08 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,DCA,SSE4.1,LONG,LAHF,PERF cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2500.09 MHz cpu2:
Re: AR9462 WLAN support
Hello, Hi. I've just realized that my laptop has the same chip. Do you have any updates? Maybe I can help somehow? Thanks I've spended a lot of time but some day a gave up. Now I have a Dell E6540 where really everything works (sincere thanx to all developers!), so I think I leave the other laptop unused (it has another problem--with the current gfx driver the C70 GPU gets near to 100 degree celsius). There is a working driver for FreeBSD. Initially I thought I could port it, but it is very FreeBSD dependent. Then I tried to extend the athn by looking at the FreeBSD code. Maybe the better way--since if you want to distribute it it has to have OpenBSD quality anyway. But if you look at the amount of code of this driver you see that it's a lot of work to do. There is also a driver for Linux, but one could assume that there would be more work to do than using the FreeBSD code. With my current time budget I can do testing and small code changes but real development I can't do in the near future, unfortunately. Regards, Carsten
Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
On Sun, Jun 01, 2014 at 11:37, Theo de Raadt wrote: Could you please provide a little bit more information? What causes encrypted vnd to be insecure Ted went a bit far; it is unusual for him to be melodratic. Basically -- less than state of the art crypto. You would never use blowfish-cbc (with a 64-bit blocksize) for disk encryption today. You can probably find a wiki page somewhere with details, but the reality is most people aren't capable of assessing whether this is secure enough. Part of the deprecation / migration process is identifying the weird ways people use vnd and finding solutions for them. But as we've seen, people never move forward without the occasional push.
Re: Requested upstream patch to use OpenBSD's malloc
Done and done. Just a heads-up if you try to comment on the issue and encounter a page with no content, it’s because you’re not logged in. - Eric On May 31, 2014, at 12:09 PM, Andrew Fresh and...@afresh1.com wrote: I opened a ticket with upstream to use OpenBSD's malloc by default. https://rt.perl.org/Public/Bug/Display.html?id=122000 Perl was setup to use perl's malloc on OpenBSD by default in 2010. https://rt.perl.org/Public/Bug/Display.html?id=75742 The perl in OpenBSD base has always used OpenBSD's malloc, and I believe that is what OpenBSD users will expect, even building perl themselves. If you have opinions that may sway the perl5-porters, please chime in on the above ticket #122000. l8rZ, -- andrew - http://afresh1.com People who invent random theories which only defend the vendor must have been beaten as children. Beaten with sticks. At least, that's my theory. -- Theo De Raadt
Apache
Hello list Could somebody please tell me if i should be worry for: 185.4.227.194 - - [01/Jun/2014:08:32:14 -0700] GET http://24x7-allrequestsallowed.com/?PHPSESSID=1rxsxtj500143SVM%5CRH%40%40BZPU HTTP/1.1 200 1723 The answer was 200. Running 5.5 Release. Thanks all. francisco.
ACPI / Toshiba laptop issues
Hi, I've been trying to use OpenBSD on an older (2009) Toshiba laptop but I am running into some difficulty with ACPI. What appears to be happening is that as soon as the \_PIC method is invoked inside acpimadt the machine usually just reboots (with the May 31st snapshot it now no longer reboots, but never proceeds past the acpimadt line in the dmesg). To run OpenBSD on this machine it is necessary to disable acpimadt but this means that the machine effectively runs under a single core. Another option is to disable the invokation of \_PIC in acpimadt, and this seems to allow OpenBSD to pickup the two CPU cores, but this doesn't really seem safe. To make matters even worse, the BIOS on the machine seems to have 2 different DSDT ACPI tables. The good table has a creator id of MSFT and is almost twice as large as the bad table (which has a creator id of INTL). The machine starts with the good DSDT table, but at some point the BIOS will swap out the good table with the bad table. The actual DSDT memory is modified in SMI. If I debug the kernel, I can see that OpenBSD is starting with the good table but by the time I get into user space, acpidump dumps the bad DSDT table. Under Windows 7, the DSDT memory never seems to get modified and the BIOS is at least happy enough to not swap out the DSDT table during SMI. At this point, I'm hoping that someone more familiar with OpenBSD's ACPI implementation and AML can see something obvious in the DSDT table. I have some older dmesgs, acpidump output, and Windows 7 DSDT table on my website: http://devinsmith.net/toshiba/ Here is a dmesg from March with the \_PIC method disabled. I did try with the May 31st snapshot, but the machine locks with acpimadt as the last line printed. OpenBSD 5.5-current (GENERIC.MP) #0: Sun Mar 9 22:40:26 PDT 2014 r...@toshiba.devinsmith.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2931376128 (2795MB) avail mem = 2844696576 (2712MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe90a0 (49 entries) bios0: vendor Insyde Corp. version 1.10 date 12/17/2009 bios0: TOSHIBA Satellite L505D acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG BOOT SLIC SSDT acpi0: wakeup devices LID_(S4) PB2_(S5) PB3_(S4) PB5_(S4) PB7_(S5) PB9_(S5) PB10(S5) AZAL(S3) USB0(S3) USB1(S3) USB4(S3) USB5(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) II Dual-Core M300, 1995.21 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) II Dual-Core M300, 1994.95 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpimcfg0 at acpi0 addr 0xf700, bus 0-15 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus -1 (PB2_) acpiprt3 at acpi0: bus -1 (PB3_) acpiprt4 at acpi0: bus 2 (PB4_) acpiprt5 at acpi0: bus 3 (PB5_) acpiprt6 at acpi0: bus 4 (PB6_) acpiprt7 at acpi0: bus -1 (PB7_) acpiprt8 at acpi0: bus -1 (PB9_) acpiprt9 at acpi0: bus -1 (PB10) acpiprt10 at acpi0: bus 10 (P2P_) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpipwrres0 at acpi0: PFA1, resource for FAN1 acpitz0 at acpi0: critical temperature is 105 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID_ acpibat0 at acpi0: BAT0 model PA353 serial 06AA type Li-ion acpiac0 at acpi0: AC unit online acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCD_ acpivideo1 at acpi0: VGA_ cpu0: 1995 MHz: speeds: 2000 1400 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD RS880 Host rev 0x00 ppb0 at pci0 dev 1 function 0 AMD RS780 PCIE rev 0x00 pci1 at
