Re: Debug / Driver / Kernel / WiFi
Hi all, The patch below works fine for me and fixes the *[ERROR: ath0 unable to reset hardware]* issue that I had on my FUJITSU SIEMENS ESPRIMO Mobile U9210. Patch is relative to -current. Please check. Many Thanks Stefan Sperling for Code Review and strong support with Copyright! Oleg Pahl (Munich) On 10/06/18 14:28, Stefan Sperling wrote: On Sat, Oct 06, 2018 at 01:32:55PM +0200, NN wrote: Hi all, Many thanks for your support and reply! I am not Profi (I have experience < 1year with OpenBSD and C Programming.), that why its will take me a lot of time to fix and try something. After Mr. Sperling first review of my Code ... I have made few fixes. In attachment you can see my new patch. Please, try it and send me your feedback. Its working for me. (*no more ERROR: ath0 unable to reset hardware*) Thank you! This is looking great. I see only two remaining problems: Please don't use C++-style // comments. The lines commented this way can just be removed. More importantly it looks like these changes are based on work done by Nick Kossifidis in Linux ath5k. I am quoting the relevant changes from the Linux git log below. So I doubt this is your original work. It is OK to copy this code into OpenBSD because it is licensed under ISC, the same licence used by our ath(4) driver which this Linux code was based on. But only under the condition that we give attribution to the original author. So please copy Nick's copyright line into our files as well. You can find it at the top of each file you've copied code from. And then we should be good to go. commit cc6323c7d8c231d83e592ff9f7acf2cac5e016f7 Author: Nick Kossifidis Date: Sun Jul 20 06:44:43 2008 +0300 ath5k: Update channel functions * Add channel function for RF2425 (got this from decompiling binary HAL, i have no idea why there is a 5GHz section but i'm looking into it) * Update RF5112 channel function (also got this from decompiling binary HAL) * Set JAPAN setting for channel 14 on all PHY chips Changes-licensed-under: ISC Signed-off-by: Nick Kossifidis Signed-off-by: John W. Linville diff --git a/drivers/net/wireless/ath5k/phy.c b/drivers/net/wireless/ath5k/phy.c index 66af70bd14e7..cbc362d20719 100644 --- a/drivers/net/wireless/ath5k/phy.c +++ b/drivers/net/wireless/ath5k/phy.c @@ -1898,9 +1898,6 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah, data = data0 = data1 = data2 = 0; c = channel->center_freq; - /* -* Set the channel on the RF5112 or newer -*/ if (c < 4800) { if (!((c - 2224) % 5)) { data0 = ((2 * (c - 704)) - 3040) / 10; @@ -1912,7 +1909,7 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah, return -EINVAL; data0 = ath5k_hw_bitswap((data0 << 2) & 0xff, 8); - } else { + } else if ((c - (c % 5)) != 2 || c > 5435) { if (!(c % 20) && c >= 5120) { data0 = ath5k_hw_bitswap(((c - 4800) / 20 << 2), 8); data2 = ath5k_hw_bitswap(3, 2); @@ -1924,6 +1921,9 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah, data2 = ath5k_hw_bitswap(1, 2); } else return -EINVAL; + } else { + data0 = ath5k_hw_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8); + data2 = ath5k_hw_bitswap(0, 2); } data = (data0 << 4) | (data1 << 1) | (data2 << 2) | 0x1001; @@ -1934,6 +1934,45 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah, return 0; } +/* + * Set the channel on the RF2425 + */ +static int ath5k_hw_rf2425_channel(struct ath5k_hw *ah, + struct ieee80211_channel *channel) +{ + u32 data, data0, data2; + u16 c; + + data = data0 = data2 = 0; + c = channel->center_freq; + + if (c < 4800) { + data0 = ath5k_hw_bitswap((c - 2272), 8); + data2 = 0; + /* ? 5GHz ? */ + } else if ((c - (c % 5)) != 2 || c > 5435) { + if (!(c % 20) && c < 5120) + data0 = ath5k_hw_bitswap(((c - 4800) / 20 << 2), 8); + else if (!(c % 10)) + data0 = ath5k_hw_bitswap(((c - 4800) / 10 << 1), 8); + else if (!(c % 5)) + data0 = ath5k_hw_bitswap((c - 4800) / 5, 8); + else + return -EINVAL; + data2 = ath5k_hw_bitswap(1, 2); + } else { + data0 = ath5k_hw_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8); + data2 = ath5k_hw_bitswap(0, 2); + } + + data = (data0 << 4) | data2 << 2 | 0x1001; + + ath5k_hw_reg_write(ah, data & 0xff, AR5K_RF_BUFFER); + ath5k_hw_reg_write(ah, (data >> 8) & 0x7f, AR5K_RF_BUFFER_CONTROL_5); + + return 0; +} + /* * Set a channel on the radio chip */ @@ -1963,6 +2002
Re: ThinkPad X220 Trackpoint Pointer Wheel Emulation Issues
On 10/17/2018 06:21 PM, Jake Champlin wrote: > On Tue, Oct 16, 2018 at 09:45:52PM -0400, Charles Daniels wrote: >> First off, I'm new around here, so my apologies in advance if this is >> the wrong list or I've formatted something incorrectly. >> >> I've recently installed OpenBSD 6.3 on my Thinkpad X220. I'm happy to >> report that almost everything seems to work the way it should >> (suspend/resume, wireless, volume controls, etc.). However, I've been >> having some difficulty with the TrackPoint. >> >> The TrackPoint works fine as a pointing device, however the "WS >> Pointer Wheel Emulation" emulation feature is not working. For those >> unfamiliar, this allows the middle mouse button to be held down, and >> while it is held, the TrackPoint can be used to scroll vertically or >> horizontally. >> >> After conducting some research, I have written the following script to >> set the appropriate xinput properties to properly enable the pointer >> wheel emulation functionality: >> >> #!/bin/sh >> >> xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation" 1 >> xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Button" 2 >> xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Axes" 6 7 4 5 >> xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Timeout" 500 >> xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Inertia" 20 >> >> I have tried many different variations on the input parameters. >> One interesting behavior I have discovered is that if I set the >> emulation axes to "4 5 0 0" then I can scroll up and down by moving >> the track point left or right by holding the middle mouse button. >> However, when I use "6 7 4 5" or "0 0 4 5", the up and down scrolling >> generally does not work at all (occasionally jumping in the direction >> the trackpoint was pushed). >> >> I have spent several days troubleshooting this issue and haven't had >> any luck. I think this may be a bug, but I wanted to see if anyone >> else had similar issues and knew of a solution before submitting a bug >> report. I am under the impression that this list does not permit >> attachments, so I will refrain from attaching the full output of dmesg >> and other long logs, but I will include the output of some >> commands that I think might be relevant. >> >> Finally, I tried digging into some of the source code for Xenocara and >> the wsmouse drive. Unfortunately, my knowledge of OpenBSD and Xorg are >> insufficient to draw any useful conclusions. However, I think the >> following files may be relevant / a good starting point for someone >> more knowledgeable than I: >> >> * xenocara/driver/xf86-input-ws/include/ws-properties.h >> * xenocara/driver/xf86-input-ws/src/emuwheel.c >> >> I would really appreciate any suggestions to troubleshoot further. >> >> Charles >> >> >> ### possibly relevant output follows >> >> nessus$ dmesg | grep -i mouse >> wsmouse0 at pms0 mux 0 >> nessus$ dmesg | grep -i ws >> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) >> wsdisplay0: screen 1-5 added (std, vt100 emulation) >> wskbd0 at pckbd0: console keyboard, using wsdisplay0 >> wsmouse0 at pms0 mux 0 >> nessus$ xinput >> ⎡ Virtual core pointerid=2[master pointer (3)] >> ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer >> (2)] >> ⎜ ↳ /dev/wsmouse id=7[slave pointer >> (2)] >> ⎣ Virtual core keyboard id=3[master keyboard (2)] >> ↳ Virtual core XTEST keyboard id=5 [slave keyboard >> (3)] >> ↳ /dev/wskbd id=6 [slave keyboard >> (3)] >> nessus$ xinput list-props /dev/wsmouse >> Device '/dev/wsmouse': >> Device Enabled (140): 1 >> Coordinate Transformation Matrix (141): 1.00, 0.00, >> 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 >> Device Accel Profile (253): 0 >> Device Accel Constant Deceleration (254): 1.00 >> Device Accel Adaptive Deceleration (255): 1.00 >> Device Accel Velocity Scaling (256):10.00 >> WS Pointer Middle Button Emulation (257): 2 >> WS Pointer Middle Button Timeout (258): 50 >> WS Pointer Wheel Emulation (259): 1 >> WS Pointer Wheel Emulation Axes (260): 4, 5, 0, 0 >> WS Pointer Wheel Emulation Inertia (261): 20 >> WS Pointer Wheel Emulation Timeout (262): 500 >> WS Pointer Wheel Emulation Button (263):2 >> nessus$ cat /etc/X11/xorg.conf >> nessus$ X -version >> >> X.Org X Server 1.19.6 >> Release Date: 2017-12-20 >> X Protocol Version 11, Revision 0 >> Build Operating System: OpenBSD 6.3 amd64 >> Current Operating System: OpenBSD nessus.domain_redacted 6.3 GENERIC.MP#107 >> amd64 >> Build Date: 24 March 2018 02:38:24PM >> >> Current version of pixman: 0.34.0 >> Before reporting problems, c
Re: VMM sh: time sleep 30 takes 56 seconds
On Sat, Oct 13, 2018 at 07:37:49PM -0300, Daniel Bolgheroni wrote: > On Sat, Oct 13, 2018 at 01:08:23AM +, Jordan Geoghegan wrote: > > Hello, > > > > Not sure if this is a bug or not, so I thought I would ask misc@ first. > > > > I was writing a script in my vmm guest that involved killing and restarting > > a long running process every hour using sleep "3600", and I noticed it ended > > up sleeping for 2 hours and 56 minutes, rather than an hour. > > > > To test, I ran "time sleep 30" and got this result: > > > > vmm$ time sleep 30 > > 0m57.50s real 0m00.00s user 0m00.00s system > > > > When run on bare metal, I get this result: > > > > server$ time sleep 30 > > 0m30.00s real 0m00.00s user 0m00.00s system > > > > I have "sysctl kern.timecounter.hardware=tsc" set in the vm to prevent clock > > drift, otherwise the vm clock runs at around half speed. > > > > When "time sleep 30" is run on a vm without "sysctl > > kern.timecounter.hardware=tsc" set, it reports the correct amount of time > > being spent sleeping, but since the clock runs at around half speed without > > tsc enabled, it still ends up sleeping for almost a minute. > > > > The host machine is running 6.3 stable, the guest is running the latest > > snapshot. I tried running a 6.3-stable guest with the same results. > > > > Has this been fixed in current? I don't have a vmm capable machine available > > running current, I only own spare macppc and i386 hardware which runs > > current. > > I get the same results as yours also with a -current vm running on > -current, also with kern.timecounter.hardware=tsc on the vm. > > # time sleep 30 > 0m59.99s real 0m00.00s user 0m00.00s system > # time sleep 30 > 1m00.30s real 0m00.00s user 0m00.00s system > # time sleep 30 > 1m00.30s real 0m00.00s user 0m00.00s system > # > > I don't know if it's somehow related to the same interrupt thing, but I > also get a slow scroll when attached to the console. A 1000Hz host helps here. I get 10.32s real time on sleep 10 with that setting. Note that qemu behaves the same way on OpenBSD. -ml
OpenSMTPd: "mail.lmtp: connect: Connection refused"
Hi misc, Please, let me know if this mailing list is not the right place for this question. I'm following -current and I found that maybe something is wrong with my setup. When the server boots the first time after an upgrade the emails from the installer are lost because of `result=PermFail stat=Error ("mail.lmtp: connect: Connection refused")`. I did a few tests and the problem appears when the dovecot is not running (or before it's been started during the boot cycle). Here is an example from maillog: Oct 17 22:22:31 hodor smtpd[78869]: a7712b562c43b7b1 smtp connected address=local host=hodor.bsdbg.net Oct 17 22:22:32 hodor smtpd[78869]: a7712b562c43b7b1 smtp message address=local host=hodor.bsdbg.net msgid=704c1aab from= to= size=328 ndest=1 proto=ESMTP Oct 17 22:22:32 hodor smtpd[78869]: a7712b562c43b7b1 smtp disconnected address=local host=hodor.bsdbg.net reason=quit Oct 17 22:22:32 hodor smtpd[78869]: mda delivery evpid=704c1aabd946b708 from= to= rcpt= user=vmail delay=0s result=PermFail stat=Error ("mail.lmtp: connect: Connection refused") Oct 17 22:22:33 hodor smtpd[78869]: a7712b5a30d2accc smtp connected address=local host=hodor.bsdbg.net Oct 17 22:22:33 hodor smtpd[78869]: a7712b5a30d2accc smtp message address=local host=hodor.bsdbg.net msgid=65c0ef95 from=<> to= size=1634 ndest=1 proto=ESMTP Oct 17 22:22:33 hodor smtpd[78869]: a7712b5a30d2accc smtp disconnected address=local host=hodor.bsdbg.net reason=quit Oct 17 22:22:33 hodor smtpd[78869]: mda delivery evpid=65c0ef9534eb622c from=<> to= rcpt= user=vmail delay=0s result=PermFail stat=Error ("mail.lmtp: connect: Connection refused") Oct 17 22:22:33 hodor smtpd[10845]: warn: queue: no return path! The smtpd.conf follows: pki hodor.bsdbg.net cert "/etc/ssl/bsdbg.fullchain.pem" pki hodor.bsdbg.net key "/etc/ssl/private/bsdbg.key" table aliases file:/etc/mail/aliases table domains file:/etc/mail/domains table virtuals file:/etc/mail/virtuals table credentials sqlite:/etc/mail/sqlite.conf listen on lo0 listen on vether0 port submission tls pki hodor.bsdbg.net auth listen on egress tls pki hodor.bsdbg.net listen on egress port submission tls-require pki hodor.bsdbg.net auth action "local" lmtp "/var/dovecot/lmtp" rcpt-to alias action "virtual" lmtp "/var/dovecot/lmtp" rcpt-to virtual action "relay" relay match from local for local action "local" match from any for domain action "virtual" match from local for any action "relay" Do you know what has been changed in smtpd so my setup is not working as expected anymore? Thanks in advance! Atanas dmesg: OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1713408 (16340MB) avail mem = 16605519872 (15836MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb5a0 (56 entries) bios0: vendor American Megatrends Inc. version "2.3" date 06/12/2018 bios0: Supermicro X9SCL/X9SCM acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SPMI SSDT SSDT DMAR EINJ ERST HEST BERT acpi0: wakeup devices PS2K(S4) UAR1(S4) UAR2(S4) P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(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) Xeon(R) CPU E3-1230 V2 @ 3.30GHz, 3293.17 MHz, 06-3a-09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz, 3292.53 MHz, 06-3a-09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz, 3292.52 MHz, 06-3a-09 cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SM
Re: Rate limiting on UDP with PF
On Wed, 17 Oct 2018 17:59:08 +0200, cont...@jdubois.me wrote: > I am trying to rate limit UDP with Packet Filter. I know there are > rules to rate limit on TCP such as "max number" or "max-src-conn-rate > number / interval" but I did not find anything for UDP. > > I still tried the options with these rules, but once the number of > states was reached, the NTP server kept answering the requests : > > pass in on $ext_if proto udp to 192.0.2.1 port 123 keep state (max 10) I think the closest to your goal is max-pkt-rate, see: https://man.openbsd.org/pf.conf.5#max-pkt-rate Note it won't block the IP like it does for TCP, the rule simply stops matching packets. This parameter was added to OpenBSD recently, but if you run a supported OpenBSD version, it should be fine ;) Cheers, Daniel
wordpress on httpd with custom URL permalinks
Hey guys, For anyone banging their head against the wall trying to get Wordpress 'pretty' permalinks working with httpd request rewrite, here's an alternative. All credits go to Ve Telko and his post (https://marc.info/?l=openbsd-misc&m=152996292328684&w=2) that steered me in the right direction.With setting permalinks to a custom structure of "http://example.com/%post_id%/"; and using index.php as the document root for the matched requests, the requests get passed correctly. httpd.conf (httpd and php-fpm chrooted to /var/www, Wordpress installed in /var/www/wordpress):server "example.com" { listen on 127.0.0.1 port 80 root "/wordpress" directory index index.php location "/*.php" { fastcgi socket "/run/wordpress.sock" } location match "/(.*)" { root "/wordpress/index.php" fastcgi socket "/run/wordpress.sock" } log access wordpress-access.log log error wordpress-error.log } If anyone managed to solve this using the request rewrite option, I'd be delighted to find out how.Regards.
Rate limiting on UDP with PF
Hi, I am trying to rate limit UDP with Packet Filter. I know there are rules to rate limit on TCP such as "max number" or "max-src-conn-rate number / interval" but I did not find anything for UDP. I still tried the options with these rules, but once the number of states was reached, the NTP server kept answering the requests : pass in on $ext_if proto udp to 192.0.2.1 port 123 keep state (max 10) --- table persist block in quick from pass in on $ext_if proto udp to 192.0.2.1 port 123 keep state \ (max-src-conn-rate 10/50, overload flush global) Is there a way to do that ? Regards, Jérémy.
Re: ThinkPad X220 Trackpoint Pointer Wheel Emulation Issues
On Tue, Oct 16, 2018 at 09:45:52PM -0400, Charles Daniels wrote: > First off, I'm new around here, so my apologies in advance if this is > the wrong list or I've formatted something incorrectly. > > I've recently installed OpenBSD 6.3 on my Thinkpad X220. I'm happy to > report that almost everything seems to work the way it should > (suspend/resume, wireless, volume controls, etc.). However, I've been > having some difficulty with the TrackPoint. > > The TrackPoint works fine as a pointing device, however the "WS > Pointer Wheel Emulation" emulation feature is not working. For those > unfamiliar, this allows the middle mouse button to be held down, and > while it is held, the TrackPoint can be used to scroll vertically or > horizontally. > > After conducting some research, I have written the following script to > set the appropriate xinput properties to properly enable the pointer > wheel emulation functionality: > > #!/bin/sh > > xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation" 1 > xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Button" 2 > xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Axes" 6 7 4 5 > xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Timeout" 500 > xinput set-prop /dev/wsmouse "WS Pointer Wheel Emulation Inertia" 20 > > I have tried many different variations on the input parameters. > One interesting behavior I have discovered is that if I set the > emulation axes to "4 5 0 0" then I can scroll up and down by moving > the track point left or right by holding the middle mouse button. > However, when I use "6 7 4 5" or "0 0 4 5", the up and down scrolling > generally does not work at all (occasionally jumping in the direction > the trackpoint was pushed). > > I have spent several days troubleshooting this issue and haven't had > any luck. I think this may be a bug, but I wanted to see if anyone > else had similar issues and knew of a solution before submitting a bug > report. I am under the impression that this list does not permit > attachments, so I will refrain from attaching the full output of dmesg > and other long logs, but I will include the output of some > commands that I think might be relevant. > > Finally, I tried digging into some of the source code for Xenocara and > the wsmouse drive. Unfortunately, my knowledge of OpenBSD and Xorg are > insufficient to draw any useful conclusions. However, I think the > following files may be relevant / a good starting point for someone > more knowledgeable than I: > > * xenocara/driver/xf86-input-ws/include/ws-properties.h > * xenocara/driver/xf86-input-ws/src/emuwheel.c > > I would really appreciate any suggestions to troubleshoot further. > > Charles > > > ### possibly relevant output follows > > nessus$ dmesg | grep -i mouse > wsmouse0 at pms0 mux 0 > nessus$ dmesg | grep -i ws > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > wsmouse0 at pms0 mux 0 > nessus$ xinput > ⎡ Virtual core pointer id=2 [master pointer (3)] > ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer > (2)] > ⎜ ↳ /dev/wsmouse id=7 [slave pointer > (2)] > ⎣ Virtual core keyboard id=3 [master keyboard (2)] > ↳ Virtual core XTEST keyboard id=5 [slave keyboard > (3)] > ↳ /dev/wskbd id=6 [slave keyboard > (3)] > nessus$ xinput list-props /dev/wsmouse > Device '/dev/wsmouse': > Device Enabled (140): 1 > Coordinate Transformation Matrix (141): 1.00, 0.00, > 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 > Device Accel Profile (253): 0 > Device Accel Constant Deceleration (254): 1.00 > Device Accel Adaptive Deceleration (255): 1.00 > Device Accel Velocity Scaling (256): 10.00 > WS Pointer Middle Button Emulation (257): 2 > WS Pointer Middle Button Timeout (258): 50 > WS Pointer Wheel Emulation (259): 1 > WS Pointer Wheel Emulation Axes (260): 4, 5, 0, 0 > WS Pointer Wheel Emulation Inertia (261): 20 > WS Pointer Wheel Emulation Timeout (262): 500 > WS Pointer Wheel Emulation Button (263): 2 > nessus$ cat /etc/X11/xorg.conf > nessus$ X -version > > X.Org X Server 1.19.6 > Release Date: 2017-12-20 > X Protocol Version 11, Revision 0 > Build Operating System: OpenBSD 6.3 amd64 > Current Operating System: OpenBSD nessus.domain_redacted 6.3 GENERIC.MP#107 > amd64 > Build Date: 24 March 2018 02:38:24PM > > Current version of pixman: 0.34.0 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > > The jumping up and down vertically should have been fixed via this
Re: 6.3-Can't boot. panic: aml_die aml_parse:4194 on PowerEdge R640
Could you try -current? Jan On Wed, Oct 17, 2018 at 12:15:32AM -0700, Luthing wrote: > Hello misc@ > > I'm currently testing new Dell PowerEdge R640 with a classic 6.3. > > I installed raid controller with a 2 disks RAID 1. > I also tried without RAID configured. > > The installation is successfully completed, but each time it boots, I'm > getting this error : > http://kosjenka.srce.hr/~hrvoje/zaprocvat/dell_r640/dell_r640_bsd.jpg > > Would you suggest something to make it works? > > Many thanks > Regards > Luthing > > > > > > -- > Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html >
Re: [relayd] set response header for tagged connexion
* tomr le [17-10-2018 15:37:42 +1100]: > > > On 10/17/18 4:14 AM, Thuban wrote: > > Hi, > > I want to set a header according to the requested path. The goal is to > > increase > > the cache-control according to file extension. > > > > For now, I have in relayd.conf something like : > > > > match request path "/*.css" tag "CSS" > > match tagged "CSS" response header set "Cache-Control" value > > "max-age=1814400" > > I think you might want to try moving 'response' left, so the line begins > 'match response tagged ' > > t > That's it, thanks. Now I have this configuration, if anyone is interested to increase cache on his website : match request path "/*.html" tag "HTML" match request path "/*.css" tag "CACHE" match request path "/*.js" tag "CACHE" match request path "/*.atom" tag "CACHE" match request path "/*.rss" tag "CACHE" match request path "/*.jpg" tag "CACHE" match request path "/*.png" tag "CACHE" match request path "/*.svg" tag "CACHE" match request path "/*.gif" tag "CACHE" match request path "/*.ico" tag "CACHE" match response tagged "CACHE" header set "Cache-Control" value "max-age=1814400" match response tagged "HTML" header set "Content-Type" value "text/html; charset=UTF-8" -- thuban
6.3-Can't boot. panic: aml_die aml_parse:4194 on PowerEdge R640
Hello misc@ I'm currently testing new Dell PowerEdge R640 with a classic 6.3. I installed raid controller with a 2 disks RAID 1. I also tried without RAID configured. The installation is successfully completed, but each time it boots, I'm getting this error : http://kosjenka.srce.hr/~hrvoje/zaprocvat/dell_r640/dell_r640_bsd.jpg Would you suggest something to make it works? Many thanks Regards Luthing -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Redistributing between bgpd and ospfd
On Wed, Oct 17, 2018 at 01:07:32PM +0200, Sebastian Benoit wrote: > open...@kene.nu(open...@kene.nu) on 2018.10.17 12:44:02 +0200: > > Hello, > > > > On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit > > wrote: > > > > > > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200: > > > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote: > > > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > > > > > > Hello, > > > > > > > > > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its > > > > > > keepalives. I will ponder the value of transporting the underlay in > > > > > > OSPF, effectively transporting loopback peering addresses for BGP in > > > > > > OSPF. I am not sure that it will make my life easier but will > > > > > > consider > > > > > > it. > > > > > > > > > > OSPF is generally faster at converging after reroute and it is > > > > > possible to > > > > > set the router-dead-time to minimal which will give you a 1 second > > > > > timeout. Also the default of 40sec is lower than the 90sec of BGP. > > > > > Additionally OSPF may give you multipath routes so the failover for > > > > > BGP > > > > > may be not noticable. Also GRE has a way to emulate link state but to > > > > > be > > > > > honest if I use OSPF on a GRE link I will not turn it on (unless > > > > > requested). > > > > > > > > I guess the brewing BFD support would speed this up for BGP when it > > > > arrives > > > > and make OSPF less useful if speed is the thing that needs to be solved. > > > > > > > > Also I've been thinking about the following config in ospfd > > > > > > > > rtlabel label external-tag number > > > > Map route labels to external route tags and vice versa. > > > > The > > > >external route tag is a non-negative 32-bit number > > > >attached to AS-external OSPF LSAs. > > > > > > > > What exactly does this mean? As I understand it is to map rtlabels to > > > > LSA > > > > Type 5 tags. But what do you do with it then? Could this be used for > > > > what > > > > this thread is talking about or is it totally off? > > > > > > If you do this on two (or more routers) you distribute the routes and they > > > end up in the fib with that rtlabel (note the "and vice versa"). > > > > > > You can do all the things you can do with route labels, for example use > > > them in pf filters. > > > > > > And yes, you could also use it to redistribute them into bgp (although > > > that > > > needs to happen on another router i think): > > > > > > ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ... > > > hostA hostB hostBhostB > > > > > > /Benno > > > > I might be wrong here but in prder to have ospfd generate type 5 LSAs > > one needs both a BGP speaker that announces the prefix in question > > into ospf and two different ospf areas in your network? > > No need for a bgp speaker: a route in the routing table with the label is > enough. > > So here is a rough description of how ospfd and bgpd announce new prefixes > (i.e. the ones not learned from other routers). > > ospfd looks at whats in the kernel routing table (FIB), and depending on its > configuration (the interface statements _and_ redistribute commands) it adds > routes into its ospfd internal RIB. That RIB is then propagated into the > ospf network (skip ospf protocol details here). > > ospfd needs routes in the FIB to inject new routes into OSPF. > > By inject, i mean "add a new network to the routes in the RIB". > > BGPD on the other hand has the "network " statement. > > It adds the prefix given there to its RIB ("injects it into BGP") without > the need for a route in the FIB. > > The additional options (network priority ..., network rtlabel ...) are > only there for convinience and special cases, they are not really needed > for standard bgp setups. > > > Or can I make ospfd generate type5 LSAs in some other way? I see that > > rtlabels would do it but that implies I have an already existing route > > in the fib which preemptively I tag in some way. In my case the routes > > are generated by interface statements in ospfd.conf (so type1 and 2 > > LSAs). > > If you use interface statements, those interfaces have IPs on them, which you > will find have routes in the routing table. > > Also, there is "ifconfig rtlabel ..." > > I don't know if ospfd will pick those route-labels up (with the rtlabel > statement). I think it should, but havent used that or looked at the code. > The rtlabel / external-tag mapping only works for Type-5 LSA which are prefixes ospfd picked up via any of the redistribute statements. Any prefix covered by interface statements end up as non Type-5 LSA and so will not use the mapping. This includes stub networks. I have not tried to use "ifconfig rtlabel ..." with ospfd together but I see no reason why it should not work if used with redistribute connected for example. -- :wq Claudio
Re: Redistributing between bgpd and ospfd
open...@kene.nu(open...@kene.nu) on 2018.10.17 12:44:02 +0200: > Hello, > > On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit wrote: > > > > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200: > > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote: > > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > > > > > Hello, > > > > > > > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its > > > > > keepalives. I will ponder the value of transporting the underlay in > > > > > OSPF, effectively transporting loopback peering addresses for BGP in > > > > > OSPF. I am not sure that it will make my life easier but will consider > > > > > it. > > > > > > > > OSPF is generally faster at converging after reroute and it is possible > > > > to > > > > set the router-dead-time to minimal which will give you a 1 second > > > > timeout. Also the default of 40sec is lower than the 90sec of BGP. > > > > Additionally OSPF may give you multipath routes so the failover for BGP > > > > may be not noticable. Also GRE has a way to emulate link state but to be > > > > honest if I use OSPF on a GRE link I will not turn it on (unless > > > > requested). > > > > > > I guess the brewing BFD support would speed this up for BGP when it > > > arrives > > > and make OSPF less useful if speed is the thing that needs to be solved. > > > > > > Also I've been thinking about the following config in ospfd > > > > > > rtlabel label external-tag number > > > Map route labels to external route tags and vice versa. The > > >external route tag is a non-negative 32-bit number > > >attached to AS-external OSPF LSAs. > > > > > > What exactly does this mean? As I understand it is to map rtlabels to LSA > > > Type 5 tags. But what do you do with it then? Could this be used for what > > > this thread is talking about or is it totally off? > > > > If you do this on two (or more routers) you distribute the routes and they > > end up in the fib with that rtlabel (note the "and vice versa"). > > > > You can do all the things you can do with route labels, for example use > > them in pf filters. > > > > And yes, you could also use it to redistribute them into bgp (although that > > needs to happen on another router i think): > > > > ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ... > > hostA hostB hostBhostB > > > > /Benno > > I might be wrong here but in prder to have ospfd generate type 5 LSAs > one needs both a BGP speaker that announces the prefix in question > into ospf and two different ospf areas in your network? No need for a bgp speaker: a route in the routing table with the label is enough. So here is a rough description of how ospfd and bgpd announce new prefixes (i.e. the ones not learned from other routers). ospfd looks at whats in the kernel routing table (FIB), and depending on its configuration (the interface statements _and_ redistribute commands) it adds routes into its ospfd internal RIB. That RIB is then propagated into the ospf network (skip ospf protocol details here). ospfd needs routes in the FIB to inject new routes into OSPF. By inject, i mean "add a new network to the routes in the RIB". BGPD on the other hand has the "network " statement. It adds the prefix given there to its RIB ("injects it into BGP") without the need for a route in the FIB. The additional options (network priority ..., network rtlabel ...) are only there for convinience and special cases, they are not really needed for standard bgp setups. > Or can I make ospfd generate type5 LSAs in some other way? I see that > rtlabels would do it but that implies I have an already existing route > in the fib which preemptively I tag in some way. In my case the routes > are generated by interface statements in ospfd.conf (so type1 and 2 > LSAs). If you use interface statements, those interfaces have IPs on them, which you will find have routes in the routing table. Also, there is "ifconfig rtlabel ..." I don't know if ospfd will pick those route-labels up (with the rtlabel statement). I think it should, but havent used that or looked at the code. /Benno
Re: Redistributing between bgpd and ospfd
Hello, On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit wrote: > > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200: > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote: > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > > > > Hello, > > > > > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its > > > > keepalives. I will ponder the value of transporting the underlay in > > > > OSPF, effectively transporting loopback peering addresses for BGP in > > > > OSPF. I am not sure that it will make my life easier but will consider > > > > it. > > > > > > OSPF is generally faster at converging after reroute and it is possible to > > > set the router-dead-time to minimal which will give you a 1 second > > > timeout. Also the default of 40sec is lower than the 90sec of BGP. > > > Additionally OSPF may give you multipath routes so the failover for BGP > > > may be not noticable. Also GRE has a way to emulate link state but to be > > > honest if I use OSPF on a GRE link I will not turn it on (unless > > > requested). > > > > I guess the brewing BFD support would speed this up for BGP when it arrives > > and make OSPF less useful if speed is the thing that needs to be solved. > > > > Also I've been thinking about the following config in ospfd > > > > rtlabel label external-tag number > > Map route labels to external route tags and vice versa. The > >external route tag is a non-negative 32-bit number > >attached to AS-external OSPF LSAs. > > > > What exactly does this mean? As I understand it is to map rtlabels to LSA > > Type 5 tags. But what do you do with it then? Could this be used for what > > this thread is talking about or is it totally off? > > If you do this on two (or more routers) you distribute the routes and they > end up in the fib with that rtlabel (note the "and vice versa"). > > You can do all the things you can do with route labels, for example use > them in pf filters. > > And yes, you could also use it to redistribute them into bgp (although that > needs to happen on another router i think): > > ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ... > hostA hostB hostBhostB > > /Benno I might be wrong here but in prder to have ospfd generate type 5 LSAs one needs both a BGP speaker that announces the prefix in question into ospf and two different ospf areas in your network? Or can I make ospfd generate type5 LSAs in some other way? I see that rtlabels would do it but that implies I have an already existing route in the fib which preemptively I tag in some way. In my case the routes are generated by interface statements in ospfd.conf (so type1 and 2 LSAs). >