Supported hardware: miniPCIe WiFi adapter
Hi, this one is just for the record, as I had a hard time finding a suitable miniPCIe WiFi adapter for a Soekris 6501 (that's easily available in DE). The Ubiquity SR71-E works surprisingly well in -current, I'm tempted to outright recommend it (amongst others because of its high range). Appending it to the list of supported hardware would make sense. Problems I reported with this card went away with the patches stsp@ commited recently BTW. Here are the facts: athn0 at pci7 dev 0 function 0 Atheros AR9281 rev 0x01: apic 0 int 17 athn0: AR9280 rev 2 (2T2R), ROM rev 16, address 00:15:7d:84:a4:3d athn0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 hwfeatures=10VLAN_MTU lladdr 00:15:7d:84:a4:3d description: Wireless IPv4 priority: 4 groups: wlan media: IEEE802.11 autoselect (autoselect mode 11b hostap) status: active ieee80211: nwid Target IPv4 chan 5 bssid 00:15:7d:84:a4:3d wpakey KEY wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip inet 10.10.10.1 netmask 0xffe0 broadcast 10.10.10.31 inet6 fe80::215:6dff:fe84:a13d%athn0 prefixlen 64 scopeid 0x3 The media output is a bit lengthy, please see below. All the best, /Markus media autoselect media autoselect mediaopt hostap media autoselect mediaopt monitor media autoselect mode 11a media autoselect mode 11a mediaopt hostap media autoselect mode 11a mediaopt monitor media OFDM6 mode 11a media OFDM6 mode 11a mediaopt hostap media OFDM6 mode 11a mediaopt monitor media OFDM9 mode 11a media OFDM9 mode 11a mediaopt hostap media OFDM9 mode 11a mediaopt monitor media OFDM12 mode 11a media OFDM12 mode 11a mediaopt hostap media OFDM12 mode 11a mediaopt monitor media OFDM18 mode 11a media OFDM18 mode 11a mediaopt hostap media OFDM18 mode 11a mediaopt monitor media OFDM24 mode 11a media OFDM24 mode 11a mediaopt hostap media OFDM24 mode 11a mediaopt monitor media OFDM36 mode 11a media OFDM36 mode 11a mediaopt hostap media OFDM36 mode 11a mediaopt monitor media OFDM48 mode 11a media OFDM48 mode 11a mediaopt hostap media OFDM48 mode 11a mediaopt monitor media OFDM54 mode 11a media OFDM54 mode 11a mediaopt hostap media OFDM54 mode 11a mediaopt monitor media autoselect mode 11b media autoselect mode 11b mediaopt hostap media autoselect mode 11b mediaopt monitor media DS1 mode 11b media DS1 mode 11b mediaopt hostap media DS1 mode 11b mediaopt monitor media DS2 mode 11b media DS2 mode 11b mediaopt hostap media DS2 mode 11b mediaopt monitor media DS5 mode 11b media DS5 mode 11b mediaopt hostap media DS5 mode 11b mediaopt monitor media DS11 mode 11b media DS11 mode 11b mediaopt hostap media DS11 mode 11b mediaopt monitor media autoselect mode 11g media autoselect mode 11g mediaopt hostap media autoselect mode 11g mediaopt monitor media DS1 mode 11g media DS1 mode 11g mediaopt hostap media DS1 mode 11g mediaopt monitor media DS2 mode 11g media DS2 mode 11g mediaopt hostap media DS2 mode 11g mediaopt monitor media DS5 mode 11g media DS5 mode 11g mediaopt hostap media DS5 mode 11g mediaopt monitor media DS11 mode 11g media DS11 mode 11g mediaopt hostap media DS11 mode 11g mediaopt monitor media OFDM6 mode 11g media OFDM6 mode 11g mediaopt hostap media OFDM6 mode 11g mediaopt monitor media OFDM9 mode 11g media OFDM9 mode 11g mediaopt hostap media OFDM9 mode 11g mediaopt monitor media OFDM12 mode 11g media OFDM12 mode 11g mediaopt hostap media OFDM12 mode 11g mediaopt monitor media OFDM18 mode 11g media OFDM18 mode 11g mediaopt hostap media OFDM18 mode 11g mediaopt monitor media OFDM24 mode 11g media OFDM24 mode 11g mediaopt hostap media OFDM24 mode 11g mediaopt monitor media OFDM36 mode 11g media OFDM36 mode 11g mediaopt hostap media OFDM36 mode 11g
Re: Supported hardware: miniPCIe WiFi adapter
On Thu, 02 16:08 , Jason McIntyre wrote: ... high range). Appending it to the list of supported hardware would make sense. ... which list of supported hardware are you referring to? this chipset is already listed as supported in athn(4). Pardon me, I thought the list also had card product names. The reason I wrote this mail is I already tested cards with chips listed under athn(4) which were performing quite poor, e.g. the Compex WLM200NX 6A: messages:Sep 19 22:39:29 aloha /bsd: athn0 at pci0 dev 14 function 0 Atheros AR9280 rev 0x01: irq 5 messages:Sep 19 22:39:29 aloha /bsd: athn0: AR9280 rev 2 (2T2R), ROM rev 16, address 00:80:48:72:5a:6b Testing it was a frustrating experience. I remember it was merely usable, i.e. only as a client and the connection dropped dead out of the blue without any indication why. This might have changed in the meantime, though. Regards, /Markus
Re: ASUS USB adapters
On Wed, 18 23:30 , mufurcz wrote: Anybody using/tested these wireless cards with OpenBSD? Unfortunately, I can't find the chip-set specs. http://www.asus.com/Networks/Wireless_Adapters/WL167G_V3/#specifications I have the predecessor version of that stick for some time (years?) now. Has decent TX power (ifconfig says 100 dBm) and runs very reliable. ural0 at uhub0 port 3 ASUS 802.11g WLAN Drive rev 2.00/0.01 addr 2 ural0: MAC/BBP RT2570 (rev 0x05), RF RT2526, address 00:15:f2:7b:12:34 This module should be relatively cheap, I think I paid about 10 Euros at the time. So just go for it. All the best, /Markus
Re: Strange connection problems with athn interface
On Sun, 15 21:18 , STeve Andre' wrote: On 01/15/12 20:52, Stuart Henderson wrote: On 2012-01-15, Markusli...@neuronenwerk.de wrote: I'm in the process of finding out why my Ubiquity SR7-e PCIe module worked perfectly with the 29.12.2011-snapshot, while I only see problems with the 13.01.2012-snapshot. ... I skimmed the CVS commit log from end of December to know and did not spot any changes that would make me suspicious in the first place. Me neither. But around this time of year it's more likely than usual that people might have new wireless gadgets which might be tickling an existing bug. Does reverting to the older kernel restore things? As I don't have any kernel from back then (faithfully overwrote just the whole disk at reinstall), I took the effort of pulling cvs sources from that date and building a new old kernel. I even built it with COUNTRYCODE defined to 00 in ar5xxx.c one time in order to exclude potential problems with the regulatory domain. This didn't turn out to be relevant though. Booting with this kernel indeed restored the expected (good) behaviour. This is the CE-version of the module, reduced to 100 dBm, BTW. I think (hope :) you're confusing your units here. Um, yeah--100dBm is 10 mega watts. The laptop (and user) might catch fire exposed to that kind of RF. I admit my hands have been faster than my brain here :) I even bugged the manufacturer again about the ominous CE certification the module has. The reply was: The module is running on 100 mW if its told its located in the German regulatory domain. Otherwise its capable of sending with at TX power of up to 26 dBm (no confusion this time). I also have two 5 dBi antennas to connect (one currently attached). Right now, I run the following version without problems: OpenBSD 5.1-beta (GENERIC) #135: Sun Jan 15 13:04:45 MST 2012 So as it looks now, the Ubiquity SR71-E module works. I will keep an eye on it since all this still appears quite strange to me. I don't really have any indication why it does work right now. All the best, /Markus
sdmmc code update
Hi, when stumbling over a SD CSD version 3 card error yesterday, I spotted that NetBSD already extended the sdmmc driver for recognizing information in the cards extended CSD field. Are there any objections to re-integrate this new code into OpenBSD? Cheers, /Markus
Re: SSD disk alignment
On Fri, 11 10:47 , Otto Moerbeek wrote: Well, we are slowly moving away from any CHS considerations in disklabel. For various reasons it is not yet possible to completely do away with CHS in all cases. But for most purposes and with LBA capable disks, you can use ANY offset. Just put in sector numbers, in that case they are not rounded to cylinder boundaries. You want to leave some room for things like alternative boot loaders and who knows. Skipping the first track is a safe practice. We used to start at the 2nd track (offset 63 in most cases) but that has been moved to 64 to accomodate 4k block disks. To my understanding, matching the erase block size of SSD memory can produce a gain in performance, however the most important thing is to align at 4k boundaries. As this is the case, the current (pre 4.9) state in OpenBSD is handling the setup of SSD disks in the best possible way automatically. From your replies I conclude that there should be no additional configuration necessary. It is amazing how old limitations tend to stick into the collective memory, despite all the work done to overcome the limitations. Sadly, this is exactly the case. Typical case of vague memories from the past that have never been updated/refreshed. Thanks nevertheless for helping me understand the current state regarding SSD disks. All the best, /Markus
SSD disk alignment
Hi, I recently bought a SSD disk to pimp ye ol X40 notebook. The device is a Mach Xtreme Technology Nano 44Pin Series 1,8 Zoll PATA SSD - 60G (see dmesg below). Currently, it looks as if my expectations towards gain in snappiness, power consumption and quietness are met. After roaming a number of lists however, I learned that SSD disks are best aligned along 128k boundaries due to the erase block size. That's what I intended to do when installing the system again yesterday (current snapshot): As the BIOS of the X40 does not support setting (and showing) drive parameters, I have no idea what the BIOS thinks is the disk geometry. The only way to guess that is looking at the fdisk C/H/S values, however this might potentially also be set by the disk driver. fdisk reports the geometry as 7732 cylinders / 240 heads / 63 sectors, which is ok, since it at least divisable by 8 and aligned to 4k. I want to change that to 9320 cylinders with 224 heads (32*7) and 56 sectors (8*7) in fdisk interactive mode (disk). However, I cannot set the right cylinder size, since fdisk says that the BIOS Cylinders must be between 1-1024. The reason is that src/sbin/fdisk/cmd.c has BIOS Cylinders hardcoded (maxcyl = 1024, roughly 8G then). Is there any necessity for limiting this value? If not, could we raise it to something more contemporary, like 2^16 or more (I'd prepare a diff if I had a suitable machine at hand right now)? If I would save the MBR in interactive mode, the values given with the disk command would actually persist and I'd be done. I mention this, because the C/H/S values do not persist, if I issue an fdisk -c 9320 -h 224 -s 56 wd0. The next call of fdisk gives me again the old geometry (even when I use -u before). I'd be happy if anyone could give me a hint on how to arrive at a point where I can set the disk geometry persistently (and correct). Thanks in advance, /Markus # atactl wd0 identify Model: MXSSD1MNANO-60G, Rev: VATE1532, Serial #: 101206112 Device type: ATA, fixed Cylinders: 16383, heads: 16, sec/track: 63, total sectors: 116916224 Device capabilities: ATA standby timer values IORDY operation Device supports the following standards: ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6 ATA-7 ATA-8 Master password revision code 0xfffe Device supports the following command sets: NOP command READ BUFFER command WRITE BUFFER command Host Protected Area feature set Read look-ahead Write cache Power Management feature set Security Mode feature set SMART feature set Flush Cache Ext command Flush Cache command 48bit address feature set Set Max security extension commands DOWNLOAD MICROCODE command Device has enabled the following command sets/features: NOP command READ BUFFER command WRITE BUFFER command Host Protected Area feature set Read look-ahead Write cache Power Management feature set SMART feature set Flush Cache Ext command Flush Cache command 48bit address feature set DOWNLOAD MICROCODE command # atactl wd0 secsetpass user high User password: test Retype user password: test atactl: ATA device returned Aborted Command - There is no way to issue a atactl secerase user without having a password # dmesg OpenBSD 4.9 (GENERIC) #671: Wed Mar 2 07:09:00 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) M processor 1.40GHz (GenuineIntel 686-class) 1.40 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2 real mem = 1063743488 (1014MB) avail mem = 1036210176 (988MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/31/06, BIOS32 rev. 0 @ 0xfd740, SMBIOS rev. 2.33 @ 0xe0010 (56 entries) bios0: vendor IBM version 1UETD2WW (2.07 ) date 08/31/2006 bios0: IBM 2371H9G apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 100% apm0: AC on, battery charge high acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd6d0/0x930 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdeb0/256 (14 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0xc800! 0xcc800/0x1000 0xcd800/0x1000 0xdc000/0x4000! 0xe/0x1 cpu0 at mainbus0: (uniprocessor) cpu0: Enhanced SpeedStep 1396 MHz: speeds: 1400, 1300, 1200, 1100, 1000, 900, 800, 600 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) io address conflict 0x5800/0x8 io address conflict 0x5808/0x4 io address conflict 0x5810/0x8 io address conflict 0x580c/0x4 mem address conflict 0x3f70/0x400 pchb0 at pci0 dev 0 function 0 Intel 82855GM Host rev 0x02 Intel 82855GM Memory rev 0x02 at pci0 dev 0 function 1 not configured Intel 82855GM Config rev 0x02 at pci0 dev 0 function 3 not configured vga1 at pci0 dev 2
Re: SSD disk alignment
Thanks Otto, this is somehow obvious, nevertheless there are tools relying on the partition layout, like disklabel (at least regarding the start of the partition). So essentially, every start above the first sector (ie. the MBR) would be acceptable? I see that the installer suggests sector 2 as start of the disk (in fdisk), however disklabel starts wd0a at offset 64 (default), which seems kind of odd. Is there an explanation for this effect? Amit: You're right. However, as disks from about 2005 onwards are larger than this boundary, you always can _accidentally_ choose to make your boot partition too big. As the C/H/S configuration is kind of an advanced option, I'd believe in a healthy common sense of people using this option, instead of preventing them to accomplish the task they're after. Thanks in advance, /Markus
Re: [NEW] sysutils/hotplug-diskmount
Hi, here's an approach I'm using for years now, giving me much more than the usual granularity when using USB hotplug devices: http://www.neuronenwerk.de/files/usb-hotplug.c http://www.neuronenwerk.de/files/attach All the best, /Markus
USB device nodes
Hi, working on setting up some crypto tokens, I noticed some differences to Free/NetBSD on handling the ugen devices. If a device is attached, the kernel reports it as ugenX, as it does it also on the other BSDs. Though /dev/ugenX itself doesn't exist on OpenBSD, so it can't be talked to. Typically, the endpoint an application wants to communicate with is the control endpoint ugenX.00. The other BSDs seem to handle that case transparently, i.e. if no endpoint is specified, .00 is chosen automatically. Since stat'ing a device-node for existance is appearently quite common, introducing a symlink /dev/ugenX - /dev/ugenX.00 would be an obvious solution in this situation. While I have no problem with creating the links by myself, it would be nice if MAKEDEV could also create the symlink by default. Any chance to get this in? Thanks in advance, /Markus
Re: VIA fanless 1GHz
On Wed, Mar 01, 2006 at 03:33:21PM -0500, marrandy wrote: Has anyone tried VIA Eden fanless at 1GHz yet or the new Eden-N or NL (Luke series) yet ? If so, how did they perform. I used to have one of them with a HD plugged. They perform quite well, as long as you keep them cool enough under high load (which you cannot do passively). In fact I was building the userland on a VIA Eden 1 GHz and this melted the plastic plugs which keep the cooler in touch with the processor. Building it with some cooling aggregates on top (yes, the one from the fridge you normally use for cooling your beer while travelling) even allowed me to build the jdk-stuff without a single poweroff caused by overheating ;) You see, not quite what it promises. If you don't expect high loads and put the board in a suitable chassis, you will be quite happy with that. Otherwise, don't waste your money. All the best, /Markus
Re: serial console
On Tue, Feb 28, 2006 at 04:36:12PM -0300, Gustavo Rios wrote: Hey folks, i am trying to set my desktop serial console in order to be able to have serial access to my soekris box. The probably easiest way is a tip -BAUDRATE TERM # tip -19200 tty00 /Markus
Re: serial console
On Tue, Feb 28, 2006 at 04:36:12PM -0300, Gustavo Rios wrote: Hey folks, i am trying to set my desktop serial console in order to be able to have serial access to my soekris box. I wonder how should i configure my local (desktop box) serial to do it? I known, the FAQ does not explain what i need: The easiest way to connect to your SOEKRIS is a tip -19200 tty00 You've probably already seen http://www.openbsd.org/faq/faq7.html#SerCon /Markus
