Hi Adrian,
On Sat, 7 Jun 2014 21:41:10 -0400
Adrian Chadd wrote:
> Can you pleease chase this up with me next week? We need to find/fix
> these issues. I'm not running v6 at home; I can easily flip that on
> when I get home next week.
>
sorry for being late. I was travelling myself until yester
Hi Adrian,
On Sat, 7 Jun 2014 21:41:10 -0400
Adrian Chadd wrote:
> Can you pleease chase this up with me next week? We need to find/fix
should be possible.
> these issues. I'm not running v6 at home; I can easily flip that on
> when I get home next week.
You only need to turn it on and the ma
Hi,
Can you pleease chase this up with me next week? We need to find/fix
these issues. I'm not running v6 at home; I can easily flip that on
when I get home next week.
THanks,
-a
On 7 June 2014 21:21, Erich Dollansky wrote:
> Hi Adrian,
>
> On Fri, 23 May 2014 09:01:36 -0700
> Adrian Chadd
Hi Adrian,
On Fri, 23 May 2014 09:01:36 -0700
Adrian Chadd wrote:
> a photo will be fine. :-)
>
did the photos help?
I did not have any problems anymore since I deactivated IPV6.
Erich
>
> -a
>
>
> On 23 May 2014 08:59, Erich Dollansky
> wrote:
> > Hi,
> >
> > On Fri, 23 May 2014 08:36:31
Hi Adrian,
On Fri, 23 May 2014 09:01:36 -0700
Adrian Chadd wrote:
> a photo will be fine. :-)
>
The photos are here:
http:/www.alogt.com/freebsd/network/SAM_0379.JPG
The first photo shows a hang of IWN after the machine successfully
started. The remaining photos show the backtrace.
http:/www
a photo will be fine. :-)
-a
On 23 May 2014 08:59, Erich Dollansky wrote:
> Hi,
>
> On Fri, 23 May 2014 08:36:31 -0700
> Adrian Chadd wrote:
>
>> Ok, it's a null pointer dereference (based on the address you posted)
>> and it's ipv6 related. That's .. odd.
>>
>> Can you provide a backtrace fr
Hi,
On Fri, 23 May 2014 08:36:31 -0700
Adrian Chadd wrote:
> Ok, it's a null pointer dereference (based on the address you posted)
> and it's ipv6 related. That's .. odd.
>
> Can you provide a backtrace from the crash?
>
I can try tomorrow. Am I right that I can only take photos of the
screen
Ok, it's a null pointer dereference (based on the address you posted)
and it's ipv6 related. That's .. odd.
Can you provide a backtrace from the crash?
-a
On 23 May 2014 04:13, Erich Dollansky wrote:
> Hi,
>
> On Tue, 8 Apr 2014 20:40:01 -0700
> Adrian Chadd wrote:
>
>> I'm not sure. I'd re
Hi,
On Tue, 8 Apr 2014 20:40:01 -0700
Adrian Chadd wrote:
> I'm not sure. I'd really like to see what the story is with
> coexistence somehow.
>
I did some more investigations and came to the result that iwn crashes
in 'in6_ifattach_linklocal'.
When I disable ipv6, it all works fine. I did sev
Hi,
On Tue, 8 Apr 2014 20:40:01 -0700
Adrian Chadd wrote:
> I'm not sure. I'd really like to see what the story is with
> coexistence somehow.
>
I upgraded my machine to this:
FreeBSD X220.alogt.com 10.0-STABLE FreeBSD 10.0-STABLE #36 r266578: Fri
May 23 16:56:23 WITA 2014
er...@x220.alogt.com
Hi,
On Tue, 8 Apr 2014 20:40:01 -0700
Adrian Chadd wrote:
> I'm not sure. I'd really like to see what the story is with
> coexistence somehow.
one other note. I start my machine randomly with a kernel built from
sources dated 26.03.14. I never faced this problem with these sources.
Erich
>
>
Hi,
On Tue, 8 Apr 2014 20:40:01 -0700
Adrian Chadd wrote:
> I'm not sure. I'd really like to see what the story is with
> coexistence somehow.
>
I cannot help there as my own access points do not have this feature.
Erich
___
freebsd-wireless@freebsd.
I'm not sure. I'd really like to see what the story is with coexistence somehow.
-a
On 8 April 2014 20:32, Erich Dollansky wrote:
> Hi,
>
> On Tue, 8 Apr 2014 20:07:39 -0700
> Adrian Chadd wrote:
>
>> Coexistence is to deal with the fact that a 40MHz channel may overlap
>> a 20MHz-only AP in
Hi,
On Tue, 8 Apr 2014 20:07:39 -0700
Adrian Chadd wrote:
> Coexistence is to deal with the fact that a 40MHz channel may overlap
> a 20MHz-only AP in the extension channel.
>
> If the AP finds a 20MHz AP in the extension channel (ie, the other
> half of its 40MHz) channel then it'll flip itsel
Coexistence is to deal with the fact that a 40MHz channel may overlap
a 20MHz-only AP in the extension channel.
If the AP finds a 20MHz AP in the extension channel (ie, the other
half of its 40MHz) channel then it'll flip itself to 20MHz. If it
determines it isn't there any more, it'll flip the BS
Hi,
On Tue, 08 Apr 2014 18:18:40 -0700
Sean Bruno wrote:
> On Mon, 2014-03-31 at 07:30 +0800, Erich Dollansky wrote:
> >
> > since I upgraded to r263767, I have the following problem:
> >
> > Wireless does not start all the while. When it does not start, it
> >
> > iwn0: mem 0xf250-0xf25
On Tue, 2014-04-08 at 18:21 -0700, Adrian Chadd wrote:
> Hi,
>
> 20/40 coex is supposed to be some corner of the spec that notices
> whether there's a 20mhz only AP on the extension channel and if so,
> flip everyone over to 20MHz.
>
> Is your DIR825 2GHz channel set to 20mhz or 40mhz?
>
>
> -a
Hi,
20/40 coex is supposed to be some corner of the spec that notices
whether there's a 20mhz only AP on the extension channel and if so,
flip everyone over to 20MHz.
Is your DIR825 2GHz channel set to 20mhz or 40mhz?
-a
On 8 April 2014 18:18, Sean Bruno wrote:
> On Mon, 2014-03-31 at 07:30
On Mon, 2014-03-31 at 07:30 +0800, Erich Dollansky wrote:
> Hi,
>
> since I upgraded to r263767, I have the following problem:
>
> Wireless does not start all the while. When it does not start, it hangs
> then forever. wpa_supplicant's state in top is then '-'. If I start
> wpa_supplicant by hand
Hi,
What were you running before and did the NIC work?
-a
On 30 March 2014 16:30, Erich Dollansky wrote:
> Hi,
>
> since I upgraded to r263767, I have the following problem:
>
> Wireless does not start all the while. When it does not start, it hangs
> then forever. wpa_supplicant's state in t
Hi,
since I upgraded to r263767, I have the following problem:
Wireless does not start all the while. When it does not start, it hangs
then forever. wpa_supplicant's state in top is then '-'. If I start
wpa_supplicant by hand, it will hang and it cannot be stopped by
control C. The light indicati
21 matches
Mail list logo