Re: iked : pf.conf rule for outgoing traffic
* Thuban le [02-12-2018 19:16:09 +0100]: > Hi, > I need help to write a correct rule in pf.conf. > > I want : > > A -> B --> web > > The appearing IP of A is the B's one on the web. > > I managed to configure iked on A and B using default pubkeys according > to Stuart Henderson advices. > > iked.conf on A : > > ikev2 active ipcomp esp \ > from 192.168.100.0/16 to 0.0.0.0/0 \ > peer "xx.xx.xx.xx" \ > srcid "m...@moria.lan" \ > dstid "B-hostname.tld" \ > tag IKED > > iked.conf on B : > > ikev2 "warrior" passive esp \ > from 0.0.0.0/0 to 0.0.0.0/0 \ > local xx.xx.xx.xx peer any \ > srcid "B-hostname.tld" \ > tag IKED > > Auth works as expected : > > # iked -vvd > .. > sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to 192.168.100.122:4500 > policy 'policy1' > .. > > > But I can't reach internet from A through B. > > Here is the pf.conf on B (at least a small part of it) > > pass out on egress \ > from any to any tagged IKED \ > nat-to (egress) > > I'm still stuck at the same point. Can someone give me an example of a working configuration natting ot Internet? Regards.
Re: radeon driver bug?
On Thu, Dec 06, 2018 at 01:26:12PM +0900, 岡本健二 wrote: > in-current means stable 6.4? > No. Look in the FAQ. Look at the running -current page Look at what release -> stable is. Run -current only if you need something new, are developing base/ports or wish to help test the software/hardware being developed. It is not always stable. It could have new security problems temporarily before those changes are fixed or pulled out. However, OpenBSD runs ports and base code as a unit. You cannot run current without making your current up to date and using the latest version of ports/packages. Unless you find a nice spot and just stay there. OpenBSD is not a jumbled mess of code all over the place. It's one of many reasons that it has fewer bugs -> better security. Also, security specific methods are always under active development. Please read the entire FAQ and PF Guide. Please read all of the man pages for any commands you need to use or are interested in. Please learn what you can do with boot -s or boot -c. You will at some point need to use them. Search the mailing list archives for interesting topics. Figure out how to handle the filesystem when it gets hosed during a power failure. Figure out how to arrange your disklabel at install to let you use growfs. I also suggest that you learn to use ed. It's not hard to use, but it's really, really old. It's still actively maintained because it's 100% worth having. The command line is so powerful once you learn to use it. We don't want GUI interfaces for this stuff because we expect you to truly learn what to do and why. Have a good day, Chris Bennett
Intel X710-DA4 and Dell R420
Hi all, i just wanted to warn people not to buy X710-DA4 and try to insert it in Dell R420. You can insert it in Dell R620 just fine. nic - http://kosjenka.srce.hr/~hrvoje/nic.jpg r420 pci slot - http://kosjenka.srce.hr/~hrvoje/r420-pci.jpg On other hand don't put chinese X710-DA2 or something like that in Dell servers (tried on r420 and r620), because UEFI panics and won't boot. It works on IBM x3550 M4 server.. X710-DA2 that breaks Dell UEFI: https://www.ebay.com/itm/DELL-Intel-X710-DA2-Y5M7N-10GB-PCI-x8-Ethernet-Converged-Network-Adapter/183371328835?hash=item2ab1c86d43:g:ol4AAOSwcrNbbXYL:rk:30:pf:0
Re: X server gbm: failed to open any driver
It seems a bug in xlock program also.
When exit from xlock getting this:
...
/usr/X11R6/bin/xlock
(EE) Segmentation fault at address 0xac986a95000
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
(EE)
Please consult the The X.Org Foundation support
...
On 12/5/2018 8:05 PM, Denis wrote:
> I've just rebuilt Xenocara from -current with bsd-wrapper patch implemented.
>
> Getting the error when run startx:
> ..
> (==) Using system config derectory "/usr/X11R6/share/X11/xorg.conf.d"
> (EE)
> Fatal server error:
> (EE) no screens found(EE)
> (EE)
> Please consult the The X.Org Foundation support
> at http://wiki.x.org
> for help.
> (EE) Please also check the log file at
> "/home/deniza/.local/share/xorg/Xorg.0.log" for additional information.
> (EE)
> (EE) Server terminated with error (1). Closing log file.
> xinit: giving up
> xinit: unable to connecto to X server: Connection refused
> xinit: server error
>
> On 12/4/2018 6:08 AM, Jonathan Gray wrote:
>> On Mon, Dec 03, 2018 at 08:06:18PM +0300, Denis wrote:
>>> When X server starts on OpenBSD6.4amd64 I'm getting the message below
>>>
>>> ...
>>> (II) [KMS] Kernel modesetting enabled.
>>> gbm: failed to open any driver (search paths /usr/X11R6/lib/modules/dri)
>>> gbm: Last dlopen error: File not found
>>> failed to load driver: redeonsi
>>> EGL_MESA_drm_image required.
>>> spectrwm: Welcome to spectrwm ...
>>>
>>> Can it be fixed?
>>>
>>
>> As the radeonsi Mesa driver depends on libLLVM and libelf it can not
>> currently be included in the xenocara sets.
>>
>> With -current using Mesa 17.3.9 in xenocara and LLVM 6.0 from ports it
>> is possible to build it yourself.
>>
>> Install libelf and llvm packages, apply the below patch and then build
>> xenocara.
>>
>> Index: lib/mesa/Makefile.bsd-wrapper
>> ===
>> RCS file: /cvs/xenocara/lib/mesa/Makefile.bsd-wrapper,v
>> retrieving revision 1.21
>> diff -u -p -r1.21 Makefile.bsd-wrapper
>> --- lib/mesa/Makefile.bsd-wrapper23 Oct 2018 06:35:32 - 1.21
>> +++ lib/mesa/Makefile.bsd-wrapper4 Dec 2018 02:44:28 -
>> @@ -11,7 +11,7 @@ GALLIUM_DRIVERS= swrast
>>
>> .if ${MACHINE} == i386 || ${MACHINE} == amd64
>> DRI_DRIVERS=swrast,radeon,r200,i915,i965
>> -GALLIUM_DRIVERS=swrast,r300,r600
>> +GALLIUM_DRIVERS=swrast,r300,r600,radeonsi
>> .endif
>>
>> .if ${MACHINE} == arm64 || ${MACHINE} == loongson || \
>> @@ -23,7 +23,8 @@ GALLIUM_DRIVERS=swrast,r300,r600
>> CONFIGURE_ARGS= --with-dri-drivers=${DRI_DRIVERS} \
>> --with-gallium-drivers=${GALLIUM_DRIVERS} \
>> --disable-silent-rules \
>> ---disable-llvm \
>> +--enable-llvm \
>> +--with-llvm-prefix=/usr/local \
>> --disable-glx-tls \
>> --disable-regen-sources \
>> --enable-gles1 --enable-gles2 \
>> @@ -70,6 +71,25 @@ O2= ${O1} -fthread-jumps -fcrossjumping
>>
>> CONFIGURE_ARGS+= USER_CFLAGS="-O0 ${O2}"
>> .endif
>> +
>> +PKGCONFIG_LIBDIR=
>> /usr/lib/pkgconfig:${X11BASE}/lib/pkgconfig:/usr/local/lib/pkgconfig
>> +
>> +XENOCARA_PATH= /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
>> +
>> +config.status:
>> +PKG_CONFIG_LIBDIR="${PKGCONFIG_LIBDIR}" \
>> +CONFIG_SITE=$(CONFIG_SITE) \
>> +CC=${CC} \
>> +CFLAGS="${CFLAGS}" \
>> +CXX=${CXX} \
>> +CXXFLAGS="${CXXFLAGS}" \
>> +AR_FLAGS="cruD" \
>> +MAKE="${MAKE}" \
>> +PATH=$(XENOCARA_PATH) \
>> +sh ${_SRCDIR}/configure --prefix=${X11BASE} \
>> +--sysconfdir=/etc \
>> +--mandir=${X11BASE}/man \
>> +${CONFIGURE_ARGS}
>>
>> ${.OBJDIR}/src/util/format_srgb.c:
>> lndir -s -e obj -e obj.${MACHINE_ARCH} -e Makefile.bsd-wrapper
>> ${.CURDIR}
>>
>
Re: iked : pf.conf rule for outgoing traffic
On 2018-12-06, Thuban wrote: > * Thuban le [02-12-2018 19:16:09 +0100]: >> Hi, >> I need help to write a correct rule in pf.conf. >> >> I want : >> >> A -> B --> web >> >> The appearing IP of A is the B's one on the web. >> >> I managed to configure iked on A and B using default pubkeys according >> to Stuart Henderson advices. >> >> iked.conf on A : >> >> ikev2 active ipcomp esp \ >> from 192.168.100.0/16 to 0.0.0.0/0 \ >> peer "xx.xx.xx.xx" \ >> srcid "m...@moria.lan" \ >> dstid "B-hostname.tld" \ >> tag IKED >> >> iked.conf on B : >> >> ikev2 "warrior" passive esp \ >> from 0.0.0.0/0 to 0.0.0.0/0 \ >> local xx.xx.xx.xx peer any \ >> srcid "B-hostname.tld" \ >> tag IKED >> >> Auth works as expected : >> >> # iked -vvd >> .. >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to 192.168.100.122:4500 >> policy 'policy1' >> .. >> >> >> But I can't reach internet from A through B. >> >> Here is the pf.conf on B (at least a small part of it) >> >> pass out on egress \ >> from any to any tagged IKED \ >> nat-to (egress) >> >> > > I'm still stuck at the same point. > Can someone give me an example of a working configuration natting ot > Internet? I used this, pass in on enc0 inet from $some_net pass out quick on egress inet received-on enc0 nat-to $some_address Also I don't remember what you've already said you checked, but make sure you have sysctl net.inet.ip.forwarding=1.
relayd: Layer 7 proxy: forward failed
Hi,
i am trying to use relayd as an outbound proxy. I am following the
manual page and also the book "Httpd and Relayd Mastery". I did this on
the latest release 6.4 and also on the latest snapshot to make sure this
was not already fixed somewhere. I am on amd64.
My relayd config looks like this:
# cat /etc/relayd.conf
relay "proxy" {
listen on 127.0.0.1 port 8080
forward to destination
}
relay "proxy2" {
listen on 192.168.0.19 port 9090
forward to destination
}
I use this command to open up a connection from a different host in the
network:
$ curl -i -x 192.168.0.19:9090 openbsd.org
I used the following command when i am on the same host:
$ curl -i -x 127.0.0.1:8080 openbsd.org
I get the same error every time:
# relayd -df /etc/relayd.conf
startup
pfe: filter init done
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
parent_tls_ticket_rekey: rekeying tickets
relay_privinit: adding relay proxy
protocol -1: name default
flags: used, relay flags: divert
tls session tickets: disabled
type: tcp
relay_privinit: adding relay proxy2
protocol -1: name default
flags: used, relay flags: divert
tls session tickets: disabled
type: tcp
init_tables: created 0 tables
relay_launch: running relay proxy
relay_launch: running relay proxy
relay_launch: running relay proxy2
relay_launch: running relay proxy
relay_launch: running relay proxy2
relay_launch: running relay proxy2
relay_connect: session 1: forward failed: Operation not permitted
relay_close: sessions inflight decremented, now 0
I used the following addition to the default pf.conf.
pass in on egress inet proto tcp to port 80 divert-to 127.0.0.1 port 8080
Is this a bug in my setup or a problem with relayd?
I also tryed the entire config from the book "Httpd and Relayd Mastery"
and even when i type it down 1 by 1 i get the same error.
Thanks and greetings
Leo
# dmesg
OpenBSD 6.4-current (GENERIC) #473: Wed Dec 5 21:55:23 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056899072 (1007MB)
avail mem = 1015734272 (968MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 1700X Eight-Core Processor, 3400.47 MHz, 17-01-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,MMXX,FFXSR,RDTSCP,LONG,LAHF,AMCR8,ABM,SSE4A,MASSE,3DNOWP,FSGSBASE,AVX2,RDSEED,CLFLUSHOPT
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu0: mwait min=64, max=64
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpiac0 at acpi0: AC unit online
acpivideo0 at acpi0: GFX0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 128-sector PIO, LBA, 16384MB, 33554432 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02:
Re: Pflow granularity
Hi, i found this old thread and i have the same problem. i need an active timeout of the netflow data. i found this patch http://marc.info/?l=openbsd-misc&m=124661838923498&w=2 which i can set the "set timeout pflowexport 60" for example Have anyone tried that ? Sebastian Benoit wrote: however right now some people are working on something similar. Is the another solution ? Thanks Thomas Diese Nachricht wurde versandt mit Webmail von www.tbits.net. This message was sent using webmail of www.tbits.net.
Mac laptop to iked errors
Folks, Fiddling with a basic iked configuration: ikev2 roadwarrior \ from any to 172.31.0.0/20 \ local 172.31.15.102 peer any \ config address 172.31.0.224/28 \ config protected-subnet 172.31.0.0/20 \ tag "IKED" I created a ca and certs using ikectl using hostnames. When I try to connect from my Mac laptop, I get the following errors (running iked with -d -vvv flags): > ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00 > length 8 > ikev2_pld_ts: count 1 length 0 > ikev2_pld_ts: malformed payload: too short for ts (4 < 8) > ikev2_msg_send: IKE_AUTH response from 172.31.15.102:4500 to > 108.31.7.69:39749 msgid 1, 1456 bytes, NAT-T > pfkey_sa_add: update spi 0x8b007e45 > pfkey_sa: udpencap port 39749 > ikev2_childsa_enable: loaded CHILD SA spi 0x8b007e45 > pfkey_sa_add: add spi 0x0758c03b > pfkey_sa: udpencap port 39749 > ikev2_childsa_enable: loaded CHILD SA spi 0x0758c03b > pfkey_flow: unsupported address family 0 > ikev2_childsa_enable: failed to load flow > ikev2_dispatch_cert: failed to send ike auth What am I doing wrong? --Paul smime.p7s Description: S/MIME cryptographic signature
default terminal autoload disable afater xenodm login
After changing X Display Manager to xenodm + spectrwm as win manager I have an additional terminal load just after xenodm login. I've disabled 'xconsole' in /etc/X11/xenodm/Xsetup_0 by commenting it. # cat ~/.xsessinon export ENV=$HOME/.kshrc xsetroot -solid grey & xterm -bg black -fg white +sb & /usr/local/bin/spectrwm After login I have one xterm with black background, and the second one (xconsole) I want to disable. It loads by default once login is accepted. Please advice to do that
Error -14 from sane-backends, pixma
Hi, I'm having no success to scan negative film on my Canoscan 9000F Mark II. I'm using OpenBSD 6.4 stable, sane-backends 1.0.27p3, and xsane 0.999p4. http://www.sane-project.org/sane-mfgs.html says that support for this scanner is "complete". The scanner works fine on Mac OS X. The scanimage command successfully recognizes the scanner then gives me "[pixma] BUG: unmapped error -14". Details are below. Thanks for your help. Marc. $ usbdevs -v -d /dev/usb0 -a 4 addr 04: 04a9:190d Canon, CanoScan high speed, self powered, config 1, rev 0.02 driver: ugen1 $ ls -l /dev/ugen1.* /dev/usb0 crw-rw 1 root _saned 63, 16 Oct 18 21:31 /dev/ugen1.00 crw-rw 1 root _saned 63, 17 Oct 18 21:31 /dev/ugen1.01 crw-rw 1 root _saned 63, 18 Oct 18 21:31 /dev/ugen1.02 crw-rw 1 root _saned 63, 19 Oct 18 21:31 /dev/ugen1.03 crw-rw 1 root _saned 63, 20 Oct 18 21:31 /dev/ugen1.04 crw-rw 1 root _saned 63, 21 Oct 18 21:31 /dev/ugen1.05 crw-rw 1 root _saned 63, 22 Oct 18 21:31 /dev/ugen1.06 crw-rw 1 root _saned 63, 23 Nov 21 19:54 /dev/ugen1.07 crw-rw 1 root _saned 63, 24 Oct 18 21:31 /dev/ugen1.08 crw-rw 1 root _saned 63, 25 Oct 18 21:31 /dev/ugen1.09 crw-rw 1 root _saned 63, 26 Oct 18 21:31 /dev/ugen1.10 crw-rw 1 root _saned 63, 27 Oct 18 21:31 /dev/ugen1.11 crw-rw 1 root _saned 63, 28 Oct 18 21:31 /dev/ugen1.12 crw-rw 1 root _saned 63, 29 Oct 18 21:31 /dev/ugen1.13 crw-rw 1 root _saned 63, 30 Oct 18 21:31 /dev/ugen1.14 crw-rw 1 root _saned 63, 31 Oct 18 21:31 /dev/ugen1.15 crw-rw 1 root _saned 61, 0 Oct 18 21:31 /dev/usb0 $ groups marc wheel _saned $ scanimage -L device `pixma:04A9190D' is a CANON Canoscan 9000F Mark II multi-function peripheral $ SANE_DEBUG_PIXMA=4 scanimage -v -T [sanei_debug] Setting debug level of pixma to 4. [pixma] pixma is compiled with pthread support. [pixma] pixma version 0.17.37 [pixma] pixma_collect_devices() found Canoscan 9000F Mark II at libusb:000:004 [pixma] WARNING:No serial number [pixma] pixma_find_scanners() found 1 devices [pixma] pixma_collect_devices() found Canoscan 9000F Mark II at libusb:000:004 [pixma] WARNING:No serial number [pixma] pixma_open(): Canoscan 9000F Mark II [pixma] Reader task started [pixma] [pixma] pixma_scan(): start [pixma] line_size=1914 image_size=1678578 channels=3 depth=8 [pixma] dpi=75x75 offset=(0,0) dimension=638x877 [pixma] gamma_table=0x151b98b60a38 source=0 [pixma] threshold=127 threshold_curve=0 [pixma] adf-wait=0 [pixma] ADF page count: 0 [pixma] Reader task id=23210381893184 (threaded) scanimage: scanning image of size 638x877 pixels at 24 bits/pixel scanimage: acquiring RGB frame, 8 bits/sample scanimage: reading one scanline, 1914 bytes...[pixma] Current status: paper=0 cal=0 lamp=0 busy=0 [pixma] Current status: paper=0 cal=0 lamp=0 busy=0 [pixma] Current status: paper=0 cal=0 lamp=0 busy=0 [pixma] Lamp status: 3 , timeout in: 19 [pixma] pixma_read_image() failed EEOF [pixma] [pixma] read_image():reader task closed the pipe:0 bytes received, 1678578 bytes expected Reader task terminated: EEOF [pixma] BUG: unmapped error -14 FAIL Error: Error during device I/O [pixma] pixma_close(): Canoscan 9000F Mark II
Re: Thinkpad T430 random power off while sleeping
On 12/4/2018 2:12 PM, Charles A Daniels wrote: Closing the lid on the T430 causes OpenBSD to suspend, as per my setting for machdep.lidaction=1. This usually works as expected, but occasionally I take my laptop out of my bag to find it sitting on the xenodm login screen, not suspended, with the lid closed, having lost power and rebooted at some point after being suspended. I would like to collect further information so a bug report can be filed, but I feel that the above description alone is insufficient to constitute a useful bug report. To that end, I would like to solicit advice on what information can be collected and what debugging steps can be taken so that I can write a useful bug report. I'm running the 6.4 release, and I have run fw_update and syspatch periodically since install. I previously asked for help on r/openbsd[1], but still have not been able to either resolve the problem or gather sufficient information for a bug report. ~ Charles 1 - https://old.reddit.com/r/openbsd/comments/9v0u4w/t430_wakes_from_suspend_with_lid_closed/ I have a similar issue with the X220, the problem is a watchdog timer, that I suspect is in the Intel ME. It expires without being reset and forces the machine to restart. Or at least that is the cause of that happening on my X230's. I've ripped a few of them apart and analyzed their guts and found only the CPU and a few other chips are active during suspend. I've probed all the buses of those other chips and none make a peep when the machine reboots, the only chip left active is the Intel ME chunk of the CPU, and for obvious reasons, I have no idea what it is doing, so I suspect it is the culprit. I gave up on the work a few months ago since it seemed easier to just accept that suspend isn't going to work and just use suspend-to-disk or just shut the machine down completely. If you want to do more, and have access to a Windows machine, you can try pulling apart the Lenovo drivers to see what the Lenovo-specific ACPI driver is doing when the machine goes into suspend.
Re: Pflow granularity
Thomas Boernert(m...@tbits.net) on 2018.12.06 18:11:17 +0100: > Hi, > > i found this old thread and i have the same problem. i need an active > timeout of the netflow data. > > i found this patch > http://marc.info/?l=openbsd-misc&m=124661838923498&w=2 > which i can set the "set timeout pflowexport 60" for example > > Have anyone tried that ? > > Sebastian Benoit wrote: > however right now some people are working on something similar. > > Is the another solution? No, the other solution never happened. By all means, try the diff, maybe it still works. /Benno
Re: Pflow granularity
Hi Benno, have you tried the diff by yourself ? Thanks Thomas Am 2018-12-06 21:14, schrieb Sebastian Benoit: Thomas Boernert(m...@tbits.net) on 2018.12.06 18:11:17 +0100: Hi, i found this old thread and i have the same problem. i need an active timeout of the netflow data. i found this patch http://marc.info/?l=openbsd-misc&m=124661838923498&w=2 which i can set the "set timeout pflowexport 60" for example Have anyone tried that ? Sebastian Benoit wrote: however right now some people are working on something similar. Is the another solution? No, the other solution never happened. By all means, try the diff, maybe it still works. /Benno Diese Nachricht wurde versandt mit Webmail von www.tbits.net. This message was sent using webmail of www.tbits.net.
Re: radeon driver bug?
I'm using acme also on OpenBSD. I don't know any better editor than that. Of course, where acme cannot use, such as cui only, I use ed. Kenji 2018年12月6日(木) 21:38 Chris Bennett : > On Thu, Dec 06, 2018 at 01:26:12PM +0900, 岡本健二 wrote: > > in-current means stable 6.4? > > > > No. Look in the FAQ. Look at the running -current page > Look at what release -> stable is. > > Run -current only if you need something new, are developing base/ports > or wish to help test the software/hardware being developed. > It is not always stable. It could have new security problems temporarily > before those changes are fixed or pulled out. > > However, OpenBSD runs ports and base code as a unit. You cannot run > current without making your current up to date and using the latest > version of ports/packages. Unless you find a nice spot and just stay > there. > > OpenBSD is not a jumbled mess of code all over the place. It's one of > many reasons that it has fewer bugs -> better security. Also, security > specific methods are always under active development. > > Please read the entire FAQ and PF Guide. Please read all of the man > pages for any commands you need to use or are interested in. > > Please learn what you can do with boot -s or boot -c. You will at some > point need to use them. Search the mailing list archives for interesting > topics. Figure out how to handle the filesystem when it gets hosed > during a power failure. Figure out how to arrange your disklabel at > install to let you use growfs. > > I also suggest that you learn to use ed. It's not hard to use, but it's > really, really old. It's still actively maintained because it's 100% > worth having. > > The command line is so powerful once you learn to use it. We don't want > GUI interfaces for this stuff because we expect you to truly learn what > to do and why. > > Have a good day, > Chris Bennett > > >
sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3
Hello, Im running a router with multiple ips on an interface using the inet alias issue: when commenting out configured aliases on hostname.if after running sh /etc/netstart vio4 if you run ifconfig vio4 after the restart of the interface the old aliases that were commented still appear in ifconfig output ahead of the first ip address configured in the /etc/hostname.vio4 file. ifconfig before commenting out 10.134.91.253 in hostname.vio4 is listed below vio4: flags=8843 mtu 1500 lladdr 16:2c:a4:f2:b4:e3 index 5 priority 0 llprio 3 media: Ethernet autoselect status: active inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235 inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239 inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243 inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247 inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 after commenting out the last 2 inet aliases , and running sh /etc/netstart vio4 the ifconfig output is as follows (i have highlighted with *** the addresses which I think should have been removed vio4: flags=8843 mtu 1500 lladdr 16:2c:a4:f2:b4:e3 index 5 priority 0 llprio 3 media: Ethernet autoselect status: active ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251 ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255 inet 10.94.0.1 netmask 0x broadcast 10.94.255.255 inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67 inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71 inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75 inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87 inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91 inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95 inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163 inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167 inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171 inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175 inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195 inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199 inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203 inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207 inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211 inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215 inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219 inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223 inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227 inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231 inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235 inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239 inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243 inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247 This behaviour is counter intuitive as it is different to sh /etc/netstart behaviour on the configuration of inet addresses im wondiring is this a feature or a bug ... or m
Re: radeon driver bug?
I checked mesa-18.3.0 sources under src/gallium/drivers/r600 and compared with those of xenocara. File names are all same, however, individual sizes are very different for most of those, which would not permit me to copy those to xenocara... Kenji 2018年12月6日(木) 15:14 岡本健二 : > also, it stull has some bugs, because the colors of some > parts are different from those of original ones. > > Kenji > > > 2018年12月6日(木) 15:10 岡本健二 : > >> Sorry, I'm a novice to OpenBSD. >> Yes, it's current branch of xenocara. >> I updated my xenocara (stable) to that current, and build new xenocara >> here. >> >> Wow, it makes the Jahshaka works! >> >> However, it still has some bugs, because it moves and stop suddenly and >> then >> move again. Whine the animation stops, the system seems to halting... >> >> Anyway it makes much advance, I included the screenshot of it. >> >> Kenji >> >> PS: sorry tfrohwein, this is doubled to you >> >> 2018年12月6日(木) 13:26 岡本健二 : >> >>> in-current means stable 6.4? >>> >>> Kenji >>> >>> 2018年12月5日(水) 23:58 tfrohw...@fastmail.com : >>> On December 5, 2018 9:41:44 AM UTC, "岡本健二" wrote: >This errors come from >/usr/xenocara/lib/mesa/src/gallium/drivers/r600/r600_state_common.c. >The mesa version of OpenBSD6.4 is 13.0.6. >I'm running this Jahshaka on Ubutu 18.04, where the mesa version is >18.x. > >So, it may be the mesa problem... > >Kenji > > >2018年12月4日(火) 16:19 岡本健二 : > >> I'm using AMD HD6450 graphic card which I reported before, and faced >a >> curious thing >> during running Jahshaka Studio (dev version 7.03a). >> To run Jahshaka on OpenBSD 6.4 I needed to delete google breakpad >> temporally, which >> is not the problem now. >> >> After start to run 'Jahshaka Studio', I got start 3D animation sample >> 'Skeletal Animation' data to load, then >> I got many errors included below which seems to come from radeon drm >> driver's bug to me. >> If you interested please check it. >> >> Thanks in advance >> >> Kenji >> >> There's a known bug where the shader on r600 uses too many registers: https://bugs.freedesktop.org/show_bug.cgi?id=99349 I encountered this bug with godot on a Radeon HD 7570, too, and it went away with the updated mesa that's in -current. >>>
