urtw0 no network on yeeloong
I've not been able to establish a wireless connection lately on urtw0 on a yeeloong. ifconfig keeps showing a status of 'no network' on urtw0 both for the local wireless network here and another wifi network I've tried that used to work. The indicator light for the wireless device is on and 'ifconfig urtw0 scan' appears to show that the network is available. I try to connect using: ifconfig urtw0 nwid MYWLAN chan 11 mode 11g wpakey MYWPAKEY This access point itself is running a snapshot but on i386 instead and the nwid, wpakey, channel, and mode all seem to match what I set with ifconfig on the yeeloong. And I can connect to this network with another platform. The cabled interface (rl0) works fine. What do I need to change to get urtw0 to finish connecting and show a status of 'active' ? Regards, /Lars [ using 487264 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.6-current (GENERIC) #159: Thu Oct 30 19:20:44 MDT 2014 dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1058701312 (1009MB) mainbus0 at root: Lemote Yeeloong cpu0 at mainbus0: STC Loongson2F CPU 797 MHz, STC Loongson2F FPU cpu0: cache L1-I 64KB D 64KB 4 way, L2 512KB 4 way bonito0 at mainbus0: memory and PCI-X controller, rev 1 pci0 at bonito0 bus 0 rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 5, address 00:23:8b:59:df:48 rlphy0 at rl0 phy 0: RTL internal PHY smfb0 at pci0 dev 8 function 0 "Silicon Motion LynxEM+" rev 0xb0 wsdisplay0 at smfb0 mux 1: console (std, vt100 emulation) glxpcib0 at pci0 dev 14 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c isa0 at glxpcib0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 mcclock0 at isa0 port 0x70/2: mc146818 or compatible ykbec0 at isa0 port 0x381/3 gpio1 at glxpcib0: 32 pins iic at glxpcib0 not configured glxclk0 at glxpcib0: clock, prof pciide0 at pci0 dev 14 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, 991MB, 2030112 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 ignored (disabled) auglx0 at pci0 dev 14 function 3 "AMD CS5536 Audio" rev 0x01: isa irq 9, CS5536 AC97 ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0) audio0 at auglx0 ohci0 at pci0 dev 14 function 4 "AMD CS5536 USB" rev 0x02: isa irq 11, version 1.0, legacy support ehci0 at pci0 dev 14 function 5 "AMD CS5536 USB" rev 0x02: isa irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1 apm0 at mainbus0 umass0 at uhub0 port 1 configuration 1 interface 0 "Generic USB2.0-CRW" rev 2.00/58.87 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: SCSI0 0/direct removable serial.0bda015811417340 urtw0 at uhub0 port 4 "Realtek RTL8187B" rev 2.00/2.00 addr 3 urtw0: RTL8187B rev E, address 00:17:c4:4d:ed:56 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets pmon bootpath: /dev/disk/wd0 boot device: wd0 root on wd0a (78c08aaf23988299.a) swap on wd0b dump on wd0b umass1 at uhub0 port 2 configuration 1 interface 0 "JetFlash Mass Storage Device" rev 2.00/1.42 addr 4 umass1: using SCSI over Bulk-Only scsibus3 at umass1: 2 targets, initiator 0 sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct removable sd1: 3911MB, 512 bytes/sector, 8011774 sectors sd1 detached scsibus3 detached umass1 detached ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done! ehci_idone: ex=0x9800801693b0 is done!
Re: still loosing connections
On Sat, Nov 01, 2014 at 20:26, Stefan Wollny wrote: > An other case of TL:DR??? > > Please help me with a 'clue-stick' on how to investigate further. I think so. Your message is a million lines long, but I have no idea what the problem is.
Re: uscom/ucom hardware question [was: OpenBSD 5.6 Released]
On Sun, Nov 02, 2014 at 06:08, ropers wrote: > When I said I wanted to use a USB-only laptop *as* a serial console, > what I meant was this: > > 1. There is a headless computer that has a physical RS-232. This is > not the laptop. So what you want to know is if you can run "cu -l /dev/cuaU0" on a laptop with (e.g.) a uplcom adapter? Yes.
bridge + vlan broke after 5.5 > 5.6 upgrade
Hey All, TL;DR: traffic leaving a bridge over a vlan does not get tagged but leaves untagged after upgrade. Is this by design? Longer version: Lost most of my night trying to figure out why my setup ended up breaking. I found a solution but I am not exactly happy with it. I think this breakage may have been intended. However I am not sure, there were a couple of vlan-tagging fixes/changes between 5.5 and 5.6. My setup (worked fine from 5.4 -> 5.5): trunk0 (LACP+tagged vlans) = em0, em1, em2 vlan150, vlan200 and vlan300 over trunk0 tun0, tun1, tun2 and tun3 = OpenVPN vether0 = for ip/dhcp bridge0 = vlan150, vether0, tun0-tun3 Every worked fine on 5.4 and 5.5. Everything on the bridge was talking to each other including physical devices behind vlan150. After upgrading to 5.6 everything going over the bridge was fine except devices behind vlan150. After a lot of head scratching I noticed that traffic coming from the bridge did not get tagged with vlan id 150 but came out untagged. In the end worked around the issue by removing em0 from trunk0 and reconfiguring it on the switch to work as an access port. I swapped out vlan150 for em0 on the bridge and everything was working again. Not very happy with this work around but it will do for now. Anybody else experiencing this? Did it get broken by design? (AKA was I doing something stupid the last year? -- probably the case) Regards Jorge (sleepy sysadmin)
Re: bridge + vlan broke after 5.5 > 5.6 upgrade
Le 2 nov. 2014 13:52, "Jorge Schrauwen" a écrit : > > Hey All, > > TL;DR: traffic leaving a bridge over a vlan does > not get tagged but leaves untagged after upgrade. > Is this by design? > [...] > > Anybody else experiencing this? Did it get broken > by design? (AKA was I doing something stupid > the last year? -- probably the case) Hi, I'm also experiencing this after upgrading from 5.4 to -current. Mattieu Baptiste "/earth is 102% full ... please delete anyone you can." > > Regards > > Jorge (sleepy sysadmin)
Re: crypto softraid and keydisk on same harddrive
On Wed, 29 Oct 2014, Patrik Lundin wrote: > On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote: > > You could try this (only compile tested) diff: > > I tried this diff on 5.5-stable and it appeared to solve my problem! The > system now boots from sr0a without asking for a passphrase. Overwriting > the keydisk partition makes the bootloader stop at the passphrase prompt. Thanks - I'll rehash it and get it in at some point... as an aside, the easiest way to "destroy" a softraid CRYPTO volume is to simply run 'bioctl -c C -C force ...' as that will replace the block encryption keys in the metadata (and works regardless of passphrase or key disk). > Thanks a lot! > > Regards, > Patrik Lundin -- "Action without study is fatal. Study without action is futile." -- Mary Ritter Beard
FreeBSD's Capsicum
Hi, >From what I gather, RBAC / MAC isn't really necessary unless you add people to >your system that you don't really trust (ref. Nick Holland @ >http://marc.info/?l=openbsd-misc&m=139321387226212). But what about FreeBSD's >Capsicum? Thanks! O.D.
Re: FreeBSD's Capsicum
2014-11-02 16:49 GMT+01:00 : > Hi, > > From what I gather, RBAC / MAC isn't really necessary unless you add people > to your system that you don't really trust (ref. Nick Holland @ > http://marc.info/?l=openbsd-misc&m=139321387226212). But what about FreeBSD's > Capsicum? http://www.openbsdfoundation.org/gsoc2014.html Daniel
Re: AR8161 patch , FYI
On Sun, Nov 02, 2014 at 08:11:51AM +0100, o...@openbsd.se wrote: > I have tested the driver on both openbsd 5.5 and 5.6, not on current. > > > OpenBSD 5.6-stable (GENERIC.MP) #6: Sat Nov 1 14:02:01 CET 2014 > root@ubook.hagen.hassel:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4157509632 (3964MB) > avail mem = 4038041600 (3850MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebdb0 (22 entries) > bios0: vendor American Megatrends Inc. version "S400CA.207" date 12/27/2012 > bios0: ASUSTeK COMPUTER INC. S400CA > > ... > > alc0 at pci3 dev 0 function 0 "Attansic Technology AR8161" rev 0x10 > > > Diffs are appended. > I have tested the driver on hw L2C and AR8161. > When looking at the diff I saw that there are some obsolete predefinition > left in the code. They have not generated any warnings, but might be > confusing for a reviewer. > I read that the freebsd driver have som problems at long cable length. If you > have access to an artificial ethernet cable this could be a subject for > testing. > Hi, Thanks for your work. 'if_alc.c.diff' didn't apply correctly because of some formatting differences - mostly spaces and TABs. I spend few hours to correct it and now it apply against if_alc.c revision 1.27. 'if_alcreg.h' is not a diff, it's if_alcreg.h revision 1.4. I used if_alcreg.h from sourceforge.net. Both diffs are appended inline so other people could test. As a result my "Attansic Technology AR8161" works as it should. Best wishes, Atanas Index: if_alc.c === RCS file: /home/vlado/cvsync/cvsroot/src/sys/dev/pci/if_alc.c,v retrieving revision 1.27 diff -u -p -r1.27 if_alc.c --- if_alc.c22 Jul 2014 13:12:11 - 1.27 +++ if_alc.c2 Nov 2014 15:11:59 - @@ -1,5 +1,10 @@ + +/* $OpenBSD: if_alc.c,v 1.26 2013/12/28 03:34:53 deraadt Exp $ */ +/*- patched by oht to fit with the AR816X_FAMILY*/ + /* $OpenBSD: if_alc.c,v 1.27 2014/07/22 13:12:11 mpi Exp $ */ /*- +>>> 1.27 * Copyright (c) 2009, Pyun YongHyeon * All rights reserved. * @@ -26,7 +31,7 @@ * SUCH DAMAGE. */ -/* Driver for Atheros AR8131/AR8132 PCIe Ethernet. */ +/* Driver for Atheros AR8131/AR8132 AR8161/AR8162 AR8171/AR8172 PCIe Ethernet. */ #include "bpfilter.h" #include "vlan.h" @@ -84,12 +89,17 @@ voidalc_watchdog(struct ifnet *); intalc_mediachange(struct ifnet *); void alc_mediastatus(struct ifnet *, struct ifmediareq *); -void alc_aspm(struct alc_softc *, int); +void alc_aspm(struct alc_softc *, int, int); +void alc_aspm_813x(struct alc_softc *, int); +void alc_aspm_816x(struct alc_softc *, int); void alc_disable_l0s_l1(struct alc_softc *); intalc_dma_alloc(struct alc_softc *); void alc_dma_free(struct alc_softc *); intalc_encap(struct alc_softc *, struct mbuf **); void alc_get_macaddr(struct alc_softc *); + void alc_get_macaddr_813x(struct alc_softc *); + void alc_get_macaddr_816x(struct alc_softc *); + void alc_get_macaddr_par(struct alc_softc *); void alc_init_cmb(struct alc_softc *); void alc_init_rr_ring(struct alc_softc *); intalc_init_rx_ring(struct alc_softc *); @@ -97,9 +107,26 @@ voidalc_init_smb(struct alc_softc *); void alc_init_tx_ring(struct alc_softc *); intalc_intr(void *); void alc_mac_config(struct alc_softc *); + uint32_t alc_mii_readreg_813x(struct alc_softc *, int, int); + uint32_t alc_mii_readreg_816x(struct alc_softc *, int, int); + uint32_t alc_mii_writereg_813x(struct alc_softc *, int, int, int); + uint32_t alc_mii_writereg_816x(struct alc_softc *, int, int, int); + void alc_dsp_fixup(struct alc_softc *, int); + intalc_miibus_readreg(struct device *, int, int); void alc_miibus_statchg(struct device *); +intalc_miibus_writeregr(struct device *, int, int, int); void alc_miibus_writereg(struct device *, int, int, int); + uint32_t alc_miidbg_readreg(struct alc_softc *, int); + uint32_t alc_miidbg_writereg(struct alc_softc *, int, int); + uint32_t alc_miiext_readreg(struct alc_softc *, int, int); + uint32_t alc_miiext_writereg(struct alc_softc *, int, int, int); + //int alc_mediachange_locked(struct alc_softc *); + void alc_phy_reset_813x(struct alc_softc *); + void alc_phy_reset_816x(struct alc_softc *); + void alc_setwol_813x(struct alc_softc *); + void alc_setwol_816x(struct alc_softc *); + intalc_newbuf(struct alc_softc *, struct alc_rxdesc *); void alc_phy_down(struct alc_softc *); void alc_phy_reset(struct alc_softc *); @@ -116,6 +143,18 @@ void alc_stop_mac(struct alc_softc *); void alc_stop_queue(struct alc_softc *); void alc_tick(void *); void alc_txeof(struct alc_softc *); +void alc_init_pcie(struct alc_softc *, int); +void alc_config_msi(struct alc_softc *); + +intalc_dma_alloc(struct alc_softc *); +void alc_dma_free(struct alc_softc *
Re: UPDATE: www/tt-rss to 1.14
On 02.11.2014 17:29, Robert Peichaer wrote: Hi Atanas As you provided update diffs in the past, would you mind testing this update for tt-rss from 1.13 to 1.14? I don't have mysql running here and being lazy I would like to avoid setting one up just to test this update. Thanks Robert Hi, I've just updated and everything seems fine. Best wishes, Atanas
Re: still loosing connections
Am 11/02/14 um 07:04 schrieb Ted Unangst: > On Sat, Nov 01, 2014 at 20:26, Stefan Wollny wrote: >> An other case of TL:DR??? >> >> Please help me with a 'clue-stick' on how to investigate further. > > I think so. Your message is a million lines long, but I have no idea > what the problem is. > Hi Ted, thank you for taking your time to reply. Long story short: "Sometimes" (=not deliberately repeatable) when fetching a fresh snapshot and/or the sources afterwards and/or running 'pkg_add -ui' connections to the internet are lost, entirely. This happens with i386-current as well with amd64-current and with different providers. I have to bring down all interfaces and flush routes prior to 'sudo sh /etc/netstart' to get a connection - but even this does not always work - a restart is then required. My problem is: I have no clue where to look or how to investigate further into this issue. That is why I have described en détail what I am doing and added as much information as possible. Can you (or s.o. else) give me hint where to look? I feel kind of lost... Thank's a lot! Cheers, STEFAN BTW: By now I use OpenBSD 5.6-current (GENERIC.MP) #515: Sat Nov 1 20:55:07 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Upgrade56.html instead of Upgrade54.html
http://www.openbsd.org/faq/faq5.html#BldBinary [Quote] It is recommended that you install the binary by using the "Upgrade" option of the install media. If that is not possible, you can also unpack the binaries as described here. Regardless, you must do the entire upgrade process, including creating any users or other /etc directory changes needed. [/Quote] ...as described here... here should link to http://www.openbsd.org/faq/upgrade56.html instead of http://www.openbsd.org/faq/upgrade54.html I presume. Mario St-Gelais
`make` problem applying 5.6 errata
Hi, I've just upgraded a couple of 5.5 servers to 5.6 and apart from the issues I'm about to describe everything went smoothly (thanks!) As the final step of my upgrade procedure (following upgrade56.html, using install kernel as usual) it was time to fetch -stable source, which I did with: cvs -danon...@anoncvs.au.openbsd.org:/cvs checkout -rOPENBSD_5_6 -P src inside /usr. I built a new kernel without issue (again, normal process from FAQ) but when it came to building libssl (for errata 005) I got the following error from make: # cd /usr/src/lib/libssl/ssl # make obj /usr/src/lib/libssl/ssl/obj -> /usr/obj/lib/libssl/ssl # make make: don't know how to make /usr/src/lib/libssl/ssl/../src/e_os.h (prerequisite of: s3_meth.o) Stop in /usr/src/lib/libssl/ssl So, what did I do wrong? Cheers, Mark
Re: `make` problem applying 5.6 errata
On Mon, Nov 03, 2014 at 10:22, mark hellewell wrote: > Hi, > > I've just upgraded a couple of 5.5 servers to 5.6 and apart from the > issues I'm about to describe everything went smoothly (thanks!) > > As the final step of my upgrade procedure (following upgrade56.html, > using install kernel as usual) it was time to fetch -stable source, > which I did with: > > cvs -danon...@anoncvs.au.openbsd.org:/cvs checkout -rOPENBSD_5_6 -P src > > inside /usr. > > I built a new kernel without issue (again, normal process from FAQ) > but when it came to building libssl (for errata 005) I got the > following error from make: > > # cd /usr/src/lib/libssl/ssl > # make obj > /usr/src/lib/libssl/ssl/obj -> /usr/obj/lib/libssl/ssl > # make > make: don't know how to make /usr/src/lib/libssl/ssl/../src/e_os.h > (prerequisite of: s3_meth.o) > Stop in /usr/src/lib/libssl/ssl > > > So, what did I do wrong? That file was deleted before 5.6. It looks you built with a dirty obj directory.
security - "pass the hash" style attacks?
I know, that pass the hash is now getting a lot of playtime on windows. and I have heard in a couple of talks that its directly related to SSO part of the OS, and may be part of posix? is OpenBSD, or BSD in general vulnerable to these style attacks? or just the normal unix dump the password /etc/passwd table for offline attacks sorts of stuff? Thoughts -Nex6 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: OpenBSD 5.6 Released
I see, TCP wrappers has been removed i am assuming using only PF is the practice for stuff people who where using TCP wrappers for and, thanks for the hard work -Nex6 On Nov 1, 2014, at 10:22 AM, Antoine Jacoutot wrote: > November 1, 2014. > > We are pleased to announce the official release of OpenBSD 5.6. > This is our 36th release on CD-ROM (and 37th via FTP/HTTP). We remain > proud of OpenBSD's record of more than ten years with only two remote > holes in the default install. > > As in our previous releases, 5.6 provides significant improvements, > including new features, in nearly all areas of the system: > > - LibreSSL: >o This release forks OpenSSL into LibreSSL, a version of the > TLS/crypto stack with goals of modernizing the codebase, improving > security, and applying best practice development processes. >o No support for legacy MacOS, Netware, OS/2, VMS and Windows > platforms, as well as antique compilers. >o Removal of the IBM 4758, Broadcom ubsec, Sureware, Nuron, GOST, > GMP, CSwift, CHIL, CAPI, Atalla and AEP engines, either because > the hardware is irrelevant, or because they require external > non-free libraries to work. >o No support for FIPS-140 compliance. >o No EBCDIC support. >o No support for big-endian i386 and amd64 platforms. >o Use standard routines from the C library (malloc, strdup, > snprintf...) instead of rolling our own, sometimes badly. >o Remove the old OpenSSL PRNG, and rely upon arc4random_buf from > libc for all the entropy needs. >o Remove the MD2 and SEED algorithms. >o Remove J-PAKE, PSK and SRP (mis)features. >o Aggressive cleaning of BN memory when no longer used. >o No support for Kerberos. >o No support for SSLv2. >o No support for the questionable DTLS heartbeat extension. >o No support for TLS compression. >o No support for US-Export SSL ciphers. >o Do not use the current time as a random seed in libssl. >o Support for ChaCha and Poly1305 algorithm. >o Support for Brainpool and ANSSI elliptic curves. >o Support for AES-GCM and ChaCha20-Poly1305 AEAD modes. > > - Improved hardware support, including: >o SCSI Multipathing support via mpath(4) and associated path drivers > on several architectures. >o New qlw(4) driver for QLogic ISP SCSI HBAs. >o New qla(4) driver for QLogic ISP2100/2200/2300 Fibre Channel HBAs. >o New upd(4) sensor driver for USB Power Devices (UPS). >o New brswphy(4) driver for Broadcom BCM53xx 10/100/1000TX Ethernet > PHYs. >o New uscom(4) driver for simple USB serial adapters. >o New axen(4) driver for ASIX Electronics AX88179 10/100/Gigabit USB > Ethernet devices. >o The inteldrm(4) and radeondrm(4) drivers have improved > suspend/resume support. >o The userland interface for the agp(4) driver has been removed. >o The rtsx(4) driver now supports card readers based on the RTS5227 > and RTL8402 chipsets. >o The firmware for the run(4) driver has been updated to version 0.33. >o The run(4) driver now supports devices based on the RT3900E > chipset. >o The zyd(4) driver, which was broken for some time, has been fixed. >o The bwi(4) driver now works in systems with more than 1GB of RAM. >o The re(4) driver now supports devices based on the RTL8168EP/8111EP, > RTL8168G/8111G, and RTL8168GU/8111GU chipsets. > > - Generic network stack improvements: >o divert(4) now supports checksum offload. >o IPv6 is now turned off on new interfaces by default. Assigning an > IPv6 address will enable IPv6 on an interface. >o Support for RFC4620 IPv6 Node Information Queries has been removed. >o The kernel no longer supports the SO_DONTROUTE socket option. >o The getaddrinfo(3) function now supports the AI_ADDRCONFIG flag > defined in RFC 3493. >o Include router alert option (RAO) in IGMP packets, as required by > RFC2236. >o ALTQ has been removed. >o The hash table for Protocol Control Block (PCB) of TCP and UDP now > resize automatically on load. > > - Installer improvements: >o Remove ftp and tape as install methods. >o Preserve the disklabel (and next 6 blocks) when installing boot > block on 4k-sector disk drives. >o Change the "Server?" question to "HTTP Server?" to allow unambiguous > autoinstall(8) handling. >o Allow autoinstall(8) to fetch and install sets from multiple > locations. >o Many sample configuration files have moved from /etc to > /etc/examples. > > - Routing daemons and other userland network improvements: >o When used with the -v flag, tcpdump(8) now shows the actual bad > checksum within the IP/protocol header itself and what the good > checksum should be. >o ftp(1) now allows its User-Agent to be changed via the -U > command-line option. >o The -r option of ping(8) and traceroute(8) has been remov
OpenBSD 5.6/amd64 WLE200NX (Atheros AR9280) athn issues
Hi, I have a PC Engines APU board with a Compex WLE200NX miniPCI-e wifi card running in hostap mode (11g). root@apu:/var/log # dmesg | grep athn0 athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx root@apu:/var/log # ifconfig athn0 athn0: flags=28843 mtu 1500 lladdr xx:xx:xx:xx:xx:xx priority: 4 groups: wlan media: IEEE802.11 autoselect mode 11g hostap status: active ieee80211: nwid obsd chan 7 bssid xx:xx:xx:xx:xx:xx wpakey 0x... wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp powersave on (100ms sleep) inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 It's rather unstable though: root@apu:/var/log # zgrep "athn0: device" messages* messages:Nov 3 01:08:40 apu /bsd: athn0: device timeout messages:Nov 2 00:41:22 apu /bsd: athn0: device timeout messages:Nov 2 02:20:06 apu /bsd: athn0: device timeout messages:Nov 2 03:11:03 apu /bsd: athn0: device timeout messages:Nov 2 19:56:36 apu /bsd: athn0: device timeout messages.0.gz:Oct 26 22:06:44 apu /bsd: athn0: device timeout messages.0.gz:Oct 27 02:17:05 apu /bsd: athn0: device timeout messages.0.gz:Oct 31 11:10:40 apu /bsd: athn0: device timeout messages.0.gz:Oct 31 20:48:43 apu /bsd: athn0: device timeout messages.0.gz:Nov 1 13:48:04 apu /bsd: athn0: device timeout messages.2.gz:Oct 14 18:26:52 apu /bsd: athn0: device timeout messages.3.gz:Oct 12 20:35:53 apu /bsd: athn0: device timeout I also see constant increasing error counters (even if there's no traffic visible via tcpdump): root@apu:/var/log # netstat -i -I athn0 5 athn0 in athn0 out total in total out packets errs packets errs colls packets errs packets errs colls 1190195 171127 2642652 4337 0 10759655 171127 8935403 4337 0 265 8 1096 0 0 2675 8 1845 0 0 12914 826 0 0 201114 1323 0 0 63015 1923 0 0 469615 3403 0 0 32214 894 0 0 231914 1738 0 0 58618 1244 0 0 365818 2956 0 0 40414 437 0 0 202114 1916 0 0 1540 13 0 0 54840 538 0 0 Anyone else seeing this? Any idea how I could fix this? Thanks. PS: OpenBSD 5.6 amd64, bsd is bsd.mp
Re: security - "pass the hash" style attacks?
On Sun, Nov 2, 2014 at 4:05 PM, Nex6|Bill wrote: > I know, that “pass the hash” is now getting a lot of playtime on windows. and > I have heard in a couple of talks > that its directly related to “SSO” part of the OS, and may be part of posix? Nope. It's just a bad (as in, completely broken) design for the NTLM and LanMan authentication protocols. > is OpenBSD, or BSD in general vulnerable to these style attacks? The vulnerability is the authentication protocol/method, independent the operating system. If you used NTLM or LanMan password authentication on OpenBSD, you would be vulnerable. You would also have to be insane. > or just the normal unix dump the password /etc/passwd table for offline > attacks sorts of > stuff? For the authentication methods in base, correct. Philip Guenther
Re: security - "pass the hash" style attacks?
On Nov 2, 2014, at 4:30 PM, Philip Guenther wrote: > On Sun, Nov 2, 2014 at 4:05 PM, Nex6|Bill wrote: >> I know, that pass the hash is now getting a lot of playtime on windows. and >> I have heard in a couple of talks >> that its directly related to SSO part of the OS, and may be part of posix? > > Nope. It's just a bad (as in, completely broken) design for the NTLM > and LanMan authentication protocols. So, any machine/OS thats authenticating to a PtH vulnerable protocol namely Lanman/NTLM would be vulnerable to this no matter the OS. what about kerberos? (windows K5 vs Unix K5?) > > >> is OpenBSD, or BSD in general vulnerable to these style attacks? > > The vulnerability is the authentication protocol/method, independent > the operating system. > If you used NTLM or LanMan password authentication on OpenBSD, you > would be vulnerable. > You would also have to be insane. > > >> or just the normal unix dump the password /etc/passwd table for offline attacks sorts of >> stuff? > > For the authentication methods in base, correct. so, for OpenBSD you would have to get the /etc/passwd for an offline attack on the password hashes and for that they would need a user account to logon to the system. Or to have compromised the system in such a way as they could copy /etc/passwd. other types of attacks would be brut force against SSHD sorts of stuff which could be detected and mitagated. > > > Philip Guenther [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: security - "pass the hash" style attacks?
On Sun, Nov 2, 2014 at 4:41 PM, Nex6|Bill wrote: ... > what about kerberos? (windows K5 vs Unix K5?) > > >> >> >>> is OpenBSD, or BSD in general vulnerable to these style attacks? >> >> The vulnerability is the authentication protocol/method, independent >> the operating system. >> If you used NTLM or LanMan password authentication on OpenBSD, you >> would be vulnerable. >> You would also have to be insane. >> >> >>> or just the normal unix dump the password /etc/passwd table for offline >>> attacks sorts of >>> stuff? >> >> For the authentication methods in base, correct. > > so, for OpenBSD you would have to get the /etc/passwd for an offline attack > on the password hashes > and for that they would need a user account to logon to the system. Or to > have compromised the system in such a > way as they could copy /etc/passwd. > > other types of attacks would be brut force against SSHD sorts of stuff which > could be detected and mitagated. > > > > >> >> >> Philip Guenther
Re: security - "pass the hash" style attacks?
[apologies for the contentless previous message] On Sun, Nov 2, 2014 at 4:43 PM, Philip Guenther wrote: > On Sun, Nov 2, 2014 at 4:41 PM, Nex6|Bill wrote: > ... >> what about kerberos? (windows K5 vs Unix K5?) There's a bunch of *really good* papers on Kerberos's design which discuss exactly these sorts of issues and how they are addressed or completely avoided. I remember finding the one cast as a dialog between two system programmers (one named Athena...) as a good intro on this stuff. Philip Guenther
Re: OpenBSD 5.6/amd64 WLE200NX (Atheros AR9280) athn issues
On Mon, Nov 03, 2014 at 01:13:40AM +0100, Stefan Krüger wrote: > Hi, > > I have a PC Engines APU board with a Compex WLE200NX miniPCI-e wifi card > running in hostap mode (11g). > > root@apu:/var/log # dmesg | grep athn0 > athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19 > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx > root@apu:/var/log # ifconfig athn0 > athn0: flags=28843 mtu 1500 > lladdr xx:xx:xx:xx:xx:xx > priority: 4 > groups: wlan > media: IEEE802.11 autoselect mode 11g hostap > status: active > ieee80211: nwid obsd chan 7 bssid xx:xx:xx:xx:xx:xx wpakey 0x... > wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp > powersave on (100ms sleep) > inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > > It's rather unstable though: > > root@apu:/var/log # zgrep "athn0: device" messages* > messages:Nov 3 01:08:40 apu /bsd: athn0: device timeout > messages:Nov 2 00:41:22 apu /bsd: athn0: device timeout > messages:Nov 2 02:20:06 apu /bsd: athn0: device timeout > messages:Nov 2 03:11:03 apu /bsd: athn0: device timeout > messages:Nov 2 19:56:36 apu /bsd: athn0: device timeout > messages.0.gz:Oct 26 22:06:44 apu /bsd: athn0: device timeout > messages.0.gz:Oct 27 02:17:05 apu /bsd: athn0: device timeout > messages.0.gz:Oct 31 11:10:40 apu /bsd: athn0: device timeout > messages.0.gz:Oct 31 20:48:43 apu /bsd: athn0: device timeout > messages.0.gz:Nov 1 13:48:04 apu /bsd: athn0: device timeout > messages.2.gz:Oct 14 18:26:52 apu /bsd: athn0: device timeout > messages.3.gz:Oct 12 20:35:53 apu /bsd: athn0: device timeout > > I also see constant increasing error counters (even if there's no traffic > visible via tcpdump): > > root@apu:/var/log # netstat -i -I athn0 5 > athn0 in athn0 out total in total out > packets errs packets errs colls packets errs packets errs colls > 1190195 171127 2642652 4337 0 10759655 171127 8935403 4337 0 > 265 8 1096 0 0 2675 8 1845 0 0 > 12914 826 0 0 201114 1323 0 0 > 63015 1923 0 0 469615 3403 0 0 > 32214 894 0 0 231914 1738 0 0 > 58618 1244 0 0 365818 2956 0 0 > 40414 437 0 0 202114 1916 0 0 > 1540 13 0 0 54840 538 0 0 > > Anyone else seeing this? Any idea how I could fix this? Yes (04/05/2014 BIOS on the APU, same wifi card, a couple of dev timeouts per month, 1.2% errs/packets). No (and not worried about it either). IIRC it wasn't much different on a Soekris net4801 with a different athn card... > Thanks. > > PS: OpenBSD 5.6 amd64, bsd is bsd.mp > --
Re: OpenBSD 5.6/amd64 WLE200NX (Atheros AR9280) athn issues
Same here. About 3 timeouts a day and I get close to 10% errors on the input on 2 different athn devices. On Nov 2, 2014 7:49 PM, "Zé Loff" wrote: > On Mon, Nov 03, 2014 at 01:13:40AM +0100, Stefan Krüger wrote: > > Hi, > > > > I have a PC Engines APU board with a Compex WLE200NX miniPCI-e wifi card > > running in hostap mode (11g). > > > > root@apu:/var/log # dmesg | grep athn0 > > athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19 > > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx > > root@apu:/var/log # ifconfig athn0 > > athn0: flags=28843 mtu > 1500 > > lladdr xx:xx:xx:xx:xx:xx > > priority: 4 > > groups: wlan > > media: IEEE802.11 autoselect mode 11g hostap > > status: active > > ieee80211: nwid obsd chan 7 bssid xx:xx:xx:xx:xx:xx wpakey 0x... > > wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp > > powersave on (100ms sleep) > > inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > > > > It's rather unstable though: > > > > root@apu:/var/log # zgrep "athn0: device" messages* > > messages:Nov 3 01:08:40 apu /bsd: athn0: device timeout > > messages:Nov 2 00:41:22 apu /bsd: athn0: device timeout > > messages:Nov 2 02:20:06 apu /bsd: athn0: device timeout > > messages:Nov 2 03:11:03 apu /bsd: athn0: device timeout > > messages:Nov 2 19:56:36 apu /bsd: athn0: device timeout > > messages.0.gz:Oct 26 22:06:44 apu /bsd: athn0: device timeout > > messages.0.gz:Oct 27 02:17:05 apu /bsd: athn0: device timeout > > messages.0.gz:Oct 31 11:10:40 apu /bsd: athn0: device timeout > > messages.0.gz:Oct 31 20:48:43 apu /bsd: athn0: device timeout > > messages.0.gz:Nov 1 13:48:04 apu /bsd: athn0: device timeout > > messages.2.gz:Oct 14 18:26:52 apu /bsd: athn0: device timeout > > messages.3.gz:Oct 12 20:35:53 apu /bsd: athn0: device timeout > > > > I also see constant increasing error counters (even if there's no traffic > > visible via tcpdump): > > > > root@apu:/var/log # netstat -i -I athn0 5 > > athn0 in athn0 out total in total out > > packets errs packets errs colls packets errs packets errs colls > > 1190195 171127 2642652 4337 0 10759655 171127 8935403 4337 > 0 > > 265 8 1096 0 0 2675 8 1845 0 0 > > 12914 826 0 0 201114 1323 0 0 > > 63015 1923 0 0 469615 3403 0 0 > > 32214 894 0 0 231914 1738 0 0 > > 58618 1244 0 0 365818 2956 0 0 > > 40414 437 0 0 202114 1916 0 0 > > 1540 13 0 0 54840 538 0 0 > > > > Anyone else seeing this? Any idea how I could fix this? > > Yes (04/05/2014 BIOS on the APU, same wifi card, a couple of dev > timeouts per month, 1.2% errs/packets). No (and not worried about it > either). IIRC it wasn't much different on a Soekris net4801 with a > different athn card... > > > Thanks. > > > > PS: OpenBSD 5.6 amd64, bsd is bsd.mp > > > > --
Re: `make` problem applying 5.6 errata
On Sun, Nov 02, 2014 at 18:49, Ted Unangst wrote: >> # cd /usr/src/lib/libssl/ssl >> # make obj >> /usr/src/lib/libssl/ssl/obj -> /usr/obj/lib/libssl/ssl >> # make >> make: don't know how to make /usr/src/lib/libssl/ssl/../src/e_os.h >> (prerequisite of: s3_meth.o) >> Stop in /usr/src/lib/libssl/ssl >> >> >> So, what did I do wrong? > > That file was deleted before 5.6. It looks you built with a dirty obj > directory. To expand and clarify. The patch instructions make certain assumptions, such as that obj is either empty or from a previous build of the same system. Generally, the more complete procedure for building a library is make obj make includes make depend make These additional steps are typically only necessary when tracking current, but transitioning from 5.5 to 5.6 would certainly count, too. Short version: When you upgrade a machine from 5.x to 5.next, delete the contents of the obj directory at the same time.
Re: Upgrade56.html instead of Upgrade54.html
On 11/02/14 18:15, Mario St-Gelais wrote: > http://www.openbsd.org/faq/faq5.html#BldBinary > [Quote] > It is recommended that you install the binary by using the "Upgrade" option > of the install media. If that is not possible, you can also unpack the > binaries as described here. Regardless, you must do the entire upgrade > process, including creating any users or other /etc directory changes needed. > [/Quote] > > ...as described here... here should link to > http://www.openbsd.org/faq/upgrade56.html instead of > http://www.openbsd.org/faq/upgrade54.html I presume. > > Mario St-Gelais > yes, and two others, too. Thanks! Nick.
Re: cubieboard
thanks .I will try 5.6 release later.I hope it will be work. At 2014-10-29 18:16:22, "Jonathan Gray" wrote: >On Wed, Oct 29, 2014 at 08:59:11AM +0800, leeqiand wrote: >> Any one had ever install openbsd on cubieboard? >> I tried in this way. >> http://comments.gmane.org/gmane.os.openbsd.arm/915 >> >> and it gives me the same panic! >> http://permalink.gmane.org/gmane.os.openbsd.arm/916 >> >> Anyone know it? > >If you try the snapshot from the 27th it may get slightly >further. > >Be warned that the armv7 port and Cortex A7/Allwinner A20 >support in particular are incomplete and need more work.
Re: security - "pass the hash" style attacks?
On November 3, 2014 1:41:24 AM CET, Nex6|Bill wrote: >so, for OpenBSD you would have to get the /etc/passwd for an offline >attack on >the password hashes >and for that they would need a user account to logon to the system. Or >to have >compromised the system in such a >way as they could copy /etc/passwd. /etc/passwd does not contain password hashes. /etc/master.passwd does, but with vastly different permission bits. /Alexander
