Re: Why are there no PKG_PATH defaults?

2014-09-25 Thread Paolo Aglialoro
This setup would be great and make life easier for the average user without
making the story complicated (i.e. a system with downloads working out of
the box without hassles)

Also ports.tar.gz fetch would be one further hassle less.
 Il 24/set/2014 23:36 Romain FABBRI - Alien Consulting 
romain.fab...@alienconsulting.net ha scritto:

 One think that could be done without hammering servers when you install
 from CD would be to add a question to the install script :

 Would you like to define the PKG PATH ? :
 - [1] : propose mirrors based on the timezone given (and then provide a
 menu and you just have to select the proxy)
 - [2] : manually define PKG PATH (type the string, could even check if the
 path seems valid)
 - [3] : nope thanks

 But would it really help much ?

 Romain

 -Message d'origine-
 De : owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] De la part de
 Alexander Hall
 Envoyé : mercredi 24 septembre 2014 23:20
 À : Ville Valkonen
 Cc : PPC Miscellaneous Discussions
 Objet : Re: Why are there no PKG_PATH defaults?

 On 09/24/14 23:09, Ville Valkonen wrote:
  Out of curiosity, what's wrong with the one that installer uses?

 Nothing, however the installer only cares about a mirror if you actually
 install from one of them. If you install from e.g. CD, you don't have a
 selected mirror.

 If you do install or upgrade (I'm pretty sure) from a mirror,
 /etc/pkg.conf will be updated accordingly.

 /Alexander

 
  --
  Regards,
  Ville
 
  On 24 September 2014 19:34, Alexander Hall alexan...@beard.se wrote:
  On September 24, 2014 6:09:04 PM CEST, openda...@hushmail.com wrote:
  Indeed, the installer only creates that if you install from a
  mirror.  Apart from that, as someone else pointed out, which mirror
  should one  choose?
 
  Cool, I didn't know that.
 
  Then, in the event that someone installed via an ISO or some
  pre-defined VM (ie. a DigitalOcean droplets) -- how about a one-time
  script upon first root login to ask for such info?
 
You do not have a `PKG_PATH` set for `pkg_add`. Would you like us
  to set it for you?  (Y/n) y
 
Choose your nearest mirror:
 
1. Continent
2. Whatever
3. ...
 
There is currently no ports collection in `/usr/ports`. Would you
  like us to get it for you? (Y/n)
 
  I can't speak for others, but I'd be terribly annoyed by this.
 
  Also, the script isn't trivial. Feel free to give it a go, share and
 use it for your own sake, but I'd be surprised to see it go in.
 
  /Alexander
 
 
  Thanks!
 
  O.D.
 
  On 24. september 2014 at 1:05 PM, Alexander Hall  wrote:On
  September 24, 2014 12:44:14 PM CEST, openda...@hushmail.com wrote:
  Because /etc/pkg.conf ?
 
  Sorry, no such file over here.
 
  Indeed, the installer only creates that if you install from a mirror.
  Apart from that, as someone else pointed out, which mirror should
  one choose?
 
  /Alexander
 
 
  O.D.
 
  On 23. september 2014 at 1:47 PM, Alexander Hall  wrote:On
  September
  23, 2014 3:00:41 PM CEST, openda...@hushmail.com wrote:
  Hi,
 
  Expanding on the whole
  http://en.wikipedia.org/wiki/Convention_over_configuration thing
  -- why aren't there any sane PKG_PATH defaults? Ie.:
 
  release=$(uname -r)
  architecture=$(uname -p)
 
  export
  PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/${release}/packages/${a
  rchitecture}/
 
  Because /etc/pkg.conf ?
 
  /Alexander
 
 
  Thanks!
 
  O.D.



Re: Why are there no PKG_PATH defaults?

2014-09-25 Thread Ville Valkonen
On 25 September 2014 01:30, Dmitrij D. Czarkoff czark...@gmail.com wrote:
 openda...@hushmail.com said:
 Then, in the event that someone installed via an ISO or some
 pre-defined VM (ie. a DigitalOcean droplets) -- how about a one-time
 script upon first root login to ask for such info?

   You do not have a `PKG_PATH` set for `pkg_add`. Would you like us to
 set it for you?  (Y/n) y

  Choose your nearest mirror:

  1. Continent
  2. Whatever
  3. ...

 FWIW the idea of presenting the list of mirrors suddenly starts to make
 sense, as now there is no browser in base install. But

 Alexander Hall said:
 I can't speak for others, but I'd be terribly annoyed by this.

 I absolutely agree with this sentiment.

 In my opinion, the best way to present list of mirrors would be to
 provide a command for fetching it, either in pkg_add(1) or in root.mail
 (the message root recieves upon completion of installation).  As I
 prefer the latter way, patch to root.mail follows.

 --
 Dmitrij D. Czarkoff

 Index: root.mail
 ===
 RCS file: /var/cvs/src/etc/root/root.mail,v
 retrieving revision 1.104
 diff -u -p -r1.104 root.mail
 --- root.mail   15 Jul 2014 22:05:29 -  1.104
 +++ root.mail   24 Sep 2014 22:05:12 -
 @@ -36,7 +36,9 @@ full list of packages for each architect
 ftp://ftp.openbsd.org/pub/OpenBSD/5.6/packages/

  If you do not find a package you want on the CD, please go look at your
 -nearest FTP mirror site.
 +nearest FTP mirror site.  To get a list of available mirrors, execute:
 +
 + ftp -o - http://ftp.openbsd.org/cgi-bin/ftplist.cgi

  Select your architecture and download the tarballs of your choice.  For 
 example
  to install the emacs package for amd64, execute:

Not that this would be a voting thing but I like the direction where
this is heading. More convenient than writing the address down or
remembering it.

--
Regards,
Ville



Re: how to debug iked failures?

2014-09-25 Thread Artem Falcon
Markus Wernig liste...@wernig.net:

 ...
 But the client is unable to connect to the VPN GW, and I just can't find
 out what's going wrong. Unfortunately there are two ways it is failing:
 
 1) Client sends IKEv2 msg IKE_SA_INIT on Port 500, VPN GW replies with
 IKE_SA_INIT and CertReq, *then client sends IKE_AUTH. But to this packet
 the VPN GW never replies, and the client resends until it times out*. I
 see in the client log that it is selecting and sending the j...@doe.com
 certificate. In the VPN GW logs I get:
 
 Aug  9 08:40:35 tunnel iked[18255]: ikev2_recv: IKE_SA_INIT from
 initiator A.B.C.D:34276 to 10.x.y.z:500 policy 'johndoevpn' id 0, 1048 bytes
 Aug  9 08:40:35 tunnel iked[18255]: ikev2_msg_send: IKE_SA_INIT from
 10.x.y.z:500 to A.B.C.D:34276, 457 bytes
 Aug  9 08:40:35 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator
 A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes
 Aug  9 08:40:39 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator
 A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes
 Aug  9 08:40:46 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator
 A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes
 Aug  9 08:40:59 tunnel iked[18255]: ikev2_recv: IKE_AUTH from initiator
 A.B.C.D:4500 to 10.x.y.z:4500 policy 'johndoevpn' id 1, 2320 bytes
 ...

Hi, folks!

I have the same failing scenario when using BlackBerry 10 client.
OpenIKED is from -current. Ikeauth mode is PSK (yeah, insecure).

Any ideas what it may be and how to fix it?
Thanks.



Re: low power device

2014-09-25 Thread Stuart Henderson
On 2014-09-23, Adam Thompson athom...@athompso.net wrote:
 On 14-09-22 05:03 PM, Stuart Henderson wrote:
 The Atom C2xxx boards run OpenBSD fine. Only glitch I've noticed is 
 the screen background goes red if you VT switch twice (ctrl+alt+f2 
 ctrl+alt+f1). 

 That bug has been around since the 3.x days; the VT code relies on VGA 
 framebuffers initializing something correctly, and increasingly modern 
 VGA implementations don't.  First observed under VMware, so Theo refused 
 to fix it back then, but now observable on a wide variety of servers.

Wide variety - yes, the Aspeed graphics/remote management controllers used
in these machines are showing up all over the place now.

 Cosmetic problem only, and AFAICT only occurs with text-mode display, 
 not the bitmap-based console available now.  Fixing it requires (IIRC - 
 going from memory several years old) resetting all video attributes, 
 preemptively erasing the screen, then resetting to correct and redrawing 
 on every VT switch.  Not too hard, but not a one-line fix, either.

Thanks for the information.



Re: How does pkg_add know I'm tracking -stable?

2014-09-25 Thread Stuart Henderson
On 2014-09-23, Henning Brauer hb-open...@ml.bsws.de wrote:
 pkg_add doesn't know or care about release/stable/current/frankenstein.
 The packages itself are built against a certain set of libraries and
 thus care (and pkg_add checks that). libraries don't change versions
 in -stable, pretty much by definition.
 to a smaller extent the same applies to syscalls and some other
 interfaces, but we get into nitpicking.

 you tell pkg_add a source for your packages, that's it.

The only addition I have to this is that fixes are committed to -stable
ports, so there are updates for these available, but official packages
aren't built for these. They are available from a third party though,
see https://stable.mtier.org/.



Re: Dansguardian not working after updating OBSD Current

2014-09-25 Thread Stuart Henderson
On 2014-09-17, Kaya Saman kayasa...@gmail.com wrote:
 Ok, so this is just a quick follow up.

 Squid started dying too, checking the logs showed not enough file 
 descriptors.

 After looking at both /etc/login.conf openfiles-cur and the sysctl 
 kern.maxfiles limits which were set extremely high to begin with 
 turns out that the:

 ulimit -n

 was only showing as 64.

 Changing that over to a value of 1 (overkill but better safe then 
 sorry), Dansguardian managed to start and now both DG and Squid seem to 
 be online and stable!

 I wonder if it has something to do with the:

 openfiles parameter in /etc/login.conf?


What version were you running before? If it was pre-5.4, this is the
most likely reason:

http://www.openbsd.org/faq/upgrade54.html#login.conf

It has bitten me on a number of occasions.



Re: thinkpad temperature climbs after resume

2014-09-25 Thread frantisek holop
David Hoskin, 24 Sep 2014 12:18:
 On 9/24/14, frantisek holop min...@obiit.org wrote:
  there seems to be a problem with my thinkpad X60s
  after resume: the cpu temperature keeps going up
  gradually, no matter that the machine is idle.
 
 I've experienced this sometimes for the past couple of months on my
 Thinkpad T420.
 
 As a workaround,
 $ apm -H
 $ apm -C
 after resume seems to cure it.

yes, this seems to be working, thanks.
so i guess this goes into /etc/apm/resume

-f
-- 
some people fall for everything and stand for nothing.



Re: quotas grace period none right away

2014-09-25 Thread Craig R. Skinner
On 2014-09-24 Wed 09:22 AM |, Boris Goldberg wrote:
 
   Does this mean you tried and found out (or knew) that disk quotas where
 not going to work for you?
 

At the moment Boris, I'm not using quotas - but did a few years ago.
I don't remember having any problems then.

I guessed Dovecot would work for you by going around any possible issue
due to filesystem delivery  ... temporarily drop privileges to users.



Re: thinkpad temperature climbs after resume

2014-09-25 Thread frantisek holop
frantisek holop, 25 Sep 2014 11:18:
 David Hoskin, 24 Sep 2014 12:18:
  On 9/24/14, frantisek holop min...@obiit.org wrote:
   there seems to be a problem with my thinkpad X60s
   after resume: the cpu temperature keeps going up
   gradually, no matter that the machine is idle.
  
  I've experienced this sometimes for the past couple of months on my
  Thinkpad T420.
  
  As a workaround,
  $ apm -H
  $ apm -C
  after resume seems to cure it.
 
 yes, this seems to be working, thanks.
 so i guess this goes into /etc/apm/resume

but what is making the temperature rise?
the machine is idle, load is 0.0, setperf=0,
cpuspeed is the lowest.

-f
-- 
it has been discovered: research causes cancer in rats.



Re: bioctl weirdness

2014-09-25 Thread Joel Sing
On Wed, 24 Sep 2014, Dan Becker wrote:
 two identical drives... shutdown system remove one turn the system back on

 bioctl shows the partitions as 536871980544 which is 137. something times
 bigger than the drive

 oddly enough it is 512 times the size of the partition

 536871980544/1048578087
 512.

 in a few days I will have all the data moved to another set of drives and
 be more than willing to do some debugging

That looks normal/expected - the size of the partition is in 512-byte blocks, 
the size from bioctl is in bytes. Using the -h option will give you 
human-readable output.

 # bioctl softraid0
 Volume  Status   Size Device
 softraid0 0 Degraded 536871980544 sd1 RAID1
   0 Offline 0 0:0.0   noencl wd0a
   1 Online   536871980544 0:1.0   noencl wd1a
 softraid0 1 Degraded 536871980544 sd2 RAID1
   0 Online   536871980544 1:0.0   noencl wd1b
   1 Offline 0 1:1.0   noencl wd0b
 softraid0 2 Degraded 536871980544 sd3 RAID1
   0 Online   536871980544 2:0.0   noencl wd1d
   1 Offline 0 2:1.0   noencl wd0d
 softraid0 3 Degraded 389781911040 sd4 RAID1
   0 Online   389781911040 3:0.0   noencl wd1e
   1 Offline 0 3:1.0   noencl wd0e

 # disklabel sd1
 # /dev/rsd1c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 1d42ceb8d332594e
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 65270
 total sectors: 1048578087
 boundstart: 0
 boundend: 1048578087
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   10485780480  4.2BSD   4096 327681
   c:   10485780870  unused
 # disklabel sd2
 # /dev/rsd2c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 978b49563ef3223a
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 65270
 total sectors: 1048578087
 boundstart: 0
 boundend: 1048578087
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   10485780480  4.2BSD   4096 327681
   c:   10485780870  unused
 # disklabel sd3
 # /dev/rsd3c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 8e245525f52a55d0
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 65270
 total sectors: 1048578087
 boundstart: 0
 boundend: 1048578087
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   10485780480  4.2BSD   4096 327681
   c:   10485780870  unused
 # disklabel sd4
 # /dev/rsd4c:
 type: SCSI
 disk: SCSI disk
 label: SR RAID 1
 duid: 390559d487f82e16
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 47388
 total sectors: 761292795
 boundstart: 0
 boundend: 761292795
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:7612927360  4.2BSD   4096 327681
   c:7612927950  unused
 # disklabel
 wd0

 # /dev/rwd0c:
 type: ESDI
 disk: ESDI/IDE disk
 label: Hitachi HDS5C302
 duid: 6c7c163233d6b678
 flags:
 bytes/sector: 512
 sectors/track: 63
 tracks/cylinder: 255
 sectors/cylinder: 16065
 cylinders: 243201
 total sectors: 3907029168
 boundstart: 0
 boundend: 3907029168
 drivedata: 0

 16 partitions:
 #size   offset  fstype [fsize bsize  cpg]
   a:   1048578551   64RAID
   b:   1048578615   1048578615RAID
   c:   39070291680  unused
   d:   1048578615   2097157230RAID
   e:761293323   3145735845RAID



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard



Re: bioctl weirdness

2014-09-25 Thread Joel Sing
On Wed, 24 Sep 2014, Dan Becker wrote:
 forgot to add this relevant part

 # bioctl -R /dev/wd0a sd1
 softraid0: wd0a partition too small, at least 536871980544 bytes required
 #

Again, note the bytes vs blocks. That has most likely been fixed already, 
however without a dmesg I have no idea what kernel you're running with. My 
guess is this is a softraid volume with pre-bootable metadata...

 On Tue, Sep 23, 2014 at 7:40 PM, Dan Becker geg...@gmail.com wrote:
  two identical drives... shutdown system remove one turn the system back
  on
 
  bioctl shows the partitions as 536871980544 which is 137. something times
  bigger than the drive
 
  oddly enough it is 512 times the size of the partition
 
  536871980544/1048578087
  512.
 
  in a few days I will have all the data moved to another set of drives and
  be more than willing to do some debugging
 
 
 
  # bioctl softraid0
  Volume  Status   Size Device
  softraid0 0 Degraded 536871980544 sd1 RAID1
0 Offline 0 0:0.0   noencl wd0a
1 Online   536871980544 0:1.0   noencl wd1a
  softraid0 1 Degraded 536871980544 sd2 RAID1
0 Online   536871980544 1:0.0   noencl wd1b
1 Offline 0 1:1.0   noencl wd0b
  softraid0 2 Degraded 536871980544 sd3 RAID1
0 Online   536871980544 2:0.0   noencl wd1d
1 Offline 0 2:1.0   noencl wd0d
  softraid0 3 Degraded 389781911040 sd4 RAID1
0 Online   389781911040 3:0.0   noencl wd1e
1 Offline 0 3:1.0   noencl wd0e
 
  # disklabel sd1
  # /dev/rsd1c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 1d42ceb8d332594e
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 65270
  total sectors: 1048578087
  boundstart: 0
  boundend: 1048578087
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   10485780480  4.2BSD   4096 327681
c:   10485780870  unused
  # disklabel sd2
  # /dev/rsd2c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 978b49563ef3223a
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 65270
  total sectors: 1048578087
  boundstart: 0
  boundend: 1048578087
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   10485780480  4.2BSD   4096 327681
c:   10485780870  unused
  # disklabel sd3
  # /dev/rsd3c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 8e245525f52a55d0
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 65270
  total sectors: 1048578087
  boundstart: 0
  boundend: 1048578087
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   10485780480  4.2BSD   4096 327681
c:   10485780870  unused
  # disklabel sd4
  # /dev/rsd4c:
  type: SCSI
  disk: SCSI disk
  label: SR RAID 1
  duid: 390559d487f82e16
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 47388
  total sectors: 761292795
  boundstart: 0
  boundend: 761292795
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:7612927360  4.2BSD   4096 327681
c:7612927950  unused
  # disklabel
  wd0
 
  # /dev/rwd0c:
  type: ESDI
  disk: ESDI/IDE disk
  label: Hitachi HDS5C302
  duid: 6c7c163233d6b678
  flags:
  bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 243201
  total sectors: 3907029168
  boundstart: 0
  boundend: 3907029168
  drivedata: 0
 
  16 partitions:
  #size   offset  fstype [fsize bsize  cpg]
a:   1048578551   64RAID
b:   1048578615   1048578615RAID
c:   39070291680  unused
d:   1048578615   2097157230RAID
e:761293323   3145735845RAID



-- 

Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard



Re: amd64 snapshot from Sep 17 - isakmpd drops fifo

2014-09-25 Thread mxb
Looks like an old OpenBSD 5.0 install caused this problem.
isakmpd is stable as soon as 5.0 - 5.6 .

//mxb

 On 22 sep 2014, at 23:23, mxb m...@alumni.chalmers.se wrote:
 
 Hey,
 isakmpd seems to lose its FIFO-file in the snapshot from Sep17
 
 [fw1]-[23:16:35]# ipsecctl -f /etc/ipsec.conf
 ipsecctl: ike_ipsec_establish: open(/var/run/isakmpd.fifo): No such file or 
 directory
 
 However the process itself is still running.
 The only way is to restart isakmpd.
 
 Any ideas?
 
 OpenBSD fw1 5.6 GENERIC.MP#383 amd64
 
 //mxb



Safe C

2014-09-25 Thread Matti Karnaattu
I ask here because I don't want to pollute tech@,

you told about those dangerous idioms, is that all knowledge collected
anywhere? Even I know a lot of secure coding practices, I that would be
interesting to read.

And question comes to my mind.. Is there attempts to use this knowledge
in tooling?

Something like using secure version of language, like some C-dialect
that compiled source-to-source to standard, portable C or some skripts
that automatically audit code?



Re: Safe C

2014-09-25 Thread Daniel Cegiełka
http://cyclone.thelanguage.org/
http://en.wikipedia.org/wiki/Cyclone_(programming_language)
http://trevorjim.com/papers/usenix2002.pdf
http://homes.cs.washington.edu/~djg/papers/cyclone-cuj.pdf

Best  regards,
Daniel



Thanks for ksh

2014-09-25 Thread Craig R. Skinner
All the highly skilled work invested in the project, keeping ordinary
users secure, is appreciated.



Re: Thanks for ksh

2014-09-25 Thread Benjamin Baier

Is this because of the newest bash-shellshock (CVE-2014-6271)?

Nevertheless. Thanks for doing things right.

On 09/25/2014 01:48 PM, Craig R. Skinner wrote:

All the highly skilled work invested in the project, keeping ordinary
users secure, is appreciated.




Re: Thanks for ksh

2014-09-25 Thread Maurice McCarthy
On Thu, Sep 25, 2014 at 02:38:32PM +0200 or thereabouts, Benjamin Baier wrote:
 Is this because of the newest bash-shellshock (CVE-2014-6271)?
 
 Nevertheless. Thanks for doing things right.
 
 On 09/25/2014 01:48 PM, Craig R. Skinner wrote:
 All the highly skilled work invested in the project, keeping ordinary
 users secure, is appreciated.
 

http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/



Re: Thanks for ksh

2014-09-25 Thread Christian Weisgerber
On 2014-09-25, Craig R. Skinner skin...@britvault.co.uk wrote:

 All the highly skilled work invested in the project, keeping ordinary
 users secure, is appreciated.

If this is a reference to the ShellShock bash bugs (CVE-2014-6271
CVE-2014-7169), I'd like to point out that, like many bash features,
exported functions originated in Korn shell and the fact that
OpenBSD's /bin/ksh doesn't implement them is a documented shortcoming
of pdksh (see src/bin/ksh/NOTES).

-- 
Christian naddy Weisgerber  na...@mips.inka.de



Re: thinkpad wifi/dhclient issue

2014-09-25 Thread frantisek holop
for everybody out there who likes a good mystery,
the 900 ping issue has happened mid-day as well
for the first time.  it is the equivalent of yanking
the ethernet cable.  so it is not an exclusively
resume connected, but resume (and startup) is
a way to reproduce instantly.

this time however when dhclient went to grab
a new lease, it started spinning and had to be killed.
so i made a debug version and hope to gdb attach
to it.

perhaps it is not a timeout, because network activity
must be present, if i dont start pinging, connections
never come back.  so perhaps it is filling up some
buffer?  what a nice guessing game :)

-f
-- 
my favorite mythical creature?  the honest politician.



Re: bioctl weirdness

2014-09-25 Thread Dan Becker
On Thu, Sep 25, 2014 at 2:37 AM, Joel Sing j...@sing.id.au wrote:

 On Wed, 24 Sep 2014, Dan Becker wrote:
  forgot to add this relevant part
 
  # bioctl -R /dev/wd0a sd1
  softraid0: wd0a partition too small, at least 536871980544 bytes required
  #

 Again, note the bytes vs blocks. That has most likely been fixed
 already,
 however without a dmesg I have no idea what kernel you're running with. My
 guess is this is a softraid volume with pre-bootable metadata...



I was hoping to see someone else having the same issue :)

I will do some more digging but here is the dmesg I didnt attach

OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar  5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2120769536 (2022MB)
avail mem = 2055761920 (1960MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (72 entries)
bios0: vendor Dell Inc. version A01 date 05/24/2005
bios0: Dell Inc. OptiPlex GX520
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET SSDT SSDT SSDT
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5)
PCI5(S5) PCI6(S5) MOU_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) 4 CPU 3.20GHz, 3192.41 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,NXE,LONG
cpu0: 2MB 64b/line 8-way L2 cache
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=0, max=0 (bogus)
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) 4 CPU 3.20GHz, 3192.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,NXE,LONG
cpu1: 2MB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
acpimcfg0 at acpi0 addr 0xf000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 4 (PCI4)
acpiprt1 at acpi0: bus 2 (PCI2)
acpiprt2 at acpi0: bus 3 (PCI3)
acpiprt3 at acpi0: bus 1 (PCI1)
acpiprt4 at acpi0: bus -1 (PCI5)
acpiprt5 at acpi0: bus -1 (PCI6)
acpiprt6 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: FVS, 3200, 3000, 2800 MHz
acpicpu1 at acpi0: FVS, 3200, 3000, 2800 MHz
acpibtn0 at acpi0: VBTN
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82945G Host rev 0x02
ppb0 at pci0 dev 1 function 0 Intel 82945G PCIE rev 0x02: msi
pci1 at ppb0 bus 1
Intel 82945G Video rev 0x02 at pci0 dev 2 function 0 not configured
Intel 82945G Video rev 0x02 at pci0 dev 2 function 1 not configured
ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: msi
pci2 at ppb1 bus 2
bge0 at pci2 dev 0 function 0 Broadcom BCM5751 rev 0x01, BCM5750 A1
(0x4001): apic 8 int 16, address 00:12:3f:64:03:96
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x01: msi
pci3 at ppb2 bus 3
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 8 int 21
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 8 int 22
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 8 int 18
uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 8 int 23
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 8 int 21
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1
pci4 at ppb3 bus 4
radeondrm0 at pci4 dev 0 function 0 ATI Radeon 9200 PRO rev 0x01
drm0 at radeondrm0
radeondrm0: apic 8 int 16
ATI Radeon 9200 PRO Sec rev 0x01 at pci4 dev 0 function 1 not configured
ATT/Lucent FW322 1394 rev 0x70 at pci4 dev 2 function 0 not configured
auich0 at pci0 dev 30 function 2 Intel 82801GB AC97 rev 0x01: apic 8 int
23, ICH7 AC97
ac97: codec id 0x41445374 (Analog Devices AD1981B)
ac97: codec features headphone, 20 bit DAC, No 3D Stereo
audio0 at auich0
pcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01
pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: TSSTcorp, CD/DVDW TS-H652M, 0414 ATAPI
5/cdrom removable
cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
pciide1 at pci0 dev 31 function 2 Intel 82801GB SATA rev 0x01: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 8 int 20 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: Hitachi HDS5C3020ALA632
wd0: 16-sector PIO, LBA48, 1907729MB, 

Re: Thanks for ksh

2014-09-25 Thread sven falempin
On Thu, Sep 25, 2014 at 8:11 AM, Christian Weisgerber
na...@mips.inka.de wrote:
 On 2014-09-25, Craig R. Skinner skin...@britvault.co.uk wrote:

 All the highly skilled work invested in the project, keeping ordinary
 users secure, is appreciated.

 If this is a reference to the ShellShock bash bugs (CVE-2014-6271
 CVE-2014-7169), I'd like to point out that, like many bash features,
 exported functions originated in Korn shell and the fact that
 OpenBSD's /bin/ksh doesn't implement them is a documented shortcoming
 of pdksh (see src/bin/ksh/NOTES).

 --
 Christian naddy Weisgerber  na...@mips.inka.de


Why just focusing on one little piece of the awesomeness ?

Thanks for all the openBSD related projects and the core project !

-- 
-
() ascii ribbon campaign - against html e-mail
/\



X dies after suspend to ram

2014-09-25 Thread Ted W.
I have really enjoyed the last few weeks of running OpenBSD on my 
Thinkpad. Almost everything I need works and or worked right out of the 
box. The only real issue I've noticed is that when the system returns 
from suspend and press ctrl-alt-del to restart X either X or SLiM (not 
sure which) will not come back up. To work around this issue, I switch 
to TTY2, log in as root and run `/etc/rc.d/slim restart`. I've tried 
suspending with and without using slock first and the behavior stays the 
same.


Any input on the matter would be appreciated,

--
Ted W. t...@xy0.org



Re: Atheros AR9380 Panic

2014-09-25 Thread Marc Suttle
Mark,

What card do you plan on using?

Also here is some more information from an interview with Adrian Chadd on
WLAN networking and BSD.  Would there need to be any NDA signed if we just
ported over the FreeBSD Atheros stack?

Interview - http://www.bsdnow.tv/episodes/2014_09_17-the_promised_wlan

I understand we can always use alternatives to this setup.  In an
enterprise env. you would probably never use one of these anyway.  It just
seems that there is quite a bit of development on the FreeBSD side and
why duplicate efforts if an NDA would not be needed for a stack port?  This
would allow OpenBSD to support more wireless chipsets especially on laptop
and home/smb firewalls.

Thanks-
Marc



On Sun, Sep 21, 2014 at 9:18 PM, mark hellewell mark.hellew...@gmail.com
wrote:

 On 21 September 2014 19:49, Stefan Sperling s...@openbsd.org wrote:
  Hunt down an older athn card that works.

 This is what I ended up doing.  I've ordered an older Ubiquiti card which
 I'll hopefully have more luck with.

  Send the one you've got to a developer who's interested in fixing
  support for it.

 I'm more than happy to send the card which was the subject of my thread to
 somebody.  Just let me know who :)

 Cheers,
 Mark



Re: Atheros AR9380 Panic

2014-09-25 Thread Stefan Sperling
On Thu, Sep 25, 2014 at 02:28:47PM -0500, Marc Suttle wrote:
 I understand we can always use alternatives to this setup.  In an
 enterprise env. you would probably never use one of these anyway.  It just
 seems that there is quite a bit of development on the FreeBSD side and
 why duplicate efforts if an NDA would not be needed for a stack port?  This
 would allow OpenBSD to support more wireless chipsets especially on laptop
 and home/smb firewalls.

A port of the FreeBSD driver won't magically be free of bugs so why
would replacing the existing driver be any easier than hunting down
remaining bugs in the existing driver code?



Re: Thanks for ksh

2014-09-25 Thread Andrew Lester
Would the /bin/sh shell in OpenBSD, which is a reimplementation of bash be 
affected by either of these exploits? So happy to learn no action is needed on 
my part for my OpenBSD sever :)

Sent from my iPhone

 On Sep 25, 2014, at 9:10 AM, sven falempin sven.falem...@gmail.com wrote:
 
 On Thu, Sep 25, 2014 at 8:11 AM, Christian Weisgerber
 na...@mips.inka.de wrote:
 On 2014-09-25, Craig R. Skinner skin...@britvault.co.uk wrote:
 
 All the highly skilled work invested in the project, keeping ordinary
 users secure, is appreciated.
 
 If this is a reference to the ShellShock bash bugs (CVE-2014-6271
 CVE-2014-7169), I'd like to point out that, like many bash features,
 exported functions originated in Korn shell and the fact that
 OpenBSD's /bin/ksh doesn't implement them is a documented shortcoming
 of pdksh (see src/bin/ksh/NOTES).
 
 --
 Christian naddy Weisgerber  na...@mips.inka.de
 
 Why just focusing on one little piece of the awesomeness ?
 
 Thanks for all the openBSD related projects and the core project !
 
 -- 
 -
 () ascii ribbon campaign - against html e-mail
 /\



Re: Thanks for ksh

2014-09-25 Thread ian kremlin
On Thu, Sep 25, 2014 at 8:50 PM, Andrew Lester martinblan...@gmail.com wrote:
 Would the /bin/sh shell in OpenBSD, which is a reimplementation of bash be 
 affected by either of these exploits? So happy to learn no action is needed 
 on my part for my OpenBSD sever :)

/bin/sh is an implementation of *the bourne shell*, not the
bourne-again shell (bash). in any case, neither /bin/sh nor ksh are
vulnerable to the recent shellshock vulnerability.