On Fri, 29 Aug 2008, Sam Leffler wrote:
The bridge code does a deep copy of the packet for each interface it
broadcasts on due the firewall code modifying the headers. It sounds like
this should just be a copy+pullup instead.
I'd not do that. I think there are paths that assume the deep cop
Andrew Thompson wrote:
On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote:
On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote:
Luigi Rizzo wrote:
...
and to be more explicit - the result of m_pullup is that
the number of bytes specified as m_pullup argume
On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote:
> On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote:
> > Luigi Rizzo wrote:
> ...
> > >and to be more explicit - the result of m_pullup is that
> > >the number of bytes specified as m_pullup argument are in
> > >a private piece
At Fri, 29 Aug 2008 18:28:53 +0200,
Luigi Rizzo wrote:
>
> and to be more explicit - the result of m_pullup is that
> the number of bytes specified as m_pullup argument are in
> a private piece of memory -- the 'data' region within the mbuf -- so
> you can freely play with them without trouble.
>
On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote:
> Luigi Rizzo wrote:
...
> >and to be more explicit - the result of m_pullup is that
> >the number of bytes specified as m_pullup argument are in
> >a private piece of memory -- the 'data' region within the mbuf -- so
> >you can freely pl
Luigi Rizzo wrote:
On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote:
[EMAIL PROTECTED] wrote:
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
J
On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote:
> [EMAIL PROTECTED] wrote:
> >At Tue, 26 Aug 2008 14:50:33 + (UTC),
> >Bjoern A. Zeeb wrote:
> >
> >>On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
> >>
> >>Hi,
> >>
> >>
> >>>At Mon, 25 Aug 2008 21:40:38 +0200,
> >>>John Ha
At Tue, 26 Aug 2008 17:56:13 -0700,
Sam Leffler wrote:
>
> [EMAIL PROTECTED] wrote:
> > At Tue, 26 Aug 2008 14:50:33 + (UTC),
> > Bjoern A. Zeeb wrote:
> >
> >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
> >>
> >> Hi,
> >>
> >>
> >>> At Mon, 25 Aug 2008 21:40:38 +0200,
> >>> Jo
[EMAIL PROTECTED] wrote:
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
I have tried it and it does fix my problem. RIP2 over multicast works
again. :-)
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
>
> On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
>
> Hi,
>
> > At Mon, 25 Aug 2008 21:40:38 +0200,
> > John Hay wrote:
> >>
> >> I have tried it and it does fix my problem. RIP2 over multicast works
> >> again. :-)
> >
> > Goo
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
I have tried it and it does fix my problem. RIP2 over multicast works
again. :-)
Good to hear. I'm waiting on a bit more feedback but I think I'll be
checking this in soon, with a big
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
>
> I have tried it and it does fix my problem. RIP2 over multicast works
> again. :-)
Good to hear. I'm waiting on a bit more feedback but I think I'll be
checking this in soon, with a big comment talking about the
performance implications etc
Greetings,
[EMAIL PROTECTED] wrote:
At Fri, 22 Aug 2008 21:42:00 +0200,
Luigi Rizzo wrote:
On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
[EMAIL PROTECTED] wrote:
I gather you mean that a fast link on which also we're looping back
the packet will be an issue?
On Mon, Aug 25, 2008 at 09:02:07PM +0200, John Hay wrote:
> On Fri, Aug 22, 2008 at 03:03:30PM -0700, [EMAIL PROTECTED] wrote:
> > At Fri, 22 Aug 2008 22:43:39 +0100,
> > Bruce M. Simpson wrote:
> > >
> > > [EMAIL PROTECTED] wrote:
> > > > Somehow the data that the device needs to do the proper ch
On Fri, Aug 22, 2008 at 03:03:30PM -0700, [EMAIL PROTECTED] wrote:
> At Fri, 22 Aug 2008 22:43:39 +0100,
> Bruce M. Simpson wrote:
> >
> > [EMAIL PROTECTED] wrote:
> > > Somehow the data that the device needs to do the proper checksum
> > > offload is getting trashed here. Now, since it's clear w
At Fri, 22 Aug 2008 22:43:39 +0100,
Bruce M. Simpson wrote:
>
> [EMAIL PROTECTED] wrote:
> > Somehow the data that the device needs to do the proper checksum
> > offload is getting trashed here. Now, since it's clear we need a
> > writable packet structure so that we don't trash the original, I'm
[EMAIL PROTECTED] wrote:
Somehow the data that the device needs to do the proper checksum
offload is getting trashed here. Now, since it's clear we need a
writable packet structure so that we don't trash the original, I'm
wondering if the m_pullup() will be sufficient.
If it's serious enoug
At Fri, 22 Aug 2008 19:43:03 +0100,
Bruce M. Simpson wrote:
>
> We end up calling if_simloop() from a few "interesting" places, in
> particular the kernel PIM packet handler.
>
> In this particular case we're going to take a full mbuf chain copy every
> time we send a packet which needs to be l
At Fri, 22 Aug 2008 21:42:00 +0200,
Luigi Rizzo wrote:
>
> On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
> > [EMAIL PROTECTED] wrote:
> > >I gather you mean that a fast link on which also we're looping back
> > >the packet will be an issue? Since this packet is only going into
On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
> [EMAIL PROTECTED] wrote:
> >I gather you mean that a fast link on which also we're looping back
> >the packet will be an issue? Since this packet is only going into the
> >simloop() routine.
> >
>
> We end up calling if_simloop
[EMAIL PROTECTED] wrote:
I gather you mean that a fast link on which also we're looping back
the packet will be an issue? Since this packet is only going into the
simloop() routine.
We end up calling if_simloop() from a few "interesting" places, in
particular the kernel PIM packet handler.
At Fri, 22 Aug 2008 03:27:11 +0100,
Bruce M. Simpson wrote:
>
> [EMAIL PROTECTED] wrote:
> >> The only thing i can think of is that it's the UDP checksum,
> >> residing beyond hlen, which is overwritten somewhere in the
> >> call to if_simloop -- in which case perhaps a better fix is
> >> to m_pul
Luigi Rizzo wrote:
On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote:
[EMAIL PROTECTED] wrote:
The only thing i can think of is that it's the UDP checksum,
residing beyond hlen, which is overwritten somewhere in the
call to if_simloop -- in which case perhaps a better fix
On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote:
> [EMAIL PROTECTED] wrote:
> >>The only thing i can think of is that it's the UDP checksum,
> >>residing beyond hlen, which is overwritten somewhere in the
> >>call to if_simloop -- in which case perhaps a better fix is
> >>to m_pull
[EMAIL PROTECTED] wrote:
The only thing i can think of is that it's the UDP checksum,
residing beyond hlen, which is overwritten somewhere in the
call to if_simloop -- in which case perhaps a better fix is
to m_pullup() the udp header as well ?
It is the checksum that gets trashed, yes.
..
At Thu, 21 Aug 2008 22:35:19 +0200,
Luigi Rizzo wrote:
>
> On Thu, Aug 21, 2008 at 03:11:56PM -0400, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > Turns out there is a bug in the code that loops back multicast
> > packets. If the underlying device driver supports checksum offloading
> > then the pack
On Thu, Aug 21, 2008 at 03:11:56PM -0400, [EMAIL PROTECTED] wrote:
> Hi,
>
> Turns out there is a bug in the code that loops back multicast
> packets. If the underlying device driver supports checksum offloading
> then the packet that is looped back, when it is transmitted on the
> wire, is incor
27 matches
Mail list logo
