On May 1, 2011, at 7:00 PM, Schoch Christian wrote:
> Zitat von Michael Tüxen:
>
>> On May 1, 2011, at 1:10 PM, Schoch Christian wrote:
>>
On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote:
>
>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote:
>>
>>> During a measur
Hi,
On Sun, May 1, 2011 at 11:32 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Sun, May 1, 2011 at 10:50 PM, Li, Qing wrote:
>> jeez, this bug has been around for quite a while ...
>>
>> Please try patch at http://people.freebsd.org/~qingli/arp.patch
>>
> Do not help:
>
> # sh -x test.sh
> + ifconfig
Hi,
On Sun, May 1, 2011 at 10:50 PM, Li, Qing wrote:
> jeez, this bug has been around for quite a while ...
>
> Please try patch at http://people.freebsd.org/~qingli/arp.patch
>
Do not help:
# sh -x test.sh
+ ifconfig vr2 up 192.168.24.1
+ arp -s 192.168.24.2 0:0:0:0:0:1
+ arp -a
? (192.168.24.
jeez, this bug has been around for quite a while ...
Please try patch at http://people.freebsd.org/~qingli/arp.patch
-- Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Sunday, May 01, 2011 4:54 PM
To:
Hi,
On Sun, May 1, 2011 at 7:54 PM, Li, Qing wrote:
> That's not the expected behavior, probably a bug, I will take a look ...
>
I just check on several version. HEAD has the same behavior,
4.9-RELEASE and a custom 7.1 keep the permanent ARP entry. In case
that matter, HEAD was tested on top of e
That's not the expected behavior, probably a bug, I will take a look ...
-- Qing
On May 1, 2011, at 4:51 PM, "Ingo Flaschberger" wrote:
>> is it expected behaviour that the static, permanent arp entry of the
>> interface ip disappear after ifdown/ifup at 8.x release?
>>
>> ifconfig em0 10.
is it expected behaviour that the static, permanent arp entry of the
interface ip disappear after ifdown/ifup at 8.x release?
ifconfig em0 10.20.20.1/24
arp -an | grep 10.20.20.1
? (10.20.20.1) at xx:xx:xx:xx:xx:xx on em0 permanent [ethernet]
ifconfig em0 down
ifconfig em0 up
arp -an | grep 10.2
On Sun, May 1, 2011 at 8:24 AM, Bernhard Schmidt wrote:
> On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote:
>> Hi,
>>
>> I finally managed to get the 11n bits for iwn(4) sorted out. Well,
>> there is still an issue somewhere with HT40 frame protection or
>> TX chain setup on 5000 adapters, re
Synopsis: [ath] Atheros card is not well supported
State-Changed-From-To: open->feedback
State-Changed-By: eadler
State-Changed-When: Sun May 1 20:20:03 UTC 2011
State-Changed-Why:
To submitter: The code in question has changed a lot since you submitted
the bug. Has the problem been fixed or is i
Synopsis: [ath] [panic] ath_start: attempted use of a free mbuf!
State-Changed-From-To: feedback->closed
State-Changed-By: eadler
State-Changed-When: Sun May 1 20:09:26 UTC 2011
State-Changed-Why:
feedback timeout
http://www.freebsd.org/cgi/query-pr.cgi?pr=107279
Synopsis: [ath] Atheros AR5006 exits on "cannot map register space" & "ath0
attach returned 6"
State-Changed-From-To: feedback->closed
State-Changed-By: eadler
State-Changed-When: Sun May 1 19:56:13 UTC 2011
State-Changed-Why:
feedback timeout
http://www.freebsd.org/cgi/query-pr.cgi?pr=129750
_
Old Synopsis: [ath] Unable to configure adhoc mode on ath0/wlan0
New Synopsis: [panic] [ath] Unable to configure adhoc mode on ath0/wlan0
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: eadler
Responsible-Changed-When: Sun May 1 19:53:47 UTC 2011
Responsible-Chan
Synopsis: [ath] ath(4) lot of bad series(0)
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: eadler
Responsible-Changed-When: Sun May 1 19:52:15 UTC 2011
Responsible-Changed-Why:
new mailing list owns this one
http://www.freebsd.org/cgi/query-pr.cgi?pr=154567
__
Synopsis: [ath] Modern ath wifi cards (such as AR9285) have missed LED
indication
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: eadler
Responsible-Changed-When: Sun May 1 19:51:54 UTC 2011
Responsible-Changed-Why:
new mailing list owns this one
http://www.fr
Synopsis: [patch] Integer overflow in wpa_supplicant(8) base64 encoder
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: eadler
Responsible-Changed-When: Sun May 1 19:49:12 UTC 2011
Responsible-Changed-Why:
New mailing list owns this one
http://www.freebsd.org/cg
Zitat von Michael Tüxen:
On May 1, 2011, at 1:10 PM, Schoch Christian wrote:
On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote:
On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote:
During a measurement with CMT-SCTP and PF i figured out, that
sometimes a ICMP Destination unreachable m
Adrian Chadd (adr...@freebsd.org) [11.05.01 09:09] wrote:
> On 1 May 2011 04:43, YongHyeon PYUN wrote:
>
> > It's tunable. Set net.link.ifqmaxlen.
>
> I know it's tunable at boot time; I mean why is it that low by default?
>
and what will be acceptable value for ASDL connections 8 and more MBi
On May 1, 2011, at 1:10 PM, Schoch Christian wrote:
>> On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote:
>>>
On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote:
> During a measurement with CMT-SCTP and PF i figured out, that sometimes a
> ICMP Destination unreachable mess
On Sunday 01 May 2011 13:19:30 Bernhard Schmidt wrote:
> Hi,
>
> I finally managed to get the 11n bits for iwn(4) sorted out. Well,
> there is still an issue somewhere with HT40 frame protection or
> TX chain setup on 5000 adapters, resulting in throughput not being
> that stable. But overall it s
Hi,
I finally managed to get the 11n bits for iwn(4) sorted out. Well,
there is still an issue somewhere with HT40 frame protection or
TX chain setup on 5000 adapters, resulting in throughput not being
that stable. But overall it seems to work pretty decently
This is for HEAD only right now, net8
On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote:
On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote:
During a measurement with CMT-SCTP and PF i figured out, that
sometimes a ICMP Destination unreachable message triggers a
message transmission on an inactive data path that has been
21 matches
Mail list logo
