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.
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 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: 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 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: 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: 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: 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: 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: 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 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: 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: 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: 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 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 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 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: 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: 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: 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 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: 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: "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: "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 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: 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: 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: 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: 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: "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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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'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: 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: 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: 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: 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: "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: 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: 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: 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: 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 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 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: 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: 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: Atheros ATH9485 in athn
On Sat, Apr 28, 2018 at 09:11:38PM -0500, Z Ero wrote: > Can any one give an idea as to the work required to get support for > the ATH9485, found in the the AR5B225 and AR5B125 cards? I have a > bunch of 225s and 125s that I would like to use with Openbsd but I see > this chipset is not currently supported by the athn driver. I guess > FreeBSD and Linux support it. > Somebody would need to tweak the code in sys/dev/ic/ar9003.c until your device works.
Re: 6.3 - dhclient not working on wireless
On Sat, May 05, 2018 at 11:03:52PM +0200, Riccardo Mottola wrote: > Hi, > > I upgraded to 6.3 and I cannot connect to a certain WiFi network anymore, > or, better, ifconfig says it is connected and the LED says it is too, but > then dhclient fails to get a lease from it. > I can connect to the same network through wired ethernet and dhclient > correctly gets an address from the same router. > > What is going wrong? can I enable some further information? > > Here you can see ifconfig "active": > wpi0: flags=8843 mtu 1500 > lladdr 00:13:02:9a:52:1b > index 2 priority 4 llprio 3 > groups: wlan > media: IEEE802.11 autoselect (DS1 mode 11g) > status: active > ieee80211: nwid westernesse chan 10 bssid f8:d1:11:b9:07:2a -16dBm > nwkey The keyword 'nwkey' indicates you are using WEP. Is that correct? A commit of mine accidentally broke WEP support back in August 2017. This was eventually fixed in -current 2 weeks ago. Nobody noticed that WEP was broken for 8 months... I'd suggest switching this wifi network to WPA2, or just leaving it open since WEP is no better than leaving your wifi open in the first place. We provide WEP only for interop with legacy networks outside your control.
WEP broken (was: Re: 6.3 - dhclient not working on wireless)
On Fri, May 11, 2018 at 04:56:19PM +0200, Riccardo Mottola wrote:
> Is a backport possible to "stable"?
I don't think it is worth the effort for us.
You are literally the only person I know of who has requested an
official backport of this fix. WEP was already broken in OpenBSD 6.2
which was released in October 2017. In all this time, nobody complained.
So it does not look like this problem affects many people.
The patch to fix WEP is trivial and should apply cleanly to
a 6.3 source tree if needed:
Index: ieee80211_proto.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_proto.c,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -p -r1.83 -r1.84
--- ieee80211_proto.c 6 Feb 2018 22:14:52 - 1.83
+++ ieee80211_proto.c 27 Apr 2018 15:33:49 - 1.84
@@ -1,4 +1,4 @@
-/* $OpenBSD: ieee80211_proto.c,v 1.83 2018/02/06 22:14:52 phessler Exp $
*/
+/* $OpenBSD: ieee80211_proto.c,v 1.84 2018/04/27 15:33:49 stsp Exp $
*/
/* $NetBSD: ieee80211_proto.c,v 1.8 2004/04/30 23:58:20 dyoung Exp $
*/
/*-
@@ -948,7 +948,8 @@ justcleanup:
break;
}
ni->ni_rsn_supp_state = RSNA_SUPP_INITIALIZE;
- ieee80211_crypto_clear_groupkeys(ic);
+ if (ic->ic_flags & IEEE80211_F_RSNON)
+ ieee80211_crypto_clear_groupkeys(ic);
break;
case IEEE80211_S_SCAN:
ic->ic_flags &= ~IEEE80211_F_SIBSS;
@@ -960,7 +961,8 @@ justcleanup:
ni->ni_associd = 0;
ni->ni_rstamp = 0;
ni->ni_rsn_supp_state = RSNA_SUPP_INITIALIZE;
- ieee80211_crypto_clear_groupkeys(ic);
+ if (ic->ic_flags & IEEE80211_F_RSNON)
+ ieee80211_crypto_clear_groupkeys(ic);
switch (ostate) {
case IEEE80211_S_INIT:
#ifndef IEEE80211_STA_ONLY
@@ -1006,7 +1008,8 @@ justcleanup:
break;
case IEEE80211_S_AUTH:
ni->ni_rsn_supp_state = RSNA_SUPP_INITIALIZE;
- ieee80211_crypto_clear_groupkeys(ic);
+ if (ic->ic_flags & IEEE80211_F_RSNON)
+ ieee80211_crypto_clear_groupkeys(ic);
switch (ostate) {
case IEEE80211_S_INIT:
if (ifp->if_flags & IFF_DEBUG)
Re: MIMO in athn(4)
On Sat, May 12, 2018 at 10:53:29PM +1000, tomr wrote: > > I've been playing with an apu2 and an AR9280, which is supported by athn(4). > > It seems to perform terribly when I connect a second antenna. Is this > the expected behaviour currently? Is there some MIMO magic that isn't > yet implemented? Or do I just need to get the antenna spacing right? > > I see a foreboding "No Tx aggregation" in the commit message... > > Thanks, > t > You'll need to be more specific before anyone can help you. You're not showing us relevant configuration files, dmesg, etc. See https://www.openbsd.org/report.html Note that there is one known big problem: This driver lacks periodic calibration which is a likely reason for bad performance in some environments. Make sure to pick a channel where your network overlaps with relatively few other networks. That might help.
Re: MIMO in athn(4)
On Sun, May 13, 2018 at 01:32:59AM +1000, tomr wrote: > With one antenna connected, I get about 60-80% signal on my iwm client > at a distance of approximately 5m. With two antennas connected, the same > client needs to be <1m away from the AP to connect at all, and even then > gets about <20%.b Huh, that is certainly not expected. This driver generally works fine with two antennas. In fact, 2 antennas are required for 11n mode to work correctly (use 11a or 11g mode instead if only one antenna is attached). If such an issue was due to a bug in the driver it almost certainly would have been noticed elsewhere already. As a first step, check the health of your antennas and cables.
Re: MIMO in athn(4)
On Tue, May 15, 2018 at 10:20:17AM +1000, tomr wrote: > > > On 05/13/18 02:21, Stefan Sperling wrote: > > On Sun, May 13, 2018 at 01:32:59AM +1000, tomr wrote: > >> With one antenna connected, I get about 60-80% signal on my iwm client > >> at a distance of approximately 5m. With two antennas connected, the same > >> client needs to be <1m away from the AP to connect at all, and even then > >> gets about <20%.b > > > > Huh, that is certainly not expected. > > > > This driver generally works fine with two antennas. In fact, 2 antennas > > are required for 11n mode to work correctly (use 11a or 11g mode instead > > if only one antenna is attached). If such an issue was due to a bug in > > the driver it almost certainly would have been noticed elsewhere already. > > > > As a first step, check the health of your antennas and cables. > > > > Looks like it is/was indeed a cable/antenna issue. > > I had a spare ar9280 card. I connected that, being extra careful that > the pigtails were properly seated this time. That improved things > immediately (whether it was the card or the connection I haven't checked > in detail). With the dual-band antennas I've got, ~2.4GHz channels seem > to work much better. > > Thanks for the pointers, > > t > Thanks for following up! I'm glad the problem is resolved.
Re: 20% package loss on CARP after upgrade to 6.3
On Thu, Jun 21, 2018 at 10:07:06AM +0200, Janne Johansson wrote: > Den ons 20 juni 2018 kl 19:59 skrev Henrik Dige Semark : > > > Hey everybody, > > > > # Server 1 > > My /etc/hostname.* for CARP's and pfsync + host adaptor: > > https://pastebin.com/vrtuPqnQ > > My /etc/pf.conf: https://pastebin.com/yhVkG4x4 > > > > # Server 2 > > My /etc/hostname.* for CARP's and pfsync + host adaptor: > > https://pastebin.com/a7fuM923 > > My /etc/pf.conf: https://pastebin.com/xNr1TtZ7 > > > > Any help or pointers would be fantastic. > > I have struggled with this for a week now and I'm running out of idears - > > the only solution I have right now is turning off the backup server. > > > > You should have different advskew on expected master and slave carps, no? Looks to me like that is already the case (Server 1 is has advskew 0, Server 2 has advskew 100). > Also, we used to have something like 20 for master and 80 on slave so one > can place slaves before master, or master after slave if you want to signal > "I am still running but would like to hand over to the other if we can". The carp demote counter is also relevant to failover and is sometimes raised at run-time when interface output errors occur. The advskew value only matters as long as the demote counter is equal on both sides. See 'ifconfig -g carp' and the 'carpdemote' directives documented in the INTERFACE GROUPS section of the ifconfig man page. To avoid potential routing issues, I would recommend setting netmasks to /32 on all carp interfaces if they share a subnet with an Ethernet interface. I have no idea about a possible specific reason for packet loss, though.
Re: How to build with VMM_DEBUG
On Fri, Jun 22, 2018 at 11:41:22PM -0500, Ax0n wrote: > I'm trying to hunt down a recent breakage with my VMM virtual machines > refusing to start, and I'm getting errors like this: > > vcpu_run_loop: vm 5 / vcpu 0 run ioctl failed: Invalid argument See https://marc.info/?l=openbsd-bugs&m=152960299009667&w=2 for a patch you could test. (raw patch: https://marc.info/?l=openbsd-bugs&m=152960299009667&q=raw)
Re: Weird routing problem on simple CARP setup
On Wed, Jun 27, 2018 at 09:30:16AM +, BARDOU Pierre wrote: > Hello, > > I have a strange problem with OpenBSD 6.2, which looks like a bug. > Steps to reproduce : > > * sh /etc/netstart -> everything works. Routing table : > root@fw-t-wan-chut01:~ # netstat -rnf inet > > > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > default10.194.119.254 UGS0 16 - 8 bge0 > 224/4 127.0.0.1 URS0 798 32768 8 lo0 > 10.194.116/22 10.194.116.29 UCn11 - 4 bge0 > 10.194.116/22 10.194.116.28 UCn00 -19 carp0 > 10.194.116.28 00:00:5e:00:01:0f UHLl 03 - 1 carp0 > 10.194.116.29 40:a8:f0:36:22:0c UHLl 0 28 - 1 bge0 > 10.194.119.254 00:1b:2a:e9:c4:00 UHLch 25 - 3 bge0 > 10.194.119.255 10.194.116.29 UHb00 - 1 bge0 > 10.194.119.255 10.194.116.28 UHb00 - 1 carp0 > 127/8 127.0.0.1 UGRS 00 32768 8 lo0 > 127.0.0.1 127.0.0.1 UHhl 1 1122 32768 1 lo0 > 192.168.190/24 192.168.190.1 Cn 00 - 4 bge1 > 192.168.190.1 40:a8:f0:36:22:0d UHLl 00 - 1 bge1 > 192.168.190.255192.168.190.1 Hb 00 - 1 bge1 > root@fw-t-wan-chut01:~ # ifconfig carp0 > > > carp0: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:0f > description: TL-INT-ADM-WAN > index 10 priority 15 llprio 3 > carp: MASTER carpdev bge0 vhid 15 advbase 1 advskew 10 > groups: carp > status: master > inet 10.194.116.28 netmask 0xfc00 broadcast 10.194.119.255 > > * then sh /etc/netstart carp0 -> routed traffic stops working (ping > 10.194.125.120 says "sendmsg: Invalid argument"). > Same result if I do ifconfig carp0 10.194.116.28/22. Have you tried using a /32 mask on carp0 instead of /22? That might work around the problem. I believe this problem is fixed in 6.3. Can you confirm?
Re: DWA-131 Rev E
On Sat, Jul 07, 2018 at 03:25:17PM +1000, Jonathan Matthew wrote: > On Fri, Jul 06, 2018 at 07:19:42AM +, Stuart Henderson wrote: > > On 2018-07-06, Christopher Turkel wrote: > > > Thanks! > > > > > > Are there any plans to support this adapter? I'll donate my adapter if it > > > would help. > > > > I don't know if anyone already plans on doing this. If there is, there's > > support in FreeBSD which might help with the task.. > > I did some work on this a while ago. It's pretty dispiriting but I'll > probably > get back to it soon. The one thing it has going for it is that the hardware > is cheap and readily available. Have you talked to kevlo@? He wrote the FreeBSD driver support and might have something in progress for OpenBSD.
Re: strange observations during my auto-join tests
On Sat, Jul 21, 2018 at 07:49:48PM +0200, vincent delft wrote: > Hello Peter, all, > > I've just tested auto-join since 13 of july. > First of all. THANKS !!! It works great. > > This email is just because I've observed 2 strange situations. > I don't know if this is linked to auto-join or if this caused by errors on > my setup. > > > 1) > egress group is not following the connected interface. > To reproduce it, just establish a connection via a cable. ifconfig will > show you that egress group is on that connection. > Pull-off the ehternet cable and run "doas sh /etc/netstart". > The system will switch perfectly to the wifi connection described in the > hostname.if file. > But, if I do a ifconfig, I still see the egress group on the cable > interface. > This was not my expectation. I thought that the egress group will switch > too to the new running interface. > > 2) > Time to times, the connection is correctly established on the correct > interface (for example from cable to wifi), but arp shows that the arp > table for few machines remains on the wrong interface. > I have to run "doas arp -ad" several times to remove this bad entry in the > arp table. > Is there a better way to avoid such situation ? Wifi has nothing to do with where the default route points to. The wifi stack only handles the link layer, ie. it works on a per-interface basis and only cares about wifi interfaces going up and down. Your questions concern routing decisions at the IP layer, which sits above the wifi layer and is managed by tools such as ifconfig and dhclient. In order to switch between different IP networks you need to kill dhclient on the wired interface and delete addresses and perhaps flush routes. Perhaps a trunk(4) in failover mode with a wired and wifi interface will do what you want. See the EXAMPLES section in the trunk(4) man page.
Re: Is BCM4360 802.11ac (on MacBook Air 6.1) supported?
On Thu, Jul 26, 2018 at 09:33:43PM +0200, MiKi wrote: > Hi, > > I installed OpenBSD 6.3 in a MacBook Air 6.1 everything works fine but > except the wireless card. > > It have a Broadcom BCM4360 802.11ac (rev3) card, the device is showed on > dmesg but left undetected as a device in ifconfig, I take a look on bwi(4) > and this exact model wasn't listed. > > I also checked the new driver bwfm(4) that seems a newer driver for Broadcom > AC cards, but it haven't any listing. > > Also I have nothing pending to install with fw_update > > So, is this card definitely unsupported? if not, can someone give me some > pointers to get it work? This card might be supported by bwfm(4) in -current.
regarding the hashcat WPA2 PMKID crack
The attack described at https://hashcat.net/forum/thread-7717.html performs a brute-force hash cracking attack on data voluntarily sent by access points which support 802.1x authentication with a pre-shared passphrase and have a feature known as "fast roaming" enabled. At present, OpenBSD-based access points support neither 802.1x authentication nor fast roaming. (There is some 802.1x code in the kernel, but it is only used in client mode and only in conjunction with the wpa_supplicant program from ports.) Lack of 802.1x support means the WPA key configured with ifconfig acts as the pairwise master key (PMK). It has always been possible to capture a 4-way handshake and attempt to crack the passphrase which hashed data exposed during the 4-way handshake is based on. This is referred to as one of the "existing attacks" in the hashcat forum post and this attack vector is even mentioned in the spec (802.11 2012, section 4.10.3.4 "Alternate operations with PSK"): """ This operation has security vulnerabilities when used with a low-entropy key and is recommended to be used only after taking that into account. """ So the bottom line is: - Never rely on WPA passphrases for end-to-end security regardless of how "strong" your passphrase seems to be. WPA passphrases may be used for access control (i.e. authorization) but they provide neither authenticity nor privacy. - If you care, configure a "strong" WPA passphrase on your access point. The maximum length is 63 characters. A command such as pwgen -s 63 will suggest a WPA passphrase which is hard to crack (pwgen is in ports).
Re: join id cannot be integer
On Wed, Aug 08, 2018 at 08:25:46AM -0700, Bryan Vyhmeister wrote: > I have not investigated the full scenario here but using the new join > option for wireless network configuration does not seem to work if I use > an ID of 0, 1, or 2 and probably others. Is this expected? The man page > seems to indicate that this should work fine. From ifconfig(8): > > "The id can either be any text string up to 32 characters in length, or > a series of hexadecimal digits up to 64 digits. Any necessary wpakey or > nwkey arguments should be specified on the same line." > > Here is the scenario to test. > > /etc/hostname.iwm0: > join 0 nwid TEST wpakey 1234567890 > dhcp > > This will not work and I will end up associated to the AP but status > will always stay as no network. > > /etc/hostname.iwm0: > join TEST nwid TEST wpakey 1234567890 > dhcp > > This will work as expected. > > Bryan > join and nwid are mutually exclusive commands. What you want in hostname.if is either: join TEST wpakey 1234567890 or the plain old: nwid TEST wpakey 1234567890 The man page talks about ESSIDs in hexstring format. This is useful only if the network name cannot be entirely represented in the ASCII character set since there's no support for character encodings other than ASCII.
Re: Qualcomm Atheros AR9485 Wireless Network Adapter
On Tue, Aug 21, 2018 at 10:29:59PM +0100, Michael Joy wrote: > Has anyone found a way to get this working on OpenBSD? Not working yet. There is some driver code related to this chip in athn(4) but it's incomplete and doesn't work.
github's generated archives are not stable (was: Re: wifi gui manager)
On Wed, Aug 22, 2018 at 08:49:57AM +0300, Consus wrote: > If you create a release > (https://help.github.com/articles/creating-releases/) then all > associated generated tarballs are immutable, as far as I know. Please stop spreading this myth. It is 100% wrong. These artifacts are not stable. If you rely on them being stable, stop doing so now. A friend of mine works at Github and when problems happened in OpenBSD's ports tree last year I asked what OpenBSD could do. Here is some of what he told us back then (I won't mention my friend's name, this was private mail). These are generated on the spot and cached so anything goes. You two are likely seeing different tarballs because you're being pointed to different frontend machines which happened to cache a different variation of the file. Back whenever (a few months ago by now, I think) we finally un-reverted a fix for git-archive for compat with OpenBSD that we had reverted years ago as people had started relying on the auto-generated tarball checksums. But at some point you have to bite the bullet, as a change in any of git, tar, zip, libz and maybe more can end up with the bytes changed for a tarball/zipfile that means the same. git has had multiple changes over the years related to non-ASCII filenames. It's basically a miracle that we didn't change the tarball checksums when we upgraded the whole fileserver fleet from Ubuntu to Debian one by one. "
Re: wifi gui manager
On Wed, Aug 22, 2018 at 10:50:46AM +0300, Consus wrote: > On 00:22 Wed 22 Aug, Anthony J. Bentley wrote: > > > If you create a release > > > (https://help.github.com/articles/creating-releases/) then all > > > associated generated tarballs are immutable, as far as I know. > > > > They're not immutable. > > The ones that you associate with with release? You sure? You have to create your own release archive and upload it. Github will host it for you. But *you* have to generate it, publish the checksum, and then never change the archive again. Github doesn't create an archive when you click the 'release' bwutton, they create or re-create an archive when someone clicks the 'download' button.
Re: wifi gui manager
On Wed, Aug 22, 2018 at 06:38:11PM -0700, Chris Bennett wrote: > Well, there are probably additional reasons too, but my father happily > runs OpenBSD. Of course, he needs to be able to turn the computer off. I would recommend using doas(1) to grant 'shutdown' to a particular user. You don't want to run a web browser from an account in the operator group. The operator group grants permissions far beyond turning the computer off. The group has read access to raw disk devices. Applications running as operator can bypass filesystem permissions by reading raw disk blocks. $ ls -l /dev/sd0a brw-r- 1 root operator - 4, 0 Apr 5 22:02 /dev/sd0a This means for instance that secrets stored in /etc are exposed. Password hashes, letsencrypt account keys and certs, smtp auth passwords, wifi passwords, VPN secrets, ... My understanding is that operator was introduced at a time when taking system backups required the computer to wait for tapes being swapped by a human. These operators didn't need root but were trusted with sensitive data.
Re: network connectivity problem (ifconfig, arp, ...)
On Mon, Sep 03, 2018 at 07:46:09PM +0200, vincent delft wrote: > Hello, > > I'm running -current and enjoy the new "join" feature of hostname.if. > > Nevertheless, I have sometime issues to have an internet connection. > > The context: > I have wifi and cable possibilities to connect the same network. Normaly I > prefer the network connection, so at my desk I plug the cable and use it. > But in some cases, I disconnect my laptop and use the wifi connection. > > Problem: > The wifi is well connected to my nwid, but the connectivity is not working > (cannot ping my main firewall to connect internet). > I think the problem is linked to wrong arp table (cfr here under) > > Why the arp entry for my firewall remains "expired" so long (could be more > than 10 minuntes) ? > Why a "doas arp -ad" does not remove this bad fw entry from the table ? > What could I do to solve the issue without rebooting the laptop ? (If I > reboot the laptop, this solve the problem). > > > > e5450:~$ arp -a > Host Ethernet AddressNetif Expire > Flags > fw (incomplete) em0 expired > 192.168.3.15 10:02:b5:83:40:41iwm0 permanent l > 192.168.3.16 f8:ca:b8:50:84:15 em0 permanent l Didn't we already discuss the same question back in July? https://marc.info/?l=openbsd-misc&m=153220020618146&w=2 Again, try trunk(4).
Re: network connectivity problem (ifconfig, arp, ...)
On Tue, Sep 04, 2018 at 09:35:38PM +0200, vincent delft wrote: > In fact, I remain with my initial question: > why arp having an entry with address "incomplete" on em0 does not perform > the task when iwm0 is triggered and request a connection to my firewall ? > The fw is running on the same address, just the path (netif) that change. Generally, having two interfaces in the same subnet is never a good idea unless you really know what you are doing. So when you switch from em0 to iwm0 and they both end up having addresses on the same IP network, then you should delete the IP address from the interface which you aren't using: ifconfig em0 delete IP addresses are managed by tools like ifconfig and dhclient, they are not managed automatically by drivers such as em and iwm. To change IP addresses you need to run commands; either manually or in some automated way. For instance, you could configure ifstated(8) to run ifconfig when the em0 interface goes down.
Re: WiFi: Join + wpa_supplicant
On Wed, Sep 05, 2018 at 01:39:53PM +0200, Stefan Wollny wrote: > After a 'sh /etc/netstart' 'ifconfig gives me the following: > > iwm0: flags=8943 mtu 1500 > lladdr 80:fa:5b:14:xx:yy > index 1 priority 4 llprio 3 > trunk: trunkdev trunk0 > groups: wlan > media: IEEE802.11 autoselect (HT-MCS0 mode 11n) > status: no network > ieee80211: join chan 36 bssid 84:b2:61:96:aa:bb 83% > wpaprotos wpa2 wpaakms 802.1x wpaciphers ccmp wpagroupcipher ccmp > ... > trunk0: flags=8843 mtu 1500 > lladdr 80:fa:5b:14:xx:yy > index 7 priority 0 llprio 3 > trunk: trunkproto failover > trunkport iwm0 > trunkport re0 master > groups: trunk > media: Ethernet autoselect > status: no carrier > > Only after I had commented the join-line for this network I was able to > reattach to my mobile phone's net. Let me guess: Your mobile phone is on a 2 GHz channel (1-13)? If that is true, then the AP on channel 36 (5 GHz) with good RSSI (83%) will always win because this is how join was taught to make decisions: * Given two APs, determine the "better" one of the two. * We compute a score based on the following attributes: * * crypto: wpa2 > wpa1 > wep > open * band: 5 GHz > 2 GHz provided 5 GHz rssi is above threshold * rssi: rssi1 > rssi2 as a numeric comparison with a slight * disadvantage for 2 GHz APs * * Crypto carries most weight, followed by band, followed by rssi. > Attaching to this particular net would be helpful - saves some time > avoiding workaraounds... You can use 'ifconfig iwm0 nwid phone' to override auto-join decisions and always attach to a network called 'phone'. To re-enable automatic network selection you can use: ifconfig iwm0 -nwid
Re: Debug / Driver / Kernel / WiFi
On Fri, Oct 05, 2018 at 04:53:40PM +0200, def...@posteo.de wrote: > > > Hi All, > > I try to make new driver for AR5424* WiFi Module (ath0) becouse of a lot > of issues on my Fujitsu Esprimo Mobile U9210 Laptop. (Just not working > out of the box) > > * https://cvsweb.openbsd.org/src/sys/dev/ic/ar5212.c > * https://cvsweb.openbsd.org/src/sys/dev/ic/ar5xxx.c > ... > Please fix the existing driver instead of adding a new one. A patch was submitted for this device some time ago but there was never any follow-up after the first round of review process: https://marc.info/?t=15170706164&r=1&w=2 You could use that patch as a starting point. But please note that it's unclear whether some or all of these changes were copied from GPL code. It would be better to base such changes on the FreeBSD driver which seems to support this device as well. > Could you be so kind to answer: > > 1. How can I try my new Driver without Build Kernel each time. No. You have to rebuild the kernel each time. > 2. What kind of tools can I use for Debuging WiFi ... (just examples) Many. Start working on it and ask again when you run into specific problems. > 3. Any info about OpenBSD Drivers ? Developers Guides (Just for OpenBSD) See https://www.openbsd.org/papers/eurobsdcon2017-device-drivers.pdf and other presentations mentioned therein.
Re: want.html: Unifi wifi gear for interop debugging
On Sat, Oct 06, 2018 at 09:52:18AM +, Tim Jones wrote: > ‐‐‐ Original Message ‐‐‐ > On Saturday, October 6, 2018 9:21 AM, Marcus MERIGHI > wrote: > > > Dear all, > > > > not everyone is reading want.html every day, therefore I wanted to hint > > at: https://www.openbsd.org/want.html > > > > stsp@wifi is asking for gear and we should deliver :-) > > > > "Ubiquity Unifi Ufo / Unifi AP Pro are needed for wifi driver debugging > > in Berlin, Germany. Contact s...@openbsd.org" > > > > I cannot find "Unifi Ufo", but "Unifi AP Pro" is not a cheapo Access > > Point, around EUR 160,-- here. > > > > Marcus > > Unifi not a cheapo access point ? That's a first for me! Unifi APs are > probably the cheapest half-decent APs on the market, especially if you > compare them to the typical cost of a brand name "enterprise" AP. Great, so if you find one or two of these lying around, ship them to me. There is no need to buy a new shrink-wrapped product to cover this request. I need these because according to reports I received they seem to trigger an iwm(4) bug which I want to try to reproduce locally, in the little spare time I have, so that your and other peoples' laptops can benefit. > As someone who has recently donated, surely this is the very sort of thing > the OpenBSD Foundation should be funding ? I didn't just give money to pay > for electricity bills caused by people insisting on maintaining racks of > vintage room-heaters. Actually, the foundation does fund hardware occasionally, but those tend to be bigger and more expensive items like laptops for developers who don't have enough spare cash to buy machines that cost more than a thousand quid. If you monitor our lists for dmesgs of rather expensive machines you'll notice that they rarely come from developers who could self-fund them. By adding an entry to want.html I didn't ask the foundation specifically, I asked *anyone* out there if they have a spare unit or two of these. If you feel your donations are being misdirected, I am sorry for your perceived loss. I know they are being put to good use in this project, not just for your own benefit, but for the benefit of the open source software ecosystem as a whole. Thanks for sharing some of your money with the rest of us, and supporting our efforts.
Re: want.html: Unifi wifi gear for interop debugging
On Sat, Oct 06, 2018 at 11:22:12AM +, Tim Jones wrote: > I think the point I'm making here is it should be worthwhile to send the kit. > > Unifi access points are so cheap, that second-hand ones "lying around" are > not likely to be worth the cost and effort to ship internationally (or even > nationally in the case of some postal systems). > > Something like a 10gig switch or whatever would be a different kettle of > fish, as the residual value would make it worthwhile. > > For commodity kit like that, I think Tom Smyth is thinking more down the > correct lines of approaching the manufacturer. I would also suggest > approaching the higher-tier "authorised resellers" would be an equally good > idea, as larger resellers higher up the food chain are often allocated a > quota of free/cheap units. They are generally not permitted to dispose of > the freebies for a defined period, but after that, they can normally do with > them as they wish. > Thank you for handling the logistics so I don't have to do that on top of everything else I'm doing. I am looking forward to receiving your shipment.
Re: Debug / Driver / Kernel / WiFi
On Sat, Oct 06, 2018 at 01:32:55PM +0200, NN wrote:
> Hi all,
>
> Many thanks for your support and reply!
>
> I am not Profi (I have experience < 1year with OpenBSD and C Programming.),
> that why its will take me a lot of time to fix and try something.
>
> After Mr. Sperling first review of my Code ... I have made few fixes.
>
> In attachment you can see my new patch. Please, try it and send me your
> feedback.
>
> Its working for me. (*no more ERROR: ath0 unable to reset hardware*)
Thank you! This is looking great. I see only two remaining problems:
Please don't use C++-style // comments. The lines commented this way
can just be removed.
More importantly it looks like these changes are based on work done
by Nick Kossifidis in Linux ath5k. I am quoting the relevant changes
from the Linux git log below. So I doubt this is your original work.
It is OK to copy this code into OpenBSD because it is licensed under
ISC, the same licence used by our ath(4) driver which this Linux code
was based on. But only under the condition that we give attribution
to the original author. So please copy Nick's copyright line into our
files as well. You can find it at the top of each file you've copied
code from.
And then we should be good to go.
commit cc6323c7d8c231d83e592ff9f7acf2cac5e016f7
Author: Nick Kossifidis
Date: Sun Jul 20 06:44:43 2008 +0300
ath5k: Update channel functions
* Add channel function for RF2425 (got this from decompiling binary
HAL, i have no idea why there is a 5GHz section but i'm looking
into it)
* Update RF5112 channel function (also got this from decompiling binary
HAL)
* Set JAPAN setting for channel 14 on all PHY chips
Changes-licensed-under: ISC
Signed-off-by: Nick Kossifidis
Signed-off-by: John W. Linville
diff --git a/drivers/net/wireless/ath5k/phy.c b/drivers/net/wireless/ath5k/phy.c
index 66af70bd14e7..cbc362d20719 100644
--- a/drivers/net/wireless/ath5k/phy.c
+++ b/drivers/net/wireless/ath5k/phy.c
@@ -1898,9 +1898,6 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah,
data = data0 = data1 = data2 = 0;
c = channel->center_freq;
- /*
-* Set the channel on the RF5112 or newer
-*/
if (c < 4800) {
if (!((c - 2224) % 5)) {
data0 = ((2 * (c - 704)) - 3040) / 10;
@@ -1912,7 +1909,7 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah,
return -EINVAL;
data0 = ath5k_hw_bitswap((data0 << 2) & 0xff, 8);
- } else {
+ } else if ((c - (c % 5)) != 2 || c > 5435) {
if (!(c % 20) && c >= 5120) {
data0 = ath5k_hw_bitswap(((c - 4800) / 20 << 2), 8);
data2 = ath5k_hw_bitswap(3, 2);
@@ -1924,6 +1921,9 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah,
data2 = ath5k_hw_bitswap(1, 2);
} else
return -EINVAL;
+ } else {
+ data0 = ath5k_hw_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8);
+ data2 = ath5k_hw_bitswap(0, 2);
}
data = (data0 << 4) | (data1 << 1) | (data2 << 2) | 0x1001;
@@ -1934,6 +1934,45 @@ static int ath5k_hw_rf5112_channel(struct ath5k_hw *ah,
return 0;
}
+/*
+ * Set the channel on the RF2425
+ */
+static int ath5k_hw_rf2425_channel(struct ath5k_hw *ah,
+ struct ieee80211_channel *channel)
+{
+ u32 data, data0, data2;
+ u16 c;
+
+ data = data0 = data2 = 0;
+ c = channel->center_freq;
+
+ if (c < 4800) {
+ data0 = ath5k_hw_bitswap((c - 2272), 8);
+ data2 = 0;
+ /* ? 5GHz ? */
+ } else if ((c - (c % 5)) != 2 || c > 5435) {
+ if (!(c % 20) && c < 5120)
+ data0 = ath5k_hw_bitswap(((c - 4800) / 20 << 2), 8);
+ else if (!(c % 10))
+ data0 = ath5k_hw_bitswap(((c - 4800) / 10 << 1), 8);
+ else if (!(c % 5))
+ data0 = ath5k_hw_bitswap((c - 4800) / 5, 8);
+ else
+ return -EINVAL;
+ data2 = ath5k_hw_bitswap(1, 2);
+ } else {
+ data0 = ath5k_hw_bitswap((10 * (c - 2) - 4800) / 25 + 1, 8);
+ data2 = ath5k_hw_bitswap(0, 2);
+ }
+
+ data = (data0 << 4) | data2 << 2 | 0x1001;
+
+ ath5k_hw_reg_write(ah, data & 0xff, AR5K_RF_BUFFER);
+ ath5k_hw_reg_write(ah, (data >> 8) & 0x7f, AR5K_RF_BUFFER_CONTROL_5);
+
+ return 0;
+}
+
/*
* Set a channel on the radio chip
*/
@@ -1963,6 +2002,9 @@ int ath5k_hw_channel(struct ath5k_hw *ah, struct
ieee80211_channel *channel)
case AR5K_RF5111:
ret = ath5k_hw_rf5111_channel(ah, channel);
break;
+ case AR5K_RF2425:
+ ret = ath5k_hw_rf2425_channel(ah, channel);
+ break;
default:
Re: USB Audio, Serial Terminal
On Mon, Oct 08, 2018 at 03:10:58AM -0400, Katherine Rohl wrote: > Hi, > > I’ve been using OpenBSD 6.3 for a few weeks and I really like it! There are > only two major things left that I haven’t been able to figure out. > > The first is using my USB headphones. I’ve tried following the instructions > in the FAQ (making sure that the audio device is set to the correct uaudio) > but to no avail. I’ve disabled my system’s onboard AC’97 audio to make sure > that there is only one audio device (confirmed with dmesg, my headphones show > up as uaudio0). Which configuration stuff do I need to post for y’all to help > me? :( > If this machine is using a USB3 controller driven by the xhci(4) driver, then USB audio devices won't work. Support for the data transfer mode these devices use (called "isochronous transfers") is not yet finished. Progress has been slow mostly because developers with the necessary expertise have been busy in areas other than USB. This problem also affects USB video devices. > The second is that I have a VT420 serial terminal I’d like to use with > OpenBSD. I have it connected to a PL2303 USB-to-serial adapter. I’ve > successfully connected it to other systems using the USB-to-serial adapter, > but I’m having some problems with connecting it to OpenBSD. I’ve added > entries to ttys for the USB-to-serial adapter and I’ve set it up to use the > regular 9600bps gettytab entry. The terminal is configured for 9600 8N1, no > XON/XOFF, no RTS/CTS handshaking. > > It connects to my system and I’m able to log in but after 15 seconds or so, > the terminal loses its DSR signal and the connection resets, sending me back > to a new login screen. Anyone have one of these terminals that may be able to > advise me on gettytab settings? Not sure, I have never added an entry to gettytab. For USB serial devices I just run cu(1) like this: cu -l /dev/cuaU0 -s 9600 In fact, 9600 is the default speed so I could omit the -s option in this case, but the -s option is required for other baud rates. Does that work for you? > Other than that, I’m very pleased with the OS, especially with how quiet my > computer is when idle compared to running, say, Windows 10 ;) > That's great :) Glad to hear it is working well for you! > Thank you for your assistance! > > - Katherine >
Re: Unexpected connection with `ifconfig join`
On Thu, Nov 01, 2018 at 04:01:51PM -0400, AB wrote: > I've run into a strange problem using ifconfig's new join statements. > I have two join lines in /etc/hostname.iwn0, with no nwid statement. > When both of these APs are out of range, it connects to a third, > unmentioned (open) AP. This is a network I've manually joined before, > but do not want to join automatically. Our plan is to address this in -current soon. But it won't be changed for 6.4. Some people expect what you expect (open networks are opt-in) some people expect the opposite (open networks are opt-out). There's no default behaviour we could choose to satisfy everyone. So -current will get a toggle...
Re: 'auto-join' to the wifi
On Thu, Nov 08, 2018 at 01:12:35PM +0500, Артур Истомин wrote: > There is example for hostname.if for auto-join to wifi network > https://www.mail-archive.com/source-changes@openbsd.org/msg99921.html > > But what if I have different networks with dynamic and static IPs or another > different options? For example: > > join home wpakey password <-- has static IP and 'wpaprotos wpa1' > option Adding the 'wpaprotos wpa1' option on the same line is supposed to work. Unfornately this is broken right now, see: https://marc.info/?l=openbsd-bugs&m=154118247412508&w=2 Regarding IP addresses: Wifi doesn't know about IP addresses! All 'join' will take care of is setting interface status to 'active'. So you need to handle such differences yourself in some way. > join work wpakey mekmitasdigoat > dhcp > inet6 autoconf > up > > Thanks! >
Re: support new
On Mon, Nov 12, 2018 at 09:56:04AM +, Stier, Sarah wrote: > Hi there, > > Please find all information below: > > 0 > C Germany > P Berlin > T Berlin > Z 10119 > O SMLan Software und Management Training > I Guenter Doerfler > A Kastanienallee 53 > M mailto:i...@smlan.de > U https://www.smlan.de/ > B 0049 30 4492545 > X 0049 30 43 73 57 59 > N BSD and Linux training and consulting. Over 10 years of experience. > > > Thank you and best wishes, > Sarah Hi Sarah, It is unclear to me how your offering relates to OpenBSD. I cannot find any mention of OpenBSD on your website. A search for "openbsd" with your website's own search box only brings up 4 unrelated results: Seminar FreeBSD Administration Seminar Samba-Server Seminar Unix Netzwerkadministration Seminar Internetanbindung Workshop It doesn't look like your site meets our criteria for entries on https://www.openbsd.org/support.html, which explicitly states that "we may at any time, and without notification, remove your entry if it is found to be inaccurate, if your website is broken, or if there is no mention of OpenBSD on it." ^^^ If you do indeed have OpenBSD-specific offerings, please add information about them to your site first, and then re-submit your entry. Thanks.
Re: support new
On Mon, Nov 12, 2018 at 12:50:03PM +0200, Jyri Hovila [Turvamies.fi] wrote: > 0 > C Finland > P Kymenlaakso > T Kouvola > Z 46900 > O Turvamies tietoturvapalvelut (Turvamies IT Security Services) > I Jyri Hovila > A Opistonkuja 1 > M i...@turvamies.fi > U https://turvamies.fi/ > B +358-404-177133 > X n/a > N Finnish specialists in OpenBSD based servers, firewalls and secure > communications systems. > Added, thanks. I left out "X n/a" because it that is an optional field anyway.
Re: amd64: installboot on RAID 1 cRYPTO
On Sun, Nov 18, 2018 at 04:38:06PM +0100, Martin Sukany wrote: > Hi, > > probably I'm overlooking something ... > > I have following disk layout: > sd0, sd1 - physical drives > sd2 - RAID 1 array with only "a" partiton on which CRYPTO device is created, > sd3 - used as "connection point" for crypted device. > > So, finally the system is installed on sd3X partitions. > > Problem comes when I want to boot, I tried > installboot sd2 /usr/mdec/biosboot /usr/mdec/boot > > After reboot I see the bootloader prompt but not able to boot softraid does not support nested disciplines. What you're seeing is a side-effect of this. To make your use case work, somebody would need to write a RAID1C (raid1 + crypto in one) discipline, or make nested disciplines work somehow.
Re: bwfm NVRAM file
On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote: > Question: Are there plans to include the NVRAM files in bwfm_firmware > package? Yes, this is being worked on. See these recent commits by Patrick: https://marc.info/?l=openbsd-cvs&m=158357502421524&w=2 https://marc.info/?l=openbsd-cvs&m=158348413626641&w=2 https://marc.info/?l=openbsd-cvs&m=158348535827039&w=2 I am not involved but it sounds like this issue could be resolved in time for the next release. But please have patience.
Re: bridge, vether & dhcpd
On Tue, Mar 17, 2020 at 08:24:34AM +0100, Salvatore Cuzzilla wrote: > Dear all, > > is someone using a setup with multiple layer 2 interfaces & a single vether > IP interface (layer 3) bundled all together in a bridge? > Well, i’m using this setup too and almost everything is working like > expected. > > However, > I have a couple of hosts connected to the L2 interfaces & i would like them > to dynamically get an IP (dhcpd instance already up & running) > atm, this is not working. I thought about PF , but probably it’s not the > issue … > > any advice? configuration examples i can go through? > > Is dhclient also running? If so, try to stop dhclient and see if it works then.
Re: bridge, vether & dhcpd
On Tue, Mar 17, 2020 at 12:14:21PM +0100, Salvatore Cuzzilla wrote: > nope, the L2 if(s) (including bridge) are running only with option ‘up’ > within hostname.if files > & all the other L3 ifs are with IP statically assigned Then you need to share a lot more details, such as your pf.conf, and tcpdumps from all relevant interfaces including pflog0 which show the facts about the actual vs. expected flow of packets.
