Re: Lenovo X130e blank video at boot.rd
On Tue, Feb 27, 2018 at 04:53:06PM -0700, j...@bitminer.ca wrote:
> I am replacing my ancient X60 with an X130e of lesser age. This model is
> previously found as working on misc.
>
> When trying to install 6.2 (release) over Windows 10 there is no video to
> see.
>
> By booting miniroot62.fs from USB the kernel loads, but the "OpenBSD 6.2
> " and subsequent boot messages do not appear. The video is blank
> (apparently backlit but no text is present.) The biosboot loader messages
> prior to that do appear for a few seconds. The USB stick activity light
> does blink as if things are happening normally.
>
> Same result for 6.1 and 5.9.
>
> The three video options: Native video, VGA and HDMI video outputs show the
> same biosboot lines and then the screen blanks. A couple of different
> monitors on the VGA output show "unsupported format" or somesuch suggesting
> the video signal is not a standard format.
>
> There is no serial port on this hardware. The BIOS is updated to the
> latest. I'm going to try to obtain a dmesg with blindly typing against the
> install script (blessed OpenBSD with a simple install CLI!)
>
> I'm wondering if there is something to be enabled/disabled in boot_config
> that would help. I don't quite understand why video would blank out once
> the kernel gets control (src/sys/arch/amd64/amd64/consinit.c and machdep.c)
> since nothing looks like it is touching video configuration. This seems to
> be way before any video driver gets control.
>
> The Windows 10 "about" page says this is AMD E-450 APU with Radeon HD
> Graphics. The Hardware page says "AMD Radeon HD 6320 Graphics".
>
> Does anyone have further advice?
>
> thanks
>
> John
>
My x130e has no problems booting -current miniroot62.fs from USB.
Video works fine ("ATI Radeon HD 6310"). dmesg below.
Did you boot from OpenBSd powered-off state or soft reboot after running
Windows? It's possible that Windows leaves devices in a state where
OpenBSD cannot use them.
BTW this machine used to be an E-450 as well, however something broke
on the mainboard so the system would not see the battery anymore.
At the time I could only find an E-300 mainboard to replace it but it's
been working fine since.
OpenBSD 6.2-current (RAMDISK_CD) #11: Tue Feb 27 17:20:47 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 3849388032 (3671MB)
avail mem = 3728969728 (3556MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf9d00 (58 entries)
bios0: vendor LENOVO version "8RET52WW (1.15 )" date 11/15/2011
bios0: LENOVO 305162G
acpi0 at bios0: rev 4
acpi0: tables DSDT FACP SLIC HPET APIC MCFG UEFI UEFI SSDT SSDT UEFI
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD E-300 APU with Radeon(tm) HD Graphics, 1297.51 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB4_)
acpiprt2 at acpi0: bus 1 (PB5_)
acpiprt3 at acpi0: bus 2 (PB6_)
acpiprt4 at acpi0: bus 3 (PB7_)
acpiprt5 at acpi0: bus 4 (P2P_)
acpiprt6 at acpi0: bus -1 (SPB0)
acpiprt7 at acpi0: bus -1 (SPB1)
acpiprt8 at acpi0: bus -1 (SPB2)
acpiprt9 at acpi0: bus -1 (SPB3)
acpiec0 at acpi0
acpicpu at acpi0 not configured
acpitz at acpi0 not configured
"PNP0C0C" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
"LEN0026" at acpi0 not configured
"LEN0068" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
vga1 at pci0 dev 1 function 0 "ATI Radeon HD 6310" rev 0x00
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
"ATI Radeon HD 6310 HD Audio" rev 0x00 at pci0 dev 1 function 1 not configured
ppb0 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
rtwn0 at pci1 dev 0 function 0 "Realtek 8188CE" rev 0x01: msi
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R, address 9c:b7:0d:e1:11:6d
ppb1 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
alc0 at pci2 dev 0 function 0 "Attansic Technology L1D" rev 0xc0: msi, address
04:7d:7b:31:00:6e
atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 0
ppb2 at pci0 dev 7 function 0 "AMD AMD64 14h PCIE" re
Re: SHA256.sig not contained in install62.iso
On Tue, Feb 20, 2018 at 07:23:05PM +0200, mazocomp wrote: > Isn't the same true when I download file sets from any mirror? No. > After all > I download SHA256.sig abd file sets from mirror, how can I trust it? You run a trusted signify binary, which was not obtained from the mirror but is part of your existing install, to check the signature on SHA256.sig. A signify binary inside installXX.iso can't be trusted to not lie about the integrity of contents of installXX.iso.
Re: Why is so slow the download speed in OpenBSD?
On Tue, Feb 13, 2018 at 11:00:39PM +, Zsolt Kantor wrote: > So if you have any idea, any new testing method, please tell me, I will try. The information we'd need to fix anyting is still not there because what you are measuring is the result of an interaction between many layers: application, sockets, TCP, IP, wifi, physical medium (radio). In order to fix anything we'll need to determine which layer is causing the problem, and why. I can make a guess, based on my knowledge of how the wifi layer behaves: The transmit rate used by wpi(4) is selected dynamically by the wifi layer. The higher the selected transmit rate is the faster your TCP stream will be because your TCP ACKs will flow faster. In the current implementation, the wifi layer selects a transmit rate based on the number of frame transmission retries reported by wpi(4) firmware. Frame transmission retries at a given transmit rate will happen if either: 1) You are too far away from the AP. A lower rate has more chance of getting through so lowering the rate is a good idea. or: 2) You are close to the AP but there is lots of unrelated wifi traffic on the same channel using up air time. Attempts to transmit a frame are often blocked by other legitimate frames on the air, so we need more than one attempt and all our attempts get counted as retries, and now we end up using a lower transmit rate. Using a lower rate in this situation means we use up more air time and make the problem even worse, not just for us but for everyone on this channel. The access point density in many residential buildings today means that case 2 is very likely and case 1 is very unlikely, especially on a 2GHz channel. Adapting the transmit rate based on retries doesn't achieve the desired result in this situation, so your download speed sucks. You can test my theory by disabling the automatic rate selection algorithm and tell wpi(4) to send all frames at a transmit rate of your choice. To do so, associate to the AP, and now fix the transmit rate as shown below. Repeat your test each time after changing the transmit rate. ifconfig wpi0 media OFDM6 mode 11g # repeat test ifconfig wpi0 media OFDM9 mode 11g # repeat test ifconfig wpi0 media OFDM12 mode 11g # repeat test ifconfig wpi0 media OFDM18 mode 11g # repeat test ifconfig wpi0 media OFDM24 mode 11g # repeat test ifconfig wpi0 media OFDM36 mode 11g # repeat test ifconfig wpi0 media OFDM48 mode 11g # repeat test ifconfig wpi0 media OFDM54 mode 11g # repeat test If you find that one of these commands makes it work as fast as it does on Windows, we can conclude that the problem is with OpenBSD's rate selection algorithm. This algorithm is very old and dates from a time when wifi networks were much less densly deployed. Windows is probably using a different algorithm to make decisions about which transmit rate to use (for reference, it probably uses a similar algorithm as was implemented in Intel's Linux iwlegacy driver, in file 3945-rs.c of that driver's source code).
Re: Wondering if any of my hardware is working on -current
On Fri, Feb 09, 2018 at 04:33:35PM -0800, Chris Bennett wrote: > Wifi is still a no go. OpenBSD has no driver for ath10k wifi devices. This is unlikely to change any time soon.
Re: athn0: device timeout with AR9271
On Mon, Feb 05, 2018 at 11:07:18AM +, Kevin Chadwick wrote: > On Mon, 5 Feb 2018 11:21:27 +0100 > > However, I can still reproduce device timeouts easily by running > > tcpbench through an AR9271 in hostap mode. I don't know yet what's > > causing the problem. > > (Not using these for production btw) > > I have unplugged my AR9271 due to these timeouts. Due to the chromecast > (below) I have a so far unneeded script now to bring it down and up > via a cronjob every minute upon a timeout in /var/log/messages. Pretty > simple but I can provide it if anyone wants it. > > I get very few timeouts on AR5008-3NG (AR5416+AR2133) but seemed to get > many suddenly with a chromecast and the athn would not recover like > usual. It seems to have stopped and since Google update chromecasts > silently I can't tell why or test further and so haven't said anything. > > The AR9271 has TxR:S of 1:1:1 compared to 3x3:2, perhaps it has a > smaller buffer or just a more constrained power supply like you > previously mentioned that struggles with many RX/TX? > > The unconfirmed possible cause was a flood of UDP MDNS packets. Our athn(4) driver is not running periodic calibration. Which is very bad and can result in problems at the PHY layer such as eventual deafness and inability to transmit. That's the one problem to solve before looking for other causes.
Re: athn0: device timeout with AR9271
On Sat, Jan 27, 2018 at 12:59:12PM +0300, Denis wrote: > I would like to add some test conditions to a previous post. > > AR9271 USB stick's antenna line of sight to AP antenna ~10m. > > It that case I usually receive > > athn0: device timeout You might have better luck with -current from today, where this driver now uses newer and actively maintained open source firmware. However, I can still reproduce device timeouts easily by running tcpbench through an AR9271 in hostap mode. I don't know yet what's causing the problem. I could not yet trigger this problem on my AR7010 device. An AR9271 device with firmware serial console would be useful for debugging, for instance: https://wikidevi.com/wiki/ALFA_Network_AWUS036NHA
Re: iwm errors with new snapshot
On Tue, Jan 23, 2018 at 11:50:28AM -0600, Vijay Sankar wrote: > Over the weekend, I was trying to do some tests requested in tech@ > (inteldrm). I downloaded the latest snapshot but had problems with iwm > firmware on my laptops (X1 Carbon 5th gen) > > I did not have these errors with the previous snapshot (from January 8, > 2018). DHCP etc all worked properly the past couple of weeks, I was able to > copy large file sets through wifi etc. > > So I tried a new build myself in case there was a mismatch between the > packages on firmware.openbsd.org and the latest snapshot but that did not > work. > > Waited couple of days for a newer snapshot, installed it and still get the > following errors Can you please try a kernel compiled from -current CVS source? Such kernels work for me.
Re: Boot problem OpenBSD 6.2 amd64 softraid keydisk
On Mon, Jan 22, 2018 at 10:08:30AM +0100, Raimo Niskanen wrote: > Hello misc@! > > I just wanted to share a problem and a solution that I encountered. Just > posting to maybe help someone else in the future, and perhaps a developer > feels that improving a particular error message could be important enough. > > My goal was to create an installation with a fully encrypted hard drive > using a keydisk, and at first reboot into the installed system I got this: > > Booting from hard disk... > Using drive 0, partition 3. > Loading.. > probing: pc0 com0 com1 mem[638K 3582M 496M a20=on] > disk: hd0+ hd1+ hd2 sr0* > >> OpenBSD/amd64 BOOT 3.33 > unknown KDF type 2 > open(sr0a:/etc/boot.conf): Operation not permitted > boot> > > The error message "unknown KDF type 2" is the one that maybe could > be improved... This error message has already been improved in -current by sunil@ in r1.3 of http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/lib/libsa/softraid.c The message now says ""keydisk not found".
Re: bsd.mp not installed on EdgeRouter Lite
On Thu, Jan 18, 2018 at 09:06:44AM -0500, Sean Murphy wrote: > I performed the steps as indicated n the links above and now have GENERIC.MP > running on my ERL. I did see that KARL failed on the initial install and > reboot, It looks like this issue was just fixed in -current by visa@
Re: 6.2-current on a MacBook
On Sat, Jan 13, 2018 at 04:35:49PM +0100, Jan Stary wrote: > This is 6.2-current on an old MacBook1,1 model A1181. > Everythng seems to work fine (dmesg below). > > What do people use for pasting instead of > the nonexistent and shift-insert? A USB mouse :)
Re: PCEngines APU2 Wifi router issues
On Sat, Jan 13, 2018 at 07:28:28AM -0500, George wrote: > On Sat, 23 Dec 2017 12:36:03 -0700 > Steve Williams wrote: > > I have one of those cards (WLE200NX ) in my APU. Be aware that > > OpenBSD drivers don't give very fast performance for it. Lots about > > it in the email list archives. > > > > Mine shows up (OpenBSD 6.1) as: > > > > athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 > > int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address > > 04:f0:21:1b:b3:68 > > Thanks Steve that is good to know. Do you have any numbers to share, > comparison under different OS maybe? > Regards, > George Devices supported by the new bwfm(4) driver could be interesting as well. http://man.openbsd.org/bwfm This driver is not yet enabled by default in -current but performance looks promising and it does support hostap mode already. Note that these devices use a relatively huge(*) closed-source proprietary firmware which gives the driver relatively little control over operation of the device. This means security of these devices is the responsibility of Broadcom alone, and there is no way around this. We cannot make any promises regarding security. Do not buy these products if that worries you. (*) This firmware contains a complete 11ac wireless stack implementation, i.e. all of the functionality our code base ships in sys/net80211/ and much more. What appears to the OS looks almost like an Ethernet device. If^WWhen a serious bug is found after Broadcom ends support, these devices become dangerous.
Re: bsd.mp not installed on EdgeRouter Lite
On Fri, Jan 12, 2018 at 11:24:59AM -0500, Scott Bennett wrote: > After reading INSTALL.octeon, I was able to write miniroot62.fs to a usb, > plug that into the ERL, and perform a normal installation. The problem is > that the installer was not able to detect both cores, so it only installed > bsd.sp (bsd.mp was not an option in the set selection). > > Running 6.2-release. > > I did follow the instructions for setting the coremask=0x3 when booting the > installer, and setting the coremask=0x3 in the bootcmd. It seems that the > installer just wasn't able to recognize that it's a dual core system. I've seen this, too. For some reason bsd.rd doesn't count CPUs correctly even with coremask=0x3. > To workaround this problem, I downloaded bsd.mp after installation and copied > that to the FAT partition. My ERL can now run SMP, but as you probably > guessed this does break KARL. That's what I did, too. > Has anyone been able to install bsd.mp on the ERL and not break KARL? Not me. Looking into this is somewhere at the far end of my todo list. Not sure I'll ever get to it.
Re: Wifi Ierrs
On Thu, Jan 11, 2018 at 10:51:32AM +0100, Raimo Niskanen wrote: > Hello misc! > > I have an PC Engines Alix 2d13 with an Atheros AR9280 running WPA2-PSK, > and see a lot of input errors over WiFi. netstat -ivn shows: > > NameMtu Network Address Ipkts IerrsOpkts Oerrs > Colls > athn0 1500 172.17/16 172.17.0.1 1160154 4029261 1485342 61906 > 0 > > I have tried calling "netstat -W athn0" with 10 seconds intervals and get > typically over such intervals: > > 170 input unencrypted packets with wep/wpa config discarded > 12 input packets with mismatched channel > 8 input packets with mismatched ssid > 2 input frames below block ack window start > > So is this normal for a congested neighbourhood (6 stories apartment house > - lots of APs around in the house on the 2.4 GHz band), or can anybody think > of > a setting to tweak? The router runs OpenBSD 6.2 stable (patched). > > Best regards > -- > > / Raimo Niskanen > These are the numbers for my AP at home: $ netstat -nI athn0 NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls athn0 150004:f0:21:17:3c:6a 2235626 123714 3743974 43802 0 The wifi network is usable but relatively slow. This same card worked perfectly fine on a clean wifi channel up in the Canadian mountains where there was virtually no interference. Up there I got about 3MB/s transfer rates if I recall correctly. After some code inspection I've done recently I came to the conclusion that this problem might be due to the fact that our driver does not run the regular calibration routines which other OS drivers use. If someone looked into that it might help fix the known issues we have with these devices. There is calibration code in our driver already but most of it is not being called yet. And what's there now needs to be cross-checked with other OSs since there are probably bugs.
Re: WLAN disconnects after a while
On Wed, Jan 03, 2018 at 03:58:13PM +, Roderick wrote: > After losing Link > > # netstat netstat -n -I run0 >> tmp-netstat1 > netstat: interval is invalid The above is bogus. Please read what you wrote before sending. > # tcpdump -n -i run0 > tcpdump: listening on run0, link-type EN10MB > ^C > 0 packets received by filter > 0 packets dropped by kernel > > # tcpdump -n -i run0 -y IEEE802_11_RADIO > tcpdump: listening on run0, link-type IEEE802_11_RADIO > 15:29:37.475139 802.11: data: 192.168.0.12.41070 > 64.233.190.16.587: FP > 3160548212:3160548235(23) ack 3357202105 win 256 4270344605 658810306>, > 15:29:45.974910 802.11: data: 192.168.0.12.47665 > 64.233.186.108.993: FP > 1359026660:1359026696(36) ack 2175423745 win 256 1626745330> (DF), > 15:30:41.473291 802.11: data: 192.168.0.12.41070 > 64.233.190.16.587: R > 24:24(0) ack 1 win 0, > 15:30:49.973049 802.11: data: 192.168.0.12.47665 > 64.233.186.108.993: R > 37:37(0) ack 1 win 0 (DF), > 15:31:28.692024 802.11: data: 192.168.0.12.4130 > 200.1.19.17.123: v4 client > strat 0 poll 0 prec 0 [tos 0x10], > 15:33:43.018220 8 This looks like the driver is still trying to send frames but the device has stopped receiving (and perhaps sending) for some reason. It's virtually impossible to debug this with back-and-forth over email. Ideally I would need to be in the same room as you or reproduce the problem independently. Can you trigger this problem elsewhere with a different AP or is it limited to the particular environmental conditions of this network?
Re: WLAN disconnects after a while
On Tue, Jan 02, 2018 at 12:01:50PM +, Roderick wrote: > > Dear Sirs, > > After connecting with the AP (Cisco DPQ3925) I lose after a while > the link. All works again after issuing again: > > # ifconfig run0 nwid .. wpakey .. bssid .. > > Bellow are the relevant messages after doing "ifconfig run0 debug". > I do not find anything suspicious. The AP is not mine and I cannot > see the configuration, but it works OK with other OS. > > Is it perhaps a bug? Or perhaps only misconfiguration? There is no error in the logs you provided. It's hard to guess what the problem is unless you can describe the problem a bit better and show more data. For example: When the problem occurs, do the counters shown by the following commands _change_ when you run these commands mulitple times? netstat -n -I run0 netstat -W run0 Another example: What do you see in tcpdump -n -i run0? What do you see in tcpdump -n -i run0 -y IEEE802_11_RADIO? The run(4) code has not been changed in a relatively long time. What version are you running and when did this problem start happening? Is it happening with only this particular AP or also others? > > > -- > > # ifconfig run0 > > run0: flags=8847 mtu 1500 > lladdr 00:1f:1f:22:ce:d2 > index 5 priority 4 llprio 3 > groups: wlan egress > media: IEEE802.11 autoselect (OFDM6 mode 11g) > status: active > ieee80211: nwid rna903295 chan 1 bssid 7c:05:07:f7:6f:4c -36dBm > wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp > wpagroupcipher ccmp > inet 192.168.0.12 netmask 0xff00 broadcast 192.168.0.255 > > -- > > # cat /var/log/messages > > > Jan 2 11:42:37 nc10 /bsd: - ec:22:80:a9:6c:71! 11 +66 54M ess > privacy rsn ""! > Jan 2 11:42:37 nc10 /bsd: run0: SCAN -> AUTH > Jan 2 11:42:37 nc10 /bsd: run0: sending auth to 7c:05:07:f7:6f:4c on > channel 1 mode 11g > Jan 2 11:42:37 nc10 /bsd: run0: AUTH -> ASSOC > Jan 2 11:42:37 nc10 /bsd: run0: sending assoc_req to 7c:05:07:f7:6f:4c on > channel 1 mode 11g > Jan 2 11:42:37 nc10 /bsd: run0: received msg 1/4 of the 4-way handshake > from 7c:05:07:f7:6f:4c > Jan 2 11:42:37 nc10 /bsd: run0: sending msg 2/4 of the 4-way handshake to > 7c:05:07:f7:6f:4c > Jan 2 11:42:37 nc10 /bsd: run0: ASSOC -> RUN > Jan 2 11:42:37 nc10 /bsd: run0: associated with 7c:05:07:f7:6f:4c ssid > "rna903295" channel 1 start 1Mb long preamble short slot time > Jan 2 11:42:37 nc10 /bsd: run0: missed beacon threshold set to 7 beacons, > beacon interval is 100 TU > Jan 2 11:42:37 nc10 /bsd: run0: received msg 3/4 of the 4-way handshake > from 7c:05:07:f7:6f:4c > Jan 2 11:42:37 nc10 /bsd: run0: sending msg 4/4 of the 4-way handshake to > 7c:05:07:f7:6f:4c > > --- > > # dmesg > > run0 at uhub0 port 6 configuration 1 interface 0 "Ralink 802.11 n WLAN" > rev 2.00/1.01 addr 2 > run0: MAC/BBP RT2860 (rev 0x0102), RF RT2720 (MIMO 1T2R), address > 00:1f:1f:22:ce:d2 > ... > ... > ... > run0: SCAN -> AUTH > run0: sending auth to 7c:05:07:f7:6f:4c on channel 1 mode 11g > run0: AUTH -> ASSOC > run0: sending assoc_req to 7c:05:07:f7:6f:4c on channel 1 mode 11g > run0: received msg 1/4 of the 4-way handshake from 7c:05:07:f7:6f:4c > run0: sending msg 2/4 of the 4-way handshake to 7c:05:07:f7:6f:4c > run0: ASSOC -> RUN > run0: associated with 7c:05:07:f7:6f:4c ssid "rna903295" channel 1 start > 1Mb long preamble short slot time > run0: missed beacon threshold set to 7 beacons, beacon interval is 100 TU > run0: received msg 3/4 of the 4-way handshake from 7c:05:07:f7:6f:4c > run0: sending msg 4/4 of the 4-way handshake to 7c:05:07:f7:6f:4c > >
Re: OpenBSD SPARC T4-1 softraid boot issues
On Thu, Dec 28, 2017 at 02:08:58AM -0800, Jordan Geoghegan wrote: > I will check to see if the T4 will boot from crypto softraid and will also > crack open the box for the T3-1 to see if I can get it booting from > softraid. The disks should be being scanned correctly during the device-tree > walk, as I am able to set the machine to autoboot when installed to a single > disk (or when having a small boot partition before RAID partitions). Do you > think this is some sort of bug? The disk tree walk is irrelevant if you're not booting from softraid. The walk is done to read softraid meta data from all disks and construct volumes. If you're booting from a single disk then the kernel is read directly from disk by open firmware. > Also, is it necessary to run installboot(8) manually after install or is > that handled automatically by the install script? It's handled automatically.
Re: OpenBSD SPARC T4-1 softraid boot issues
On Wed, Dec 27, 2017 at 02:29:09PM -0800, Jordan Geoghegan wrote: > Cannot boot from softraid: Unknown error: code 19 > > Any ideas? In this condition, the boot loader has not assembled a softraid volume. Which means that either the disks which make up the volume aren't being scanned during the device-tree walk for some reason, or softraid meta data on these disks is messed up somehow.
Re: OpenBSD SPARC T4-1 softraid boot issues
On Tue, Dec 26, 2017 at 12:56:53PM -0800, Jordan wrote: > The install procedure I followed on the T4 was: > > 1) Boot install kernel and drop to shell and provision RAID partitions on > both disks using the letter “a” via disklabel(8) > > 2) Assemble RAID volume with # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0 > > 3) I zeroed the first 10MB of the RAID volume with # dd if=/dev/urandom > of=/dev/rsd2c bs=1m Step 3 might get you in trouble. You're writing to the raw disk device so this command might nuke disklabel and/or softraid meta data. > 4) I finished off the install as usual by typing ”install” into command line > and proceeded normally > > 5) I then rebooted and set the boot parameters at the ok prompt as per > boot_sparc(8) > In short, on sparc64, is softraid boot like that of i386/amd64 where > everything including root is stored within the RAID volume, Yes, except as mentioned the RAID fs needs to be on an 'a' partition. > or does sparc64 > require me to have a small partition at the beginning of my physical disks > containing the kernel and ofwboot? No it does not.
Re: Is it okay to clone OpenBSD from GitHub from India?
On Sat, Dec 23, 2017 at 05:19:54PM +0530, Dinesh Thirumurthy wrote:
>
> > Just use cvs from a mirror outisde the US? You don't *need* to use
> > github, github is a copy anyway and only cvs is authorative.
> >
> > -Otto
>
> Otto,
>
> Thanks.
>
> I was trying to distribute a tweaked OpenBSD to teachers and students in
> India, so they could compile kernel, base, and xenocara very easily.
> Not that it is difficult now. But just made it easier. I was using
> github.com as my distribution platform from a forked OpenBSD. Now I need
> to find another way to distribute it.
>
> Regards,
> Dinesh
>
>
Note that openbsd's github conversion is not considered stable yet.
Which means all commit hashes could change at any time. Regardless
of the crypto export issue, I would not rely on it for very important
tasks until it is declared stable.
If you really want it in git format without legal trouble, you could
create your own git conversion with e.g. git-cvs ('pkg_add git-cvs').
Re: Library versions mismatch in the 14-Dec-2017 14:45 amd64 snapshot?
On Thu, Dec 14, 2017 at 08:52:28PM +0100, Peter N. M. Hansteen wrote: > First trouble I've had with jumping snapshot to snapshot in years, this: > > upgrading from the previous amd64 snapshot (yesterday or possibly the day > before, > not easy to tell at the moment), on reboot I get (transcribed from my laptop's > console): > > reordering libraries: done. > ld.so: ssh-keygen: can't load library 'libutil.so.13.0' > Killed > starting early daemons: syslogd pflogd ntpd(failed) > starting RPC daemons:. > savecore: no core dump > acpidump: aml_dump: Is a directory > checking quotas: done. > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd(failed) smtpd(failed) vmd(failed) sndiod. > starting local daemons apmd crond xenodm(failed). > Thu Dec 14 20:23:43 CET 2017 > reorder_kernel: kernel relinking failed; see > /usr/share/relink/kernel/GENERIC.MP/relink.log > > and it proceeds no further, I never get a login prompt. > > after poweroff and boot -s fsck, mount and shell builtins work, but not > much else, even cat dies (coredumps) with the same message about > libutil.so.13.0. > > is there some way I can collect useful data about this, or should I just > wait for a new snapshot to appear (in case this has bit others and is > being addressed already)? It's already been fixed. New libutil wasn't packaged until this commit: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/sets/lists/base/mi.diff?r1=1.871&r2=1.872 You could try to build + install just libutil from source, or wait for the next snapshot.
Re: EdgeRouter Lite VS Alix2D3
On Mon, Dec 04, 2017 at 03:49:19PM +0200, Ivo Chutkin wrote: > Hello list, > > When I read OpenBSD could run on EdgeRouter Lite, I give it a try (now with > 6.2 current as of 28.11.2017). > I expected closer performance to Alix, but ERL even do not respond on > console in reasonable times, for example, it takes 10-15 sec to log in. > After reboot, it takes about 5 min on "reordering libraries:" vs 30 sec on > Alix. > > Is it what I should expect from ERL or I am doing something wrong here? > > Thanks for your input, > Ivo > Did you add 'usb reset' to the bootcmd as described in INSTALL.octeon?
Re: OpenBSD NFC support
On Sun, Dec 03, 2017 at 03:48:06PM +0200, Lari Rasku wrote: > I've been thinking about getting a laptop with a Near Field Communication > module, but I'm worried if it'll work on OpenBSD. A search through the > mailing list archives, man pages and packages revealed only the the > qtconnectivity package, whose description holds the following paragraph: > > Qt NFC enables connectivity between NFC enabled devices. > Be warned that Qt NFC on OpenBSD may need some additional > components. > > Which seems to suggest that it's possible, but doesn't mention what those > "additional components" might be. Does anyone have any firm knowledge? > I am quite certain that OpenBSD contains no drivers for any NFC devices. I have an NFC device in a laptop. If it is enabled in the BIOS OpenBSD hangs at boot due to an interrupt storm. I don't know if this happens on other machines, but you may even have to disable the NFC device in the BIOS in order to use OpenBSD at all...
Re: xterm(1) changing UTF-8 characters when copy-pasting?
On Fri, Dec 01, 2017 at 12:14:48PM +0100, Ingo Schwarze wrote: > Hi Anthony, > > Anthony J. Bentley wrote on Thu, Nov 30, 2017 at 11:28:54PM -0700: > > > You'll need extra fonts once I finish my patch to add situationally > > appropriate emoji to all our manpages. > > I'm looking forward to that. Don't forget to make them animated, > make the colours fully configurable, and maybe add some nice > background music, a pleasant scent, and touchscreen support. And make them soft and plushy to the touch!
Re: broken EHCI USB on AMD chipset?
On Tue, Nov 28, 2017 at 08:03:05PM -0800, Paul B. Henson wrote: > The EHCI ports seem to work fine under Linux, including the LTE modem > when attached to them, so this seems to be an issue with openbsd, not > faulty hardware per se. The Linux driver does have a couple of > workarounds in their EHCI driver for AMD chipsets, I'm not sure if > either of them are relevant for this; one involves disabling low power > mode during transfers and the other says: > > "EHCI controller on AMD SB700/SB800/Hudson-2/3 platforms may > read/write memory space which does not belong to it when > there is NULL pointer with T-bit set to 1 in the frame list > table. To avoid the issue, the frame list link pointer > should always contain a valid pointer to a inactive qh" > > I don't see anything specifically discussing flaky interrupts. Any > thoughts on what might be going on here with USB and how it fix it? > Problems with ehci(4) on AMD SB700 are known. For instance, athn(4) USB devices don't work on such ports. Could you try adding missing workarounds to our EHCI driver to fix your problem? That would probably help with other known issues, too.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
On Wed, Nov 29, 2017 at 07:05:05PM +0100, Ingo Schwarze wrote: > Anthony J. Bentley wrote on Wed, Nov 29, 2017 at 10:29:28AM -0700: > > The only unexpected thing here is xterm doing these transformations > > without asking. > > I think i would support a diff to fix that Seconded. The current default behaviour is broken.
Re: want.html wifi stsp@
On Tue, Nov 21, 2017 at 06:48:49PM +, Alfred Morgan wrote: > I looked through your links and found some relatively inexpensive devices. > Would any of these satisfy any of your requirements? > > 15 GBP - Datel Wireless and Network Adaptor (Xbox 360) > http://amzn.eu/6Bi93OR See the remark about lack of support in the ath9k_htc driver here: https://wikidevi.com/wiki/Datel_Wireless_%27N%27_Networking_Adapter_For_Xbox_360 That said, information on wikidevi might be outdated; perhaps Linux supports this device nowadays? Best way of finding out is to buy and try. But for now I'd prefer to work against a device that's known to work. > 15 USD - TP- Link Wireless USB Adapter > http://a.co/8Qjf8gN Hard to know with this one. TP-Link has reused this product name for different atheros and realtek chips: https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v1 some atheros legacy 11n :( https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2 atheros AR7010 :) https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v3 realtek :( https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v4 realtek :( I suppose that most athn USB users will end up with AR9271 instead of AR7010, because AR9271 devices are much easier to track down for a reasonable price. Still, I need an AR7010 to make sure my driver changes don't break it. One such device has now been secured by sthen@, but for development it would help to have at least two (e.g. to test client/hostap interaction).
Re: want.html wifi stsp@
On Tue, Nov 21, 2017 at 12:40:32PM +0100, Marcus MERIGHI wrote: > I found: > > Panasonic TYWL20U Wireless LAN Adaptor EUR 137,-- > But cannot afford to just hit "buy" atm. Beware, unfortunately there are some seriously overpriced offers for this type of hardware. I think it's a shame. The hardware by itself isn't nearly worth that much. The expensive offers I've been shown are either for products tied to a specific brand of equipment (e.g. Panasonic, Sony), or they come from shops selling originally cheap but now suddenly very expensive rebranded devices "certified" compatible with some "linux-libre" OS. This is taking advantage of people who believe in software freedom but lack the expertise or community support to choose their hardware accordingly. I have already turned down an offer from someone who wanted to buy a device from such a linux-libre shop for me. In my opinion, shops with such enormously overblown prices are in opposition to ethical values implied by free software, such as fairness and co-operation. Should it turn out that these devices aren't cheaply and widely available because they're being scooped up by such shops, this would call efforts for supporting the open firmware into question. These devices are supposed to be a commodity, not expensive toys. Reasonable prices would be in the 10-30 Euro range.
Re: pppd and DNS
On Thu, Nov 16, 2017 at 08:36:18PM +, Roderick wrote: > But still I want to get the DNS from the ppp peer. Then you need to ask your ISP for static nameserver IPs, or use a umb(4) device, or implement this missing feature in sppp(8) such that it decodes the relavant IPCP options passed by the PPP session peer and makes the information available somehow. See /usr/src/sys/net/if_spppsubr.c for relevant source code. With my umsm(4) device, running 'tcpdump -n -i ppp0 -v' while connecting, I see: 23:15:59.704894 IPCP: Configure-Nak, Unknown IPCP code 0x81 0308 001c 8106 0a0b 0c0d 8306 0a0b 0c0e 8206 0a0b 0c0d 8406 0a0b 0c0e This seems to be one of several DNS related IPCP codes which our sppp(4) driver ignores. According to Table 7.10 here: https://technet.microsoft.com/en-us/library/cc957981.aspx "Primary DNS server address | 129 or 0x81"
Re: pppd and DNS
On Thu, Nov 16, 2017 at 08:09:27PM +, Roderick wrote: > > > On Thu, 16 Nov 2017, Stefan Sperling wrote: > > > For WAN devices supported by umsm(4), the situation is a bit better. > > The umsm(4) driver shows DNS resolver IPs in ifconfig output so scripts > > can grab them from there. > > Thanks. How do I get the DNS with ifconfig? This is what I get: Sorry, I got confused. I meant umb(4) devices, not umsm(4) devices.
Re: pppd and DNS
On Thu, Nov 16, 2017 at 01:13:55PM +, Roderick wrote: > > Dear Sirs! > > How it is supposed that I get the DNS servers from a PPP connection? > > Should I guess the servers and put them manually in resolv.conf? > > Something like dhclient ppp0 does not work. > > I think this is an old thema: > > http://openbsd-archive.7691.n7.nabble.com/pppd-usepeerdns-td261633.html > > https://marc.info/?l=openbsd-tech&m=111946828027916&w=2 > > Is there a solution that I do not know? > > Otherwise I wonder that others do not miss such a feature: > UMTS providers do not give much information and one must > lietraly quess it with help google. > > Rodrigo. Indeed, it seems pppd doesn't support getting DNS resolvers in client mode. I've run into the same issue years ago. Nowadays I always use a VPN across such links and just get DNS from the other end of my tunnel. You could try running unbound(8) and make resolv.conf point to 127.0.0.1. That should give you working DNS in any case. For WAN devices supported by umsm(4), the situation is a bit better. The umsm(4) driver shows DNS resolver IPs in ifconfig output so scripts can grab them from there.
Re: Atheros AR9300
On Wed, Nov 15, 2017 at 03:04:15PM -0500, mabi wrote: > Hi, > > I just got myself a new firewall device (Lanner FW-7526) to replace my dying > Soekris box. That new firewall shipped with an Atheros AR9300 wireless chip > and just realized from the dmesg output and athn man page (OpenBSD 6.2) that > this chip must not be supported (yet). > > The dmesg output is the following: > > "Atheros AR9300" rev 0x01 at pci4 dev 0 function 0 not configured > > Is my conclusion here correct? or am I just missing a non-free firmware > (though I ran the fw_update command already). > > Best regards, > Mabi Not yet supported. And athn(4) PCI devices do not require any firmware, a firmware is only needed for athn(4) USB devices. I would suggest to try locating an athn(4) AR9280 or ral(4) RT2700/RT2800 device instead.
Re: Atheros A5424 still not supported?
On Wed, Nov 15, 2017 at 06:39:20PM +, Roderick wrote: > > I get in dmesg: > > ath0 at pci1 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 16 > ath0: AR5424 14.2 phy 7.0 rf 10.2 eeprom 5.3, EU1W, address > 00:24:2b:e3:03:40 > [...] > ath0: unable to reset hardware; hal status 3523714312 > ath0: unable to reset hardware; hal status 1 > > I thank for any hint. > > Rodrigo > Nobody has done any work to fix AR5424. Sorry.
Re: CUPS and AVAHI (bloatware)
On Mon, Oct 30, 2017 at 06:36:38AM -0400, Rupert Gallagher wrote: > The openbsd decision to make cups package dependent from avahi is > opaque. Where can we read this decision? What is the evidence that > supported it? Is this evidence still relevant? Why, oh why, the > package maintainer(s) of cups resist the opportunity to make their own > burden less heavy by removing needless parts? Are they on avahi's > payroll? What is the point of stirring around in the past? That won't change anything. Where is your diff that fixes a problem, today? Venting frustration on this list is not productive and won't solve your problem. Instead, you could be patiently and respectfully discussing technical details of your proposed diff with the package maintainers (provided they're still in the mood for such a discussion after you've derided their work on this list).
Re: CUPS and AVAHI (bloatware)
On Mon, Oct 30, 2017 at 06:11:45AM -0400, Rupert Gallagher wrote: > Ingo, we must not install 100MB of unwanted optional software. > Since when OpenBSD joined the bandwagon of bloatware? It's happened ever since you chose not to do anything about it. It's your choice. If you really need to get rid of those extra 100MB you can figure out what's involved, try to achieve consensus for your ideas within the community, and get the work done. If consensus for your ideas cannot be achieved, you can still maintain custom changes locally and be happy with a system built just as you like it.
Re: fuse version
On Tue, Oct 24, 2017 at 07:46:29PM +0200, Zbyszek Żółkiewski wrote: > Hi, > > llfuse requires FUSE 2.9.0 or newer, i think OpenBSD uses 2.6, am I right? > > thanks, Yes, OpenBSD's API declares version 2.6. But it's not the same implementation as on Linux. I don't know if even 2.6 support can be considered complete. Since llfuse seems to be a Python wrapper for fuse, it probably requires a larger subset of the fuse API than most other fuse consumers. So what you're asking for requires a complete API and llfuse audit just to document requirements, and then implementations of any missing APIs in libfuse and/or the kernel. That's quite a big project. The answer for now will probably be: If you invest time and work into it, it might happen. Otherwise, no. More help on fuse support would certainly be welcome, I think. It has not been actively maintained for some time.
Re: fuse version
On Tue, Oct 24, 2017 at 11:21:17AM +0200, Zbyszek Żółkiewski wrote: > Hi, > > Quick question: Any plans to support newer version of fuse? > > thanks, > > _ > Zbyszek Żółkiewski > Your question is not specific enough.
Re: About WPA2 compromised protocol
On Mon, Oct 16, 2017 at 06:47:21AM -0400, Raul Miller wrote: > What is the relevant language from the spec? Well, the spec is huge. The section on WPA is pretty long. Everyone can download the spec from IEEE. I am not going to quote it here.
Re: About WPA2 compromised protocol
On Mon, Oct 16, 2017 at 12:45:24PM +0200, Erik van Westen wrote: > But did every manufacturer make the same mistake then? Yes.
Re: About WPA2 compromised protocol
On Mon, Oct 16, 2017 at 10:22:26AM +, C. L. Martinez wrote: > HI all, > > Regarding WPA2 alert published today: https://www.krackattacks.com/, > if I use an IPSec tunnel with shared-key or certifcate or an OpenVPN > connection to authenticate and protect clients and hostAP comms, is > this vulnerability mitigated? > > Thanks. > Also this was *NOT* a protocol bug. arstechnica claimed such nonesense without any basis in fact and now everybody keeps repeating it :( It was an implementation bug.
Re: About WPA2 compromised protocol
On Mon, Oct 16, 2017 at 10:22:26AM +, C. L. Martinez wrote: > is this vulnerability mitigated? Yes. This was 6.1 errata 027.
Re: athn0: device timeout and network hanging with AR9285
On Sun, Oct 15, 2017 at 12:38:56AM -0500, Ax0n wrote: > Frequently -- several times per hour when I'm actively doing stuff on my > laptop, the network hangs for perhaps 30-60 seconds. This coincides with > athn0 timeout messages on the console. I don't have much data to back up my > claim that it feels like it's more frequent since the upgrade to 6.2, but > it was happening under 6.1 Stable as well. I notice it more if I am moving > large-ish files around, but that could simply be because my work gets > interrupted. athn can indeed stall and be generally slow on channels where other access point are active as well. The first thing to check is to see if you can find an empty channel to move it to.
Re: iwm fatal firmware error on - current
On Sat, Oct 14, 2017 at 04:24:29PM -0600, Dan Jones wrote: > On 6.2 current shortly after boot iwm fails with the error: > > iwm0: fatal firmware error > iwm0: could not remove MAC context (error 35) > > The device is able to initially connect get an address and connect for a few > minutes. Output from ifconfig and dmesg are below. Let me know what other > troubleshooting steps will be helpful. > This looks like a spurious failure during disassociation from an AP. When this error happens, the device will be reset and should resume normal operation. Is this a recurring issue or did it happen just once?
Re: "athn0: could not load firmware" for AR9271
On Sat, Oct 14, 2017 at 11:59:11AM -0400, Tim Stewart wrote: > Maximilian Pichler writes: > > > The dmesg is the same as previously (this is on the APU), except for: > > athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16 > > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:e2 > > I'm debugging some issues with my wle200nx in a PC Engines apu2c4, and I > have a very similar dmesg output: > > athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16 > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:26:d3:28 > > I am curious, is it expected that the first line says "Atheros AR9281" > and the second says "AR9280"? In particular, athn(4) makes the AR9281 > sound less capable: > > The AR9281 is a single-chip PCIe 802.11n solution. It exists in PCIe > Mini Card (XB91) and half Mini Card (HB91) form factors. It operates in > the 2GHz spectrum and supports 1 transmit path and 2 receiver paths > (1T2R). This is indeed contradictory information. The string "AR9281" comes from a static list in OpenBSD's kernel and bears no actual relation to what's in the hardware. Provided the in-kernl list is correct, It means the manufacturor has written the PCI ID of an AR9281 into the card's PCI config space. The OS will try to attach a driver which matches on this PCI ID. Once attached, the driver performs actual probing and finds an AR9280 chip. If the driver were misidentifying the chip this could lead to all sorts of problems and misbehaviours. Whether the driver's probing or the vendor's PCI ID is correct, I cannot tell. I'll note though that no code which is specific to the 9281 seems to exist in our driver. That's a bad sign, and could indicate that this chip isn't properly supported yet. > I will reply with more details if I can better quantify the issues I'm > having. Please do.
Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode
On Thu, Oct 12, 2017 at 03:16:44AM +0300, Rostislav Krasny wrote: > Boasty? I just try to help you to fix this bug by providing the > information I've found. It's hard to fix it by myself because of the > several times mentioned reasons. If you don't want to fix it just > because you don't want I can live with that. Of course, people who don't suffer from this particular problem don't want to fix it. They simply don't have any need to fix it. The problem has been acknowledged, and people have suggested workarounds, and given you reasons why it's not immediately solvable without more effort on your part. That's where this conversion could have ended with a one liner from you such as "OK, bummer. Anyway, thank you for your time" and it would have been entirely appropriate.
Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode
On Thu, Oct 12, 2017 at 12:18:52AM +0300, Rostislav Krasny wrote: > You just lose users and popularity. In this community, your statement has the opposite effect of what it is trying to achieve. It puts developers off and discourages them from worrying about your problem. At any given moment, there are enough problems developers have to worry about already. Hardware they want to use which does not work yet, new problems people report in code they've recently changed, chasing new developments in code they've ported from other projects, new features they want to implement, etc. etc.; all stacked against limited time. Worrying about popularity on top of it all would just be distracting. The mindset here is that if you really want something fixed in OpenBSD, try to fix it yourself, and then try to share your fix with the rest of us. That's how, collectively, we produce value, and popularity has nothing to do with it.
Re: softraid crypto with keydisk and password
On Tue, Oct 10, 2017 at 11:13:45PM +1100, tomr wrote: > Well... there's nothing in the FAQ about using a keydisk at all, and > there's no hints in bioctl(8) about using both a keydisk and a password > together. That's because using both isn't a supported use case yet. In the current design and implementation, there's either a passphrase or a keydisk, but never both. > The last comment on this thread describes what I'd like to do, which is > to somehow have a keydisk *and* a passphrase: > https://undeadly.org/cgi?action=article&sid=20131112031806 Please understand that I don't have any interest in supporting such hacks. If you use them and they work for you, that's fine of course. I'd rather see a patch that makes this feature a proper part of the design and implementation. I don't need this feature. But if you write a patch to implement it properly, I will review your patch.
Re: l2tp client
On Mon, Oct 09, 2017 at 08:03:54PM -0500, Daniel Boyd wrote: > I’ve just started a job where I will be working from home a bunch, so I would > like to configure my home router as an ipsec/l2tp client and to push the > routes from my work network to all computers on my home network. i.e. a > site-to-site VPN. > > I have found a bunch of documentation for configuring OpenBSD as a ipsec/l2tp > server, but not as much as a client. > > I assume I’ll need the xl2tpd package… When I connect a Mac, iOS device, or > PC, the VPN requires a username, password and a secret. > > Can anyone point me in the direction of some documentation to get started? > > Thanks! > > Daniel Boyd If you install the xl2tpd package you'll find a README file with instructions in /usr/local/share/doc/pkg-readmes/
Re: Can't boot from encrypted disk after attaching/detaching from another machine
On Wed, Oct 04, 2017 at 10:57:28AM +0100, Zé Loff wrote: > On Wed, Oct 04, 2017 at 10:41:56AM +0100, Zé Loff wrote: > > > > Hi all > > > > I connected my laptop's encrypted HDD to my desktop machine to copy some > > stuff and when I put it back on the laptop the boot loader no longer > > asks for the passphrase and thus I can't boot from it. Any clues? Some > > notes: > > > > - Both machines are amd64 running snapshots, 6.2 #115 (Sep 27) on the > > laptop, 6.1 #125 (Oct 1) on the desktop (I had to disable pcppi on the > > desktop, so not exactly vanilla). > > > > - The softraid volume was and still is correctly attached/detached on > > the desktop and on a i386 machine running 6.1-release+mtier > > > > - The metadata changed when connecting to the desktop, roaming from sd1 > > to sd3. I attached/detached it on the i386 machine to make it roam > > back to sd1, just in case, but it expectedly made no difference. > > > > - I ran installboot on the softraid volume, to no avail. > > > > - Tried booting bsd.rd from a USB stick, starting an upgrade, dropping > > to shell, MAKEDEV sd0 sd1 sd2, attaching the crypto volume and > > selecting it as the root disk. The installer complains that it is not > > a valid root disk even though all tests mention here[1] pass: > > > > > > [1] https://marc.info/?l=openbsd-bugs&m=150170071321416&w=2 > > Strike that last one. Forgot to umount /mnt before going back to the > installer, so the "mount test" failed in the installer. Just managed to > do the upgrade and it's all back to normal now. > > Anyway, I took a bit of a scare there. Can anyone shed some light on to > what happened? Is a CAVEAT in order? I can try to write something up, > but I'd need to understand it first... Sounds like the BIOC_SCBOOTABLE flag in softraid meta data got cleared when the meta data was rewritten by your desktop machine. If you compile kernels on both machines with 'option SR_DEBUG' and repeat the process, you should be able to confirm this. The kernel will now print softraid meta data to dmesg while rewriting it. Among several lines there will be a line 'ssd_vol_flags 0x...'. The volume is bootable only if flag bit 0x80 is set. The only way to set the 'bootable' bit is via installboot(8). You said you were running installboot (how exactly?) but it seems this somehow didn't succeed and only the installer eventually succeeded with this when you did an upgrade? So far, I cannot tell if this is a bug or intended behaviour.
Re: Can I rotate the framebuffer (e.g. using wsdisplay) in OpenBSD?
On Thu, Sep 28, 2017 at 08:48:31AM -, ti...@openmailbox.org wrote: > In a world where such weird laptop manufacturers exist, OpenBSD > having framebuffer rotation would fix the whole setup. Yes, and as was already stated there are developers (not me) who plan to do that work and might even generously share their results with all of us. Just be patient, please.
Re: Can I rotate the framebuffer (e.g. using wsdisplay) in OpenBSD?
On Thu, Sep 28, 2017 at 12:55:41AM +0200, Stéphane Aulery wrote: > Le 27/09/2017 à 17:24, Stefan Sperling a écrit : > > On Wed, Sep 27, 2017 at 04:11:45PM +0200, Kamil Cholewiński wrote: > > > On Wed, 27 Sep 2017, Francois Pussault wrote: > > > > maybe installing a tool like xrandr ? > > > > > > Xrandr works only for X. I've skimmed wscons(4), wsdisplay(4), > > > wsconscfg(8), wsconsctl(8), nothing about rotation... > > > > In -current, the console is rotated counter-clockwise if the display > > isn't already upright: > > https://marc.info/?l=openbsd-cvs&m=150266331224832&w=2 > > https://marc.info/?l=openbsd-cvs&m=150300131911666&w=2 > > > > This behaviour is hard-coded and cannot be configured. It helps machines > > which > > need counter-clockwise rotation, but is not ideal because some machines need > > clockwise rotation instead. There are plans to auto-detect and use the > > correct > > rotation required in the future. > > And if I use a monitor in portrait orientation ? I have been using a monitor in portrait for many years and was never bothered by the console being the wrong way (X is rotated of course). In a rare situation where I need the console, I can make use of the laws of physics and turn the monitor upright with my hands and arms. This approach seems to work very reliably. I've never seen it fail.
Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?
On Wed, Sep 27, 2017 at 05:02:06PM -, ti...@openmailbox.org wrote: > > On Wed, Sep 27, 2017 at 10:31:22AM -, ti...@openmailbox.org wrote: > >> >> OpenBSD/amd64 BOOTX64 3.32 Are you running -current? (We would already know that if you had included a dmesg -- tsk tsk). In -current, boot is version "3.33", not "3.32". > I then booted the machine (by typing "boot sr0a:/bsd" in the boot console > again of course) and did "installboot -v sd1", and it gave: > > Using / as root > installing bootstrap on /dev/rsd0c > using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot > sd1: softraid volume with 1 disk(s) > sd1: installing boot loader on softraid volume > /usr/mdec/boot is 6 blocks x 16384 bytes > copying /usr/mdec/BOOTIA32.EFI to > /tmp/installboot.1lt1hgtQYa/efi/BOOT/BOOTIA32.EFI > copying /usr/mdec/BOOTIX64.EFI to > /tmp/installboot.1lt1hgtQYa/efi/BOOT/BOOTIX64.EFI > > Rebooting, that also did not help. That looks OK, though. Passing the softraid disk is correct. > I tried with "fdisk -e sd1" and disabling the 1 (EFI) partition by setting > its type to 0 (so that installboot would not try to install any EFI files to > sd1i) and then doing "installboot sd1", and that did not help too. > > What am I doing wrong, are there actually any installboot arguments that > could help me make it work? It looks like you're using GPT on both the physical and the softraid disk, correct? In my setup, I have GPT on the physical disk (sd0) but an MBR on the softraid volume. So perhaps try using an MBR on sd1 and see if that helps? I am poking in the dark here. No idea if that will work for you.
Re: softraid crypto with keydisk and password
On Thu, Sep 28, 2017 at 04:15:20AM +0200, Erling Westenvik wrote: > On Thu, Sep 28, 2017 at 09:11:49AM +1000, tomr wrote: > > I remember seeing a post, I think on undeadly.org, which went through > > having the bootloader on password-encrypted usb drive, that also > > contains a keyfile for the main disk. It said something like "I also > > wanted the laptop to appear broken, and the disk full of random data, if > > the usb drive wasn't present - rather than stopping at a password prompt" > > Here you go: > > http://www.undeadly.org/cgi?action=article&sid=20110530221728 Hi, I am the author of this undeadly article. It is now very old and full of outdated information. Follow this FAQ section instead: http://www.openbsd.org/faq/faq14.html#softraid
Re: Can I rotate the framebuffer (e.g. using wsdisplay) in OpenBSD?
On Wed, Sep 27, 2017 at 04:11:45PM +0200, Kamil Cholewiński wrote: > On Wed, 27 Sep 2017, Francois Pussault wrote: > > maybe installing a tool like xrandr ? > > Xrandr works only for X. I've skimmed wscons(4), wsdisplay(4), > wsconscfg(8), wsconsctl(8), nothing about rotation... In -current, the console is rotated counter-clockwise if the display isn't already upright: https://marc.info/?l=openbsd-cvs&m=150266331224832&w=2 https://marc.info/?l=openbsd-cvs&m=150300131911666&w=2 This behaviour is hard-coded and cannot be configured. It helps machines which need counter-clockwise rotation, but is not ideal because some machines need clockwise rotation instead. There are plans to auto-detect and use the correct rotation required in the future.
Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?
On Wed, Sep 27, 2017 at 10:31:22AM -, ti...@openmailbox.org wrote: > probing: pc0 mem[572K 56K 495M 1455M 5M 6144M] > disk: hd0* hd1* hd2 sr0* > >> OpenBSD/amd64 BOOTX64 3.32 > open(hd0a:/etc/boot.conf): Invalid Argument > boot> > > > This error may be because OpenBSD creating "boot.conf" within the FAT32 EFI > system boot volume actually crates "bo~1.con", which is not resolved as > "boot.conf" by OpenBSD's BOOTX64 EFI loader program? - boot.conf has nothing to do with it. softraid boot is handled independently from boot.conf. > How do I instruct BOOTX64 to boot from sr0a:/boot ? What's odd is that you have a bootable sr0 but the boot loader still tries hd0 instead. That looks like a bug. Usually sr0 should be tried in this situation. I don't know the solution. Perhaps try re-running installboot? FWIW, this all works fine for me on a thinkpad helix2.
Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?
On Wed, Sep 27, 2017 at 08:06:15AM -, ti...@openmailbox.org wrote: > Hi! > > Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, > right? > > It's supposed to work exactly the same way, just out of the box, the boot > code will ask for typed password or keydisk, right? > > Thanks, > Tinker http://www.openbsd.org/faq/faq14.html#softraid
Re: Wireless not working with Linksys
On Sat, Sep 23, 2017 at 12:18:22PM +0300, Timo Myyrä wrote: > $ doas ifconfig iwn0 scan | grep MyNet > nwid MyNet chan 11 bssid xx:xx:xx:xx:xx:xx -21dBm HT-MCS23 > privacy,short_preamble,short_slottime,wpa2,wpa1 Try disabling WPA1 on your AP. In your AP's configuration, look for config items such as "WPA2", "CCMP", "AES" and enable them. Disable anything labeled "WPA1" and/or "TKIP".
Re: Xbox 360 controller emulators/snes9x hangs at startup
On Fri, Sep 22, 2017 at 12:33:29AM -0700, Nam Nguyen wrote: > I tested 6.0 -release and 6.1 -release, and emulators/snes9x > loaded OK with all controllers. This bug appeared once I updated to a > -current snapshot. My hypothesis is that -current introduced a > regression with uhid(4). Can you compile a kernel with sys/dev/usb/uhid.c reverted to older revisions to test your hypothesis? Your system has both xhci(4) USB 3 and ehci(4) USB 2 ports. Does it matter where the input devices are plugged? > xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 > addr 1 > ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 > usb1 at ehci0: USB revision 2.0 > uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 > addr 1 > ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 23 > usb2 at ehci1: USB revision 2.0 > uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 > addr 1
Re: Wireless devices for a new product
On Tue, Sep 19, 2017 at 03:00:15PM +0100, Kevin Chadwick wrote: > > We are designing a PCB board that will run OpenBSD and wish to build in > wifi and 3g/UMTS/LTE devices whilst avoiding PCIEX as those are more > expensive than a module. > > I assume ar9280 is still the recommended wifi chipset out of all > including surface mount devices? If it's going to run an AP, then probably yes. However, there seems to be a problem where the hardware does not go beyond about 24 Mbit/s for transmissions. I've never figured out what's wrong, but I suspect it's a long-standing bug in our driver. There have been reports indicating that an AP using ral(4) in 11g mode can work faster than athn(4). I can confirm that ral(4) can reach 54 Mbit/s under the same conditions where athn(4) is stuck at 24 Mbit/s. And since 11n support is still incomplete (no Tx aggregation, no 40MHz channels) I don't think it's going to be a solution that can compete with commercial APs. It simply doesn't offer performance levels people expect nowadays. Perhaps your target market doesn't care about performance as much. But nobody here will feel responsible if your product doesn't sell or becomes a refund nightmare. Read the licence! Client mode will be much happier with iwm(4) which has sufficient performance for many use cases, though complete 11n (or even 11ac) support could squeeze out much more. > p.s. This is for our soon to be trialled products and we don't have > plans certainly in the short term of releasing a board and it won't > be multi ethernet port, initially atleast anyway. Sounds interesting. I am happy to see OpenBSD being used in such products. > I wish to give > back to this community any way I can in the future though :) If you ever happen to come across a budget to help improve the driver situation, it could be possible to find developers who would use such funding for great good.
Re: softraid crypto seem really slower than plain ffs
On Sun, Sep 17, 2017 at 07:32:49PM +0100, Kevin Chadwick wrote: > I'm not a developer but I know 6.1 moved to a shiny new side channel > resistant AES. I seem to remember Theo saying that if it is that slow > then even worse; people won't use encryption at all and if they need > side channel resistance then they could get a processor with AES-NI > etc.. Not sure if it was reverted in the end or not. It was reverted.
Re: uvideo0: could not open VS pipe: INVAL + error: [drm:pid49266:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
On Sat, Sep 16, 2017 at 02:24:17AM +0300, MazoComp wrote: > $ fswebcam > --- Opening /dev/video0... > Trying source module v4l2... > /dev/video0 opened. > No input was specified, using the first. > Adjusting resolution from 384x288 to 320x240. > Error starting stream. > VIDIOC_STREAMON: Invalid argument > Unable to use mmap. Using read instead. > --- Capturing frame... > Timed out waiting for frame! > No frames captured. > $ dmesg | grep video > acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: DD1F > uvideo0 at uhub0 port 6 configuration 1 interface 0 "Chicony Electronics > Co.,Ltd. Lenovo EasyCamera" rev 2.00/95.60 addr 5 > video0 at uvideo0 > uvideo0: could not open VS pipe: INVAL > uvideo0: could not open VS pipe: INVAL This error is expected. xhci(4) does not support isochronous transfers yet which are required for 'real-time streaming' data like video/audio. This is being worked on. I hope to get this working in the coming months. > $ dmesg | grep error > error: [drm:pid49266:intel_pipe_update_start] *ERROR* Potential atomic update > failure on pipe A Known issue. I can't say if/when this will be fixed. > I hope that is fixable, I'd like to use my built-in webcam for videocalls... > By the way, I think the only solution for this: > $ dmesg | grep 8188EE > "Realtek 8188EE" rev 0x01 at pci3 dev 0 function 0 not configured > $ > is smashing this built-in adapter with hammer. This one needs patches to rtwn(4) to make it work. The USB version of this chip is already supported, so it shouldn't be hard to do for somebody who can program in C and owns the hardware.
Re: IKEv1 IKEv2 coexistance ?
On Mon, Sep 11, 2017 at 09:24:55AM +, Christoph Leser wrote: > I read in an 2013 paper by Reyk Floeter about openIKED > (https://www.openbsd.org/papers/openiked-asiabsdcon2013.pdf) > > "The design intends to allow operation of both protocol versions on the same > host" > > but > > "The unprivileged IKEv1 process is currently an empty stub" > > Does this mean that I cannot have both IKEv1 and IKEv2 on a single openBSD > machine? AFAIK an underlying problem is that iked(4) and isakmpd(4) cannot share the in-kernel SA DB. > Is there any way to run iked and isakmpd on the same machine ( maybe with the > help of > pf to redirect ike2 hosts to a non default port )? I haven't tried this myself but if you are constrained to one _physical_ machine, you could run another virtual machine in vmm(4) to serve one of the two IKE protocols. I suspect you'll want two separate IP addresses in any case, though. Keeps things simple.
Re: MediaTek Mt7601
On Fri, Aug 25, 2017 at 01:57:46PM -0700, Heppler, J. Scott wrote: > The wikidevi entry suggests that this may be low-hanging fruit to > add to OpenBSD/FreeBSD/NetBSD. The question I have is whether to give > the MediaTek away and try to purchase on older RealTek or be patient and > wait a few months? Drivers do not write themselves, and as far as I know nobody is working on this newer family of mediatek chips. Which is unfortunate. Finding a working USB wifi dongle should not be hard. If in doubt, try pasting some of the device names listed in man pages into ebay.
Re: iwn0: no link after 6.1 upgrade
On Sat, Aug 19, 2017 at 03:51:32PM +0200, Alexis de BRUYN wrote: > Yes, I have double-checked, this is what is shown in the Web GUI. > "Authentication PassPhrase Settings" : "WPA-Personal" > "WPA Mode" : "WPA2 Only" > "Cipher Type" : "TKIP" Please set Cipher Type to 'AUTO' or 'AES'. Then it should work. TKIP is used with WPA1 only.
Re: iwn0: no link after 6.1 upgrade
On Sat, Aug 19, 2017 at 02:54:05PM +0200, Alexis de BRUYN wrote: > On 08/19/17 11:35, Stefan Sperling wrote: > > On Sat, Aug 19, 2017 at 11:12:04AM +0200, Alexis de BRUYN wrote: > > > After an 6.1 upgrade (from 6.0-release to 6.1-release) on my Lenovo X230 > > > laptop, I can't get my wireless connection working anywore on different > > > kind > > > of access points or ISP boxes. Same problem on 6.1-current > > > > My guess is that your AP is using WPA1. Is this correct? > On my DLINK DAP-2310 with the last firmware, the WPA mode is WPA2 Only. I > cannot check with other AP today. Are you really sure about that? > > WPA1 has been disabled by default because it is not secure. > > Make sure your AP is using WPA2 (sometimes called "AES" by vendors). > > Only if you cannot change the AP, try: ifconfig iwn0 wpaprotos wpa1,wpa2 > $ sudo ifconfig iwn0 wpaprotos wpa1,wpa2 > $ sh /etc/netstart iwn0 > DHCPREQUEST on iwn0 to 255.255.255.255 > DHCPREQUEST on iwn0 to 255.255.255.255 > DHCPACK from 192.168.0.51 (ec:a8:6b:ff:15:4e) > bound to 192.168.0.9 -- renewal in 900 seconds. > > But not working with > $ sudo ifconfig iwn0 wpaprotos wpa2 > $ sudo sh /etc/netstart iwn0 > iwn0: no link ... sleeping This implies that the AP is using WPA1, no? > > Please also show the output of 'ifconfig iwn0 scan' and show any > > additional messages produced in /var/log/messages after running > > 'ifconfig iwn0 debug'. > > $ sudo ifconfig iwn0 scan > iwn0: flags=8843 mtu 1500 > lladdr 60:67:20:43:86:aa > index 2 priority 4 llprio 3 > groups: wlan > media: IEEE802.11 autoselect (autoselect mode 11a) > status: no network > ieee80211: nwid my_ssid wpakey [...] wpaprotos wpa2 wpaakms psk > wpaciphers ccmp wpagroupcipher ccmp And there were no lines here showing access points? These lines would probably tell us which WPA version is used by your AP, if you had shown them. > $ sudo ifconfig iwn0 debug > $ tail -f /var/log/messages > Aug 19 14:48:29 lt4-alexis /bsd: iwn0: end passive scan > Aug 19 14:48:29 lt4-alexis /bsd: - 54:b8:0a:39:df:481! +233 54M ess > privacy rsn! "my_ssid" This shows the AP is not being selected because it has the wrong channel (channel 1 when we expected something else, probably cause the scan was currently scanning 11a mode which only supports channels >= 36, nothing to worry about) and the wrong encryption settings (rsn!) (so again, this indicates AP is using WPA1).
Re: iwn0: no link after 6.1 upgrade
On Sat, Aug 19, 2017 at 11:12:04AM +0200, Alexis de BRUYN wrote: > After an 6.1 upgrade (from 6.0-release to 6.1-release) on my Lenovo X230 > laptop, I can't get my wireless connection working anywore on different kind > of access points or ISP boxes. Same problem on 6.1-current My guess is that your AP is using WPA1. Is this correct? WPA1 has been disabled by default because it is not secure. Make sure your AP is using WPA2 (sometimes called "AES" by vendors). Only if you cannot change the AP, try: ifconfig iwn0 wpaprotos wpa1,wpa2 Please also show the output of 'ifconfig iwn0 scan' and show any additional messages produced in /var/log/messages after running 'ifconfig iwn0 debug'.
Re: OpenBSD 6.1 on Asus E200HA (SoC Intel z8350)
On Thu, Aug 17, 2017 at 02:53:09PM +0100, Pedro Ramos wrote: > Hello, > I am having troubles making the Asus E200HA (SoC Intel z8350) keyboard work > correctly on OpenBSD 6.1. > > OpenBSD does detect the keyboard and it works at boot time during > installation. But as soon it gets to the installer prompt the keyboard does > not work any more. > > Any idea how to fix this issue? Thanks. > > Best regards, > Pedro Ramos > This was fixed in -current yesterday. I would recommend -current on this machine anyway as it contains relatively new hardware.
Re: D-Link DWA-137 A1 and DWA-140 D1 to work (patch)
On Mon, Aug 14, 2017 at 01:41:22AM +0300, Mike Korbakov wrote: > Hello, misc! > > I propose a patch for working Wi-Fi device D-Link DWA-130 B1 and DWA-140 D1: > http://wikidevi.com/wiki/D-Link_DWA-137 > http://wikidevi.com/wiki/D-Link_DWA-140_rev_D1 > > In my case, both devices were identifiable and worked on OpenBSD-6.1 amd64, > if anyone else has these devices, please confirm their function with my patch. > I hope that developers will include support for these devices. > > Best regards, > Mike Korbakov Comitted, thanks!
Re: run(4) D-Link DWA-130 rev F1
On Wed, Aug 02, 2017 at 10:08:51AM -0700, Jacqueline Jolicoeur wrote: > Hi, > > I have a D-Link DWA-130 rev F1 which was not being detected. > > I took a guess and made this kernel patch for run(4) which seems > to work for me thus far. The device is now detected, connects with > nwid, wpakey and dhclient. The 0x3c25 magic is from usbdevs(8) > > Tested using amd64 GENERIC.MP -current Committed, thanks! > > Index: share/man/man4/run.4 > === > RCS file: /cvs/src/share/man/man4/run.4,v > retrieving revision 1.49 > diff -u -p -r1.49 run.4 > --- share/man/man4/run.4 13 Jul 2017 08:10:50 - 1.49 > +++ share/man/man4/run.4 2 Aug 2017 05:21:21 - > @@ -120,7 +120,7 @@ The following adapters should work: > .It Corega CG-WLUSB300AGN > .It Corega CG-WLUSB300GNM > .It D-Link DWA-127 > -.It D-Link DWA-130 rev B1 > +.It D-Link DWA-130 rev B1, F1 > .It D-Link DWA-140 rev B1, B2, B3, \&D1 > .It D-Link DWA-160 rev B2 > .It D-Link DWA-162 > Index: sys/dev/usb/if_run.c > === > RCS file: /cvs/src/sys/dev/usb/if_run.c,v > retrieving revision 1.121 > diff -u -p -r1.121 if_run.c > --- sys/dev/usb/if_run.c 21 Jul 2017 00:55:05 - 1.121 > +++ sys/dev/usb/if_run.c 2 Aug 2017 05:21:31 - > @@ -153,6 +153,7 @@ static const struct usb_devno run_devs[] > USB_ID(COREGA, RT3070), > USB_ID(CYBERTAN,RT2870), > USB_ID(DLINK, DWA127), > + USB_ID(DLINK, DWA130F1), > USB_ID(DLINK, DWA140B3), > USB_ID(DLINK, DWA160B2), > USB_ID(DLINK, DWA162), > Index: sys/dev/usb/usbdevs > === > RCS file: /cvs/src/sys/dev/usb/usbdevs,v > retrieving revision 1.674 > diff -u -p -r1.674 usbdevs > --- sys/dev/usb/usbdevs 6 Jun 2017 00:52:02 - 1.674 > +++ sys/dev/usb/usbdevs 2 Aug 2017 05:21:32 - > @@ -1544,6 +1544,7 @@ product DLINK DWA140B3 0x3c15 DWA-140 r > product DLINK DWA160B2 0x3c1a DWA-160 rev B2 > product DLINK DWA127 0x3c1b DWA-127 > product DLINK DWA162 0x3c1f DWA-162 Wireless Adapter > +product DLINK DWA130F1 0x3c25 DWA-130 rev F1 > product DLINK DSB650C0x4000 10Mbps Ethernet > product DLINK DSB650TX1 0x4001 10/100 Ethernet > product DLINK DSB650TX 0x4002 10/100 Ethernet >
Re: Lumina enable Shut Down
On Sun, Jul 23, 2017 at 09:10:07PM +0200, Martijn Rijkeboer wrote: > On 22-07-17 02:02, Sha'ul wrote: > > In Lumina desktop how do I enable shutdown from GUI menu for point and > > click poweroff and reboot? > > Try adding yourself to the 'operator' group. The operator group has read access to raw disk device nodes, bypassing file system permissions: ls -l /dev/r[ws]d[0-9]* Allowing shutdown/reboot via doas(1) is a safer option.
Re: Doubts about the successors of OpenBSD leadership and development
On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote: > Who will succeed Theo de Raadt in the leadership and development of OpenBSD? Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and development of OpenBSD: http://marc.info/?l=openbsd-misc&m=137609553004700&w=2
Re: "iwi0: fatal firmware error"
On Sat, Jul 01, 2017 at 06:19:59PM +, Roderick wrote: > > Wlan works, but I continously get the above message in the > Toshiba Satellite mentioned in my previous posting. > > Rodrigo. > This driver has been reporting such errors forever. I would happily review patches fixing bugs in iwi(4) but I myself do not have much incentive to invest time in fixing it. It is an old driver for old hardware and does not exist in a lot of machines used today. If this problem bothers you, I would suggest finding a USB urtwn(4) or run(4) device, or a cardbus ath(4) or ral(4) device for your machine.
Re: Can't fuseFs as user: Operation not permitted
On Wed, Jun 21, 2017 at 04:09:54PM +0200, Stephane HUC "PengouinBSD" wrote: > >> On OpenBSD v6.1, i attempt to use fuse, by sshfs or encfs. > >> > >> But fuse reply by: 'fuse_mount on /home/my_user: Operation not permitted' > > You need to use doas. The usermount feature was removed. > I know about usermount;) > > Ok to mount with doas, Good. > but files permissions are only root, not user :( That sounds like a separate issue. It sounds like sshfs maps files to root, however you want it to map files to my_user instead? sshfs has several options which control user ID mapping. For encfs, the permissions depend on the underlying filesystem. What is the underlying filesystem? If it's FFS or ext2, just fix permissions with chown/chmod. If it is MSDOS, you can map permissions to a specific user with the -u option of mount_msdos(8), or by making sure the directory you're mounting at is owned by my_user.
Re: Can't fuseFs as user: Operation not permitted
On Wed, Jun 21, 2017 at 03:51:45PM +0200, Stephane HUC "PengouinBSD" wrote: > Hi, all. > > On OpenBSD v6.1, i attempt to use fuse, by sshfs or encfs. > > But fuse reply by: 'fuse_mount on /home/my_user: Operation not permitted' > > => My user is onto wheel group. > > $ getent group wheel > wheel:*:0:root,my_user > > => And i chmoded 0660 on /dev/fuse0 > > $ ls -al /dev/fuse0 > crw-rw 1 root wheel 92, 0 Apr 14 13:00 /dev/fuse0 > > Egual, i've tried with chmod 664, 666; same bad result! > > How i use it, without rights admin? You need to use doas. The usermount feature was removed.
Re: bug tracking system for OpenBSD
On Mon, Jun 19, 2017 at 07:01:13PM +0200, Philipp Buehler wrote: > Am 19.06.2017 18:51 schrieb Harald Dunkel: > > some reliable response time > > I've to decide between popcorn and other stuff with flames. Or just point out the support list? http://www.openbsd.org/support.html I guess most people and companies on that list wouldn't mind fielding bugs with reliable response time, for a price :-)
Re: With Multiple PPPoE interfaces on one will work
On Thu, May 18, 2017 at 11:15:53AM +, Steve wrote:
> Thanks,I was mostly checking if this was a known issue.If I rename
> hostname.pppoe0 to hostname.pppoe1 and then rename hostname.pppoe2 to
> hostname.pppoe0The original pppoe2 (now pppoe0) works fine but the other
> interface stops working. If I swap them back the original behaviour is seen.
> ifconfig pppoe2 debug shows no ouput.As shown below pppoe2 just stays in
> state: initial.
>
> vr2: flags=8843 mtu 1500
> lladdr 00:00:24:d1:9d:6a
> priority: 0
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
>
> pppoe2: flags=8810 mtu 1492
> priority: 0
> dev: vr2 state: initial
> sid: 0x0 PADI retries: 0 PADR retries: 0
> groups: pppoe
> status: no carrier
>
> I have now "upgraded" to 6.1. The same is noted
> Any thoughts would be appreciated.
I believe this stopped working due to legitimate changes in how the
routing table works.
To reproduce the problem, start with a fresh routing table.
Before any interfaces (except loopback) are configured it looks like:
DestinationGatewayFlags Refs Use Mtu Prio Iface
127.0.0.1 127.0.0.1 UHl00 32768 1 lo1
Prepare configuration of two pppoe interfaces as per the pppoe(4) man page:
$ cat /etc/hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev em0 authproto pap \
authname 'testcaller' authkey 'donttell' up
dest 0.0.0.1
$ cat /etc/hostname.pppoe1
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev em1 authproto pap \
authname 'testcaller2' authkey 'donttell2' up
dest 0.0.0.1
After 'sh /etc/netstart pppoe0' the routing table looks like:
DestinationGatewayFlags Refs Use Mtu Prio Iface
0.0.0.1defaultH 00 - 8 pppoe0
127.0.0.1 127.0.0.1 UHl00 32768 1 lo1
And the pppoe interface is ready to get its addresses from the peer:
pppoe0: flags=8851 rdomain 1 mtu 1492
index 15 priority 0 llprio 3
dev: em0 state: PADI sent
sid: 0x0 PADI retries: 18 PADR retries: 0
sppp: phase establish authproto pap
groups: pppoe
status: no carrier
inet 0.0.0.0 --> 0.0.0.1 netmask 0x
But the second interface fails to set its dest address since the same
route already exists in the table:
# sh /etc/netstart pppoe1
ifconfig: SIOCAIFADDR: File exists
So there's no address on pppoe1:
pppoe1: flags=8851 rdomain 1 mtu 1492
index 16 priority 0 llprio 3
dev: cdce0 state: PADI sent
sid: 0x0 PADI retries: 5 PADR retries: 0
sppp: phase establish authproto pap
groups: pppoe
status: no carrier
And as a result, this code in sys/net/if_spppsubr.c cannot work:
if (myaddr == 0) {
/*
* I don't have an assigned address, so i need to
* negotiate my address.
*/
sp->ipcp.flags |= IPCP_MYADDR_DYN;
sp->ipcp.opts |= (1 << IPCP_OPT_ADDRESS);
}
if (hisaddr == 1) {
/*
* XXX - remove this hack!
* remote has no valid address, we need to get one assigned.
*/
sp->ipcp.flags |= IPCP_HISADDR_DYN;
}
It seems a correct fix would involve replacing the above code with a better
way of setting the IPCP_MYADDR_DYN and IPCP_HISADDR_DYN flags. And this
new way should not require any 'wildcard' addresses on pppoe interfaces.
One workaround is to run each pppoe interface in a separate routing domain
so that each interface gets its own routing table.
Offhand I'm not quite sure to combine this workaround with a failover setup.
Re: "athn0: could not load firmware" for AR9271
On Sat, May 27, 2017 at 08:31:23PM -0400, Maximilian Pichler wrote:
> I've tried a PPD-AR5BHB92-H (AR9280 miniPCIe) in AP mode and connected
> clients get ~12 Mbit/s downstream and ~35 Mbit/s upstream (i.e. the
> card appears to receive data much faster than it sends). Selecting a
> less crowded 5GHz channel helped quite a bit. Is this performance more
> or less what is currently to be expected?
There is an issue where the card won't transmit at rates beyond 18M / MCS 12.
Whenever rate scaling selects a higher transmit rate it drops back down
right away, even on a clean channel. I haven't figured out why.
I expect fixing this will involve a dive into the dark magic of the
chip's low-level configuration since it looks as if OFDM modulations
at the higher end don't work (and never ever worked) with our driver.
Also, we do not support Tx aggregation in 11n mode yet.
This is why other 11n implementations manage to send more data
per second at a given data rate than we do.
> The measurements were conducted by running the following commands on a
> Macbook connected to the AP's wireless network:
>
> $ for i in {1..10}; do nc 192.168.0.1 1234 | dd of=/dev/null
> count=10240 bs=1000; sleep 1; done 2>&1 | grep trans
> 6899272 bytes transferred in 4.307439 secs (1601711 bytes/sec)
> 6864520 bytes transferred in 4.275299 secs (1605623 bytes/sec)
> 6837456 bytes transferred in 4.256377 secs (1606403 bytes/sec)
> 6734200 bytes transferred in 4.194057 secs (1605653 bytes/sec)
> 6952848 bytes transferred in 4.311542 secs (1612613 bytes/sec)
> 6898272 bytes transferred in 4.294667 secs (1606241 bytes/sec)
> 6867864 bytes transferred in 4.256106 secs (1613650 bytes/sec)
> 6906512 bytes transferred in 4.291027 secs (1609524 bytes/sec)
> 6757816 bytes transferred in 4.182866 secs (1615595 bytes/sec)
> 6871760 bytes transferred in 5.059761 secs (1358119 bytes/sec)
>
> $ for i in {1..10}; do dd if=/dev/urandom count=10240 bs=1000 | nc
> 192.168.0.1 1234; sleep 1; done 2>&1 | grep trans
> 1024 bytes transferred in 2.290328 secs (4470975 bytes/sec)
> 1024 bytes transferred in 2.251763 secs (4547548 bytes/sec)
> 1024 bytes transferred in 2.160710 secs (4739183 bytes/sec)
> 1024 bytes transferred in 2.031869 secs (5039695 bytes/sec)
> 1024 bytes transferred in 2.215611 secs (4621750 bytes/sec)
> 1024 bytes transferred in 3.615391 secs (2832335 bytes/sec)
> 1024 bytes transferred in 2.340003 secs (4376063 bytes/sec)
> 1024 bytes transferred in 2.185185 secs (4686102 bytes/sec)
> 1024 bytes transferred in 2.509382 secs (4080686 bytes/sec)
> 1024 bytes transferred in 2.333018 secs (4389164 bytes/sec)
>
> On the AP box:
> $ nc -kl 1234 < /dev/urandom
> $ nc -kl 1234 > /dev/null
Thanks for sharing this.
Re: "athn0: could not load firmware" for AR9271
On Sat, May 27, 2017 at 10:51:08AM -0400, Maximilian Pichler wrote: > On Sat, May 27, 2017 at 4:05 AM, Stefan Sperling wrote: > > What is the model of your USB host controller? (please always send a > > complete dmesg in problem reports -- you cannot guess exactly what people > > will want to know about your machine, so by sending a complete dmesg > > you'll save people a round-trip to get more information they need) > > It appears to be an ATI SB700, on the PC Engines APU board > (https://www.pcengines.ch/apu.htm). Full dmesg below. The ATI SB700 is known to suffer from this issue. > By the way, if you had any advice on which WiFi adapter (mini PCIe or > USB) gives best performance as a Host AP right now, I'd be most > grateful. Get a 9280 miniPCIe. Pcengines sells them as "wle200nx". A list of similar products can be found on wikidevi: https://wikidevi.com/wiki/Atheros -> Search for the entry called "AR9280 (Merlin)" and follow the "19 devices" link.
Re: "athn0: could not load firmware" for AR9271
On Fri, May 26, 2017 at 08:39:14PM -0400, Maximilian Pichler wrote: > I'm trying to use an Olimex MOD-WIFI-AR9271-ANT USB wireless adapter, but: > # dmesg > OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > [...] > athn0 at uhub0 port 5 configuration 1 interface 0 "ATHEROS UB93" rev > 2.00/1.08 addr 2 > athn0: could not load firmware What is the model of your USB host controller? (please always send a complete dmesg in problem reports -- you cannot guess exactly what people will want to know about your machine, so by sending a complete dmesg you'll save people a round-trip to get more information they need) > According to the manufacturer > (https://www.olimex.com/Products/USB-Modules/MOD-WIFI-AR9271-ANT/) > this is an AR9271 chip, which is listed on the athn man page. What am > I missing? There's a problem where this chip does not get enough juice from the USB host controller in some cases. The firmware failing to load is a symptom of this. The cause has not been pinned down. It could probably be fixed in software, somewhere in the USB stack. On one of my laptops, firmware fails to load when I plug a USB athn into a hub, but the device works fine when inserted directly into a port on the machine. But it works with a hub on other laptops so I stopped investigating...
Re: OpenBSD 6.1 on Lenovo P50
On Mon, May 22, 2017 at 07:29:53PM +0200, L. Jankok wrote: > Anybody running OpenBSD on a Lenovo P50 laptop? > I am looking for tips and experiences. I don't have one but I looked up the specs online. I would not recommend this machine for OpenBSD because it has an Nvidia GPU. If you can live with sloppy 2D graphics because all you're doing is typing into an xterm, then it might be tolerable. The Intel 8260 wifi card is supported so you'd have network. Intel and Radeon GPUs are more likely to be supported already (to some degree at least) and in the future. I would prefer models with such GPUs instead.
Re: Installing openbsd on MacBook air 2014
On Tue, May 16, 2017 at 12:22:18PM +, flipchan wrote: > Here is the output: > > > first boot didnt work so i searched around and found this blog post > http://www.sacrideo.us/openbsd-on-macbook/ and i tried typing in the mkdir > commands i it booted > > >>OpenBSD/i386 BOOT 3.31 > boot> > boot>mkdir cd-dir > boot>cd cd-dir > boot>mkdir -p 4.2/i386 > boot>mkdir -p etc > boot>cp ~/cdboot ~/cdbr ~/bsd.rd 4.2/i386 > boot>config -ef 4.2/i386/bsd.rd These aren't commands for the boot loader. This guide recommends that you create a custom ISO image. It's very outdated. I would not rely on it. > Welcome to the OpenBSD/i386 6.1 installation program: Please try amd64 instead of i386.
Re: Installing openbsd on MacBook air 2014
On Tue, May 16, 2017 at 08:43:39AM +, flipchan wrote: > Hi the install61.fs boots up but it gets frozen giveing errors > > Link to pic : > https://www.file-upload.net/download-12501308/2017-05-1610.41.54.jpg.html Sorry, I tried a few times, enabled some java script in firefox along the way, and then gave up. I cannot see your image. > Maybe I'm missing something Please do not send image attachements, or links like this. If you want help, please describe your problem in plain text. If necessary type off your screen. Yes it feels very silly to do that, but it saves everyone else a bit of time.
Re: Installing openbsd on MacBook air 2014
On Tue, May 16, 2017 at 07:49:51AM +, flipchan wrote: > Hi I am trying to install openbsd on my MacBook air 2014. I have tried > burning the 6.1 intel install61.iso to a USB and tried to boot from that but > I have got zero success (burned it with dd like a normal os install). Does > anyone know how to install openbsd on a MacBook air? The MacBook air don't > detect the USB as a bootable device. > > > Take care and have a good day The first comment here indicates you may need to hold down the Option key while booting: https://www.geeklan.co.uk/?p=1283o And this also supports the idea: https://support.apple.com/en-us/HT201255 Good luck!
Re: How to syspatch from a different server?
On Mon, May 15, 2017 at 09:05:38AM +0200, Federico Giannici wrote: > We use an internal server to speedup the upgrade of OS and packages of all > our internal machines (all amd64). We simply set /etc/installurl in every > machine to point to our server were there are the OS tarballs and packages. > > Anyway we'd like to use the standard OpenBSD servers for syspatch as it uses > much less files than complete installation and it's often updated. > > How can we do it? Mirroring the 'pub/OpenBSD/syspatch/' directory on your local mirror should make it work.
Re: iwm0: could not initiate scan
On Sun, May 14, 2017 at 06:06:47PM +0300, G wrote: > sorry for the last email. i wanted to write ifconfig iwm0 chan 5. > Still i dont know what you mean by change to 5GHz channel. 2GHz channels are numbered 1 to 14. 5GHz channels are numbered 36, 40, 48, 50, 52, etc. See https://en.wikipedia.org/wiki/WLAN_channels 5GHz channels are usually a lot less crowded than 2GHz so performance is much better. Of course, your AP needs to support it, too.
Re: iwm0: could not initiate scan
On Sun, May 14, 2017 at 03:47:59PM +0200, Jan Stary wrote: > Would you please recommend a card that has one of the radio chips > that support 5G, fits into the ALIX, and is known to work well? In my experience AR9280 chips work well. Cards with this chip exist in MiniPCI format as well as PCIe. I am using a 9280 MiniPCI card in my ALIX which shows up as: athn0 at pci0 dev 14 function 0 "Atheros AR9280" rev 0x01: irq 11 athn0: AR9280 rev 2 (2T2R), ROM rev 16, address xx:xx:xx:xx:xx:xx 0:14:0: Atheros AR9280 0x: Vendor ID: 168c Product ID: 0029 I forgot where I got it from. A good site to search is https://wikidevi.com/wiki/Atheros It looks like you want one of the 22 adapters linked at 'AR9220' which is noted to be a "AR9280 w/ PCI IF". Note that you'll need 2 antennas to use 11n mode. My ALIX case does not have a second hole drilled yet so I'm running it in 11a mode for now.
Re: iwm0: could not initiate scan
On Sun, May 14, 2017 at 03:24:34PM +0200, Jan Stary wrote: > > But please show me your hostname.iwm0 file. > dhcp So you're not setting a network name (and perhaps a WPA password) before bringing the interface up. Does the message go away if you do that? > > It's possible that you're running a specific sequence of commands which > > triggers this. If I knew what those are I could try to reproduce it. > > I move between different SSIDs and never got around to automatize it > (btw, what do people use for that?), so I do it manually, like this: > > $ doas ifconfig iwm0 up nwid stare.cz wpakey XXXPASSWORDXXX -nwkey No need for 'up' in this line. 'up' triggers a scan because the interface will try to find an AP when it goes UP. The following commands on this line then set additional parameters and because of that the device must be reset. So with this single line you bounce the device up and down several times. It works, but it may cause a scan to be aborted midway and then you'll see the 'could not initiate scan' message. It is really just a cosmetic problem. You're pushing the configuration through various states before things eventually settle down. I am not blaming you -- this is a problem with how the ifconfig->kernel interfaces and scanning logic were designed. There is no way for the driver to tell whether ifconfig is looking for a list of APs or a specific AP to connect to, for example. The commands 'ifconfig scan' and 'ifconfig up' are the same from the driver's perspective. Changing this would be a lot of work so we'd need another wifi developer to do that. Any volunteers? > $ doas sh /etc/netstart iwm0 You could just run 'dhclient iwm0' here. > > > Running against a current/i364 AP > > > seems to work fine with 11g (less so with 11n). > > > > It's an athn(4) AP? > > Yes. It's an ALIX (dmesg below) with > > athn0 at pci0 dev 12 function 0 "Atheros AR5416" rev 0x01: irq 9 > athn0: MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 2, address > 00:1d:6a:6b:03:07 > I was having problems using 11n (with various clients) and > was advised here to use 11g for now, which indeed seems more reliable. You have a device with unequal numbers of Tx and Rx streams. There was a bug in 6.1 which affects those. I believe a commit I made on the 23rd of April has fixed 11n mode for your athn device but you're still running a snap from April 9. So please upgrade and try again! > OpenBSD 6.1-current (GENERIC) #304: Sun Apr 9 20:21:01 MDT 2017 > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Re: iwm0: could not initiate scan
On Sun, May 14, 2017 at 04:00:02PM +0300, G wrote: > I noticed that wifi after a while becomes really slow and i have to restart > sh /etc/netstart > in order for the speed to improve. Try a 5 GHz channel. Works great here.
Re: iwm0: could not initiate scan
On Sun, May 14, 2017 at 12:16:55PM +0200, Jan Stary wrote: > This is current/amdd64 on a Dell Latitude E5570 (dmesg below). > The "device timeouts" of iwm have mostly disappeared, Great! > but the boot sequence ends with > > iwm0: hw rev 0x200, fw ver 16.242414.0, address e4:a4:71:40:21:08 > iwm0: could not initiate scan > > This particular message is not in iwm(4) DIAGNOSTICS. > Is it anything to worry about? This is nothing to worry about if it works eventually. But please show me your hostname.iwm0 file. It's possible that you're running a specific sequence of commands which triggers this. If I knew what those are I could try to reproduce it. > Running against a current/i364 AP > seems to work fine with 11g (less so with 11n). It's an athn(4) AP?
Re: OpenBSD 6.1/i386 iwi0 problems
On Fri, May 12, 2017 at 09:36:33PM +0200, Infoomatic wrote: > hi, > I upgraded my old notebook to 6.1. However, I am experiencing hickups with > wifi (no problems with 6.0) > some lines in dmesg: > > iwi0 at pci1 dev 13 function 0 "Intel PRO/Wireless 2200BG" rev 0x05: irq 11, > address 00: > . > iwi0: fatal firmware error > iwi0: timeout waiting for master > iwi0: fatal firmware error > iwi0: timeout waiting for master > iwi0: fatal firmware error > iwi0: fatal firmware error > iwi0: fatal firmware error > iwi0: timeout waiting for master > iwi0: unknown authentication state 1 > > Any advice? > iwi(4) was entirely broken since the WPA security patch for 6.0. I made it work again for 6.1 but also saw these firmware errors occasionally. But I thought these errors were already present in 6.0 and before. It looks like that's not the case, and there is even more left to fix...
Re: iwm0 slow wireless - AC 7265 on ThinkPad X250
On Fri, May 12, 2017 at 11:14:35AM +0100, Caolan McMahon wrote: > >> Please test -current. > >> > >> Or you could try the following diffs on a 6.1 source tree but I have > >> not tested that and don't want to support it, so you are on your own. > >> https://marc.info/?l=openbsd-tech&m=149399149502787&q=raw > >> https://marc.info/?l=openbsd-tech&m=149399299003411&q=raw > > Thanks Stefan, just knowing there are relevant commits in -current is good. > > > > Come to think of it, an easy workaround might be to disable 11n mode: > > > > ifconfig iwm0 mode 11g > > > > That should make it work in 6.1. > > 11g has better range than 11n in 6.1 (the first patch above addresses this). > > You are probably far away from the AP, right? > > I'm reasonably far away from the AP now, but I've also tested sitting > right next to the AP and I hit the same speed issue. > I'm also running in 11g mode at the moment in the hope that it would > help - I have subjectively noticed fewer stalls but networking > continues to be slow. For now, I won't be able to help you beyond what I have already suggested. I am quite sure that the driver itself is generally fine, though it may have problems in specific cases. Please try other environments and access points with the same laptop and I hope you'll find that it can perform well. It can be slow for any number of reasons and it's hard to debug remotely. Any bugs left in the driver at this stage are quite subtle and will require details to figure out (that means I would need lot more than "it is slow", such as captured frame exchanges which demonstrate a particular problem). Perhaps it will become better in future releases if more parts of the 802.11n spec get implemented since our current implementation is still incomplete. When you test the Linux driver you're testing a much more complete 802.11n implementation so one can't really draw a direct comparison.
Re: iwm0 slow wireless - AC 7265 on ThinkPad X250
On Fri, May 12, 2017 at 11:58:30AM +0200, Stefan Sperling wrote: > On Fri, May 12, 2017 at 10:30:27AM +0100, Caolan McMahon wrote: > > I'm seeing very slow wireless networking speeds on OpenBSD 6.1 using > > the iwm driver. > > > > $ dmesg | grep iwm0 > > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, > > msi > > iwm0: hw rev 0x210, fw ver 16.242414.0, address 60:57:18:91:f1:86 > > > > I struggle to get more than ~30-40kb/s download speed. Running Linux > > on the same machine and network I could easily get 1mb/s or more. I've > > also noticed the network will appear to hang for seconds at a time, > > without pages loading in the browser. > > > > I found some posts on this list from November 2016 which seem to > > describe a similar problem with the driver in OpenBSD 6.0, but > > according to that the fixes should be available in OpenBSD 6.1. > > > > Wired networking works fine. > > > > Is there anything I can try on OpenBSD 6.1 before having to re-test on > > -current? > > > > Thanks, > > > > Caolan > > > > Please test -current. > > Or you could try the following diffs on a 6.1 source tree but I have > not tested that and don't want to support it, so you are on your own. > https://marc.info/?l=openbsd-tech&m=149399149502787&q=raw > https://marc.info/?l=openbsd-tech&m=149399299003411&q=raw Come to think of it, an easy workaround might be to disable 11n mode: ifconfig iwm0 mode 11g That should make it work in 6.1. 11g has better range than 11n in 6.1 (the first patch above addresses this). You are probably far away from the AP, right?
Re: iwm0 slow wireless - AC 7265 on ThinkPad X250
On Fri, May 12, 2017 at 10:30:27AM +0100, Caolan McMahon wrote: > I'm seeing very slow wireless networking speeds on OpenBSD 6.1 using > the iwm driver. > > $ dmesg | grep iwm0 > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi > iwm0: hw rev 0x210, fw ver 16.242414.0, address 60:57:18:91:f1:86 > > I struggle to get more than ~30-40kb/s download speed. Running Linux > on the same machine and network I could easily get 1mb/s or more. I've > also noticed the network will appear to hang for seconds at a time, > without pages loading in the browser. > > I found some posts on this list from November 2016 which seem to > describe a similar problem with the driver in OpenBSD 6.0, but > according to that the fixes should be available in OpenBSD 6.1. > > Wired networking works fine. > > Is there anything I can try on OpenBSD 6.1 before having to re-test on > -current? > > Thanks, > > Caolan > Please test -current. Or you could try the following diffs on a 6.1 source tree but I have not tested that and don't want to support it, so you are on your own. https://marc.info/?l=openbsd-tech&m=149399149502787&q=raw https://marc.info/?l=openbsd-tech&m=149399299003411&q=raw
Re: OpenBSD 6.1: BOOTIA32 3.32 issue
On Tue, May 09, 2017 at 09:47:14PM +0200, Michele Curti wrote:
> On Tue, May 09, 2017 at 09:36:02PM +0200, Michele Curti wrote:
> > On Tue, May 09, 2017 at 10:20:03AM +0200, Michele Curti wrote:
> > > Hi all, I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay
> > > trail, 32 bit efi, 64 bit os) but the bootloader do not correctly
> > > detect the internal disk.
> > >
> > > I also tried a fresh install, but things do not change. Boot fails
> > > and when I do a "machine diskinfo" I got a lot of "?" symbols (a video
> > > here https://www.youtube.com/watch?v=fsomNX-oFTQ )
> > >
> > > How can I debug the issue?
> > >
> >
> > Compiling bootia32.efi :p
> >
> > With sys/arch/amd64/stand/efiboot/efiboot.c revision 1.15 it works,
> > revision 1.16 it fails.
> >
> > I'll try to understand, thanks, Michele
>
>
> With the following diff it works, bye!
Looks good to me. Is anyone handling this patch?
> Index: efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 efiboot.c
> --- efiboot/efiboot.c 3 Mar 2017 08:56:18 - 1.17
> +++ efiboot/efiboot.c 9 May 2017 19:44:30 -
> @@ -92,7 +92,7 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
> if (DevicePathType(dp) == MEDIA_DEVICE_PATH &&
> DevicePathSubType(dp) == MEDIA_HARDDRIVE_DP) {
> bios_bootdev = 0x80;
> - efi_bootdp = dp0;
> + efi_bootdp = dp;
> break;
> }
> }
>
Re: ThinkPad x250 with USB DAC (Audioquest DragonFly v1.2)
On Tue, May 09, 2017 at 11:22:17AM +0100, Caolan McMahon wrote: > Thanks Stefan. Do you know if anyone is working on this? I am not aware of anyone working on this at present. I hope it will happen some day. I would also benefit from this since one of my laptops has its internal audio device wired up on USB at xhci.
Re: ThinkPad x250 with USB DAC (Audioquest DragonFly v1.2)
On Tue, May 09, 2017 at 11:00:26AM +0100, Caolan McMahon wrote: > uaudio_chan_open: error creating pipe: err=INVAL endpt=0x01 The problem is that xhci(4) does not yet support isochronous transfers which are needed for USB audio devices to work. http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous AFAIK this also affects other devices such as cameras. USB disks work because they use bulk transfers.
Re: iwm0 problems
On Tue, May 02, 2017 at 10:13:01AM +0200, Stefan Sperling wrote:
> Thank you all for the additional reports! So there is indeed a regression
> in 6.1 which is causing this problem.
>
> I will try to find a 3165 device to play with.
Thanks to benno@ I got my hands on a machine with a 3165 device.
There is indeed a bug which I introduced while adding MIMO support.
This patch fixes the problem:
Index: if_iwmreg.h
===
RCS file: /cvs/src/sys/dev/pci/if_iwmreg.h,v
retrieving revision 1.26
diff -u -p -r1.26 if_iwmreg.h
--- if_iwmreg.h 24 Apr 2017 09:31:31 - 1.26
+++ if_iwmreg.h 3 May 2017 14:12:55 -
@@ -3873,8 +3873,8 @@ enum {
IWM_RATE_MCS_4_INDEX = IWM_RATE_36M_INDEX,
IWM_RATE_MCS_10_INDEX,
IWM_RATE_48M_INDEX,
- IWM_RATE_MCS_11_INDEX,
IWM_RATE_MCS_5_INDEX = IWM_RATE_48M_INDEX,
+ IWM_RATE_MCS_11_INDEX,
IWM_RATE_54M_INDEX,
IWM_RATE_MCS_6_INDEX = IWM_RATE_54M_INDEX,
IWM_LAST_NON_HT_RATE = IWM_RATE_54M_INDEX,
Re: OpenBSD/octeon on EdgeRouter PoE - my experience
On Tue, May 02, 2017 at 12:57:23AM +0200, Doggie wrote: > W dniu 2017-05-02 o 00:01, etie...@magickarpet.org pisze: > > I also own one of these nice devices, and replaced the usb thumbdrive > > that was present for my own, to keep the original filesystem intact, > > just in case. But I had to try a few USB drives, and I suspect the only > > ones that could be booted on were USB2, and not USB3. That said, I > > haven't verified this thoroughly. > > > > Cheers, > > I based my USB flashdrive research on this thread: > > https://community.ubnt.com/t5/EdgeMAX/List-of-Compatible-USB-drives/td-p/1185011# > (especially post #5) > > and eventually chose Transcend JetFlash 710 32GB USB 3.1 Gen 1 - works like > a charm in my EdgeRouter PoE. On the ERL, try typing 'usb reset' to the boot loader if it does not detect a USB stick. That made any USB stick work for me and also improved system stability in general. 'usb reset' can also be put into the bootcmd variable. The INSTALL.octeon file mentions this now (in 6.1). See there for details.
Re: iwm0 problems
On Sun, Apr 30, 2017 at 06:08:18PM -0400, Steve Throckmorton wrote: > > I also have this issue with AC 3160. What i did as a workaround was to > > switch iwm to 802.11g using > > ifconfig iwm0 media autoselect mode 11g > > Excellent! That got my wireless interface working without error messages. > As far as I haven’t had a single firmware error in two hours. I haven’t > tested the download speed because I don’t have anything to compare it to, but > it’s more than sufficient for my purposes. > > Thank you. Thank you all for the additional reports! So there is indeed a regression in 6.1 which is causing this problem. I will try to find a 3165 device to play with.
Re: iwm0 problems
On Fri, Apr 28, 2017 at 06:56:08PM +0300, G wrote: > I should add that video on 6.1 works fine when im connected to ethernet > So i guess the problem is with the iwm driver It could be a driver bug but based on the information I have so far there is nothing I can do but wait and see if somebody else reports the same problem with an 3165 device. I have no such device to check myself. Wifi is complicated. I am getting about 1 or 2 problem reports like yours per week. Most of them turn out to not be driver bugs but general problems with people's wifi setups. The most recent one was that Lenovo had mistakenly wired up one of the WAN antennas for 3g devices to the WLAN device in an x230 laptop they sold, and that caused a bad signal and poor performance (I did not figure that out, but gladly the person who reported the problem eventually found out). Based on such experiences I have become careful about jumping to conclusions about what must be a wifi driver bug. I certainly will not spend time debugging a driver unless I get some very solid clues that point towards a driver bug. As far as I can tell from your report, your machine needs a BIOS update or has broken ACPI or has some other hardware issue. Who knows.
Re: iwm0 problems
On Fri, Apr 28, 2017 at 03:56:04PM +0300, G wrote: > Hello. > When i connect my laptop using wifi (iwm0) my browser freeze for a > couple of seconds from time to time. > Also when i start play videos the video freeze after a couple of seconds. > > My dmesg gives me > > device timeout > iwm0: fatal firmware error > iwm0: device timeout > iwm0: device timeout > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x99, msi Support for AC 3165 chips was already present in 6.0. Does the same problem happen in OpenBSD 6.0? Given that video also has issues there may be an underlying problem that prevents the iwm driver from working properly. As far as I know 3165 chips are working in general. I do not have such a chip test with, though.
