Re: NOINET6 by default

[Claudio Jeker]

On Fri, May 16, 2014 at 12:43:52AM -0500, Todd T. Fries wrote:
 Penned by Henning Brauer on 20140516  0:26.37, we have:
 | * Claudio Jeker cje...@diehard.n-r-g.com [2014-05-15 09:33]:
 |  On Wed, May 14, 2014 at 11:29:20PM +0200, Henning Brauer wrote:
 |   so as discussed recently having the inet6 link-local addrs on every
 |   interface by default is stupid and a security risk.
 |   
 |   this diff fixes that. well, really two independent parts.
 |   one: set the NOINET6 flag by default on each and every interface.
 |   two: implement ifconfig if +inet6 to turn inet6 on and assign
 |   the link-local addr.
 |   
 |   this should be transparent for almost all real use cases of inet6
 |   since assigning any inet6 address also resets the flag (and ll is
 |   assigned then as well).
 |   lo0 still gets it's ::1 and fe80::1%lo0 by default.
 |   
 |   the only use case that needs config adoption: people ONLY using
 |   link-local, they will need to put +inet6 in the corresponding
 |   hostname.if file.
 |   
 |   ok?
 |  
 |  To be honest the right fix would be to get rid of IFXF_NOINET6 and
 |  just make it the default. There is no need for such a flag anymore.
 | 
 | very valid point, I'll happily clean that up right after - one thing
 | at a time.
 
 When I travel between networks.. at home with rtsol capable networks ..
 and at e.g. a library that does not have native IPv6 .. I find it invaluable
 to 'zzz' then upon resume 'ifconfig wpi0 -inet6' for the library and then
 'rtsol wpi0' at home.
 
 Just because the new default will be the equivalent of 'ifconfig wpi0 -inet6'
 until configured doesn't mean there isn't a use for clearing it later on as 
 well.
 
 I wish there were an equivalent for IPv4, but at least dhclient clears the old
 address on 'ifconfig wpi0 down' ...
 

I did not talk about -inet6 but about the kernel IFXF_NOINET6 flag.
It is not needed to use a flag on the interface for this. Instead we
handle it all when creating / removing IPv6 addresses on the interface.

In the long run I would like to have a -inet as well so that you can
remove all IPv4 addresses of an interface in a easy way.

-- 
:wq Claudio

Re: better free checking

[Otto Moerbeek]

On Wed, May 14, 2014 at 03:28:02PM -0400, Ted Unangst wrote:

 As I learned the hard way not long ago, free() doesn't detect all
 errors because of the delay mechanism. We can make two improvements.
 
 1. Perform the sanity checking from free_bytes before we insert
 something into the delay array. This detects many kinds of badness
 much sooner.
 
 2. Check that the freed pointer isn't the same as the pointer in the
 delay array. Checking the entire array would be more complete, but
 slower. Randomly crashing immediately is a modest improvement.

I like both. I plan to test this diff this weekend, hoping real-life
does not interfere.

-Otto

 
 Index: malloc.c
 ===
 RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
 retrieving revision 1.163
 diff -u -p -r1.163 malloc.c
 --- malloc.c  12 May 2014 19:02:20 -  1.163
 +++ malloc.c  14 May 2014 19:21:15 -
 @@ -966,16 +966,11 @@ malloc_bytes(struct dir_info *d, size_t 
   return ((char *)bp-page + k);
  }
  
 -
 -/*
 - * Free a chunk, and possibly the page it's on, if the page becomes empty.
 - */
  static void
 -free_bytes(struct dir_info *d, struct region_info *r, void *ptr)
 +check_free_chunk(struct dir_info *d, struct region_info *r, void *ptr)
  {
 - struct chunk_head *mp;
   struct chunk_info *info;
 - int i, listnum;
 + int i;
  
   info = (struct chunk_info *)r-size;
   if (info-canary != d-canary1)
 @@ -992,6 +987,24 @@ free_bytes(struct dir_info *d, struct re
   wrterror(chunk is already free, ptr);
   return;
   }
 +}
 +
 +/*
 + * Free a chunk, and possibly the page it's on, if the page becomes empty.
 + */
 +static void
 +free_bytes(struct dir_info *d, struct region_info *r, void *ptr)
 +{
 + struct chunk_head *mp;
 + struct chunk_info *info;
 + int i, listnum;
 +
 + check_free_chunk(d, r, ptr);
 +
 + info = (struct chunk_info *)r-size;
 +
 + /* Find the chunk number on the page */
 + i = ((uintptr_t)ptr  MALLOC_PAGEMASK)  info-shift;
  
   info-bits[i / MALLOC_BITS] |= 1U  (i % MALLOC_BITS);
   info-free++;
 @@ -1204,9 +1217,14 @@ ofree(void *p)
   if (mopts.malloc_junk  sz  0)
   memset(p, SOME_FREEJUNK, sz);
   if (!mopts.malloc_freenow) {
 + check_free_chunk(g_pool, r, p);
   i = getrbyte()  MALLOC_DELAYED_CHUNK_MASK;
   tmp = p;
   p = g_pool-delayed_chunks[i];
 + if (tmp == p) {
 + wrterror(double free, p);
 + return;
 + }
   g_pool-delayed_chunks[i] = tmp;
   }
   if (p != NULL) {
 

Re: fun with smtpd, (two bugs)

[Creamy]

On Thu, May 15, 2014 at 09:53:39PM +0059, Jason McIntyre wrote:
 On Thu, May 15, 2014 at 10:40:27PM +0200, Frank Brodbeck wrote:
  Hi Jason,
  
  On Wed, May 14, 2014 at 11:16:59PM +0059, Jason McIntyre wrote:
   it's still missing some . also i think we can wholly simplify the
   auth/auth-optional line.
  
  Heh. Thought I found all, thanks for fixing the rest.
  
   -.Op Ic auth | auth-optional | auth Ar authtable | Ic auth-optional Ar 
   authtable
   +.Op Ic auth | auth-optional Aq Ar authtable
  
  the man page sates that:
  
   Both auth and auth-optional accept an optional table as a
   parameter.  When provided, credentials are looked up in this
   table.
  
  but reading the new smtpd.conf(5) gives the impression that authtable is
  mandatory. I haven't checked the code but the following passes a check
  with smtpd -n
  
listen on iwn0 tls auth
listen on em0 tls auth-optional
  
  so it seems to be a valid syntax.
  
 
 it's why i added the word optional to the description. the syntax
 [table] is really ugly, and is hard to understand.

Why is it ugly and hard to understand???  I think it's rather obvious
that [] signifies optional and  signifies the name of a table.

 we could do it, but i don;t want to. sometimes it's better to sacrifice
 being a million percent correct for clarity.

Eh?  How can giving incorrect information help clarity?  That's a bit
strange.

-- 
Creamy! 3

Re: run(4) firmware update; please test

[Dinar Talypov]

Hi,

I have tested with D-Link  DWA-140 rev B2G:

run0 at uhub0 port 1 Ralink 11n Adapter rev 1.10/1.01 addr 2
run0: MAC/BBP RT3071 (rev 0x021C), RF RT3022 (MIMO 2T2R), address
14:d6:4d:49:73:4e

with this diff nothing works. It doesn't find any access point.



2014-05-15 19:32 GMT+04:00 Fred open...@crowsons.com:

 On 05/15/14 10:35, Stefan Sperling wrote:

 This firmware update to version 0.33 is a prequisite for
 newer run(4) devices which are not yet supported.

 Can active users of run(4) devices please test this update
 to make sure no regressions are introduced for already working
 devices? I don't have a supported run(4) device to test with.

   cd /usr/src/sys/dev/microcode/rum  # yes, rum with m
   patch  this-patch
   make obj
   make depend
   sudo make install

 I've obtained permission from Mediatek/Ralink to distribute this
 firmware update under the terms in /etc/firmware/run-license.


 Hi,

 Tested with the at TP-Link TL-WN727N USB Wifi device:

 May 15 13:24:46 x41 /bsd: run0 at uhub0 port 4 Ralink 802.11 n WLAN rev
 2.00/1.01 addr 3
 May 15 13:24:46 x41 /bsd: run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020
 (MIMO 1T1R), address 74:ea:3a:8a:b6:8f

 No regressions with this diff.

 Thanks

 Fred

umsm support for Alcatel OneTouch L100V

[Łukasz Ratajski]

Attached is a diff for umsm+man page which enables support for the
Alcatel OneTouch L100V USB 2G/3G/LTE modem, known in Germany as Telekom
SpeedStick LTE II.

The storage part has to be ejected first. Connectivity tested with
userland ppp on amd64. Patch is against 5.5-STABLE.

umass1 at uhub0 port 5 configuration 1 interface 2 USBModem Mobile
Broad Band rev 2.00/0.00 addr 3
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd2 at scsibus3 targ 1 lun 0: USBModem, MMC Storage, 2.31 SCSI2
0/direct removable
umsm2 at uhub0 port 5 configuration 1 interface 3 USBModem Mobile Broad
Band rev 2.00/0.00 addr 3
ucom2 at umsm2
umsm3 at uhub0 port 5 configuration 1 interface 4 USBModem Mobile Broad
Band rev 2.00/0.00 addr 3
ucom3 at umsm3

Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.96
diff -u -p -u -p -r1.96 umsm.c
--- umsm.c  13 Dec 2013 17:43:07 -  1.96
+++ umsm.c  16 May 2014 10:20:16 -
@@ -251,6 +251,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM }, 0},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM_2 }, 0},
+   {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM_3 }, 0},

{{ USB_VENDOR_TOSHIBA, USB_PRODUCT_TOSHIBA_HSDPA }, 0},

Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.623
diff -u -p -u -p -r1.623 usbdevs
--- usbdevs 15 Feb 2014 02:16:57 -  1.623
+++ usbdevs 16 May 2014 10:20:16 -
@@ -3969,6 +3969,7 @@ product SYNTECH CIPHERLAB100  0x1000  Ciph
 /* TCT Mobile products */
 product TCTMOBILE UMSM 0x  Modem mode
 product TCTMOBILE UMSM_2   0x0017  Modem mode
+product TCTMOBILE UMSM_3   0x011e  Modem mode
 product TCTMOBILE UMASS0xf000  Storage mode

 /* Tangtop products */
Index: umsm.4
===
RCS file: /cvs/src/share/man/man4/umsm.4,v
retrieving revision 1.88
diff -u -p -u -p -r1.88 umsm.4
--- umsm.4  16 Jul 2013 16:05:49 -  1.88
+++ umsm.4  16 May 2014 10:20:42 -
@@ -37,6 +37,7 @@ driver:
 .Bl -column Medion Mobile S4012 (Huawei E1550 OEM) Bus -offset 6n
 .It Em Device Ta Em Bus
 .It Li AirPrime PC5220 Ta CardBus
+.It Li Alcatel One Touch L100V Ta USB
 .It Li Alcatel One Touch X060 Ta USB
 .It Li Alcatel One Touch X200 Ta USB
 .It Li Alcatel One Touch X210 Ta USB

With best regards,

Łukasz

-- 
PGP Key 0x7F0B40F4 | 9E98 D004 EEF8 1B49 38DD  AE51 162A 0644 7F0B 40F4



signature.asc
Description: OpenPGP digital signature

Re: run(4) firmware update; please test

[Stefan Sperling]

On Fri, May 16, 2014 at 02:44:10PM +0400, Dinar Talypov wrote:
 Hi,
 
 I have tested with D-Link  DWA-140 rev B2G:
 
 run0 at uhub0 port 1 Ralink 11n Adapter rev 1.10/1.01 addr 2
 run0: MAC/BBP RT3071 (rev 0x021C), RF RT3022 (MIMO 2T2R), address
 14:d6:4d:49:73:4e
 
 with this diff nothing works. It doesn't find any access point.

Are you able to help me debug this by providing more details?

Are you really sure it's the firmware update that's causing the problem?

Are you able to try your run(4) device with FreeBSD-current (10 isn't
new enough)? They claim to support your device and use the updated firmware.

Re: umsm support for Alcatel OneTouch L100V

[David Coppa]

On Fri, May 16, 2014 at 1:02 PM, Łukasz Ratajski
lukasz.rataj...@t-online.de wrote:
 Attached is a diff for umsm+man page which enables support for the
 Alcatel OneTouch L100V USB 2G/3G/LTE modem, known in Germany as Telekom
 SpeedStick LTE II.

 The storage part has to be ejected first. Connectivity tested with
 userland ppp on amd64. Patch is against 5.5-STABLE.

Is it ejecting automatically?
I mean, is this using {{ USB_VENDOR_TCTMOBILE,
USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3} ?

If so, then it's ok with me.

ciao,
David

 umass1 at uhub0 port 5 configuration 1 interface 2 USBModem Mobile
 Broad Band rev 2.00/0.00 addr 3
 umass1: using SCSI over Bulk-Only
 scsibus3 at umass1: 2 targets, initiator 0
 sd2 at scsibus3 targ 1 lun 0: USBModem, MMC Storage, 2.31 SCSI2
 0/direct removable
 umsm2 at uhub0 port 5 configuration 1 interface 3 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 ucom2 at umsm2
 umsm3 at uhub0 port 5 configuration 1 interface 4 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 ucom3 at umsm3

 Index: umsm.c
 ===
 RCS file: /cvs/src/sys/dev/usb/umsm.c,v
 retrieving revision 1.96
 diff -u -p -u -p -r1.96 umsm.c
 --- umsm.c  13 Dec 2013 17:43:07 -  1.96
 +++ umsm.c  16 May 2014 10:20:16 -
 @@ -251,6 +251,7 @@ static const struct umsm_type umsm_devs[
 {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
 {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM }, 0},
 {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM_2 }, 0},
 +   {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM_3 }, 0},

 {{ USB_VENDOR_TOSHIBA, USB_PRODUCT_TOSHIBA_HSDPA }, 0},

 Index: usbdevs
 ===
 RCS file: /cvs/src/sys/dev/usb/usbdevs,v
 retrieving revision 1.623
 diff -u -p -u -p -r1.623 usbdevs
 --- usbdevs 15 Feb 2014 02:16:57 -  1.623
 +++ usbdevs 16 May 2014 10:20:16 -
 @@ -3969,6 +3969,7 @@ product SYNTECH CIPHERLAB100  0x1000  Ciph
  /* TCT Mobile products */
  product TCTMOBILE UMSM 0x  Modem mode
  product TCTMOBILE UMSM_2   0x0017  Modem mode
 +product TCTMOBILE UMSM_3   0x011e  Modem mode
  product TCTMOBILE UMASS0xf000  Storage mode

  /* Tangtop products */
 Index: umsm.4
 ===
 RCS file: /cvs/src/share/man/man4/umsm.4,v
 retrieving revision 1.88
 diff -u -p -u -p -r1.88 umsm.4
 --- umsm.4  16 Jul 2013 16:05:49 -  1.88
 +++ umsm.4  16 May 2014 10:20:42 -
 @@ -37,6 +37,7 @@ driver:
  .Bl -column Medion Mobile S4012 (Huawei E1550 OEM) Bus -offset 6n
  .It Em Device Ta Em Bus
  .It Li AirPrime PC5220 Ta CardBus
 +.It Li Alcatel One Touch L100V Ta USB
  .It Li Alcatel One Touch X060 Ta USB
  .It Li Alcatel One Touch X200 Ta USB
  .It Li Alcatel One Touch X210 Ta USB

 With best regards,

 Łukasz

 --
 PGP Key 0x7F0B40F4 | 9E98 D004 EEF8 1B49 38DD  AE51 162A 0644 7F0B 40F4

Re: run(4) firmware update; please test

[Raphael Graf]

On Thu, May 15, 2014 11:35 am, Stefan Sperling wrote:
 This firmware update to version 0.33 is a prequisite for
 newer run(4) devices which are not yet supported.

 Can active users of run(4) devices please test this update
 to make sure no regressions are introduced for already working
 devices? I don't have a supported run(4) device to test with.


This one keeps working as expected:

run0 at uhub13 port 1 Belkin Belkin Enhanced Wireless USB Adapter rev 
2.00/1.01 addr 2
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
00:22:75:f5:df:b8

Re: run(4) firmware update; please test

[Gerhard Roth]

On Fri, 16 May 2014 13:07:24 +0200 Stefan Sperling s...@openbsd.org wrote:
 On Fri, May 16, 2014 at 02:44:10PM +0400, Dinar Talypov wrote:
  Hi,
  
  I have tested with D-Link  DWA-140 rev B2G:
  
  run0 at uhub0 port 1 Ralink 11n Adapter rev 1.10/1.01 addr 2
  run0: MAC/BBP RT3071 (rev 0x021C), RF RT3022 (MIMO 2T2R), address
  14:d6:4d:49:73:4e
  
  with this diff nothing works. It doesn't find any access point.
 
 Are you able to help me debug this by providing more details?
 
 Are you really sure it's the firmware update that's causing the problem?
 
 Are you able to try your run(4) device with FreeBSD-current (10 isn't
 new enough)? They claim to support your device and use the updated firmware.
 


He's using a model that requires a firmware-blob different from the one
of all other testers (run-rt2870 vs. run-rt3071). That might explain,
why he's the only one who got troubles with the new FW.

On topic: new FW works fine on a SparkLAN WPER-150GN:

   run0 at uhub1 port 3 Ralink 802.11 n WLAN rev 2.00/1.01 addr 3
   run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
00:0e:8e:xx:xx:xx

Re: NOINET6 by default

[Henning Brauer]

* Claudio Jeker cje...@diehard.n-r-g.com [2014-05-16 08:06]:
 On Fri, May 16, 2014 at 12:43:52AM -0500, Todd T. Fries wrote:
  When I travel between networks.. at home with rtsol capable networks ..
  and at e.g. a library that does not have native IPv6 .. I find it invaluable
  to 'zzz' then upon resume 'ifconfig wpi0 -inet6' for the library and then
  'rtsol wpi0' at home.

-inet6 stays no matter what, wether that does setifxflags IFXF_NOINET6
in the back or just removes all inet6 addrs is transparent to the
user.

how to add linklocal back without the flag is another question, need
to come up with something in that case (that is definately not a hard
problem tho), since eui64 effectively does nothing but whine if it
cannot find a link-local...

 I did not talk about -inet6 but about the kernel IFXF_NOINET6 flag.
 It is not needed to use a flag on the interface for this. Instead we
 handle it all when creating / removing IPv6 addresses on the interface.

yup.

 In the long run I would like to have a -inet as well so that you can
 remove all IPv4 addresses of an interface in a easy way.

yeah, that makes sense. probably comes for free when implementing
-inet6 without IFXF_NOINET6.

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual  Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

Re: umsm support for Alcatel OneTouch L100V

[David Coppa]

On Fri, May 16, 2014 at 3:31 PM, Łukasz Ratajski
lukasz.rataj...@t-online.de wrote:
 Am 16.05.2014 13:10, schrieb David Coppa:
 On Fri, May 16, 2014 at 1:02 PM, Łukasz Ratajski
 lukasz.rataj...@t-online.de wrote:
 Attached is a diff for umsm+man page which enables support for the
 Alcatel OneTouch L100V USB 2G/3G/LTE modem, known in Germany as Telekom
 SpeedStick LTE II.

 The storage part has to be ejected first. Connectivity tested with
 userland ppp on amd64. Patch is against 5.5-STABLE.

 Is it ejecting automatically?
 I mean, is this using {{ USB_VENDOR_TCTMOBILE,
 USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3} ?

 If so, then it's ok with me.

 I had to eject the umass part manually in order to access the modem.
 Now, after some inspection, I am certain that I found the solution.
 After manual ejection the usbdevs output changed as following:

 - port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
 Band(0xf017), USBModem(0x1bbb), rev 0.00
 + port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
 Band(0x011e), USBModem(0x1bbb), rev 0.00

 Apparently the umass device uses a different product ID, so I decided to
 add it to usbdevs, and change umsm.c accordingly. Plugged in, and dmesg
 shows this (without any manual interaction):

 umsm0 at uhub0 port 5 configuration 1 interface 0 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 umsm1 at uhub0 port 5 configuration 1 interface 1 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 umsm0 detached
 umsm1 detached
 umsm0 at uhub0 port 5 configuration 1 interface 0 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 ucom0 at umsm0
 umsm1 at uhub0 port 5 configuration 1 interface 1 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 ucom1 at umsm1
 umass1 at uhub0 port 5 configuration 1 interface 2 USBModem Mobile
 Broad Band rev 2.00/0.00 addr 3
 umass1: using SCSI over Bulk-Only
 scsibus3 at umass1: 2 targets, initiator 0
 sd2 at scsibus3 targ 1 lun 0: USBModem, MMC Storage, 2.31 SCSI2
 0/direct removable
 umsm2 at uhub0 port 5 configuration 1 interface 3 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 ucom2 at umsm2
 umsm3 at uhub0 port 5 configuration 1 interface 4 USBModem Mobile Broad
 Band rev 2.00/0.00 addr 3
 ucom3 at umsm3

 Firing up ppp confirmed that it's working. Here is the revised patch:

It's committed.

Thanks  ciao!
David

Re: run(4) firmware update; please test

[Alexey Suslikov]

Stefan Sperling stsp at openbsd.org writes:

 Are you able to try your run(4) device with FreeBSD-current (10 isn't
 new enough)? They claim to support your device and use the updated 
firmware.

Please take a look at my (unfinished) attempt to bring
MediaTek/Ralink RT5370/RT5372 support to run(4).

http://marc.info/?l=openbsd-techm=138903287819764w=2

Re: [PATCH 1/2] use correct size_t formatter, include string.h for memcmp

[Joel Sing]

Thanks for the diff - I've committed a more comprehensive diff that makes it 
clean with WARNINGS=Yes.

On Mon, 12 May 2014, bust...@gmail.com wrote:
 From: Brent Cook bust...@gmail.com

 ---
  base64/base64test.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/base64/base64test.c b/base64/base64test.c
 index a7d167e..fedbdcd 100644
 --- a/base64/base64test.c
 +++ b/base64/base64test.c
 @@ -19,6 +19,7 @@

  #include err.h
  #include stdio.h
 +#include string.h

  #define BUF_SIZE 128

 @@ -205,7 +206,7 @@ base64_encoding_test(int test_no, struct base64_test
 *bt, int test_nl)

   len = BIO_write(bio_mem, bt-in, bt-in_len);
   if (len != bt-in_len) {
 - fprintf(stderr, FAIL: test %i - only wrote %i out of %i 
 + fprintf(stderr, FAIL: test %i - only wrote %i out of %zu 
   characters\n, test_no, len, bt-in_len);
   failure = 1;
   goto done;
 @@ -296,7 +297,7 @@ base64_decoding_test(int test_no, struct base64_test
 *bt, int test_nl) len = BIO_read(bio_mem, buf, BUF_SIZE);
   if (len != bt-valid_len  (bt-in_len != 0 || len != -1)) {
   fprintf(stderr, FAIL: test %i - decoding resulted in %i 
 - characters instead of %i\n, test_no, len, bt-valid_len);
 + characters instead of %zu\n, test_no, len, bt-valid_len);
   fprintf(stderr,   input: );
   for (i = 0; i  inlen; i++)
   fprintf(stderr, %c, input[i]);



-- 

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

Re: [PATCH 2/2] include openssl/evp.h for OPENSSL_add_all_algorithms_noconf()

[Joel Sing]

On Mon, 12 May 2014, bust...@gmail.com wrote:
 From: Brent Cook bust...@gmail.com

 ---
  rc4/rc4test.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/rc4/rc4test.c b/rc4/rc4test.c
 index a0b08a6..c4d34b1 100644
 --- a/rc4/rc4test.c
 +++ b/rc4/rc4test.c
 @@ -60,6 +60,7 @@
  #include stdlib.h
  #include string.h

 +#include openssl/evp.h
  #include openssl/rc4.h
  #include openssl/sha.h

Committed. Thanks.
-- 

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

Re: umsm support for Alcatel OneTouch L100V

[Creamy]

On Fri, May 16, 2014 at 03:31:41PM +0200, ??ukasz Ratajski wrote:
 Am 16.05.2014 13:10, schrieb David Coppa:
  On Fri, May 16, 2014 at 1:02 PM, ??ukasz Ratajski
  lukasz.rataj...@t-online.de wrote:
  Attached is a diff for umsm+man page which enables support for the
  Alcatel OneTouch L100V USB 2G/3G/LTE modem, known in Germany as Telekom
  SpeedStick LTE II.
 
  The storage part has to be ejected first. Connectivity tested with
  userland ppp on amd64. Patch is against 5.5-STABLE.
  
  Is it ejecting automatically?
  I mean, is this using {{ USB_VENDOR_TCTMOBILE,
  USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3} ?
  
  If so, then it's ok with me.
 
 I had to eject the umass part manually in order to access the modem.
 Now, after some inspection, I am certain that I found the solution.
 After manual ejection the usbdevs output changed as following:
 
 - port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
 Band(0xf017), USBModem(0x1bbb), rev 0.00
 + port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
 Band(0x011e), USBModem(0x1bbb), rev 0.00
 
 Apparently the umass device uses a different product ID, so I decided to

It's not unusual - I've seen Huaweii devices that behave similarly.  They
have a bitmap register that enables and disabled various aspects of the
hardware, for example the micro-sd card slot and the built in flash
storage.  With an AT command that I've long since forgotten, you can
clobber it and make it a 'dumb' device that only acts as a modem, (yay!
exactly what I want), and at that point it changes it's usb device ID,
(to one that is already supported by OpenBSD).

But this isn't the strangest USB thing I've seen - that was a usb HUB
that typed things at the boot prompt, behaving like a keyboard.

Actually, this worries me a bit, because how do we know that any innocent
USB device, a mouse or a keyboard for example, doesn't have firmware that
tells it to emulate a disk for 10 seconds after power is applied if it
sees that a BIOS is initialising it, and then change to an innocent device
afterwards?

-- 
Creamy! 3

mountd: handle unresolvable hosts in a netgroup

[Todd C. Miller]

Currently, if you have a host netgroup with an unresolvable hostname,
the file system will not be exported to any of the netgroup members.
This is because we don't zero out grp before reusing it when a host
is unresolvable.

 - todd

Index: sbin/mountd/mountd.c
===
RCS file: /home/cvs/openbsd/src/sbin/mountd/mountd.c,v
retrieving revision 1.74
diff -u -r1.74 mountd.c
--- sbin/mountd/mountd.c22 Apr 2014 20:25:16 -  1.74
+++ sbin/mountd/mountd.c16 May 2014 16:52:09 -
@@ -875,6 +875,8 @@
if (has_host) {
grp-gr_next = get_grp();
grp = grp-gr_next;
+   } else {
+   memset(grp, 0, sizeof(*grp));
}
if (netgrp) {
if (hst == NULL) {

Re: mountd: handle unresolvable hosts in a netgroup

[Kenneth Westerback]

On 16 May 2014 12:54, Todd C. Miller todd.mil...@courtesan.com wrote:
 Currently, if you have a host netgroup with an unresolvable hostname,
 the file system will not be exported to any of the netgroup members.
 This is because we don't zero out grp before reusing it when a host
 is unresolvable.

  - todd

 Index: sbin/mountd/mountd.c
 ===
 RCS file: /home/cvs/openbsd/src/sbin/mountd/mountd.c,v
 retrieving revision 1.74
 diff -u -r1.74 mountd.c
 --- sbin/mountd/mountd.c22 Apr 2014 20:25:16 -  1.74
 +++ sbin/mountd/mountd.c16 May 2014 16:52:09 -
 @@ -875,6 +875,8 @@
 if (has_host) {
 grp-gr_next = get_grp();
 grp = grp-gr_next;
 +   } else {
 +   memset(grp, 0, sizeof(*grp));
 }
 if (netgrp) {
 if (hst == NULL) {


Reading the code leads me to the same conclusion. ok krw@.

 Ken

Re: better free checking

[Otto Moerbeek]

On Wed, May 14, 2014 at 03:28:02PM -0400, Ted Unangst wrote:

 As I learned the hard way not long ago, free() doesn't detect all
 errors because of the delay mechanism. We can make two improvements.
 
 1. Perform the sanity checking from free_bytes before we insert
 something into the delay array. This detects many kinds of badness
 much sooner.
 
 2. Check that the freed pointer isn't the same as the pointer in the
 delay array. Checking the entire array would be more complete, but
 slower. Randomly crashing immediately is a modest improvement.

I think you can return i in check_free_chunk() and use that in free_bytes().

Like this,

-Otto


Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.163
diff -u -p -r1.163 malloc.c
--- malloc.c12 May 2014 19:02:20 -  1.163
+++ malloc.c16 May 2014 18:00:19 -
@@ -966,16 +966,11 @@ malloc_bytes(struct dir_info *d, size_t 
return ((char *)bp-page + k);
 }
 
-
-/*
- * Free a chunk, and possibly the page it's on, if the page becomes empty.
- */
-static void
-free_bytes(struct dir_info *d, struct region_info *r, void *ptr)
+static int
+check_free_chunk(struct dir_info *d, struct region_info *r, void *ptr)
 {
-   struct chunk_head *mp;
struct chunk_info *info;
-   int i, listnum;
+   int i;
 
info = (struct chunk_info *)r-size;
if (info-canary != d-canary1)
@@ -986,12 +981,27 @@ free_bytes(struct dir_info *d, struct re
 
if ((uintptr_t)ptr  ((1U  (info-shift)) - 1)) {
wrterror(modified chunk-pointer, ptr);
-   return;
+   return i;
}
if (info-bits[i / MALLOC_BITS]  (1U  (i % MALLOC_BITS))) {
wrterror(chunk is already free, ptr);
-   return;
+   return i;
}
+   return i;
+}
+
+/*
+ * Free a chunk, and possibly the page it's on, if the page becomes empty.
+ */
+static void
+free_bytes(struct dir_info *d, struct region_info *r, void *ptr)
+{
+   struct chunk_head *mp;
+   struct chunk_info *info;
+   int i, listnum;
+
+   info = (struct chunk_info *)r-size;
+   i = check_free_chunk(d, r, ptr);
 
info-bits[i / MALLOC_BITS] |= 1U  (i % MALLOC_BITS);
info-free++;
@@ -1204,9 +1214,14 @@ ofree(void *p)
if (mopts.malloc_junk  sz  0)
memset(p, SOME_FREEJUNK, sz);
if (!mopts.malloc_freenow) {
+   check_free_chunk(g_pool, r, p);
i = getrbyte()  MALLOC_DELAYED_CHUNK_MASK;
tmp = p;
p = g_pool-delayed_chunks[i];
+   if (tmp == p) {
+   wrterror(double free, p);
+   return;
+   }
g_pool-delayed_chunks[i] = tmp;
}
if (p != NULL) {

make kernel build with EHCI_DEBUG

[Jean-Philippe Ouellet]

There are a bunch of nearby printfs which start with : ... without
a devname. I'm not sure which one is preferred, so here's both ways.


Index: ehci_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/ehci_cardbus.c,v
retrieving revision 1.17
diff -u -p -r1.17 ehci_cardbus.c
--- ehci_cardbus.c  15 Apr 2013 09:23:00 -  1.17
+++ ehci_cardbus.c  16 May 2014 17:47:18 -
@@ -130,7 +130,7 @@ ehci_cardbus_attach(struct device *paren
 
/* Disable interrupts, so we don't get any spurious ones. */
sc-sc.sc_offs = EREAD1(sc-sc, EHCI_CAPLENGTH);
-   DPRINTF((: offs=%d, devname, sc-sc.sc_offs));
+   DPRINTF((%s: offs=%d, devname, sc-sc.sc_offs));
EOWRITE2(sc-sc, EHCI_USBINTR, 0);
 
sc-sc_ih = cardbus_intr_establish(cc, cf, ca-ca_intrline,


Index: ehci_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/ehci_cardbus.c,v
retrieving revision 1.17
diff -u -p -r1.17 ehci_cardbus.c
--- ehci_cardbus.c  15 Apr 2013 09:23:00 -  1.17
+++ ehci_cardbus.c  16 May 2014 18:05:38 -
@@ -130,7 +130,7 @@ ehci_cardbus_attach(struct device *paren
 
/* Disable interrupts, so we don't get any spurious ones. */
sc-sc.sc_offs = EREAD1(sc-sc, EHCI_CAPLENGTH);
-   DPRINTF((: offs=%d, devname, sc-sc.sc_offs));
+   DPRINTF((: offs=%d, sc-sc.sc_offs));
EOWRITE2(sc-sc, EHCI_USBINTR, 0);
 
sc-sc_ih = cardbus_intr_establish(cc, cf, ca-ca_intrline,

Re: make kernel build with EHCI_DEBUG

[Stefan Sperling]

On Fri, May 16, 2014 at 02:16:10PM -0400, Jean-Philippe Ouellet wrote:
 There are a bunch of nearby printfs which start with : ... without
 a devname. I'm not sure which one is preferred, so here's both ways.
 
 
 Index: ehci_cardbus.c
 ===
 RCS file: /cvs/src/sys/dev/cardbus/ehci_cardbus.c,v
 retrieving revision 1.17
 diff -u -p -r1.17 ehci_cardbus.c
 --- ehci_cardbus.c15 Apr 2013 09:23:00 -  1.17
 +++ ehci_cardbus.c16 May 2014 17:47:18 -
 @@ -130,7 +130,7 @@ ehci_cardbus_attach(struct device *paren
  
   /* Disable interrupts, so we don't get any spurious ones. */
   sc-sc.sc_offs = EREAD1(sc-sc, EHCI_CAPLENGTH);
 - DPRINTF((: offs=%d, devname, sc-sc.sc_offs));
 + DPRINTF((%s: offs=%d, devname, sc-sc.sc_offs));
   EOWRITE2(sc-sc, EHCI_USBINTR, 0);
  
   sc-sc_ih = cardbus_intr_establish(cc, cf, ca-ca_intrline,
 
 
 Index: ehci_cardbus.c
 ===
 RCS file: /cvs/src/sys/dev/cardbus/ehci_cardbus.c,v
 retrieving revision 1.17
 diff -u -p -r1.17 ehci_cardbus.c
 --- ehci_cardbus.c15 Apr 2013 09:23:00 -  1.17
 +++ ehci_cardbus.c16 May 2014 18:05:38 -
 @@ -130,7 +130,7 @@ ehci_cardbus_attach(struct device *paren
  
   /* Disable interrupts, so we don't get any spurious ones. */
   sc-sc.sc_offs = EREAD1(sc-sc, EHCI_CAPLENGTH);
 - DPRINTF((: offs=%d, devname, sc-sc.sc_offs));
 + DPRINTF((: offs=%d, sc-sc.sc_offs));
   EOWRITE2(sc-sc, EHCI_USBINTR, 0);
  
   sc-sc_ih = cardbus_intr_establish(cc, cf, ca-ca_intrline,

mpi@ and myself came up with this some days ago, but then I forgot
about committing it.

Index: ehci_cardbus.c
===
RCS file: /cvs/src/sys/dev/cardbus/ehci_cardbus.c,v
retrieving revision 1.17
diff -u -p -r1.17 ehci_cardbus.c
--- ehci_cardbus.c  15 Apr 2013 09:23:00 -  1.17
+++ ehci_cardbus.c  11 May 2014 21:53:02 -
@@ -51,14 +51,6 @@
 #include dev/usb/ehcireg.h
 #include dev/usb/ehcivar.h
 
-#ifdef EHCI_DEBUG
-#define DPRINTF(x) if (ehcidebug) printf x
-extern int ehcidebug;
-#else
-#define DPRINTF(x)
-#endif
-
-
 intehci_cardbus_match(struct device *, void *, void *);
 void   ehci_cardbus_attach(struct device *, struct device *, void *);
 intehci_cardbus_detach(struct device *, int);
@@ -130,7 +122,6 @@ ehci_cardbus_attach(struct device *paren
 
/* Disable interrupts, so we don't get any spurious ones. */
sc-sc.sc_offs = EREAD1(sc-sc, EHCI_CAPLENGTH);
-   DPRINTF((: offs=%d, devname, sc-sc.sc_offs));
EOWRITE2(sc-sc, EHCI_USBINTR, 0);
 
sc-sc_ih = cardbus_intr_establish(cc, cf, ca-ca_intrline,

ifconfig segmentation fault

[Giancarlo Razzolini]

Hi,

I was configuring one new interface in one of my new machines, and I
disabled ipv6 with -inet6 as I always do. But I handcrafted the
hostname.if file and forgot to put a NONE in the broadcast address. This
caused the ifconfig to segfault when called from the /etc/netstart
script. For example:

/etc/hostname.if:
inet 1.2.3.4 255.255.255.0 -inet6

result: ifconfig segfault.

/etc/hostname.if:
inet 1.2.4.5 255.255.255.0 NONE -inet6

result: everything work as usual.

   I am using 5.5 stable. Can't post the dmesg right now, but will
do this night. I will also take a look at the core dump, see if I can
pinpoint where are the bits responsible for the segfault.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

[Kenneth Westerback]

On 16 May 2014 15:00, Giancarlo Razzolini grazzol...@gmail.com wrote:
 Hi,

 I was configuring one new interface in one of my new machines, and I
 disabled ipv6 with -inet6 as I always do. But I handcrafted the
 hostname.if file and forgot to put a NONE in the broadcast address. This
 caused the ifconfig to segfault when called from the /etc/netstart
 script. For example:

 /etc/hostname.if:
 inet 1.2.3.4 255.255.255.0 -inet6

 result: ifconfig segfault.

 /etc/hostname.if:
 inet 1.2.4.5 255.255.255.0 NONE -inet6

 result: everything work as usual.

I am using 5.5 stable. Can't post the dmesg right now, but will
 do this night. I will also take a look at the core dump, see if I can
 pinpoint where are the bits responsible for the segfault.

 Cheers,

 --
 Giancarlo Razzolini
 GPG: 4096R/77B981BC


Did a quick test on amd64 -current using run0, and got 'bad value: -inet6'.

 Ken

Re: ifconfig segmentation fault

[Giancarlo Razzolini]

Em 16-05-2014 16:45, Kenneth Westerback escreveu:
 On 16 May 2014 15:00, Giancarlo Razzolini grazzol...@gmail.com wrote:
 Hi,

 I was configuring one new interface in one of my new machines, and I
 disabled ipv6 with -inet6 as I always do. But I handcrafted the
 hostname.if file and forgot to put a NONE in the broadcast address. This
 caused the ifconfig to segfault when called from the /etc/netstart
 script. For example:

 /etc/hostname.if:
 inet 1.2.3.4 255.255.255.0 -inet6

 result: ifconfig segfault.

 /etc/hostname.if:
 inet 1.2.4.5 255.255.255.0 NONE -inet6

 result: everything work as usual.

I am using 5.5 stable. Can't post the dmesg right now, but will
 do this night. I will also take a look at the core dump, see if I can
 pinpoint where are the bits responsible for the segfault.

 Cheers,

 --
 Giancarlo Razzolini
 GPG: 4096R/77B981BC

 Did a quick test on amd64 -current using run0, and got 'bad value: -inet6'.

  Ken
As I mentioned, I'm running 5.5 stable. So this might got fixed in
current, I'm taking a look at the CVS commits right now to see if it was
fixed. But, funny thing, I've managed to get another segmentation fault,
this time from command line. While trying to replicate the bug in
another machine, I've wrongly typed:

ifconfig em4 -inet

Instead of:

ifconfig em4 -inet6

The first command also caused a segfault. As promised, follows a dmesg
of one of the machines where I reproduced this segfault:

OpenBSD 5.5 (GENERIC) #0: Fri Apr 25 13:07:59 CEST 2014
   
r...@stable-55-amd64.mtier.org:/binpatchng/work-binpatch55-amd64/src/sys/arch/amd64/compile/GENERIC
real mem = 520085504 (495MB)
avail mem = 497729536 (474MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf09f0 (10 entries)
bios0: vendor Bochs version Bochs date 01/01/2011
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
mpbios at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: QEMU Virtual CPU version 2.0.0, 2813.47 MHz
cpu0:
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,POPCNT,NXE,LONG,LAHF,SVM,ABM,SSE4A
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
pciide0 at pci0 dev 1 function 1 Intel 82371SB IDE rev 0x00: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: QEMU HARDDISK
wd0: 16-sector PIO, LBA48, 30720MB, 62914560 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 2.0. ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: irq 11
piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: irq 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 Cirrus Logic CL-GD5446 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00:
Virtio Network Device
vio0 at virtio0: address 52:54:00:ab:f7:d6
virtio0: irq 11
virtio1 at pci0 dev 4 function 0 Qumranet Virtio Memory rev 0x00:
Virtio Memory Balloon Device
viomb0 at virtio1
virtio1: irq 11
virtio2 at pci0 dev 5 function 0 Qumranet Virtio Network rev 0x00:
Virtio Network Device
vio1 at virtio2: address 52:54:00:4f:65:af
virtio2: irq 10
virtio3 at pci0 dev 6 function 0 Qumranet Virtio Network rev 0x00:
Virtio Network Device
vio2 at virtio3: address 52:54:00:42:d8:ff
virtio3: irq 10
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 1: density unknown
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (ae6577d8240a3c26.a) swap on wd0b dump on wd0b
clock: unknown CMOS layout

This one is my test machine, and yes, it's virtualized. 

Re: ifconfig segmentation fault

[Stuart Henderson]

On 2014/05/16 17:12, Giancarlo Razzolini wrote:
 As I mentioned, I'm running 5.5 stable. So this might got fixed in
 current, I'm taking a look at the CVS commits right now to see if it was
 fixed. But, funny thing, I've managed to get another segmentation fault,
 this time from command line. While trying to replicate the bug in
 another machine, I've wrongly typed:
 
 ifconfig em4 -inet
 
 Instead of:
 
 ifconfig em4 -inet6

I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
then if you can trigger it do a 'bt'.

Re: ifconfig segmentation fault

[Luis Coronado]

On my OBSD 5.5 box I cannot reproduce:

/etc/hostname.bge0
inet 192.168.2.170 255.255.255.0  -inet6

# sh /etc/netstart
bge0

ifconfig: -inet6: bad value

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 = 8563326976 (8166MB)
avail mem = 8326762496 (7941MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcf79c000 (58 entries)
bios0: vendor Dell Inc. version 1.4.1 date 08/03/2009
bios0: Dell Inc. PowerEdge T100
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET MCFG SLIC TCPA SSDT SSDT SSDT
acpi0: wakeup devices PCI0(S5) COMP(S5)
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) Dual CPU E2220 @ 2.40GHz, 2400.45 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,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
cpu0: 1MB 64b/line 4-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) Dual CPU E2220 @ 2.40GHz, 2400.08 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,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
cpu1: 1MB 64b/line 4-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEX1)
acpiprt2 at acpi0: bus 2 (SBE0)
acpiprt3 at acpi0: bus 3 (SBE4)
acpiprt4 at acpi0: bus 4 (SBE5)
acpiprt5 at acpi0: bus 5 (COMP)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
cpu0: Enhanced SpeedStep 2400 MHz: speeds: 2400, 2200, 2000, 1800, 1600,
1400, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 3200/3210 Host rev 0x01
ppb0 at pci0 dev 1 function 0 Intel 3200/3210 PCIE rev 0x01: msi
pci1 at ppb0 bus 1
uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x02: apic 2 int 17
uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x02: apic 2 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb1 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02
pci4 at ppb3 bus 4
bge0 at pci4 dev 0 function 0 Broadcom BCM5722 rev 0x00, BCM5755 C0
(0xa200): msi, address 00:23:8b:64:75:70
brgphy0 at bge0 phy 1: BCM5722 10/100/1000baseT PHY, rev. 0
uhci2 at pci0 dev 29 function 0 Intel 82801I USB rev 0x02: apic 2 int 21
uhci3 at pci0 dev 29 function 1 Intel 82801I USB rev 0x02: apic 2 int 20
uhci4 at pci0 dev 29 function 2 Intel 82801I USB rev 0x02: apic 2 int 21
ehci1 at pci0 dev 29 function 7 Intel 82801I USB rev 0x02: apic 2 int 21
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x92
pci5 at ppb4 bus 5
re0 at pci5 dev 0 function 0 Realtek 8169 rev 0x10: RTL8169/8110SB
(0x1000), apic 2 int 18, address c8:3a:35:d8:bb:a5
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 3
radeondrm0 at pci5 dev 5 function 0 ATI ES1000 rev 0x02
drm0 at radeondrm0
radeondrm0: apic 2 int 19
pcib0 at pci0 dev 31 function 0 Intel 82801IR LPC rev 0x02
pciide0 at pci0 dev 31 function 2 Intel 82801I SATA rev 0x02: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 2 int 23 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: WDC WD1601ABYS-18C0A0
wd0: 16-sector PIO, LBA48, 152587MB, 31250 sectors
atapiscsi0 at pciide0 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: PLDS, DVD-ROM DH-16D3S, SD11 ATAPI 5/cdrom
removable
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 5
atapiscsi1 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi1: 2 targets
cd1 at scsibus1 targ 0 lun 0: HL-DT-ST, DVDRAM GH22NS40, NL00 ATAPI
5/cdrom removable
cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 5
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1
usb6 at uhci4: 

Re: ifconfig segmentation fault

[Giancarlo Razzolini]

Em 16-05-2014 17:18, Stuart Henderson escreveu:
 On 2014/05/16 17:12, Giancarlo Razzolini wrote:
 As I mentioned, I'm running 5.5 stable. So this might got fixed in
 current, I'm taking a look at the CVS commits right now to see if it was
 fixed. But, funny thing, I've managed to get another segmentation fault,
 this time from command line. While trying to replicate the bug in
 another machine, I've wrongly typed:

 ifconfig em4 -inet

 Instead of:

 ifconfig em4 -inet6
 I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
 i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
 then if you can trigger it do a 'bt'.

Yes, I was able to repeat:

(gdb) set args em4 -inet
(gdb) run
Starting program: /sbin/ifconfig em4 -inet
warning: shared library handler failed to enable breakpoint

Program received signal SIGSEGV, Segmentation fault.
0x0043607a in ?? ()
(gdb) bt
#0  0x0043607a in ?? ()
#1  0x00412835 in ?? ()
#2  0x00412ac5 in ?? ()
#3  0x00404919 in ?? ()
#4  0x0040aaba in ?? ()
#5  0x00400301 in ?? ()
#6  0x0003 in ?? ()
#7  0x7f7beb28 in ?? ()
#8  0x7f7beb37 in ?? ()
#9  0x7f7beb3b in ?? ()
#10 0x in ?? ()

Very odd. If you want I can also attach the core dump.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

[Giancarlo Razzolini]

Em 16-05-2014 17:18, Stuart Henderson escreveu:
 On 2014/05/16 17:12, Giancarlo Razzolini wrote:
 As I mentioned, I'm running 5.5 stable. So this might got fixed in
 current, I'm taking a look at the CVS commits right now to see if it was
 fixed. But, funny thing, I've managed to get another segmentation fault,
 this time from command line. While trying to replicate the bug in
 another machine, I've wrongly typed:

 ifconfig em4 -inet

 Instead of:

 ifconfig em4 -inet6
 I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
 i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
 then if you can trigger it do a 'bt'.

Just to be thrill, here follows my sha256sum of my /sbin/ifconfig:

SHA256 (/sbin/ifconfig) =
e1b9688f2ebf5a278408c49ac13e35479a96b883ff9891ada141470d55a1b158

If anyone running stable can check it yours is the same, I appreciate.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

[Luis Coronado]

# sha256
/sbin/ifconfig

SHA256 (/sbin/ifconfig) =
e1b9688f2ebf5a278408c49ac13e35479a96b883ff9891ada141470d55a1b158

and mine does not crash.

-luis



On Fri, May 16, 2014 at 2:29 PM, Giancarlo Razzolini
grazzol...@gmail.comwrote:

 Em 16-05-2014 17:18, Stuart Henderson escreveu:
  On 2014/05/16 17:12, Giancarlo Razzolini wrote:
  As I mentioned, I'm running 5.5 stable. So this might got fixed in
  current, I'm taking a look at the CVS commits right now to see if it was
  fixed. But, funny thing, I've managed to get another segmentation fault,
  this time from command line. While trying to replicate the bug in
  another machine, I've wrongly typed:
 
  ifconfig em4 -inet
 
  Instead of:
 
  ifconfig em4 -inet6
  I'm unable to repeat this on amd64 5.5 release. Can you repeat it under
 gdb?
  i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and
 'run',
  then if you can trigger it do a 'bt'.
 
 Just to be thrill, here follows my sha256sum of my /sbin/ifconfig:

 SHA256 (/sbin/ifconfig) =
 e1b9688f2ebf5a278408c49ac13e35479a96b883ff9891ada141470d55a1b158

 If anyone running stable can check it yours is the same, I appreciate.

 Cheers,

 --
 Giancarlo Razzolini
 GPG: 4096R/77B981BC

PC-122 keyboard

[Creamy]

Hi Miod,

(cc'ing tech@ to see if anybody else has one of these keyboards)

Is this the correct way to go about adding a sub-keymap to place
the VT switch commands on dedicated keys?  For local use, I just
hacked up the standard keymap :-))).  Likewise the necessary
changes to wskbd.c to process these keys without control and alt
held down is missing, because I just did a bad hack on my local
copy to make it work, (and break all other keyboards).

For those who are interested, the 122 key mainframe keyboards
have F13-F24 on the top row, (which are supported by default
in the OpenBSD console), and 10 extra function keys on the left.

There is also an extra key in the cursor section, instead of
an inverted T, the cursor movement keys are in the shape of a
plus sign, (+), with a key in the middle.

Oh, and page up, page down, and escape are in the 'correct'
positions for real programmers.


--- wsksymdef.h.origFri May 16 20:36:22 2014
+++ wsksymdef.h Fri May 16 20:44:18 2014
@@ -507,6 +507,7 @@
 #define KS_Henkan  0xf115  /* Alias for Henkan_Mode */
 #define KS_Muhenkan0xf116  /* Cancel Conversion */
 #define KS_Mode_Lock   0xf117
+#define KS_Repeat  0xf118  /* Repeat key */
 
 /*
  * Group 2 (keypad) character in low byte
@@ -743,6 +744,7 @@
 #define KB_METAESC 0x0020 /* generate ESC prefix on ALT-key */
 #define KB_IOPENER 0x0040 /* f1-f12 - ESC,f1-f11 */
 #define KB_MACHDEP 0x0080 /* machine dependent */
+#define KB_TERM122 0x0100 /* commands to dedicated keys on 122 
key terminal keyboards */
 #define KB_APPLE   0x0001 /* Apple specific layout */
 #define KB_DEFAULT 0x8000 /* (attach-only) default layout */
 
@@ -784,6 +786,7 @@
{ KB_DVORAK,dvorak }, \
{ KB_METAESC,   metaesc }, \
{ KB_IOPENER,   iopener }, \
+   { KB_TERM122,   term122 }, \
{ KB_MACHDEP,   machdep }, \
{ KB_APPLE, apple }
 

--- wskbdmap_mfii.c.origFri May 16 20:35:04 2014
+++ wskbdmap_mfii.c Fri May 16 20:54:42 2014
@@ -172,6 +172,25 @@
 
 #if !defined(WSKBD_NO_INTL_LAYOUTS)
 
+static const keysym_t pckbd_keydesc_term122[] = {
+/*  pos  command   normal  shifted */
+
+KC(1), KS_Escape,
+KC(59),KS_f1,
+KC(60),KS_f2,
+KC(61),KS_f3,
+KC(62),KS_f4,
+KC(63),KS_f5,
+KC(64),KS_f6,
+KC(113),  KS_Cmd_Screen0,
+KC(118),  KS_Cmd_Screen1,
+KC(114),  KS_Cmd_Screen2,
+KC(127),  KS_Cmd_Screen3,
+KC(116),  KS_Cmd_Screen4,
+KC(109),  KS_Cmd_Screen5,
+KC(117),  KS_Cmd_Debugger,
+};
+
 static const keysym_t pckbd_keydesc_de[] = {
 /*  pos  normalshifted altgr   shift-altgr */
 KC(3),   KS_2, KS_quotedbl,KS_twosuperior,
@@ -1096,6 +1115,7 @@
KBD_MAP(KB_US | KB_DVORAK,  KB_US,  pckbd_keydesc_us_dvorak),
KBD_MAP(KB_US | KB_SWAPCTRLCAPS, KB_US, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_US | KB_IOPENER, KB_US,  pckbd_keydesc_iopener),
+   KBD_MAP(KB_UK | KB_TERM122, KB_UK,  pckbd_keydesc_term122),
KBD_MAP(KB_UK | KB_SWAPCTRLCAPS, KB_UK, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_JP | KB_SWAPCTRLCAPS, KB_JP, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_FR | KB_SWAPCTRLCAPS, KB_FR, pckbd_keydesc_swapctrlcaps),

-- 
Creamy! 3

Re: ifconfig segmentation fault

[Creamy]

On Fri, May 16, 2014 at 05:29:10PM -0300, Giancarlo Razzolini wrote:
 Em 16-05-2014 17:18, Stuart Henderson escreveu:
  On 2014/05/16 17:12, Giancarlo Razzolini wrote:
  As I mentioned, I'm running 5.5 stable. So this might got fixed in
  current, I'm taking a look at the CVS commits right now to see if it was
  fixed. But, funny thing, I've managed to get another segmentation fault,
  this time from command line. While trying to replicate the bug in
  another machine, I've wrongly typed:
 
  ifconfig em4 -inet
 
  Instead of:
 
  ifconfig em4 -inet6
  I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
  i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
  then if you can trigger it do a 'bt'.
 
 Just to be thrill, here follows my sha256sum of my /sbin/ifconfig:
 
 SHA256 (/sbin/ifconfig) =
 e1b9688f2ebf5a278408c49ac13e35479a96b883ff9891ada141470d55a1b158
 
 If anyone running stable can check it yours is the same, I appreciate.

It matches -release from the official CD.

-- 
Creamy! 3

Re: ifconfig segmentation fault

[Stuart Henderson]

On 2014/05/16 17:26, Giancarlo Razzolini wrote:
 Em 16-05-2014 17:18, Stuart Henderson escreveu:
  On 2014/05/16 17:12, Giancarlo Razzolini wrote:
  As I mentioned, I'm running 5.5 stable. So this might got fixed in
  current, I'm taking a look at the CVS commits right now to see if it was
  fixed. But, funny thing, I've managed to get another segmentation fault,
  this time from command line. While trying to replicate the bug in
  another machine, I've wrongly typed:
 
  ifconfig em4 -inet
 
  Instead of:
 
  ifconfig em4 -inet6
  I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
  i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
  then if you can trigger it do a 'bt'.
 
 Yes, I was able to repeat:
 
 (gdb) set args em4 -inet
 (gdb) run
 Starting program: /sbin/ifconfig em4 -inet
 warning: shared library handler failed to enable breakpoint
 
 Program received signal SIGSEGV, Segmentation fault.
 0x0043607a in ?? ()
 (gdb) bt
 #0  0x0043607a in ?? ()
 #1  0x00412835 in ?? ()
 #2  0x00412ac5 in ?? ()
 #3  0x00404919 in ?? ()
 #4  0x0040aaba in ?? ()
 #5  0x00400301 in ?? ()
 #6  0x0003 in ?? ()
 #7  0x7f7beb28 in ?? ()
 #8  0x7f7beb37 in ?? ()
 #9  0x7f7beb3b in ?? ()
 #10 0x in ?? ()
 
 Very odd. If you want I can also attach the core dump.
 
 Cheers,
 
 -- 
 Giancarlo Razzolini
 GPG: 4096R/77B981BC
 

Oh, static stripped binary of course... worth a try with this,
if you have 5.5-stable sources on the system:

cd /usr/src/sbin/ifconfig
make obj
make clean
make DEBUG=-g -O0
gdb obj/ifconfig
[...]

Re: ifconfig segmentation fault

[Giancarlo Razzolini]

Em 16-05-2014 18:15, Stuart Henderson escreveu:
 On 2014/05/16 17:26, Giancarlo Razzolini wrote:
 Em 16-05-2014 17:18, Stuart Henderson escreveu:
 On 2014/05/16 17:12, Giancarlo Razzolini wrote:
 As I mentioned, I'm running 5.5 stable. So this might got fixed in
 current, I'm taking a look at the CVS commits right now to see if it was
 fixed. But, funny thing, I've managed to get another segmentation fault,
 this time from command line. While trying to replicate the bug in
 another machine, I've wrongly typed:

 ifconfig em4 -inet

 Instead of:

 ifconfig em4 -inet6
 I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb?
 i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run',
 then if you can trigger it do a 'bt'.

 Yes, I was able to repeat:

 (gdb) set args em4 -inet
 (gdb) run
 Starting program: /sbin/ifconfig em4 -inet
 warning: shared library handler failed to enable breakpoint

 Program received signal SIGSEGV, Segmentation fault.
 0x0043607a in ?? ()
 (gdb) bt
 #0  0x0043607a in ?? ()
 #1  0x00412835 in ?? ()
 #2  0x00412ac5 in ?? ()
 #3  0x00404919 in ?? ()
 #4  0x0040aaba in ?? ()
 #5  0x00400301 in ?? ()
 #6  0x0003 in ?? ()
 #7  0x7f7beb28 in ?? ()
 #8  0x7f7beb37 in ?? ()
 #9  0x7f7beb3b in ?? ()
 #10 0x in ?? ()

 Very odd. If you want I can also attach the core dump.

 Cheers,

 -- 
 Giancarlo Razzolini
 GPG: 4096R/77B981BC

 Oh, static stripped binary of course... worth a try with this,
 if you have 5.5-stable sources on the system:

 cd /usr/src/sbin/ifconfig
 make obj
 make clean
 make DEBUG=-g -O0
 gdb obj/ifconfig
 [...]

In this system I don't. But will do ASAP. I'm starting to believe that
this has something to do with virtualization.

Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

[Héctor Luis Gimbatti]

/etc/hostname.if
Inet 1.2.3.4 255.255.255.0 NONE -inet6

# ksh /etc/netstart
# ifconfig 
## NO PROBLEM

/etc/hostname.if
Inet 1.2.3.4 255.255.255.0 -inet6

# ksh /etc/netstart
ifconfig: -inet6: bad value
## NO SEGMENTATION FAULT


So, IMHO, if there is any problem at all, of course it should be due to the 
''correctness'' of the line in /etc/hostname.
We should check if the parsing of such file is OK (by that I mean of course to 
check for the correctness of the values )

But AFAIK , and As Far I've tested /etc/hostname.if for different, WRONG LINES, 
it has never cause ifconfig to segfault.

Re: ifconfig segmentation fault

[Giancarlo Razzolini]

Em 16-05-2014 18:19, Héctor Luis Gimbatti escreveu:
 /etc/hostname.if
 Inet 1.2.3.4 255.255.255.0 NONE -inet6

 # ksh /etc/netstart
 # ifconfig 
 ## NO PROBLEM

 /etc/hostname.if
 Inet 1.2.3.4 255.255.255.0 -inet6

 # ksh /etc/netstart
 ifconfig: -inet6: bad value
 ## NO SEGMENTATION FAULT


 So, IMHO, if there is any problem at all, of course it should be due to the 
 ''correctness'' of the line in /etc/hostname.
 We should check if the parsing of such file is OK (by that I mean of course 
 to check for the correctness of the values )

 But AFAIK , and As Far I've tested /etc/hostname.if for different, WRONG 
 LINES, it has never cause ifconfig to segfault.




Anyone else running OpenBSD under linux kvm can test this? I was only
able to reproduce it on virtualized machines. My test on a physical one
wasn't on 5.5 and it didn't segfault, as I wrongly stated before. I was
so eager to test it, that I wasn't logged on the right machine, sorry.
Stuart, I didn't had a chance yet to recompile ifconfig following your
instructions, but I'll try to ASAP. Really seem to be something with
virtualization itself. I've tried on three OpenBSD installs that are
under kvm, and all of them segfaulted. All of them are amd64, I didn't
tried with an i386 installation.


Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC

Re: ifconfig segmentation fault

[sven falempin]

On Fri, May 16, 2014 at 10:15 PM, Giancarlo Razzolini
grazzol...@gmail.comwrote:

 Em 16-05-2014 18:19, Héctor Luis Gimbatti escreveu:
  /etc/hostname.if
  Inet 1.2.3.4 255.255.255.0 NONE -inet6
 
  # ksh /etc/netstart
  # ifconfig
  ## NO PROBLEM
 
  /etc/hostname.if
  Inet 1.2.3.4 255.255.255.0 -inet6
 
  # ksh /etc/netstart
  ifconfig: -inet6: bad value
  ## NO SEGMENTATION FAULT
 
 
  So, IMHO, if there is any problem at all, of course it should be due to
 the ''correctness'' of the line in /etc/hostname.
  We should check if the parsing of such file is OK (by that I mean of
 course to check for the correctness of the values )
 
  But AFAIK , and As Far I've tested /etc/hostname.if for different, WRONG
 LINES, it has never cause ifconfig to segfault.
 
 
 
 
 Anyone else running OpenBSD under linux kvm can test this? I was only
 able to reproduce it on virtualized machines. My test on a physical one
 wasn't on 5.5 and it didn't segfault, as I wrongly stated before. I was
 so eager to test it, that I wasn't logged on the right machine, sorry.
 Stuart, I didn't had a chance yet to recompile ifconfig following your
 instructions, but I'll try to ASAP. Really seem to be something with
 virtualization itself. I've tried on three OpenBSD installs that are
 under kvm, and all of them segfaulted. All of them are amd64, I didn't
 tried with an i386 installation.


 Cheers,

 --
 Giancarlo Razzolini
 GPG: 4096R/77B981BC


Linux / kvm is not a precise statement enough,

for example on recent version the network can completly stop under load
(but is very fast) while older release remain stable.

What qemu version ? what (linux)kernel version ?


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

Re: ifconfig segmentation fault

[Giancarlo Razzolini]

Em 16-05-2014 23:48, sven falempin escreveu:



 On Fri, May 16, 2014 at 10:15 PM, Giancarlo Razzolini
 grazzol...@gmail.com mailto:grazzol...@gmail.com wrote:

 Em 16-05-2014 18:19, Héctor Luis Gimbatti escreveu:
  /etc/hostname.if
  Inet 1.2.3.4 255.255.255.0 NONE -inet6
 
  # ksh /etc/netstart
  # ifconfig
  ## NO PROBLEM
 
  /etc/hostname.if
  Inet 1.2.3.4 255.255.255.0 -inet6
 
  # ksh /etc/netstart
  ifconfig: -inet6: bad value
  ## NO SEGMENTATION FAULT
 
 
  So, IMHO, if there is any problem at all, of course it should be
 due to the ''correctness'' of the line in /etc/hostname.
  We should check if the parsing of such file is OK (by that I
 mean of course to check for the correctness of the values )
 
  But AFAIK , and As Far I've tested /etc/hostname.if for
 different, WRONG LINES, it has never cause ifconfig to segfault.
 
 
 
 
 Anyone else running OpenBSD under linux kvm can test this? I was only
 able to reproduce it on virtualized machines. My test on a
 physical one
 wasn't on 5.5 and it didn't segfault, as I wrongly stated before.
 I was
 so eager to test it, that I wasn't logged on the right machine, sorry.
 Stuart, I didn't had a chance yet to recompile ifconfig following your
 instructions, but I'll try to ASAP. Really seem to be something with
 virtualization itself. I've tried on three OpenBSD installs that are
 under kvm, and all of them segfaulted. All of them are amd64, I didn't
 tried with an i386 installation.


 Cheers,

 --
 Giancarlo Razzolini
 GPG: 4096R/77B981BC


 Linux / kvm is not a precise statement enough,

 for example on recent version the network can completly stop under
 load (but is very fast) while older release remain stable.

 What qemu version ? what (linux)kernel version ?


 -- 
 -
 () ascii ribbon campaign - against html e-mail 
 /\ 
It's a ubuntu 14.04 running kernel 3.13.0 and the qemu-kvm version is
2.0.0. I believe that on Monday I'll be able to test it more and even
compile ifconfig, as Stuart mentioned. Just to be clear, my machines
work perfectly I don't have any problems at all.


Cheers,

-- 
Giancarlo Razzolini
GPG: 4096R/77B981BC