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/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/75dpi/,
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.
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: nsd sendto failure - how to debug?
On 2013-12-23, Adam Thompson athom...@athompso.net 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: dhcpd(8) support for option domain-search
On 2013-12-23, Darren Spruell phatbuck...@gmail.com 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: 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: 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: netstat segfault on -current
On Mon, Dec 23, 2013 at 11:51 PM, Kenneth R Westerback kwesterb...@gmail.com 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 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
Peter, From the resolv.conf man page: http://www.openbsd.org/cgi-bin/man.cgi?query=resolv.confsektion=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 p...@centroid.eu 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 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
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 1:03 PM, Peter J. Philipp p...@centroid.eu 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
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.confsektion=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 p...@centroid.eu 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 3:50 PM, Andy Bradford amb-open...@bradfords.org 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: 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=8802BROADCAST,SIMPLEX,MULTICAST 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST 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 not displayed 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
