Re: When OpenBSD 6.7 is going to be released?
According to this [0], it's scheduled for May 19. [0]: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/root/root.mail.diff?r1=1.137&r2=1.138
Re: pf table for all publicly routable ipv4 addresses
On 2020-05-04 19:23, Stuart Henderson wrote:
On 2020-05-04, Marko Cupać wrote:
Hi,
I'd like to create pf table "all publicly routable ipv4 addresses". Is
this possible with some short syntax?
Thank you in advance.
something like this?
# https://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
table {
!0.0.0.0/8
!10.0.0.0/8
!100.64.0.0/10
!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
!192.168.0.0/16
!198.18.0.0/15
!198.51.100.0/24
!203.0.113.0/24
!224.0.0.0/3
}
Yes. I want to have the opposite of table described in pf
faq:
https://www.openbsd.org/faq/pf/example1.html#pf
...so I can permit hosts on guest vlan access Internet hosts, but not
hosts on other private vlans similar to:
block log all
pass in on $guest_vlan from $guest_vlan:network to
However, this apparently doesn't work. If I tested well, your
table expands to "no addresses", not "all addresses but those".
I thought I could do such table like this:
table {0.0.0.0/0 \
!0.0.0.0/8 \
...
!224.0.0.0/3 }
...but https://www.openbsd.org/faq/pf/tables.html#addr states that "One
limitation when specifying addresses is that 0.0.0.0/0 and 0/0 will not
work in tables".
I know I can solve this by reordering rules, and using block instead of
pass, but I'd really like to have a table of all publicly routable ip
addresses in pf.
Regards,
--
Before enlightenment - chop wood, draw water.
After enlightenment - chop wood, draw water.
Marko Cupać
https://www.mimar.rs/
When OpenBSD 6.7 is going to be released?
Please let me know.
Re: Privoxy crashes on one OpenBSD machine but not another
> Same DNS setup on the machine, same network speed/latency? If this is a > race condition that could be the difference. Same LAN/DNS, yes. > Anyways, when looking at the privoxy code and their community I got so > discouraged that I realized that for me, it was not worth the risk. I'm getting to that point. If there's no change with 3.0.28 I'll just look for alternatives. Thanks. ‐‐‐ Original Message ‐‐‐ On Monday, May 4, 2020 2:31 PM, Gabriel Kihlman wrote: > TJ dll-kms...@protonmail.com writes: > > > Thanks, that looks very similar to my last backtrace, included > > below. Any guesses why an identically-configured Privoxy on the P4 box > > runs apparently without issues? > > Same DNS setup on the machine, same network speed/latency? If this is a > race condition that could be the difference. > > > Assuming Privoxy 3.0.26 is the problem > > and OpenBSD 6.7 is around the corner, I can wait for that in the > > meantime. > > Last year 6.5 was released on 1st of May so really should be very soon. > > Anyways, when looking at the privoxy code and their community I got so > discouraged that I realized that for me, it was not worth the risk. > > /gabriel
Re: pf table for all publicly routable ipv4 addresses
Just a question and a thought may be.
I am not sure why having this pass valid table oppose to block.
The reason is that if you pass all valid IP's then some service you want
to block, don't you have to add more rules to do that oppose to only
allow incoming from service you want?
Look to me you do
1. Block all.
2. Pass all valid IPv4
3. Block to protect devices you want not to be open to all.
4. allow specific services on the above one.
May be I don't get it. You may have a very valid reason or preference,
but thinking about it, I see it as being more confusing and less
efficient in global numbers or rules.
Me I have for the relevant part.
# Block of IP's that shouldn't ever be seen on the Interent.
# Refer to RFC 919, 922, 1122, 1918, 3171, 3927, 5735, 5736,
# 5737 and 5771
# When CARP is use, without peercarp, don't block multicast 224.0.0.0/24
table const { 0/8, 10/8, 100.64/10, 127/8, 169.254/16, /
172.16/12, 192/24, 192.0.2/24, 192.168/16, 198.18/15, /
198.51.100/24, 203.0.113/24, 224/4, 240/4, 255.255.255.255/32 }
...
# Drop all packets from the reserved address space.
block drop quick on egress inet from
block drop quick on egress inet to
May be this is useful or not.
Just wanted to offer you food for thought just in case.
Do as you see fit, may be I am wrong, I assume no one else or sure a
very limited numbers of users would do as you want, pass all and then
block later. In any case what do I know really, I am more then welling
to be wrong.
I think you have way less chance of mistake when you block all and only
allow what you need.
Daniel
On 5/4/20 4:42 PM, Marko Cupać wrote:
> On 2020-05-04 19:23, Stuart Henderson wrote:
>> On 2020-05-04, Marko Cupać wrote:
>>> Hi,
>>>
>>> I'd like to create pf table "all publicly routable ipv4 addresses". Is
>>> this possible with some short syntax?
>>>
>>> Thank you in advance.
>>>
>>
>> something like this?
>>
>> # https://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
>> table {
>> !0.0.0.0/8
>> !10.0.0.0/8
>> !100.64.0.0/10
>> !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
>> !192.168.0.0/16
>> !198.18.0.0/15
>> !198.51.100.0/24
>> !203.0.113.0/24
>> !224.0.0.0/3
>> }
>
> Yes. I want to have the opposite of table described in pf faq:
> https://www.openbsd.org/faq/pf/example1.html#pf
>
> ...so I can permit hosts on guest vlan access Internet hosts, but not
> hosts on other private vlans similar to:
>
> block log all
> pass in on $guest_vlan from $guest_vlan:network to
>
> However, this apparently doesn't work. If I tested well, your
> table expands to "no addresses", not "all addresses but those".
>
> I thought I could do such table like this:
>
> table { 0.0.0.0/0 \
> !0.0.0.0/8 \
> ...
> !224.0.0.0/3 }
>
> ...but https://www.openbsd.org/faq/pf/tables.html#addr states that "One
> limitation when specifying addresses is that 0.0.0.0/0 and 0/0 will not
> work in tables".
>
> I know I can solve this by reordering rules, and using block instead of
> pass, but I'd really like to have a table of all publicly routable ip
> addresses in pf.
>
> Regards,
Re: pf table for all publicly routable ipv4 addresses
Marko Cupa??(marko.cu...@mimar.rs) on 2020.05.04 22:42:50 +0200:
> I thought I could do such table like this:
>
> table {0.0.0.0/0 \
> !0.0.0.0/8 \
> ...
>!224.0.0.0/3 }
>
> ...but https://www.openbsd.org/faq/pf/tables.html#addr states that "One
> limitation when specifying addresses is that 0.0.0.0/0 and 0/0 will not
> work in tables".
table {1.0.0.0/8 \
2.0.0.0/8 \
3.0.0.0/8 \
4.0.0.0/6 \
8.0.0.0/5 \
16.0.0.0/4 \
32.0.0.0/3 \
64.0.0.0/2 \
128.0.0.0/3 \
160.0.0.0/3 \
192.0.0.0/3 \
!192.168.0.0/24 \
...
}
>
> I know I can solve this by reordering rules, and using block instead of
> pass, but I'd really like to have a table of all publicly routable ip
> addresses in pf.
>
> Regards,
> --
> Before enlightenment - chop wood, draw water.
> After enlightenment - chop wood, draw water.
>
> Marko Cupa??
> https://www.mimar.rs/
>
--
Re: How to enable TLS 1.3?
Chad Hoolie(chad.hoo...@protonmail.com) on 2020.05.03 22:10:05 +: > Is there any chance we can have TLS 1.3 support in relayd in the upcoming 6.7 > release? No, for lack of a time machine.
pf table for all publicly routable ipv4 addresses
Hi, I'd like to create pf table "all publicly routable ipv4 addresses". Is this possible with some short syntax? Thank you in advance. -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: pf table for all publicly routable ipv4 addresses
On 2020-05-04, Marko Cupać wrote:
> Hi,
>
> I'd like to create pf table "all publicly routable ipv4 addresses". Is
> this possible with some short syntax?
>
> Thank you in advance.
>
something like this?
# https://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
table {
!0.0.0.0/8
!10.0.0.0/8
!100.64.0.0/10
!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
!192.168.0.0/16
!198.18.0.0/15
!198.51.100.0/24
!203.0.113.0/24
!224.0.0.0/3
}
Re: [SOLVED] pkg_add can't resolve package - bad major
I think I forgot to run pkg_add -u after upgrade, my pkg_add is working again after running this. Thanks you all!
Re: dhcp dhcp problem with ramnode.com: "CLASSLESS_STATIC_ROUTES too long" (workaround included)
On 2020-05-04, James Cook wrote: > Hi misc, > > I'm mostly posting this so people doing a web search can find my > workaround. However, if someone's interested in debugging it, I'm > happy to cooperate. I don't know whether this is dhclient's fault or > ramnode's fault. Can you capture the DHCP packets while running dhclient? tcpdump -i vio0 -s 1500 -vv port bootpc or bootps There may be a problem with the server, but it may just be that the server is sending more than dhclient's fairly low hard limit on what it is willing to accept (the buffer is a bit smaller than some use cases foreseen by RFC 3442), the packet capture will tell us more.
OSPF lsa_check issue
Hi, Following on from the OSPF issue we were seeing in 5.8, we have built a vagrant lab with a complete replica of our production network in order to test config against 6.6 (latest syspatch applied) and test a number of scenarios. All in all everything has gone well, and other than some minor config enhancements, everything is fundamentally working. The original issue we had was routes not being advertised beyond the DR, when there were situations like a network blip or restart of the ospf process on another router/firewall. Since moving to 6.6 we have been able to recreate the same situation we have had in production, we do this by doing a "rcctl restart ospfd" on the DR, typically a few times. Eventually other routers start logging as follows: May 4 15:44:19 va-l1-tun ospfd[75371]: lsa_check: bad age May 4 15:44:19 va-l1-tun ospfd[75371]: lsa_check: bad age May 4 15:44:24 va-l1-br-02 ospfd[27625]: lsa_check: bad age May 4 15:44:24 va-l1-br-02 ospfd[27625]: lsa_check: bad age May 4 15:44:24 1 va-l1-tun ospfd[75371]: lsa_check: bad age If we run a tcpdump using tcpdump -i vio0 -s 1500 -w /tmp/ospf.pcap proto ospf, we can then see the ospf hello packets fully in wireshark, but the LS update packets are fragmented so we can not see the full detail or what is being passed from the relevant neighbor. We have tried to increase the verbosity of logging using "ospfctl log verbose", but still we are unsure which lsa update is incorrect. The only way we have found to stop these logs from appearing is to "rcctl restart ospfd" on various boxes until it stops. What we are hoping for help with is diagnosing exactly which record has the lsa_check: bad age, and understanding whether this should in effect clear itself for example. We have looked at the source code, but do not fully understand the flow beyond the check itself in lsa_check. We are wondering if there is something fundamentally wrong with our config, but it is pretty simple. Effectively a set of connected routers in a single area with one of the hops having a backup across the internet with a GRE tunnel. At most we are only ever 3 hops away between a source and destination. We have also on occasion seen "seq num mismatch, bad flags" messages, but these have appeared to clear themselves. Thanks
dhcp dhcp problem with ramnode.com: "CLASSLESS_STATIC_ROUTES too long" (workaround included)
Hi misc, I'm mostly posting this so people doing a web search can find my workaround. However, if someone's interested in debugging it, I'm happy to cooperate. I don't know whether this is dhclient's fault or ramnode's fault. Here is my /etc/dhclient.conf ; the comment mostly explains the issue. Without this, dhclient doesn't set up routing, so I can't access the outside network. -- BEGIN /etc/dhclient.conf # OpenBSD's dhclient seems to play badly with ramnode's implementation of # classless-static-routes, as shown in the following example. (I don't know if # specifying -v a second time did anything.) # # # dhclient -vv vio0 # vio0: DHCPREQUEST to 255.255.255.255 # vio0: DHCPACK from 168.235.109.252 (fa:16:3e:60:7a:33) # vio0: CLASSLESS_STATIC_ROUTES too long # vio0: 168.235.109.198 lease accepted from 168.235.109.252 (fa:16:3e:60:7a:33) # # The below request line contains the default value with classless-static-routes # removed (according to the default documented in the dhclient.conf(5) man # page). This alone didn't fix the problem, so I added the ignore line. I guess # the ignore on its own might be enough but there's a certain logic to not # asking for something we're going to ignore. request bootfile-name,broadcast-address,host-name,domain-name,domain-name-servers,domain-search,routers,subnet-mask,tftp-server-name,time-offset; ignore classless-static-routes; -- END /etc/dhclient.conf A couple more notes: * I set up my server by initializing its disk with install66.fs. I needed the network for the install to work, since I overwrote the disk with the new server's partition layout. To get the network to work temporarily, I ran dhclient -v vio0, noted the IP address that the DHCPACK came from, and simply ran "route add default (that IP)". It's not the same IP that gets configured when I use the above workaround, but it worked. * Before I implemented the workaround, I remember /etc/hostname.vio0 had an entry for classless-static-routes, even though dhclient said "CLASSLESS_STATIC_ROUTES too long". I haven't delved deep enough into the code to understand the significance of that, but mentioning it in case it's relevant. BTW, this is my first time using OpenBSD, and I'm quite happy so far. James
10Gbps X520 network adapter only passing 3.5Gbps
Greetings OpenBSD community, I am running into severe bandwidth limitations whilst passing traffic through an OpenBSD firewall. The NIC in use is an Intel 10Gb 2-port X520 adapter from which I would hope to pass through at least 7Gbps+, yet the best results I have gotten is only around 3.5Gbps. The results of bandwidth measurements (iperf for 30sec, lacp trunk is 2x10 Gbps, without carp means that the IP was moved on top of VLAN direcly): PF+carp+isakmpd+lacp = 2.03 Gbits/sec PF+isakmpd+lacp = 2.88 Gbits/sec PF+lacp = 2.53 Gbits/sec lacp = 2.90 Gbits/sec W/O LACP single direct 10 Gbps link to OpenBSD box = 3.44 Gbits/sec In the full setup the interface hierarchy goes like this: ix0+ix1 > trunk0 > vlanXXX > carpXXX System running OpenBSD: OpenBSD 6.6 (GENERIC.MP) PowerEdge FC430 CPU: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz Memory: 64 GB NIC: 10GbE 2P X520 LP PCI-e 8x Adapter - Intel 82599 Output of /var/run/dmesg.boot: https://pastebin.com/j8SkurNM During the testing, CPU barely saw any real usage and 64GB of memory should be more than enough. My guess was that it might have been due to some sort of PF limit kicking in, but the counters did not show that and the last test excluded PF from the interface altogether. Tested the bandwidth also with 1, 2, 4 cores but that did not change the results for the better (left it at 4). Does anyone have any further ideas on what to test or check which might give a lead to getting this situation improved? Or if that PCIe card is simply not capable of greater bandwidths using OpenBSD, which cards would you recommend? I also followed this thread previously listed on openbsd-misc: https://marc.info/?l=openbsd-misc&m=157381313901337&w=2 Even though the case seems to be very similar, I did not manage to find a solution from that thread which would work in this case. Thank you for your time Best regards, Kalle
Re: pkg_add can't resolve package - bad major
On Mon, May 04, 2020 at 08:23:10AM +0200, Marc Espie wrote: > On Sun, May 03, 2020 at 12:58:41PM -0400, Chris Bennett wrote: > > I have had this exact same problem before > > > > pkg_info -q > packages_installed > > pkg_delete gettext. > > pkg_add gettext-runtime > > pkg_add -u > > pkg_add -zl packages_installed > > > Update your procedures, use pkg_info -z and not pkg_add -z. > It's been there for ages. > My bad. Thanks. That also gives me info I was finding hard to understand about stems. Time to sit down and re-read man pages again. Chris Bennett
Re: Dell VEP 1445 OpenBSD 6.6 Booting Failed
In Addition, I rebooted the device after installation. Now, I cannot give any input from console. I cannot even enter the bios. Vertigo Altair , 4 May 2020 Pzt, 16:15 tarihinde şunu yazdı: > Hello, > I cannot change IRQ in Bios, > In BIOS, com0 settings are like this; > IO = 3F8h (correct) , IRQ = 7 (incorrect) > For installation, I set com0's IRQ to 7 at UKC. And I completed > installation successfully. However, when I try to boot after installation > the console is stucking again. There are 16 character on the last line and > com0 are using to IRQ = 4. At this point, I cannot reach the UKC with "boot > -c". How can I overcome this? > > "Intel X553 SGMII" rev 0x11 at pci10 dev 0 function 0 not configured > "Intel X553 SGMII" rev 0x11 at pci10 dev 0 function 1 not configured > "Intel C3000 ME HECI" rev 0x11 at pci0 dev 24 function 0 not configured > "Intel C3000 UART" rev 0x11 at pci0 dev 26 function 0 not configured > "Intel C3000 UART" rev 0x11 at pci0 dev 26 function 1 not configured > "Intel C3000 UART" rev 0x11 at pci0 dev 26 function 2 not configured > sdhc0 at pci0 dev 28 function 0 "Intel C3000 eMMC" rev 0x11: apic 2 int 16 > sdhc0: SDHC 3.0, 200 MHz base clock > sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma > pcib0 at pci0 dev 31 function 0 "Intel C3000 LPC" rev 0x11 > "Intel C3000 PMC" rev 0x11 at pci0 dev 31 function 2 not configured > "Intel C3000 SMBus" rev 0x11 at pci0 dev 31 function 4 not configured > "Intel C3000 SPI" rev 0x11 at pci0 dev 31 function 5 not configured > isa0 at pcib0 > isadma0 at isa0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > C▒▒+ > сJͅс▒▒ɻ▒▒▒J▒Ł▒▒: ns16550a, 16 byte fifo > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33 > lm1 at wbsio0 port 0xa10/8: NCT6776F > vmm0 at mainbus0: VMX/EPT > sdmmc0: can't enable card > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > root on sd0a (1589b7458f9250cf.a) swap on sd0b dump on sd0b > WARNING: / was not properly unmounted > Automatic boot i > > Vertigo Altair , 3 May 2020 Paz, 17:29 > tarihinde şunu yazdı: > >> Hello Again, >> I have already disabled ACPI at the boot prompt, but the result didn't >> change.Thanks for suggestion.. >> >> Andrea Fleckenstein , 3 May 2020 Paz, 16:41 >> tarihinde şunu yazdı: >> >>> Vertigo Altair writes: >>> >>> Hello, >>> >>> I had a Dell XPS 8100 with a similar problem and I was able to get >>> around it by disabling ACPI at the boot prompt. Of course, we have very >>> different machines, but it's worth a shot. Unfortunately the boot was >>> extremely slow, on the order of 10min with acpi reenabled, and several >>> minutes >>> without it. Hopefully someone more knowledgeable than me will give a >>> more reasoned answer. Good luck. >>> >>> Best, >>> Andrea >>> >>> > Hi, >>> > I have a Dell VEP 1445 Whitebox, I want to install OpenBSD 6.6. on it. >>> But >>> > When I try to boot, the boot process is stucking. There is no output >>> after >>> > " erase ^?, werase" >>> > >>> > BIOS Boot Selector for VEP1400-X >>> > Version 3.48.0.9-4 >>> > >>> > >>> > POST Configuration >>> > CPU Signature 506F1 >>> > CPU FamilyID=6, Model=5F, SteppingId=1, Processor=0 >>> > Microcode Revision 2E >>> > Platform ID: 0x0 >>> > PMG_CST_CFG_CTL: 0x37 >>> > Misc EN: 0x840089 >>> > Gen PM ConA: 0xA0A00200 >>> > Therm Status: 0x800 >>> > POST Control=0xEA000F03, Status=0xE600DF00 >>> > >>> > BIOS initializations... >>> > >>> > CPGC Memtest Channel 0 .. PASS >>> > >>> > POST: >>> > RTC Battery OK at last cold boot >>> > RTC date 5/3/2020 9:24:11 >>> > >>> > POST SPD test ... PASS >>> > >>> > POST Lower DRAM Memory test . >>> > POST ECC Test ... PASS >>> > >>> > Perf cnt (curr,fixed): 0x32AFD1520,0x8B637FB20 >>> > >>> > POST Lower DRAM Memory test . PASS >>> > POST Lower DRAM ECC check ... PASS >>> > >>> > Current BOOT from Primary BIOS >>> > DxE POST >>> > >>> > POST Upper DRAM Memory test >>> > Short memory cell test >>> > >>> > POST Upper DRAM Memory test . PASS >>> > HDD Access .. PASS >>> > USB device detected >>> > Temperature test PASS >>> > FAN controller test . PASS >>> > EEPROM test . PASS >>> > POST PCI test ... PASS >>> > POST BMC Interface test . PASS >>> > POST NVRAM check PASS >>> > POST overall test results ... PASS >>> > >>> > NVRAM: 00 DF 00 E6 03 0F 00 EA 01 55 3E __ 00 0F 00 F7 >>> > Version 2.19.1266. Copyright (C) 2019 American Megatrends, Inc. >>> > BIOS Date: 06/26/2019 22:19:26 Ver: 0ACHI040 >>> > Press or to enter setup. >>> > probing: pc0 com1 com2 com3 mem[640K 1894M 117M 972K 4M 14336M]
Re: Dell VEP 1445 OpenBSD 6.6 Booting Failed
Hello, I cannot change IRQ in Bios, In BIOS, com0 settings are like this; IO = 3F8h (correct) , IRQ = 7 (incorrect) For installation, I set com0's IRQ to 7 at UKC. And I completed installation successfully. However, when I try to boot after installation the console is stucking again. There are 16 character on the last line and com0 are using to IRQ = 4. At this point, I cannot reach the UKC with "boot -c". How can I overcome this? "Intel X553 SGMII" rev 0x11 at pci10 dev 0 function 0 not configured "Intel X553 SGMII" rev 0x11 at pci10 dev 0 function 1 not configured "Intel C3000 ME HECI" rev 0x11 at pci0 dev 24 function 0 not configured "Intel C3000 UART" rev 0x11 at pci0 dev 26 function 0 not configured "Intel C3000 UART" rev 0x11 at pci0 dev 26 function 1 not configured "Intel C3000 UART" rev 0x11 at pci0 dev 26 function 2 not configured sdhc0 at pci0 dev 28 function 0 "Intel C3000 eMMC" rev 0x11: apic 2 int 16 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma pcib0 at pci0 dev 31 function 0 "Intel C3000 LPC" rev 0x11 "Intel C3000 PMC" rev 0x11 at pci0 dev 31 function 2 not configured "Intel C3000 SMBus" rev 0x11 at pci0 dev 31 function 4 not configured "Intel C3000 SPI" rev 0x11 at pci0 dev 31 function 5 not configured isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo C▒▒+ сJͅс▒▒ɻ▒▒▒J▒Ł▒▒: ns16550a, 16 byte fifo pcppi0 at isa0 port 0x61 spkr0 at pcppi0 wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33 lm1 at wbsio0 port 0xa10/8: NCT6776F vmm0 at mainbus0: VMX/EPT sdmmc0: can't enable card vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (1589b7458f9250cf.a) swap on sd0b dump on sd0b WARNING: / was not properly unmounted Automatic boot i Vertigo Altair , 3 May 2020 Paz, 17:29 tarihinde şunu yazdı: > Hello Again, > I have already disabled ACPI at the boot prompt, but the result didn't > change.Thanks for suggestion.. > > Andrea Fleckenstein , 3 May 2020 Paz, 16:41 tarihinde > şunu yazdı: > >> Vertigo Altair writes: >> >> Hello, >> >> I had a Dell XPS 8100 with a similar problem and I was able to get >> around it by disabling ACPI at the boot prompt. Of course, we have very >> different machines, but it's worth a shot. Unfortunately the boot was >> extremely slow, on the order of 10min with acpi reenabled, and several >> minutes >> without it. Hopefully someone more knowledgeable than me will give a >> more reasoned answer. Good luck. >> >> Best, >> Andrea >> >> > Hi, >> > I have a Dell VEP 1445 Whitebox, I want to install OpenBSD 6.6. on it. >> But >> > When I try to boot, the boot process is stucking. There is no output >> after >> > " erase ^?, werase" >> > >> > BIOS Boot Selector for VEP1400-X >> > Version 3.48.0.9-4 >> > >> > >> > POST Configuration >> > CPU Signature 506F1 >> > CPU FamilyID=6, Model=5F, SteppingId=1, Processor=0 >> > Microcode Revision 2E >> > Platform ID: 0x0 >> > PMG_CST_CFG_CTL: 0x37 >> > Misc EN: 0x840089 >> > Gen PM ConA: 0xA0A00200 >> > Therm Status: 0x800 >> > POST Control=0xEA000F03, Status=0xE600DF00 >> > >> > BIOS initializations... >> > >> > CPGC Memtest Channel 0 .. PASS >> > >> > POST: >> > RTC Battery OK at last cold boot >> > RTC date 5/3/2020 9:24:11 >> > >> > POST SPD test ... PASS >> > >> > POST Lower DRAM Memory test . >> > POST ECC Test ... PASS >> > >> > Perf cnt (curr,fixed): 0x32AFD1520,0x8B637FB20 >> > >> > POST Lower DRAM Memory test . PASS >> > POST Lower DRAM ECC check ... PASS >> > >> > Current BOOT from Primary BIOS >> > DxE POST >> > >> > POST Upper DRAM Memory test >> > Short memory cell test >> > >> > POST Upper DRAM Memory test . PASS >> > HDD Access .. PASS >> > USB device detected >> > Temperature test PASS >> > FAN controller test . PASS >> > EEPROM test . PASS >> > POST PCI test ... PASS >> > POST BMC Interface test . PASS >> > POST NVRAM check PASS >> > POST overall test results ... PASS >> > >> > NVRAM: 00 DF 00 E6 03 0F 00 EA 01 55 3E __ 00 0F 00 F7 >> > Version 2.19.1266. Copyright (C) 2019 American Megatrends, Inc. >> > BIOS Date: 06/26/2019 22:19:26 Ver: 0ACHI040 >> > Press or to enter setup. >> > probing: pc0 com1 com2 com3 mem[640K 1894M 117M 972K 4M 14336M] >> > disk: hd0 hd1* hd2* >> >>> OpenBSD/amd64 BOOTX64 3.46 >> > boot> stty com0 115200 >> > boot> set tty com0 >> > switching console to com0 >> >>> OpenBSD/amd64 BOOTX64 3.46 >> > boot> >> > cannot open hd0a:/etc/random.seed: No such file or directory >> > booting hd0a:/6.6/amd64/bsd.rd: 3732171+1537024+3885432+0+598016 >> > [376562+128+455544+303577]=0xa648
Privoxy crashes on one OpenBSD machine but not another
I'm migrating my system configs from one OpenBSD machine (Pentium 4) to another (Core 2 Duo). I noticed unpredictable crashes of the Privoxy package when run and used on the C2D computer. These crashes don't occur on the P4 at all, with the same traffic. Both computers are running the same versions of OpenBSD-stable 6.6 with the latest syspatches, and the same versions of Privoxy. As part of my testing I copied over the old Privoxy config and files as closely as possible, with the same result. I did the same with my fstab options, pf.conf, and anything else that I thought might interact with Privoxy. I tried launching the daemon from gdb to diagnose the problem, but the package of course has no debug symbols. When gdb ran it from the /var/privoxy chroot, the process crashed with a SIGPIPE. When I tested it running outside the chroot, it crashed with a SIGABRT due to a use-after-free. Privoxy also develops problems resolving its own IP address, but this might be a separate issue/misconfiguration. Having come up short, I turn to you. What might be causing this issue on one computer but not the other? How can I explore further to find a solution? Are there crash logs that I am overlooking? (Incidentally, the reason for the initial move to the new machine is because within the past few weeks the P4 box suddenly began rebooting continuously under network load. Privoxy traffic is apparently under the threshold to trigger this problem, which I was also unable to diagnose or fix, and might be a bug report for another day.) dmesg follows: OpenBSD 6.6 (GENERIC.MP) #8: Fri Apr 17 15:06:32 MDT 2020 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4173365248 (3980MB) avail mem = 4034170880 (3847MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (75 entries) bios0: vendor Dell Inc. version "A07" date 06/13/2012 bios0: Dell Inc. OptiPlex 380 acpi0 at bios0 acpi0: TCPA checksum error: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT MCFG HPET TCPA SLIC SSDT SSDT SSDT acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) 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 E7500 @ 2.93GHz, 2926.40 MHz, 06-17-0a 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,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 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 E7500 @ 2.93GHz, 2926.00 MHz, 06-17-0a 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,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpimcfg0: addr 0x149f0888b5d7, bus 243-249 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PCI4) acpiprt2 at acpi0: bus 2 (PCI2) acpiprt3 at acpi0: bus -1 (PCI3) acpiprt4 at acpi0: bus 1 (PCI1) acpiprt5 at acpi0: bus -1 (PCI5) acpiprt6 at acpi0: bus -1 (PCI6) acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS acpibtn0 at acpi0: VBTN "*pnp0c14" at acpi0 not configured acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 cpu0: Enhanced SpeedStep 2926 MHz: speeds: 2933, 2667, 2400, 2133, 1867, 1600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel G41 Host" rev 0x03 ppb0 at pci0 dev 1 function 0 "Intel G45 PCIE" rev 0x03: msi pci1 at ppb0 bus 1 bge0 at pci1 dev 0 function 0 "Broadcom BCM5722" rev 0x00, BCM5755 C0 (0xa200): msi, address 00:10:18:5a:74:e7 brgphy0 at bge0 phy 1: BCM5722 10/100/1000baseT PHY, rev. 0 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: apic 8 int 16 "Intel G41 Video" rev 0x03 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi azalia0: codecs: Realtek ALC269 audio0 at azalia0 ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi pci2 at ppb1 bus 2 bge1 at pci2 dev 0 function 0 "Broadcom BCM57780" rev 0x01, BCM57780 A1 (0x57780001): msi, address 78:2b:cb:ac:40:61 brgphy1 at bge1 phy 1: BC
Re: Privoxy crashes on one OpenBSD machine but not another
Hi, TJ writes: > > I tried launching the daemon from gdb to diagnose the problem, but the > package of course has no debug symbols. When gdb ran it from the > /var/privoxy chroot, the process crashed with a SIGPIPE. When I tested > it running outside the chroot, it crashed with a SIGABRT due to a > use-after-free. Privoxy also develops problems resolving its own IP > address, but this might be a separate issue/misconfiguration. I had it crashing on me all the time as well two years ago with similiar symptoms like you describe. I see that Privoxy 3.0.28 has had substantial improvements but you need to go to current or wait for 6.7 to get that. I include my, by now, archaeological back traces that seems to indicate problems with async resolving: (gdb) info registers rax0x322802 rbx0xbc1f59ba36a12927677211498 rcx0xbc284e5c30012930081211136 rdx0xbc234bb12e012928736236256 rsi0xdfdfdfdf 3755991007 rdi0xbc1f59b87e012927677204448 rbp0xbc1f59ba6200xbc1f59ba620 rsp0xbc1f59ba2d00xbc1f59ba2d0 r8 0x10101010101010172340172838076673 r9 0x8080808080808080 -9187201950435737472 r100x96a09c9d9693a0ff -7592896771096600321 r110x0 0 r120xbc234bb162012928736237088 r130xbbfcfa3cddb12918450277851 r140xbc27819b80812929866512392 r150x1bb443 rip0xbbfcf91c7f90xbbfcf91c7f9 eflags 0x10206 66054 cs 0x2b 43 ss 0x23 35 ds 0x23 35 es 0x23 35 fs 0x23 35 gs 0x23 35 (gdb) bt #0 0x0bc293f1e8e5 in getaddrinfo_async_run (as=0xbc296c3d100, ar=0xbc1f59ba138) at /usr/src/lib/libc/asr/getaddrinfo_async.c:515 #1 0x0bc293eec63c in _libc_asr_run_sync (as=0xbc296c3d100, ar=0xbc1f59ba138) at /usr/src/lib/libc/asr/asr.c:148 #2 0x0bc293f64f46 in _libc_getaddrinfo (hostname=0xbc234bb1620 "scontent.xx.fbcdn.net", servname=0xbc1f59ba36a "443", hints=0xbc1f59ba330, res=0xbc1f59ba328) at /usr/src/lib/libc/asr/getaddrinfo.c:47 #3 0x0bbfcf91c7f9 in load_action_files () from /usr/local/sbin/privoxy #4 0x0bbfcf91bd67 in load_action_files () from /usr/local/sbin/privoxy #5 0x0bbfcf92040c in load_action_files () from /usr/local/sbin/privoxy #6 0x0bbfcf91edf5 in load_action_files () from /usr/local/sbin/privoxy #7 0x0bc26629e39e in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:96 #8 0x0bc293ee9ebb in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 #9 0x in ?? () (gdb) Second crash> Program received signal SIGSEGV, Segmentation fault. [Switching to thread 490396] _libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46 46 free(p->ai_canonname); (gdb) bt #0 _libc_freeaddrinfo (ai=0x0) at /usr/src/lib/libc/net/freeaddrinfo.c:46 #1 0x06925e91cb8d in load_action_files () from /usr/local/sbin/privoxy #2 0x06925e91bd67 in load_action_files () from /usr/local/sbin/privoxy #3 0x06925e92040c in load_action_files () from /usr/local/sbin/privoxy #4 0x06925e91edf5 in load_action_files () from /usr/local/sbin/privoxy #5 0x0694ba53c39e in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:96 #6 0x0694a9946ebb in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 #7 0x in ?? () (gdb) info reg rax0x694be27b0007235915198464 rbx0x0 0 rcx0x694a9c0b0807235572904064 rdx0x694ac6d64407235617776704 rsi0x694a9aeddff7235571736063 rdi0x0 0 rbp0x695056a5e800x695056a5e80 rsp0x695056a5e700x695056a5e70 r8 0x694ac6d64407235617776704 r9 0x0 0 r100x2 2 r110x0 0 r120x694a2d8a0207235457032224 r130x695056a5f307237110751024 r140x0 0 r150x50 80 rip0x694a9966bb00x694a9966bb0 <_libc_freeaddrinfo+16> eflags 0x10246 66118 cs 0x2b 43 ss 0x23 35 ds 0x23 35 es 0x23 35 fs 0x23 35 gs 0x23 35 (gdb) Program received signal SIGSEGV, Segmentation fault. [Switching to thread 260559] 0x083d7f02d8e5 in getaddrinfo_async_run (as=0x83e17b97600, ar=0x83e04037548) at /usr/src/lib/libc/asr/getaddrinfo_async.c:515 515 return AS_FAMILY(as); Current language: auto; currently minimal (gdb) bt #0 0x083d7f02d8e5 in getaddrinfo_async_run (as=0x83e17b97600, ar=0x83e04037548) at /usr/src/lib/libc/asr/getaddrinfo_async.c:515 #1 0x083d7effb63c in
