if you want MPLS on BSD, check out http://www.ayame.org/.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Mike Silbersack wrote:
>
> On Fri, 31 May 2002, Andre Oppermann wrote:
>
> Ok, here we go.
>
> > if (req == RTM_RESOLVE) {
> > rt->rt_rmx = (*ret_nrt)->rt_rmx; /* copy metrics */
> > + rt->rt_rmx.rmx_pksent = 0; /* reset packet counter */
On Wed, May 29, 2002 at 12:16:50PM -0700, Paul Traina wrote:
>
> > Bwah... It lacks things like transparent-nexthop and transparent-as
> > which is quite useful in Route Servers and such.
>
> We don't add features to code unless people are willing to pay for them and
> use them.
which is why we
Hi,
I'm starting to play with netgraph, and there doesn't seem to be much
documentation out there (other then the DaemonNews article, and the man
pages.)
For starters, I was going to modify the UDP tunneling example in the
DaemonNews article to do TCP tunneling. However, I'm having problems
Hi,
There is an inconsistency in the kernel mbuf code around the
"m->m_ext.ext_size" field of an M_EXT mbuf.
At first glance you might assume that this field is the total amount
of contiguous space available in the external buffer pointed to by
"m->m_ext.ext_buf". For example, look at the M_TRAI
On Fri, May 31, 2002 at 11:29:20AM -0700, Archie Cobbs wrote:
...
if you add the additional Note, then it might be worthwhile that the
writability of the returned buffer should be checked in the
standard way (whatever macro it is, i forget the name).
cheers
luigi
>
> --- kern/u
On Fri, May 31, 2002 at 11:29:20AM -0700, Archie Cobbs wrote:
> Hi,
>
> There is an inconsistency in the kernel mbuf code around the
> "m->m_ext.ext_size" field of an M_EXT mbuf.
>
> At first glance you might assume that this field is the total amount
> of contiguous space available in the exte
When I added these fields in freebsd1.x
(They may have gone through some metamorphesis since)
it was to support some stuff we were doing at TFS.
They were variants of similar fields in BSD4.3 RENO.
The problem that can occur is that the code that splits
the data can end up having two references
On Fri, 31 May 2002, Bosko Milekic wrote:
>
> I don't remember why the ext_size here was this originally (as you
> mention, it was imported that way), but it certainly seems bogus and
> you catching it now is hopefully going to solve some really wierd and
> difficult-to-debug problems
On Fri, May 31, 2002 at 12:54:39PM -0700, Julian Elischer wrote:
>
>
> On Fri, 31 May 2002, Bosko Milekic wrote:
>
> >
> > I don't remember why the ext_size here was this originally (as you
> > mention, it was imported that way), but it certainly seems bogus and
> > you catching it now
On Fri, May 31, 2002 at 01:25:09PM -0700, Archie Cobbs wrote:
[...]
> As a temporary saftey measure, I'll add M_WRITABLE(m) into the
> M_TRAILINGSPACE() macro. However, I see this as a temporary hack;
> the correct fix is to put the burden of writability on the caller.
> After all, M_TRAILINGSPAC
On Fri, 31 May 2002, Archie Cobbs wrote:
>
> It's not clear whether the caller of M_TRAILINGSPACE()/M_LEADINGSPACE()
> is responsible for checking for writability, or the macros themselves.
> It seems to make more sense that the caller would be responsible...
> why would you call M_TRAILINGSPAC
Julian Elischer writes:
> > It's not clear whether the caller of M_TRAILINGSPACE()/M_LEADINGSPACE()
> > is responsible for checking for writability, or the macros themselves.
> > It seems to make more sense that the caller would be responsible...
> > why would you call M_TRAILINGSPACE() unless you
On Thu, May 30, 2002 at 05:21:17PM +0200, Andre Oppermann wrote:
>
> > Please explain how that would not work for servers?
>
> It would work but not optimal because the packet flow is different for
> locally terminated/generated packets.
Howso? Both do a routing lookup exactly the same.
> > Th
auth e09fb9ff subscribe freebsd-net [EMAIL PROTECTED]
Lars Eggert writes:
> For starters, I was going to modify the UDP tunneling example in the
> DaemonNews article to do TCP tunneling. However, I'm having problems
> getting the "server" side of the TCP tunnel to listen on the ksocket:
>
> /usr/sbin/ngctl mkpeer iface dummy inet
> /usr/sbin/ngctl
Hi all,
I've found another bug in net/route.c in the function rtredirect().
When learning a new gateway from a ICMP redirect icmp_input calls
rtredirect() in net/route.c. rtredirect is doing some sanity checks
and then creates, if it did not find an existing host route, a new
host route tagged w
Richard A Steenbergen wrote:
>
> On Thu, May 30, 2002 at 05:21:17PM +0200, Andre Oppermann wrote:
> > > This is a non sequitur. All routes will be available through the kernel
> > > RIB, but for exact matches only. When is a longest prefix match needed
> > > there?
> >
> > When the routing daemon
On Sat, 1 Jun 2002, Andre Oppermann wrote:
> I'm axing that right now and will provide a tcp_hostcache that will
> assume that role (tcp is the only consumer of rt_metrics, except for
> rmx_mtu and rmx_pksent). By moving this every node/leaf in the routing
> table shrinks by 48 bytes. On a defau
On Fri, 31 May 2002, Andre Oppermann wrote:
> I think it will break. Isn't there a compiler warning in net/rtsocket.c
> on 64bit platforms about the u_long to int assignment?
>
> IMO the right solution would to simply axe this field from rt_msghdr.
> It serves no purpose. At least none of the ba
20 matches
Mail list logo
