--On 23 August 2005 10:44 -0400, Will H. Backman wrote:

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of
Will H. Backman
Sent: Monday, August 22, 2005 2:33 PM
To: Misc OpenBSD
Subject: Re: problem with rtw in hostap mode

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of
> Will H. Backman
> Sent: Monday, August 22, 2005 1:06 PM
> To: Misc OpenBSD
> Subject: problem with rtw in hostap mode
> Data modified on freelist: word 4 of object 0xd09d2a00 size 0xc0
> previous type devbuf (0xdeadbeee != 0xdeadbeef) Data modified on
> freelist: word 4 of object 0xd0a08100 size 0x100 previous type
devbuf
> (0xdeadbeee != 0xdeadbeef) Data modified on freelist: word 4 of
object
> 0xd0a31900 size 0x100 previous type devbuf (0xdeadbeee !=
0xdeadbeef)
>
> --
> Will Backman - Network Administrator
> Coastal Enterprises, Inc.
> http://www.ceimaine.org

Kinda funny how the hex worked out: (0xdeadbeee != 0xdeadbeef)
Perhaps I'm the only one that sees humor it that.

Hmmm...Looking at the man page for rtw, I noticed that the example WEP
key looks very similar to the error messages that I got.  Is something
hard-coded in there?
I wasn't using WEP.

deadbeef is a simple easy-to-type thing when you need some literal value, so it's not surprising it appears in more than one place.

0x1deadbeef1 (example WEP key) != 0xdeadbeef (WEIRD_ADDR in
/usr/src/sys/kern/kern_malloc.c, 'known text to copy into free objects so that modifications after frees can be detected').

I think this means that an operation (probably --) is done on an object which has already been freed (which, if in userland, I imagine would be trapped by the malloc protection recently mentioned).

You'll probably find this happens when you 'ifconfig rtw0 down', it does with ral anyway (http://archives.neohapsis.com/archives/openbsd/2005-05/2421.html), so I guess it's in some common hostap-related code.

Reply via email to