I've been watching this thread with great interest, having recently been
introduced to the possibilities of OLSR (net/olsrd) for local (and
beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in.
Some refs: My discovery point, a great (online) book found from a review
by Geoff Huston
On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
D> This "lost interrupt" type of problem is addressed by the use of the
D> status_tag
D> field in the status block. (Listed as bge_rsvd0 in the bge_status_block
D> structure).
D> Everytime the status block is updated a new tag va
Pat Lashley wrote:
The one thing
I'd be worried about is how the socket code handles connect() requests.
My hope would be that it would pick the address that goes with the
router to be used and thus the LLA would never be the source of a packet
going to a non-LLA address in normal circumstanc
Stefan Bethke wrote:
Hi,
just found my router being unable to reestablish the PPPoE connection
this morning. This had been going on for about four hours before I
restarted ppp. Any ideas what would cause the output queue to choke,
why it would report Already in NETWORK phase, why the ou
Hi,
just found my router being unable to reestablish the PPPoE connection
this morning. This had been going on for about four hours before I
restarted ppp. Any ideas what would cause the output queue to choke,
why it would report Already in NETWORK phase, why the output queue is
choking
On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
> This "lost interrupt" type of problem is addressed by the use of the
> status_tag
> field in the status block. (Listed as bge_rsvd0 in the bge_status_block
> structure).
> Everytime the status block is updated a new tag va
On Wed, Aug 23, 2006 at 06:21:28PM -0700, David Christensen wrote:
> Here's how it's done in Linux:
>
> static void tg3_disable_ints(struct tg3 *tp)
> {
> tw32(TG3PCI_MISC_HOST_CTRL,
>(tp->misc_host_ctrl | MISC_HOST_CTRL_MASK_PCI_INT));
> tw32_mailbox_f(MAILBOX_INTERRUPT_0
> > > Could you please answer few questions?
> > >
> > > 1) I've found status tag is returned in status block even if
> > > bit 9 of Misc.
> > >Host Control Register is not set, is it ok?
> >
> > Which controller are you using? This bit is reserved on the 5700
> > (which didn't support tagg
On Wed, Aug 23, 2006 at 05:54:24PM -0700, David Christensen wrote:
> > On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
> > > This "lost interrupt" type of problem is addressed by the use of the
> > > status_tag
> > > field in the status block. (Listed as bge_rsvd0 in the
> > b
> On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
> > This "lost interrupt" type of problem is addressed by the use of the
> > status_tag
> > field in the status block. (Listed as bge_rsvd0 in the
> bge_status_block
> > structure).
> > Everytime the status block is updated a
On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
> This "lost interrupt" type of problem is addressed by the use of the
> status_tag
> field in the status block. (Listed as bge_rsvd0 in the bge_status_block
> structure).
> Everytime the status block is updated a new tag value i
DHCP+static is rather weird, but common enough that we do support it. I
suspect LLA with other address types is also of use at least some
of the time so we should ideally support it. Actually if we don't mind
always configuring a LLA I think we might support be OK right now as
long as the LLA da
On Wed, Aug 23, 2006 at 03:07:32PM -0400, Pat Lashley wrote:
> >> I would agree that LLA is part of the minimal set; and as I mentioned
> >> before, it is the only part for which there is currently no FreeBSD
> >> solution. It should be possible to enable LLA on a per-NIC basis in
> >> rc.conf; and
> I would agree that LLA is part of the minimal set; and as I mentioned
> before, it is the only part for which there is currently no FreeBSD
> solution. It should be possible to enable LLA on a per-NIC basis in
> rc.conf; and it should be possible to have both LLA and non-LLA addresses
> on the s
> 2. What are the linux flavors doing?
It appears that the Avahi (http://avahi.org/) responder is the
current leader, it's API compatible (client wise) with mDNSResponder.
It is my impression that the mDNSResponder API compatibility lib/shim is a
build-time option and not actually used by the
On Wed, Aug 23, 2006 at 02:12:20PM -0400, Pat Lashley wrote:
> >If no one else steps forward, I will be glad to lead the charge to get an
> >implementation of this committed. Before I do though, we'll need to get
> >some
> >basic questions answered (some of which have already been discussed here).
If no one else steps forward, I will be glad to lead the charge to get an
implementation of this committed. Before I do though, we'll need to get some
basic questions answered (some of which have already been discussed here).
1. What are the other *BSDs doing in this area?
2. What are the linux f
Doug Barton wrote:
I find it very interesting. :) One of my side projects at the moment is to
come further up to speed on the subject of multicast DNS in general, so I'm
following this discussion with a great deal of interest. I'd really like to
see FreeBSD take a lead in this area, since the mo
This "lost interrupt" type of problem is addressed by the use of the
status_tag
field in the status block. (Listed as bge_rsvd0 in the bge_status_block
structure).
Everytime the status block is updated a new tag value is written to the
status block.
When the ISR starts the driver should record
On Wed, Aug 23, 2006 at 12:48:02PM -0700, Doug Barton wrote:
> Brooks, if you're reading this, can I count on you to broach the question
> about the Apache license in [EMAIL PROTECTED]
Will do.
-- Brooks
pgpxSVsk16XB7.pgp
Description: PGP signature
Fredrik Lindberg wrote:
> The thing is that I would like to see mDNS in base (and the other
> zeroconfig utilities).
...
> However that doesn't have a chance of happening unless a committer finds
> it interesting.
I find it very interesting. :) One of my side projects at the moment is to
come
On Wed, Aug 23, 2006 at 10:26:48PM +0400, Oleg Bulyzhin wrote:
> On Wed, Aug 23, 2006 at 08:16:49PM +0400, Gleb Smirnoff wrote:
> > Colleagues,
> >
> > I've faced a problem in bge(4) when a single packet is in the RX
> > ring, but it isn't noticed by the driver. A reception of a packet
> > tri
Gleb Smirnoff wrote:
Colleagues,
I've faced a problem in bge(4) when a single packet is in the RX
ring, but it isn't noticed by the driver. A reception of a packet
triggers interrupt and both packets are processed - an old one
and the new one.
To reproduce the problem you need to run netper
On Wed, Aug 23, 2006 at 08:16:49PM +0400, Gleb Smirnoff wrote:
> Colleagues,
>
> I've faced a problem in bge(4) when a single packet is in the RX
> ring, but it isn't noticed by the driver. A reception of a packet
> triggers interrupt and both packets are processed - an old one
> and the new o
Bruce Walker wrote:
Fredrik Lindberg wrote:
mDNSResponder-108 appears to still be under APSL 2, I don't
know if that license is acceptable for base utilities, if it is, it
might be a viable alternative.
It should be under the Apache 2.0 license now.
Yes, you are correct. I just grabbed the
On Wed, Aug 23, 2006 at 01:45:10PM -0400, Bruce Walker wrote:
> Fredrik Lindberg wrote:
> >mDNSResponder-108 appears to still be under APSL 2, I don't
> >know if that license is acceptable for base utilities, if it is, it
> >might be a viable alternative.
>
> It should be under the Apache 2.0 lice
Fredrik Lindberg wrote:
mDNSResponder-108 appears to still be under APSL 2, I don't
know if that license is acceptable for base utilities, if it is, it
might be a viable alternative.
It should be under the Apache 2.0 license now.
Here's the announcement from the bonjour-dev list ...
Pat Lashley wrote:
As I investigate further, it appears that avahi is the most mature,
feature-rich, and widely supported and adopted mDNS implementation. The
only potential drawback would be the GPL.
I've also discovered that Apple are moving the iCal server, Bonjour, and
launchd to the A
Colleagues,
I've faced a problem in bge(4) when a single packet is in the RX
ring, but it isn't noticed by the driver. A reception of a packet
triggers interrupt and both packets are processed - an old one
and the new one.
To reproduce the problem you need to run netperf (from ports
collect
29 matches
Mail list logo
