Re: Intermittent stops in network traffic with urtw interface

2014-02-06 Thread Brian Curran
On Thu, Feb 06, 2014 at 09:29:37AM -0500, Brad Smith wrote:
 On 06/02/14 9:25 AM, Alexey Suslikov wrote:
 Brian Curran brian at brianpcurran.com writes:
 
 when it stops passing traffic, does issuing ifconfig urtw0 scan help?
 
 
 I test this just now and it seemed to help, although I only started
 seeing ping replies about 10 seconds after issuing the scan. There is
 a similar small delay, though usually not as long, when bringing the
 interface down then up.
 
 Also maybe of note is that the status of the interface as reported by
 ifconfig remains active when it is not receiving any traffic.
 
 I have urtwn(4) which also experience intermittent stops
 with some Access Points (not all).
 
 Looks like it is common problem for urtw(4) and urtwn(4).
 
 and rsu(4).
 

Also perhaps of note is that 'arp -a' hangs indefinitely while the
interface isn't receiving traffic. I did notice however that I am still
seeing RSTP messages from the router during the outage. The arp command
returns some stuff immediately after I bring the interface down then
back up.

Does anyone have any idea as to how this might be troubleshot further?

FWIW, this is the relevant output of 'usbdevs -v':

port 4 addr 2: high speed, power 500 mA, config 1, RTL8187(0x8187),
Realtek(0x0bda), rev 1.00, iSerialNumber 00C0CA753185

I've seen similar behavior on OpenBSD in years past with various
wireless adapters and have never been able to solve it. I don't want to
go back to Debian and iptables :(((.

-Brian



Re: Intermittent stops in network traffic with urtw interface

2014-02-06 Thread Brian Curran
On Thu, Feb 06, 2014 at 01:37:46PM -0800, Philip Guenther wrote:
 On Thu, Feb 6, 2014 at 1:28 PM, Brian Curran br...@brianpcurran.com wrote:
  Also perhaps of note is that 'arp -a' hangs indefinitely while the
  interface isn't receiving traffic.
 
 arp does IP-hostname lookups by default, which probably involve DNS.
 Condition yourself to use the -n option with arp.
 
A ha, good catch. I thought I had a local DNS server configured but
turns out I had a public one in resolv.conf so that explains the hang.



Intermittent stops in network traffic with urtw interface

2014-02-05 Thread Brian Curran
Hello,

I have an Alfa AWUS036H USB wi-fi adapter that I am using on OpenBSD
5.4 amd64. Problem is, sometimes as often as every 15 minutes, the only way to
get the interface to pass traffic is with 'ifconfig urtw0 down 
ifconfig urtw0 up'. I've monitored the traffic with tcpdump to look for
a pattern as to when it stops passing traffic, but I have not been able
to find one.

At the tail of dmesg output the following messages are repeated:

usb_insert_transfer: xfer=0x80568000 not busy 0x4f4e5155
urtw0: could not send frame: INVAL

I am getting a 70-80 dB signal according to ifconfig, which is not
ideal, but should by no means be unusable. I have used the interface
with media set to DS1 mode 11g and OFDM54 mode 11g, with the same
behavior. I am using WPA2-PSK to authenticate to the access point (a
Verizon router).

dmesg.boot has the following lines for the device:

urtw0 at uhub0 port 4 Realtek RTL8187 rev 2.00/1.00 addr 2
urtw0: RTL8187 rev 0x04, RFv2, address 00:c0:ca:75:31:85
urtw0 at uhub0 port 4 vendor 0x0bda RTL8187_Wireless rev 2.00/1.00
addr 2
urtw0: RTL8187 rev 0x04, RFv2, address 00:c0:ca:75:31:85
urtw0: expect 0xe6!! (0xd2)

Is there any way in which I can troubleshoot this? It's becoming a bit
frustrating, but I'd like to keep using OpenBSD! I'm a bit lost at this
point as to how to approach this issue further, so hopefully someone may
be able to point me in the right direction.

Let me know if any additional information would be of help. Thanks!

-Brian



Re: Intermittent stops in network traffic with urtw interface

2014-02-05 Thread Brian Curran
On Wed, Feb 05, 2014 at 10:51:19PM +, Alexey Suslikov wrote:
 Brian Curran brian at brianpcurran.com writes:
 
  
  Hello,
  
  I have an Alfa AWUS036H USB wi-fi adapter that I am using on OpenBSD
  5.4 amd64. Problem is, sometimes as often as every 15 minutes, the only way 
 to
  get the interface to pass traffic is with 'ifconfig urtw0 down 
  ifconfig urtw0 up'. I've monitored the traffic with tcpdump to look for
  a pattern as to when it stops passing traffic, but I have not been able
  to find one.
 
 when it stops passing traffic, does issuing ifconfig urtw0 scan help?
 

I test this just now and it seemed to help, although I only started
seeing ping replies about 10 seconds after issuing the scan. There is
a similar small delay, though usually not as long, when bringing the
interface down then up.

Also maybe of note is that the status of the interface as reported by
ifconfig remains active when it is not receiving any traffic.



Re: 4.6 arriving

2009-10-16 Thread Brian Curran
Received my order of CDs and a t-shirt in New England today!



OS X as an NFS client

2008-08-25 Thread Brian Curran
I have OpenBSD 4.3 configured as an NFS server. portmap=YES and  
nfs_server=YES are both in /etc/rc.conf.local. My exports file has a  
single line: /share 10.0.1.3. /share is chmodded 777.


I can mount the NFS share from my OS X (10.4.9) box with 'mount_nfs - 
P hostname:/share /mnt'. (The -P flag causes mount_nfs to use a  
reserved socket port number.) I would like to be able to mount the  
share through the Finder's GUI, which provides no means of passing  
flags to mount_nfs.


If I understand the man page correctly, it is possible to pass the -n  
flag to mountd on OpenBSD and no longer require clients make mount  
requests from reserved ports. If I manually kill mountd and start it  
with the -n flag (it shows up in ps -aux as mountd -n), I'm still  
not able to mount the share from OS X without using the -P flag. I  
receive the error mount_nfs: /mnt: Permission denied.


I've also played around with maproot and mapall, thinking the  
permission denied error could be related to users, but any  
combination of these options and user options always yielded the same  
result: the -P flag made the difference.


Any help would be much appreciated.

-Brian