Garrett Cooper wrote:
I think setting it to a value of 0 has two good points...
In code that does:
if (XXX & RTF_LLINFO) {
yyy()
}
the optimiser should simply remove the code,
or at worst give an error messages that makes people go look for
the answer, and secondly,
the conditional
#if
On Mon, Jan 12, 2009 at 12:37 PM, Julian Elischer wrote:
> Garrett Cooper wrote:
>
> I think setting it to a value of 0 has two good points...
>
> In code that does:
> if (XXX & RTF_LLINFO) {
>yyy()
> }
> the optimiser should simply remove the code,
> or at worst give an error messages tha
s,
>
> -- Qing
>
>
>> -Original Message-
>> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
>> Sent: Friday, January 09, 2009 1:27 AM
>> To: Li, Qing
>> Cc: Tijl Coosemans; Qing Li; freebsd-net@freebsd.org; freebsd-
>> curr...@freebsd.org
>>
09 1:27 AM
> To: Li, Qing
> Cc: Tijl Coosemans; Qing Li; freebsd-net@freebsd.org; freebsd-
> curr...@freebsd.org
> Subject: RE: HEADSUP: arp-v2 has been committed
>
> On Tue, 30 Dec 2008, Li, Qing wrote:
> > I don't think we can provide binary compatibility without p
+1 for introducing RTF_LLINFO backwards compatibility.
I had to sneak in a fix to XORP and pretty much broke release protocol
to do so.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send
On Tue, 30 Dec 2008, Li, Qing wrote:
> I don't think we can provide binary compatibility without putting
> back RTF_LLINFO exactly as it was. My preference is to continue down
> the new path without RTF_LLINFO.
So, you are saying that applications built on FreeBSD 7 or earlier
that use RTF_LLINFO
Li, Qing wrote:
> I don't think we can provide binary compatibility without putting
> back RTF_LLINFO exactly as it was. My preference is to continue down
> the new path without RTF_LLINFO.
Out of curiosity, what's your reasoning for this decision? If I've
missed this explanation previously, my a
Hi,
>
> > If it's easy to reintroduce it and become backwards compatible I
> > would do it. Like Julian said, you can give it the value 0. It
> > would be nice if the kernel tested for the old value as well,
> > perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people
> > upgrade to FreeBSD
On Sun, 28 Dec 2008, Tijl Coosemans wrote:
> On Saturday 27 December 2008 21:21:25 Qing Li wrote:
>> I believe all of the affected ports have been updated to
>> include the conditional blocks around RTF_LLINFO.
emulators/wine has not been adjusted yet, pending this discussion.
> Yes, and I'm OK
On Saturday 27 December 2008 21:21:25 Qing Li wrote:
> Right now I am also a bit leaning towards reintroducing
> the RTF_LLINFO flag bit. This is mainly due to the recent
> discovery of the "route" command issued with the
> "-iface/-interface" option, which conflicts with the
> way how "arp" and "n
Julian Elischer wrote:
Qing Li wrote:
I believe examining the impacts of RTF_LLINFO on the ports was a good
exercise even if we have to rejuvenate it.
I hope we could reach a consensus soon now that we have more input
from the ports developers.
Please provide your input ...
reintroduce
On 2008-Dec-27 14:54:34 -0800, Julian Elischer wrote:
>Qing Li wrote:
>> I believe examining the impacts of RTF_LLINFO on the ports
>> was a good exercise even if we have to rejuvenate it.
>
>reintroduce it with value 0
And a comment indicating that the definition of RTF_LLINFO is solely
for bac
Qing Li wrote:
I believe examining the impacts of RTF_LLINFO on the ports
was a good exercise even if we have to rejuvenate it.
I hope we could reach a consensus soon now that we have more
input from the ports developers.
Please provide your input ...
reintroduce it with value 0
then te
Right now I am also a bit leaning towards reintroducing
the RTF_LLINFO flag bit. This is mainly due to the recent
discovery of the "route" command issued with the
"-iface/-interface" option, which conflicts with the
way how "arp" and "ndp" is handled in the kernel.
I renamed this flag bit to RTF_
On Saturday 27 December 2008 13:28:42 Gerald Pfeifer wrote:
> On Tue, 23 Dec 2008, Tijl Coosemans wrote:
>>> No, the output of this command is still the same. NET_RT_DUMP
>>> obtains the entire L3 table and filtering for RTF_GATEWAY
>>> non-multicast routes have the same semantics. Those flags neve
On Tue, 23 Dec 2008, Tijl Coosemans wrote:
>> No, the output of this command is still the same. NET_RT_DUMP obtains
>> the entire L3 table and filtering for RTF_GATEWAY non-multicast
>> routes have the same semantics. Those flags never apply to L2 entries.
> Thanks for answering my questions. I've
Hi Ian,
Well, yuletide and new year is a good time to clean out the cupboards,
so... without further ado...
Ian FREISLICH wrote:
...
Do you have applications which do not explicitly specify the interface
address to use for multicast group joins?
If they do not, that's a bug in the applica
Bruce Simpson wrote:
> Ian FREISLICH wrote:
> > ...
> > I can't quite remember exactly why imr_ifindex doesn't work, but
> > on my hosts which have several hundred interfaces and my OSPF
> > sessions are never on the interface that has the default route,
> > until I explicitly set the imr_address,
On Wed, Dec 24, 2008 at 2:09 AM, Kip Macy wrote:
> The should be fixed with 186468. Please confirm.
Yes it seems to be fixed, thanks!
Cheers,
Antoine
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To uns
Ian FREISLICH wrote:
You can add net/quagga to that list as well.
net/xorp got bit too.
XORP doesn't do anything with the RTF_LLINFO information, so I have
checked in a 2 line fix to the XORP repo.
The ability to turn off ARP, or redirect ARP processing to a userland
daemon, would be in
Ian FREISLICH wrote:
...
I can't quite remember exactly why imr_ifindex doesn't work, but
on my hosts which have several hundred interfaces and my OSPF
sessions are never on the interface that has the default route,
until I explicitly set the imr_address, the kernel always chooses
the interface w
On Tue, Dec 23, 2008 at 11:39:09PM +0100, Hartmut Brandt wrote:
> Well, they did this in the past, for example when I did some heavy work
> on make(1). At that time Kris did this, I don't know through which
> magic, though.
Just email portmgr@ and ask for a regression-test on the build cluster.
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
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
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
maintainers into the boat earlier.
not so happy,
harti
-- Qing
-Original Message-
From: Hartmut Brandt
Sent: Sunday, December 21, 2008 8:54 AM
To: Kip Macy
Cc: Vladimir Grebenschikov ; Qing Li ; freebsd-net@freebsd.org
; Gerald Pfeifer ; freebsd-curr...@freebsd.org
Subject: Re: HEAD
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
Sergey Matveychuk wrote:
> Ian FREISLICH wrote:
> > --- lib/sockopt.c.orig 2007-08-21 18:32:56.0 +0200
> > +++ lib/sockopt.c 2008-08-13 09:07:20.0 +0200
> > @@ -231,6 +231,7 @@
> >else
> > mreqn.imr_address = if_addr;
> >
> > + mreqn.imr_address = if_add
Pfeifer; Vladimir Grebenschikov; Kip Macy; Qing Li; Ian FREISLICH;
> Erwin Lansing
> Subject: Re: HEADSUP: arp-v2 has been committed
>
> Li, good day.
>
> Mon, Dec 22, 2008 at 01:55:34AM -0800, Li, Qing wrote:
> > Thank you all for patching these programs.
>
> Thank
Hi Tijl,
Good questions and see my comments below.
>
> 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_FLAGS
On Monday 22 December 2008 10:55:34 Li, Qing wrote:
> Thank you all for patching these programs.
>
> I scanned through your patches and they all look fine.
> Each one that I read through seems to be simple fix, which
> is what I hoped for.
>
> Again, just to emphasize the points I made in my prev
Ian FREISLICH wrote:
--- lib/sockopt.c.orig 2007-08-21 18:32:56.0 +0200
+++ lib/sockopt.c 2008-08-13 09:07:20.0 +0200
@@ -231,6 +231,7 @@
else
mreqn.imr_address = if_addr;
+ mreqn.imr_address = if_addr;
ret = setsockopt(sock, IPPROTO_IP, optna
Li, good day.
Mon, Dec 22, 2008 at 01:55:34AM -0800, Li, Qing wrote:
> Thank you all for patching these programs.
Thank you for your work!
> I scanned through your patches and they all look fine.
> Each one that I read through seems to be simple fix, which
> is what I hoped for.
Are you going t
Macy; Qing Li; Ian FREISLICH;
Erwin Lansing
Subject: Re: HEADSUP: arp-v2 has been committed
Greetings!
Mon, Dec 22, 2008 at 10:04:22AM +0200, Ian FREISLICH wrote:
> Erwin Lansing wrote:
> > > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications
> > > s
Greetings!
Mon, Dec 22, 2008 at 10:04:22AM +0200, Ian FREISLICH wrote:
> Erwin Lansing wrote:
> > > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications
> > > such as "arp" and "ndp" have been modified to reflect those changes.
> > > so I guess it's not so easy.
> > > How m
Erwin Lansing wrote:
> > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications
> > such as "arp" and "ndp" have been modified to reflect those changes.
> > so I guess it's not so easy.
> > How many other ports are affected?
> The latest full run with HEAD from a few days back
mut Brandt
Cc: Gerald Pfeifer; Vladimir Grebenschikov; Kip Macy; Qing Li;
freebsd-curr...@freebsd.org; freebsd-net@freebsd.org
Subject: Re: HEADSUP: arp-v2 has been committed
Hartmut Brandt wrote:
> Kip Macy wrote:
>> The flag is not needed. It is only possible to retrieve arp entries
Hartmut Brandt wrote:
Kip Macy wrote:
The flag is not needed. It is only possible to retrieve arp entries by
way of sysctl. The converse of this is you no longer need to grab all
the entries in the routing table and look at each one to determine
which are cloned routes (dynamic host routes) whic
Pfeifer
Sent: Sunday, December 21, 2008 4:06 AM
To: Vladimir Grebenschikov
Cc: Qing Li ; freebsd-curr...@freebsd.org
; freebsd-net@freebsd.org
Subject: Re: HEADSUP: arp-v2 has been committed
The code in question on the Wine side is
#if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP)
d.org ; Gerald Pfeifer
; freebsd-curr...@freebsd.org
Subject: Re: HEADSUP: arp-v2 has been committed
Kip Macy wrote:
> The flag is not needed. It is only possible to retrieve arp entries by
> way of sysctl. The converse of this is you no longer need to grab all
> the entries in the routing tab
Hartmut Brandt wrote:
Kip Macy wrote:
The flag is not needed. It is only possible to retrieve arp entries by
way of sysctl. The converse of this is you no longer need to grab all
the entries in the routing table and look at each one to determine
which are cloned routes (dynamic host routes) whic
Hi Kip&Erwin!
On Sun, 21 Dec 2008 13:51:21 +0100
Erwin Lansing wrote:
> > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications
> > such as "arp" and "ndp" have been modified to reflect those changes.
> > so I guess it's not so easy.
> > How many other ports are affected?
>
Kip Macy wrote:
The flag is not needed. It is only possible to retrieve arp entries by
way of sysctl. The converse of this is you no longer need to grab all
the entries in the routing table and look at each one to determine
which are cloned routes (dynamic host routes) which contain ARP
entries.
On Sun, Dec 21, 2008 at 06:01:35AM +0100, Gerald Pfeifer wrote:
> The code in question on the Wine side is
>
> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP)
> int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};
>
> and there is nothing FreeBSD-specific in dlls/iphlpa
The flag is not needed. It is only possible to retrieve arp entries by
way of sysctl. The converse of this is you no longer need to grab all
the entries in the routing table and look at each one to determine
which are cloned routes (dynamic host routes) which contain ARP
entries.
-Kip
On Sat, Dec
The code in question on the Wine side is
#if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP)
int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};
and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far
as I can see.
If the arp-v2 update now made us incomp
requests for addresses that are not proxied locally.
-Original Message-
From: owner-freebsd-curr...@freebsd.org on behalf of Vladimir
Grebenschikov
Sent: Fri 12/19/2008 9:04 AM
To: Qing Li
Cc: freebsd-net@freebsd.org; freebsd-curr...@freebsd.org
Subject: Re: HEADSUP: arp-v2 has been
Sent: Fri 12/19/2008 9:04 AM
To: Qing Li
Cc: freebsd-net@freebsd.org; freebsd-curr...@freebsd.org
Subject: Re: HEADSUP: arp-v2 has been committed
On Mon, 2008-12-15 at 15:42 +0200, Giorgos Keramidas wrote:
> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote:
> > Hi All,
> >
> &g
On Mon, 2008-12-15 at 15:42 +0200, Giorgos Keramidas wrote:
> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote:
> > Hi All,
> >
> > The arp-v2 changes have been committed into HEAD.
> > Please report problems to me and Kip Macy.
Nice, my host sends arp-reply about other hosts
my host has MAC addr
On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote:
> > The arp-v2 changes have been committed into HEAD.
> > Please report problems to me and Kip Macy.
Wine is not build any more:
...
cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT
-fPIC -Wall -pipe -fno-strict-aliasi
At 11:34 PM 12/16/2008, Kip Macy wrote:
Try changeid 186209.
Thanks, no panic now!
---Mike
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubsc
Try changeid 186209.
Thanks,
Kip
On Wed, Dec 17, 2008 at 3:32 AM, Mike Tancsa wrote:
> At 01:34 AM 12/15/2008, Qing Li wrote:
>
>> Hi All,
>>
>> The arp-v2 changes have been committed into HEAD.
>> Please report problems to me and Kip Macy.
>
> Not sure if its related or not, but if I create and
At 01:34 AM 12/15/2008, Qing Li wrote:
Hi All,
The arp-v2 changes have been committed into HEAD.
Please report problems to me and Kip Macy.
Not sure if its related or not, but if I create and destroy a lagg
port, I get a panic
e.g.
0[current]# ifconfig lagg0 laggproto failover laggport ig
This was caused by a change I made today. Evidently we're trying to
acquire a shared lock while holding an exclusive lock.
I will take a look.
-Kip
On Wed, Dec 17, 2008 at 3:32 AM, Mike Tancsa wrote:
> At 01:34 AM 12/15/2008, Qing Li wrote:
>
>> Hi All,
>>
>> The arp-v2 changes have been commit
o up for every outgoing packet.
-- Qing
> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of Giorgos Keramidas
> Sent: Monday, December 15, 2008 5:42 AM
> To: Qing Li
> Cc: freebsd-net@freebsd.org; freebsd-c
On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote:
> Hi All,
>
> The arp-v2 changes have been committed into HEAD.
> Please report problems to me and Kip Macy.
Thanks! I've just updated my installation here to the new kernel and
userland and it seems to work fine so far. At least, ARP and IPv4 se
Hi All,
The arp-v2 changes have been committed into HEAD.
Please report problems to me and Kip Macy.
-- Qing
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-un
61 matches
Mail list logo
