Re: wpa_supplicant segfaults with ath

On Sun, 2005-08-28 at 23:12 -0700, Hanns Hartman wrote:
> Hi,
>    This is my first time posting to the list so if you need more information 
> let me know. also since I have no internet on my freebsd box it is difficult 
> to get all of the verbose output. so here goes.
> 
> I am using freebsd6.0beta2 on an amd64. I am using the src tree from august 
> 21.
> 
> I am trying to associate with a 2wire gateway that was supplied by sbc for 
> my dsl.  I have set the gateway up with wpa-psk encription.
> I am able to connect perfectly fine to this gateway with my ibm t42 but when 
> I try to associate with the gateway using wpa_supplicant I get a 
> segmentation fault after the program reaches "wpa: sending eapol-key 4/4"  
> specifially it faults right after displaying "wpa: rsc - hexdump(len=6): 00 
> 00 00 00 00 00" while using option -d for output.
> 
> when running the supplicant in gdb I get program received SIGSEGV, 
> segmentation fault.  0x000000080082d4d0 in strlen () from /lib/libc.so.6
> 
> if there is anything else needed that might help to explain the problem let 
> me know.  I appoligize for not having more output to post at this time.
> thanks for the help
> Hanns

Thank you for posting this ... as it reminded me i should probably file
a bug report on this. I recently tried to do some investigative work of
my own hoping to find out why my if_ral interface kept acting up when i
bumped into the exact same problem myself.

i can tell you why the segfault happens .. though i am not entirely sure
how it should be fixed properly.

The problem you're experiencing is caused by the ether_ntoa(addr) call
in /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c:280

ether_ntoa expects a "const struct ether_addr" as it's parameter where
in the code the parameter passed is a "const unsigned char*", further
more in that same printf statement seq_len and key_len are being
displayed using "%d" where this should be "%zu" since these are
size_t's. The size_t construct happens a few more times in the code if i
recall correctly.

The actual crash you're experiencing though is caused by the faulty
ether_ntoa argument.

If somebody more knowledgable on this particular subject could have a
closer look at what was actually intended here that would be
appreciated.

-- 
Pascal Hofstee <caelian_at_gmail.com>