* Doug Barton [081223 11:46] wrote:
> On Mon, 22 Dec 2008, Alfred Perlstein wrote:
>
> >Hey guys, we found a bug at Juniper and it resolves an issue
> >for us. I've been asked to forward this to FreeBSD, I honestly
> >am not that clear on the issue so I'm hoping someone can step
> >up to review
Hajimu UMEMOTO 写道:
Hi,
On Wed, 10 Dec 2008 13:48:51 +0800
"=?GB2312?B?s8LQocn6?=" said:
stutiredboy> hi,all,we have a project which must resolv some domains in the
server
stutiredboy> process
stutiredboy> our system in FreeBSD 6.2 or 6.3, the server process may open 7000+
st
The should be fixed with 186468. Please confirm.
Thanks,
Kip
On Tue, Dec 23, 2008 at 2:01 PM, Antoine Brodin wrote:
> On Mon, Dec 15, 2008 at 7:34 AM, Qing Li wrote:
>> Hi All,
>>
>> The arp-v2 changes have been committed into HEAD.
>> Please report problems to me and Kip Macy.
>
> Hi,
>
> I s
Hi Kip,
Kip Macy wrote:
And another point: when changing external interfaces it might be
possible to ask for a full port build with the changes to look for the
fall-out on ports. I would say that this commit was a good candidate
to
get the port maintainers into the boat earlier.
n
On Mon, Dec 15, 2008 at 7:34 AM, Qing Li wrote:
> Hi All,
>
> The arp-v2 changes have been committed into HEAD.
> Please report problems to me and Kip Macy.
Hi,
I still have a panic with ipv6 enabled with current from yesterday
afternoon (in6.c rev 1.92):
%%%
# cat info.1
Dump header from devic
Li, Qing wrote:
Hi Hartmut,
I appreciate your candid feedback. You raised many valid points.
I combined both of your emails in this reply, please see my
comments below ...
You are absolutely right. This was a complete oversight on my part.
I was telling myself "I think I am forgetting
Hi Harti,
Let me first preface this e-mail by saying that you and I have had
very little contact prior to this. The comments below are meant to
explain the point of view of myself and that of a number of other
developers with whom I have spoken, not to criticize you or trivialize
your point of vie
g...@freebsd.org wrote:
Hi,
I just checked in a small tool to HEAD in
/usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect
ethernet packets just about the driver layer without involving the
protocol stacks. This is useful for people doing low level testing of
drivers and switch
Hi Hartmut,
I appreciate your candid feedback. You raised many valid points.
I combined both of your emails in this reply, please see my
comments below ...
>
> Also one thing that would be extremly helpful is a short description
of
> that interface arp(4). Currently one has to reverse engine
We are using pf+ALTQ for shaping and ipfw for filtering, diverting into
netgraph nodes, attaching altq queues.
Best regards,
Vladimir
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org]
On Behalf Of g...@freebsd.org
Sent: Tuesday, December 23, 200
Hi,
I just checked in a small tool to HEAD in
/usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect
ethernet packets just about the driver layer without involving the
protocol stacks. This is useful for people doing low level testing of
drivers and switches. If you happen to be l
On Mon, 22 Dec 2008, Alfred Perlstein wrote:
Hey guys, we found a bug at Juniper and it resolves an issue
for us. I've been asked to forward this to FreeBSD, I honestly
am not that clear on the issue so I'm hoping someone can step
up to review this.
Synopsis is:
The traffic class byte is set
At Tue, 23 Dec 2008 13:57:39 +0200,
Vladimir V. Kobal wrote:
>
> With fastforwarding off the system works well and boots without panicing.
>
OK, that narrows it down. Are you using any filtering such as PF,
ipfw, etc.?
Best,
George
___
freebsd-net@fre
On Tuesday 23 December 2008 03:27:21 Li, Qing wrote:
>> I'm looking into the Wine case, but don't have any experience with
>> the implementation of routing tables, so I need to have a few things
>> spelled out.
>>
>> Wine currently uses:
>>
>> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_F
The following reply was made to PR kern/119432; it has been noted by GNATS.
From: Axel Scheepers
To: bug-follo...@freebsd.org, a...@axel.truedestiny.net
Cc:
Subject: Re: kern/119432: [arp] route add -host -iface
causes arp entry with nic's arp address [regression]
Date: Tue, 23 De
All:
Ok here is the latest... this:
1) Incorporates Matt's changes
2) Goes with Matt's idea of adding an INP.
3) We now are holding the INP lock across the
call to the tunnel as well as the append. Since
the caller will have the INP they can unlock
if they need to :-)
4) revamped my s9
Li, Qing wrote:
Yes, at least in the IPv4 case, I still generate the routing messages whenever
entries are modified, so you can still wait for notifications on the routing
socket. One should check for the address family AF_LINK type instead of
checking for RTF_LLINFO flag. It's an over sight t
Li, Qing wrote:
Yes, at least in the IPv4 case, I still generate the routing messages whenever
entries are modified, so you can still wait for notifications on the routing
socket. One should check for the address family AF_LINK type instead of
checking for RTF_LLINFO flag. It's an over sight t
With fastforwarding off the system works well and boots without panicing.
As for the rtfree messages, they were caused by
net.link.ether.inet.proxyall=1 and were not connected to panicing.
Best regards,
Vladimir
-Original Message-
From: g...@freebsd.org [mailto:g...@freebsd.org]
Sent: M
19 matches
Mail list logo
