Re: Unable to associate with wifi AP until channel changed on AP
Sorry for late answer - had some problems with my ISP. On Sunday 22 December 2013 01:42:09 electronmuontau neutrino wrote: > I have two machines configured as wifi access points that use the > athn(4) driver. One is an Acer Aspire One D250 and the other is an > ALIX.2D13 with a Compex WLM200NX Atheros 802.11 a/b/g/n miniPCI > card. Both have OpenBSD 5.4 release installed. I've been able to > reproduce the problem reliably on both. The following is one > procedure I used to test the problem: > > -boot machine with athn down > > $ ifconfig athn0 > athn0: flags=8802 mtu 1500 > lladdr: xx:xx:xx:xx:xx:xx > priority: 4 > groups: wlan > media: IEEE802.11 autoselect > status: no network > ieee80211: nwid "" > $ sudo ifconfig athn0 inet 192.168.2.1 255.255.255.0 nwid > 1234567890 wpakey keykeykey mediaopt hostap > $ ifconfig athn0 > athn0: flags=8843 mtu > 1500 lladdr: xx:xx:xx:xx:xx:xx > priority: 4 > groups: wlan > media: IEEE802.11 autoselect (autoselect hostap) > status: active > ieee80211: nwid 1234567890 chan 3 bssid xx:xx:xx:xx:xx:x: > wpakey wpaprotos wpa1, wpa2 wpaakms psk wpaciphers > tkip, ccmp wpagroupcipher tkip > inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 > inet6 ::xxx:::%athn0 pfrefixlen 64 scopeid > 0x1 > > -edit dhcpd.conf and run dhcpd daemon > $ sudo /usr/sbin/dhcpd athn0 > > -attempt to associate from MacOSX and WinXP machines > -not able to see nwid on WinXP after refreshing list multiple > times -can see nwid on MacOSX, but connection times out when trying > to associate > Down to here you are sending on 5120MHz, right? > -change channel on access point > $ sudo ifconfig athn0 chan 7 Now you switch to 2.4GHz - right? > > -association with AP is successful from MacOSX and WinXP machines > now and IP addresses are assigned WinXP machine might not work with 5GHz? Are the antennas suitable for 5GHz? What about signal strength? On the MAC it might be useful to install a WiFi scanner which will tell you all about signal strength. There is a free program called "Wifi Scanner" in the AppleStore. It is very useful. I can't help with the COMPEX miniPCI 'cause I got another brand on my Alix 2D13. But I realized that signal strength with 5GHz can be significantly lower than with 2.4GHz using antennas which are meant to work on both bands. Just my 2 c > > Acer Aspire One D250 > athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 4 int > 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address > xx:xx:xx:xx:xx:xx > > Alix 2D13 > athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 9 > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx Some might like to see a complete dmesg of this setup [hint-hint] > > Has anyone else encountered this? Please let me know if more info > is needed. Cheers Eike
Re: resolver question
On Tue, Dec 24, 2013 at 3:50 PM, Andy Bradford wrote: > Thus said "Peter J. Philipp" on Tue, 24 Dec 2013 17:33:10 +: > >> I was browsing http://chealth.canoe.ca when I saw the above log. I'm >> supposing the resolver looks up chealth.canoe.ca, and then eventually >> does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the >> domain I configured in resolv.conf by means of DHCP. > > You have a some options: > > 1) Change your habits to use a fully qualified domain name; e.g., a > domain name that ends with a final/trailing dot. chealth.cano.ca is > ambiguous (perhaps not in your brain, but to a computer, it doesn't know > that you really mean chealth.canoe.ca. which is absolute). So use > http://chealth.canoe.ca./ (note the trailing dot). > 2) Don't configure a search option in /etc/resolv.conf as each domain > listed in the search is appended to the query in order. E.g., if > you have centroid.eu and google.com in your search, then your DNS > resolver will take chealth.canoe.ca and append centroid.eu., attempt to > resolve it but fail. Then it will take chealth.canoe.ca and append > google.com., attempt to resolve it but fail, and then finally it will > try chealth.canoe.ca., attempt to resolve it and receive a successful > response. the suffix list may still be initialized from the ``domain'' keyword, which is very likely in a dhcp scenario, and more than that, present in the OP dhcp-fed resolv.conf thus setting ``search .'' is the way of insuring that no suffixes be appended, even when ``domain'' is present, or when ``domain'' is absent and it's consequently deduced from the system hostname what's interesting is that the query has more than the default ndots i think further investigation is due on OP's part > Andy > -- > TAI64 timestamp: 400052b9ecb0
Re: resolver question
On Tue, Dec 24, 2013 at 12:09:18PM -0800, Jeff O'Neal wrote: > Peter, > > >From the resolv.conf man page: > > http://www.openbsd.org/cgi-bin/man.cgi?query=resolv.conf&sektion=5 > > > "The domain and search keywords are mutually exclusive. If more than one > instance of these keywords is present, the last instance will > override." > > I believe what is happening is the search keyword is sticking > centroid.euto probably everything. This isn't a issue with the code, > its a > miss-configuration. Jeff, Maybe you're on to something, but the last instance is the domain keyword, not the search. I'll take that out of my resolv.conf.tail file where I believe it is and watch the logs if I see any behaviour like this. Give me a few days... Cheers, -peter > Of course I could be horribly wrong and someone might come over and kick my > dog to teach me a lesson > ~Jeff > > > > On Tue, Dec 24, 2013 at 9:33 AM, Peter J. Philipp wrote: > > > On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: > > > On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: > > > > I'm trying to track down the code in the libasr that causes this > > behaviour: > > > > > > > > Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain > > > > like a search. So with logging turned on, on my nameserver I get this: > > > > > > > > pjp@americas$ grep canoe.ca.centroid.eu /var/log/all > > > > Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 > > > > interface "em0" from 212.114.242.132 (ttl=54, region=255) for > > > > "chealth.canoe.ca.centroid.eu." type=(28) class=1, answering > > "NXDOMAIN" > > > > > > > > The problem is that my nameservers are in china and latin america and > > > > I'M sorta worried about these leaks. This particular log came from my > > > > nameserver in panama and the packet passes miami. > > > > > > I'm not clear on what the leak you are worried about is. > > > > > > Ken > > > > Hi Ken, Merry Christmas! > > > > I was browsing http://chealth.canoe.ca when I saw the above log. I'm > > supposing > > the resolver looks up chealth.canoe.ca, and then eventually does a lookup > > for > > chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in > > resolv.conf by means of DHCP. > > > > I'm wondering why it does that though? Someone in the US, like the NSA, > > can > > then sit back and see my browsing habits, which I call a leak. I'm hoping > > on > > finding the knob that turns this off. The leak wouldn't happen if my > > centroid.eu nameservers were just in .de but then you can just replace NSA > > with BND the german intelligence sniffers (s/NSA/BND). > > > > I'd really just rather replace the function that allows > > chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should > > exit is > > a lookup for just chealth.canoe.ca, which takes a different lookup path > > in the > > Internet. > > > > Regards, > > > > -peter > > > > > > > > > > My resolv.conf file looks like this on the workstation here in germany: > > > > > > > > jupiter$ more /etc/resolv.conf > > > > # Generated by re0 dhclient > > > > search centroid.eu > > > > nameserver 192.168.34.1 > > > > domain centroid.eu > > > > lookup file bind > > > > family inet6 inet4 > > > > > > > > > > > > The leak only happens with queries, like said. Any hints on > > > > tracking this down and squelching it? > > > > > > > > Regards, > > > > > > > > -peter
Re: resolver question
On Tue, Dec 24, 2013 at 1:03 PM, Peter J. Philipp wrote: > On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: >> On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: >> > I'm trying to track down the code in the libasr that causes this behaviour: >> > >> > Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain >> > like a search. So with logging turned on, on my nameserver I get this: >> > >> > pjp@americas$ grep canoe.ca.centroid.eu /var/log/all >> > Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 >> > interface "em0" from 212.114.242.132 (ttl=54, region=255) for >> > "chealth.canoe.ca.centroid.eu." type=(28) class=1, answering "NXDOMAIN" >> > >> > The problem is that my nameservers are in china and latin america and >> > I'M sorta worried about these leaks. This particular log came from my >> > nameserver in panama and the packet passes miami. >> >> I'm not clear on what the leak you are worried about is. >> >> Ken > > Hi Ken, Merry Christmas! > > I was browsing http://chealth.canoe.ca when I saw the above log. I'm > supposing > the resolver looks up chealth.canoe.ca, and then eventually does a lookup for > chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in > resolv.conf by means of DHCP. a FQDN ends with a period this tells a correctly functioning dns subsystem--"correctly" being subject to your willingness to abide a collection of rfcs, all the way from local binaries to remote hosts[0]--that you wish to resolve that name sans transformations the ``search'' keyword in resolv.conf is a suffix that may be appended to unqualified domain names prior resolving them to ip addresses 1. check if you are really configuring the appropiate settings. some programs, eg dig, willfully ignore the search keyword by default. some browsers use their own resolvers 2. clear the ``search`` keyword: $ echo 'search .' >> /etc/resolv.conf.tail # dhclient $INTERFACE > > I'm wondering why it does that though? Someone in the US, like the NSA, can > then sit back and see my browsing habits, which I call a leak. I'm hoping on > finding the knob that turns this off. The leak wouldn't happen if my > centroid.eu nameservers were just in .de but then you can just replace NSA > with BND the german intelligence sniffers (s/NSA/BND). > > I'd really just rather replace the function that allows > chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should exit is > a lookup for just chealth.canoe.ca, which takes a different lookup path in the > Internet. > > Regards, > > -peter > >> > >> > My resolv.conf file looks like this on the workstation here in germany: >> > >> > jupiter$ more /etc/resolv.conf >> > # Generated by re0 dhclient >> > search centroid.eu >> > nameserver 192.168.34.1 >> > domain centroid.eu >> > lookup file bind >> > family inet6 inet4 >> > >> > >> > The leak only happens with queries, like said. Any hints on >> > tracking this down and squelching it? >> > >> > Regards, >> > >> > -peter
Re: resolver question
Thus said "Peter J. Philipp" on Tue, 24 Dec 2013 17:33:10 +: > I was browsing http://chealth.canoe.ca when I saw the above log. I'm > supposing the resolver looks up chealth.canoe.ca, and then eventually > does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the > domain I configured in resolv.conf by means of DHCP. You have a some options: 1) Change your habits to use a fully qualified domain name; e.g., a domain name that ends with a final/trailing dot. chealth.cano.ca is ambiguous (perhaps not in your brain, but to a computer, it doesn't know that you really mean chealth.canoe.ca. which is absolute). So use http://chealth.canoe.ca./ (note the trailing dot). 2) Don't configure a search option in /etc/resolv.conf as each domain listed in the search is appended to the query in order. E.g., if you have centroid.eu and google.com in your search, then your DNS resolver will take chealth.canoe.ca and append centroid.eu., attempt to resolve it but fail. Then it will take chealth.canoe.ca and append google.com., attempt to resolve it but fail, and then finally it will try chealth.canoe.ca., attempt to resolve it and receive a successful response. Andy -- TAI64 timestamp: 400052b9ecb0
Re: resolver question
On Tue, Dec 24, 2013 at 17:33, Peter J. Philipp wrote: > I was browsing http://chealth.canoe.ca when I saw the above log. I'm > supposing > the resolver looks up chealth.canoe.ca, and then eventually does a lookup for > chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in > resolv.conf by means of DHCP. I think you have this backwards. It looks up chealth.canoe.ca.centroid.eu first. Your browser apparently doesn't think chealth.canoe.ca is a full domain, and so it starts creating a full name and resolving that. (or not the browser, but the local dns cache. you're not clear what server you're machine is contacting.) fwiw, I only see queries to chealth.canoe.ca and not any local domain extended variants, using both both ping and firefox. on the other hand, if I ping "apple", there are lookup requests for apple.home.tedunangst.com, apple.tedunangst.com, and apple.
Re: resolver question
Peter, >From the resolv.conf man page: http://www.openbsd.org/cgi-bin/man.cgi?query=resolv.conf&sektion=5 "The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance will override." I believe what is happening is the search keyword is sticking centroid.euto probably everything. This isn't a issue with the code, its a miss-configuration. Of course I could be horribly wrong and someone might come over and kick my dog to teach me a lesson ~Jeff On Tue, Dec 24, 2013 at 9:33 AM, Peter J. Philipp wrote: > On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: > > On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: > > > I'm trying to track down the code in the libasr that causes this > behaviour: > > > > > > Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain > > > like a search. So with logging turned on, on my nameserver I get this: > > > > > > pjp@americas$ grep canoe.ca.centroid.eu /var/log/all > > > Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 > > > interface "em0" from 212.114.242.132 (ttl=54, region=255) for > > > "chealth.canoe.ca.centroid.eu." type=(28) class=1, answering > "NXDOMAIN" > > > > > > The problem is that my nameservers are in china and latin america and > > > I'M sorta worried about these leaks. This particular log came from my > > > nameserver in panama and the packet passes miami. > > > > I'm not clear on what the leak you are worried about is. > > > > Ken > > Hi Ken, Merry Christmas! > > I was browsing http://chealth.canoe.ca when I saw the above log. I'm > supposing > the resolver looks up chealth.canoe.ca, and then eventually does a lookup > for > chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in > resolv.conf by means of DHCP. > > I'm wondering why it does that though? Someone in the US, like the NSA, > can > then sit back and see my browsing habits, which I call a leak. I'm hoping > on > finding the knob that turns this off. The leak wouldn't happen if my > centroid.eu nameservers were just in .de but then you can just replace NSA > with BND the german intelligence sniffers (s/NSA/BND). > > I'd really just rather replace the function that allows > chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should > exit is > a lookup for just chealth.canoe.ca, which takes a different lookup path > in the > Internet. > > Regards, > > -peter > > > > > > > My resolv.conf file looks like this on the workstation here in germany: > > > > > > jupiter$ more /etc/resolv.conf > > > # Generated by re0 dhclient > > > search centroid.eu > > > nameserver 192.168.34.1 > > > domain centroid.eu > > > lookup file bind > > > family inet6 inet4 > > > > > > > > > The leak only happens with queries, like said. Any hints on > > > tracking this down and squelching it? > > > > > > Regards, > > > > > > -peter
Re: resolver question
On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: > On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: > > I'm trying to track down the code in the libasr that causes this behaviour: > > > > Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain > > like a search. So with logging turned on, on my nameserver I get this: > > > > pjp@americas$ grep canoe.ca.centroid.eu /var/log/all > > Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 > > interface "em0" from 212.114.242.132 (ttl=54, region=255) for > > "chealth.canoe.ca.centroid.eu." type=(28) class=1, answering "NXDOMAIN" > > > > The problem is that my nameservers are in china and latin america and > > I'M sorta worried about these leaks. This particular log came from my > > nameserver in panama and the packet passes miami. > > I'm not clear on what the leak you are worried about is. > > Ken Hi Ken, Merry Christmas! I was browsing http://chealth.canoe.ca when I saw the above log. I'm supposing the resolver looks up chealth.canoe.ca, and then eventually does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in resolv.conf by means of DHCP. I'm wondering why it does that though? Someone in the US, like the NSA, can then sit back and see my browsing habits, which I call a leak. I'm hoping on finding the knob that turns this off. The leak wouldn't happen if my centroid.eu nameservers were just in .de but then you can just replace NSA with BND the german intelligence sniffers (s/NSA/BND). I'd really just rather replace the function that allows chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should exit is a lookup for just chealth.canoe.ca, which takes a different lookup path in the Internet. Regards, -peter > > > > My resolv.conf file looks like this on the workstation here in germany: > > > > jupiter$ more /etc/resolv.conf > > # Generated by re0 dhclient > > search centroid.eu > > nameserver 192.168.34.1 > > domain centroid.eu > > lookup file bind > > family inet6 inet4 > > > > > > The leak only happens with queries, like said. Any hints on > > tracking this down and squelching it? > > > > Regards, > > > > -peter
Re: netstat segfault on -current
On Mon, Dec 23, 2013 at 11:51 PM, Kenneth R Westerback wrote: > It is a real issue, due to errors I made replacing CIRCLEQ with TAILQ. > > A fix is being worked on, and a workaround probably sooner than that. Thanks. I knew it wasn't a userland/kernel sync problem.
Re: resolver question
On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: > I'm trying to track down the code in the libasr that causes this behaviour: > > Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain > like a search. So with logging turned on, on my nameserver I get this: > > pjp@americas$ grep canoe.ca.centroid.eu /var/log/all > Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 > interface "em0" from 212.114.242.132 (ttl=54, region=255) for > "chealth.canoe.ca.centroid.eu." type=(28) class=1, answering "NXDOMAIN" > > The problem is that my nameservers are in china and latin america and > I'M sorta worried about these leaks. This particular log came from my > nameserver in panama and the packet passes miami. I'm not clear on what the leak you are worried about is. Ken > > My resolv.conf file looks like this on the workstation here in germany: > > jupiter$ more /etc/resolv.conf > # Generated by re0 dhclient > search centroid.eu > nameserver 192.168.34.1 > domain centroid.eu > lookup file bind > family inet6 inet4 > > > The leak only happens with queries, like said. Any hints on > tracking this down and squelching it? > > Regards, > > -peter
Re: dhcpd(8) support for option domain-search
On Mon, Dec 23, 2013 at 12:03:13AM -0700, Darren Spruell wrote: > Wanted to verify my understanding that the included dhcpd(8) in base > does not currently support the domain-search option: > > """ > option domain-search domain-list; The domain-search option specifies a > 'search list' of Domain Names to be used by the client to locate > not-fully-qualified domain names. The difference between this option > and historic use of the domain-name option for the same ends is that > this option is encoded in RFC1035 compressed labels on the wire. For > example: > > option domain-search "example.com", "sales.example.com", > "eng.example.com"; > """ > > dhcpd.conf(5) and dhcp-options(5) don't mention the option. option 119 (domain search, specified in rfc 3397) is not supported in the base version of dhcpd. One *could* provide it with the syntax option-119 nn:nn:nn:nn:nn... where you provide the appropriate hex digits to specify the contents of the option. Not a nice solution. :-) > > I can currently override the search domains on clients, and it seems > like it might be supported in isc-dhcp-server package. Anything likely > to make it into base? Simply a matter of patch not having been > submitted, or anything deeper than that? Nothing deeper than that, as far as I know. Is option 119 in wide use as far as you know? Ken
Re: dhcpd(8) support for option domain-search
On 2013-12-23, Darren Spruell wrote: > Wanted to verify my understanding that the included dhcpd(8) in base > does not currently support the domain-search option: > > """ > option domain-search domain-list; The domain-search option specifies a > 'search list' of Domain Names to be used by the client to locate > not-fully-qualified domain names. The difference between this option > and historic use of the domain-name option for the same ends is that > this option is encoded in RFC1035 compressed labels on the wire. For > example: > > option domain-search "example.com", "sales.example.com", > "eng.example.com"; > """ > > dhcpd.conf(5) and dhcp-options(5) don't mention the option. > > I can currently override the search domains on clients, and it seems > like it might be supported in isc-dhcp-server package. Anything likely > to make it into base? Simply a matter of patch not having been > submitted, or anything deeper than that? > I suppose nobody found a requirement for it that was sufficiently important to be worth implementing it in dhcpd/dhclient to use (it's more work than just adding to the options table as it uses a name compression method borrowed from DNS that would need to be written or borrowed from elsewhere - and done with care, particularly for the client, as historically dns-compression has been a bit susceptible to bugs). As a dirty hack for dhcpd you could probably specify it as hex using "option-119" but would need to handle the dns compression yourself, http://tools.ietf.org/search/rfc3397 contains clues, but it's fiddly. (IMHO it would really want to be supported in both client and server if it was added to OpenBSD..).
Re: nsd sendto failure - how to debug?
On 2013-12-23, Adam Thompson wrote: > On 13-12-22 06:44 AM, Stuart Henderson wrote: >>> I'm seeing lots of "nsd[11026]: error: sendto failed: No route to host" >> You may need to raise net.inet.udp.sendspace > > Done. Raised from ~9000ish (default) to 41600. Errors still occurring > periodically, no perceptible change in rate. > If that was the problem in the first place, wouldn't the error be > different (ENOBUFS instead of EHOSTUNREACH)? > > If it's of any interest, the error often occurs in bursts (n>=4 within > syslog's "last message repeated /n/ times" window). > Hmm, good point. Is there any chance you receive (and try to reply to) packets with bogus source addresses (spoofed/non-reachable, or packets which should have been natted but weren't)? I would also keep an eye on output of 'route -n monitor' and look for instability there (e.g. RTM_MISS messages).
Re: (5.4) System hangs during shutdown
Em 21-12-2013 21:52, Adam Jensen escreveu: > On 12/20/2013 09:05 AM, Giancarlo Razzolini wrote: >> Em 19-12-2013 17:56, Adam Jensen escreveu: >>> I've been using a KVM switch (USB keyboard and mouse) on a couple of >>> machines recently and I noticed that when the Keyboard, Video, and >>> Mouse connections are switched away from the OpenBSD machine, a USB >>> disconnect is reported (as expected). When switched back, the keyboard >>> and mouse are not reconnected (video is displayed, of course). Once >>> the machine is in this state, I can continue to work with it through >>> ssh but if the machine is "shutdown -hp" or "halt -p" it hangs during >>> the "Syncing disks..." stage and stays there indefinitely (or until >>> the power cable is pulled). The file-systems are not cleanly >>> unmounted. This behavior occurs with an i386 machine and with an amd64 >>> machine. >>> >>> It seems like it might be a serious issue if the USB software stack is >>> preventing a disk sync. >>> >> Do you have all patches on http://www.openbsd.org/errata54.html applied? >> Specifically, I had random issues until I've applied this one: >> http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/003_vnode.patch >> >> Also, try enabling the ddb.panic sysctl flag, it might help debugging >> the issue. A dmesg would help too. >> > > I rebuilt the machines recently and I have not been able to reproduce > the system hang during shutdown. The USB devices still don't reconnect > after being disconnected but both machines have been powering down > without any problems. So on the one hand, huzzah! It works. On the > other hand, wtf? > KVM systems are at best a hack. I do not personally uses them, since they have the tendency to not follow standards and ultimately breaking things. Your dmesg doesn't show anything when you switch back to openbsd? -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Can't start X with dual Radeon graphics
The radeon kms work went in just after 5.4 was tagged. You'll want to use a -current snapshot to get radeondrm support.
Can't start X with dual Radeon graphics
I type startx and this is what I get, log file with xorg.conf and dmesg included xauth: file /home/shaul/.serverauth.20596 does not exist xauth: (stdin):1: bad display name "mynetwork.net:0" in "add" command X.Org X Server 1.14.1 Release Date: 2013-04-17 X Protocol Version 11, Revision 0 Build Operating System: OpenBSD 5.4 amd64 Current Operating System: OpenBSD mynetwork.net 5.4 GENERIC.MP#3 amd64 Build Date: 23 December 2013 02:40:00PM Current version of pixman: 0.30.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 23 16:30:08 2013 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX (II) GPU only supported with KMS, using vesa instead. (II) GPU only supported with KMS, using vesa instead. (II) GPU only supported with KMS, using vesa instead. (II) GPU only supported with KMS, using vesa instead. Fatal server error: no screens found (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error xauth: (argv):1: bad display name "mynetwork.net:0" in "remove" command [ 518.855] (--) checkDevMem: using aperture driver /dev/xf86 [ 518.878] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) [ 519.897] X.Org X Server 1.14.1 Release Date: 2013-04-17 [ 519.897] X Protocol Version 11, Revision 0 [ 519.897] Build Operating System: OpenBSD 5.4 amd64 [ 519.897] Current Operating System: OpenBSD vgj.vc.shawcable.net 5.4 GENERIC.MP#3 amd64 [ 519.897] Build Date: 23 December 2013 02:40:00PM [ 519.897] [ 519.897] Current version of pixman: 0.30.0 [ 519.898]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 519.898] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 519.898] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 23 16:30:08 2013 [ 519.899] (==) Using config file: "/etc/X11/xorg.conf" [ 519.899] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [ 519.900] (==) ServerLayout "X.org Configured" [ 519.900] (**) |-->Screen "Screen0" (0) [ 519.900] (**) | |-->Monitor "Monitor0" [ 519.901] (**) | |-->Device "Card0" [ 519.901] (**) |-->Screen "Screen1" (1) [ 519.901] (**) | |-->Monitor "Monitor1" [ 519.901] (**) | |-->Device "Card1" [ 519.901] (**) |-->Screen "Screen2" (2) [ 519.901] (**) | |-->Monitor "Monitor2" [ 519.902] (**) | |-->Device "Card2" [ 519.902] (**) |-->Screen "Screen3" (3) [ 519.902] (**) | |-->Monitor "Monitor3" [ 519.902] (**) | |-->Device "Card3" [ 519.902] (**) |-->Input Device "Mouse0" [ 519.902] (**) |-->Input Device "Keyboard0" [ 519.903] (==) Disabling SIGIO handlers for input devices [ 519.903] (==) Automatically adding devices [ 519.903] (==) Automatically enabling devices [ 519.903] (==) Not automatically adding GPU devices [ 519.903] (WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist. [ 519.903]Entry deleted from font path. [ 519.903] (**) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/
