Re: What are xxxterm users using today?
https://marc.info/?l=openbsd-ports&m=148587723122194&w=2 — gonzalo > On 31. Jan 2020, at 18:46, Allan Streib wrote: > > I used to use xxxterm, then xombrero, and really liked the minimal > approach and keyboard driven navigation. > > Any other former users of this browser, what are you using today to > achieve any of this functionality in your browser? > > Allan >
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
I don’t remember now the version we have in 6.8 but are you compiling it for some reason instead of use the package? — gonzalo > On 27. Jan 2021, at 13:31, Carlos Lopez wrote: > > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the > following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with > --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez
Re: thinkpad sl500: iwn0: radio is disabled by hardware switch
OpenBSD version? Dmesg? The man of iwn(4) it's pretty clear about that error. 2010/5/21 Gregory Edigarov : > Hi, > > Where is that 'hardware switch'? > > > -- > With best regards, >Gregory Edigarov
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Download again the tar files from official mirrors and try again the upgrade. 2010/6/1 Uwe Dippel : > Joachim Schipper joachimschipper.nl> writes: > >> Just untarring the release should work, but it's still odd. At least > the >> md5sum of pfctl matches what I just downloaded, so that seems >> fine; did you actually use *that* tarball, though? (Note that the >> "right" pfctl binary is 500856 bytes long.) >> >> Are you sure that you upgraded the right disk? > > Yep. > > When I untar the files (I have them locally on a webserver: > ftp://metalab.uniten.edu.my/pub/OpenBSD/4.7/ > all files come out perfectly well, as above. I did the upgrades using this > URL; I am sure it were these files, because they only exist once locally > (the speed with which the updates were done is proof that I used these local > resources, downloaded by myself). In the Upgrade procedure I only added the > (internal) IP for that server, accepting all else. And it can't be 4.6 that > I used, kind of, because the installed (upgraded) kernel is 4.7. > I need to repeat, this is a remote production machine with serial access. I > have no desire ever to do anything not along clear procedures, and I > followed the Upgrade Guide 4.6->4.7 meticulously (system administration is > part of my job description), even ticking off point after point on the > printout of the upgrade guide. > So something was done to the files, at least they have the new time stamp, > and some files have actually been installed correctly (kernels); as the > hashsums show. So, finally, I *was* in the right directory and installed to > the correct disk. > Here are the kernels, on the first machine, that has seemingly the > previous 'base' throughout: > # cksum -a sha256 bsd > SHA256 (bsd) = > e2af09ed48d1d94bec27aa4c18ffa6172d8435a190c3abecae53d26940ed9536 > # cksum -a sha256 bsd.sp > SHA256 (bsd.sp) = > a34175b766d6ea9cefcc0903efa51c4dc3d87018b1e2f85c2333133ed25e9ff4 > > Now I wonder if the problem was with the untar? Maybe all sets have not been > installed properly? Next, I will have to identify for each and every set, a > sample file, and check if it is the previous one or the recent one. > > Very, very strange ... > > Thanks so much, you did actually help me a step further, > > Uwe
Re: It is 2010. Still no >3GB support by default?
don't feed the trolls 2010/6/7 Adam M. Dutko : > Maybe it's more attributable to increased interest and the increase has > brought a proportional increase in what you call "trolls." More noise is > distracting but has "fringe" benefits...sometimes... > > On Jun 7, 2010 9:01 PM, "Jason Beaudoin" wrote: > > maybe I haven't been on this list long enoug.. but it seems like 2010 > has been the year of the troll, first update to the chinese calander > in ages.. > > > > On Mon, Jun 7, 2010 at 2:52 PM, Dexter Tomisson > wrote: >> I'd really, reall...
Re: another slow connection on openbsd 3.4
http://www.openbsd.org/faq/faq6.html#Tuning 2010/8/24 Hendro Susanto : > Hi, I just read the article from > http://www.pubbs.net/201005/openbsd/14859-strangely-slow-openbsd-server-connection.html > > However, my problem was just started since last week. > The system was fine and running smoothly for more 5 years! (PF and Squid > Cache). > > All the sudden the internet speed has been reduced by half - mine is 5Mbps > max and it only can get 2,5Mbps. > Have directly plugged into a laptop running Windows XP (instead of OpenBSD) > and the speed was fine. > > Any suggestions? > Do you think the internet provider has changed on their side e.g autoneg > etc? > > -hendro-
Ettercap issue
Hi there,
I have a issue using ettercap (ettercap-0.7.3p4-no_x11 multi-purpose
sniffer/interceptor/logger) in 4.7-release
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
RTC BIOS diagnostic error 80
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem = 268009472 (255MB)
avail mem = 250978304 (239MB)
RTC BIOS diagnostic error 80
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xe/0xa800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:0d:b9:1c:13:bc
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:0d:b9:1c:13:bd
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio
gpio0 at glxpcib0: 32 pins
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 3831MB, 7847280 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 12,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 12
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
biomask f3e7 netmask ffe7 ttymask
mtrr: K6-family MTRR support (2 registers)
nvram: invalid checksum
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
root on wd0a swap on wd0b dump on wd0b
clock: unknown CMOS layout
WARNING: clock time much less than file system time
WARNING: using file system time
WARNING: CHECK AND RESET THE DATE!
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding=1
# ettercap -T -i vr0
...sniff stuff...
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding=0
anyone with this problem?
regards.
Re: Ettercap issue
Sorry for the noise:
ettercap(8)
ettercap NG has a new unified sniffing method. This
implies that ip_forwarding in the kernel is always dis-
abled and the forwarding is done by ettercap. Every packet
with destination mac address equal to the host's mac
address and destination ip address different for the one
bound to the iface will be forwarded by ettercap. Before
forwarding them, ettercap can content filter, sniff, log
or drop them. It does not matter how these packets are
hijacked, ettercap will process them. You can even use
external programs to hijack packet.
You have full control of what ettercap should receive. You
can use the internal mitm attacks, set the interface in
promisc mode, use plugins or use every method you want.
IMPORTANT NOTE: if you run ettercap on a gateway, remember
ettercap NG-0.7.3 4
ETTERCAP(8) ETTERCAP(8)
to re-enable the ip_forwarding after you have killed
ettercap. Since ettercap drops its privileges, it cannot
restore the ip_forwarding for you.
Is in the manual.
thanks
2010/9/4 Gonzalo Rodriguez :
> Hi there,
>
> I have a issue using ettercap (ettercap-0.7.3p4-no_x11 multi-purpose
> sniffer/interceptor/logger) in 4.7-release
>
> OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
>dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> RTC BIOS diagnostic error 80
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
> 586-class) 499 MHz
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
> real mem = 268009472 (255MB)
> avail mem = 250978304 (239MB)
> RTC BIOS diagnostic error 80
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088
> pcibios0 at bios0: rev 2.1 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xe/0xa800
> cpu0 at mainbus0: (uniprocessor)
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:0d:b9:1c:13:bc
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:0d:b9:1c:13:bd
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
> 32-bit 3579545Hz timer, watchdog, gpio
> gpio0 at glxpcib0: 32 pins
> pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0:
> wd0: 1-sector PIO, LBA, 3831MB, 7847280 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 12,
> version 1.0, legacy support
> ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 12
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
> isa0 at glxpcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0:
> spkr0 at pcppi0
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
> biomask f3e7 netmask ffe7 ttymask
> mtrr: K6-family MTRR support (2 registers)
> nvram: invalid checksum
> vscsi0 at root
> scsibus0 at vscsi0: 256 targets
> softraid0 at root
> root on wd0a swap on wd0b dump on wd0b
> clock: unknown CMOS layout
> WARNING: clock time much less than file system time
> WARNING: using file system time
> WARNING: CHECK AND RESET THE DATE!
>
>
> # sysctl net.inet.ip.forwarding
> net.inet.ip.forwarding=1
>
> # ettercap -T -i vr0
> ...sniff stuff...
>
> # sysctl net.inet.ip.forwarding
> net.inet.ip.forwarding=0
>
> anyone with this problem?
>
> regards.
