In my MAC tree, I add an additional:
struct mbuf *aux; /* extra data buffer; ipsec/others */
+ struct mac label; /* label of data in packet */
};
As we move towards more generalized access control, it would similarly be
nice to have a place to 'hang' a
< said:
> I'd be happy with a HAS_A(mbuf), as long as I have SOMEWHERE,
> to stash the metadata.
Mind, you don't put the metadata there; you put that in the packet
structure (or rather, in the ip_packet etc. structures). I'd like to
get rid of mbufs entirely, but that's a whole 'nother kettle
On Fri, 16 Nov 2001, Luigi Rizzo wrote:
> > so far there hasn't been a lot of suggestion as to how the goal can be
> > achieved however..
>
> i actually suggested one i.e. have explicit pointers
> to metadata area(s) in the pkthdr. I think you forget the
> most fundamental feature which is per
On Fri, 16 Nov 2001, Garrett Wollman wrote:
> <
>said:
>
> > (and anyhow Garrett got rid of the 'static' uses
> > of mbufs, not 'travelling' 'per packet' uses..)
>
> Only because I did not have the time or stomach then to introduce
> `struct packet' everywhere. All of the queueing and metad
ok, so how would you envision it? example?
Adding fields to the pkthdr? (and flags to say
what they are used for).
A pointer to route,
(maybe the route in ip_forward() can be dynamically allocated on the
stack, I'm not sure yet)
A pointer to a sockaddr, with a flag to say if it's for
'fwd' use
< said:
> (and anyhow Garrett got rid of the 'static' uses
> of mbufs, not 'travelling' 'per packet' uses..)
Only because I did not have the time or stomach then to introduce
`struct packet' everywhere. All of the queueing and metadata crap
should be pulled out of mbufs and put into a higher-le
> so far there hasn't been a lot of suggestion as to how the goal can be
> achieved however..
i actually suggested one i.e. have explicit pointers
to metadata area(s) in the pkthdr. I think you forget the
most fundamental feature which is performance.
This is way more important than flexibility i
On Fri, 16 Nov 2001, Luigi Rizzo wrote:
> On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote:
>
> > it. MT_DUMMYNET must die, not be propagated elsewhere.
>
> i agree!
>
> cheers
> luigi
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-curr
Alfred Perlstein wrote:
>
> * Peter Wemm <[EMAIL PROTECTED]> [06 18:02] wrote:
> > Julian Elischer wrote:
> > [..]
> > > What is needed is obviously a 'per packet' storage location
> > > for those things, defined in a "per protocol family" manner.
> > >
> > > Luigi has already tried this sche
Well I don't care exactly how we do it but we need to
figure out a way of storing such metadata along with packets.
and it needs to be queueable along with the packets..
(sounds like an mbuf to me but if you have a better idea.)
(and anyhow Garrett got rid of the 'static' uses
of mbufs, not 't
* Peter Wemm <[EMAIL PROTECTED]> [06 18:02] wrote:
> Julian Elischer wrote:
> [..]
> > What is needed is obviously a 'per packet' storage location
> > for those things, defined in a "per protocol family" manner.
> >
> > Luigi has already tried this scheme by defining a
> > dummynet specific
On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote:
> it. MT_DUMMYNET must die, not be propagated elsewhere.
i agree!
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
struct pkthdr already has a field (struct mbuf *aux)
which i think is used to store info per-packet
state by ipsec, at least according to the comment
(my dummynet hack predated this, i would have used
this field if it had been available at the time).
So this field could be used to access the metad
Julian Elischer wrote:
[..]
> What is needed is obviously a 'per packet' storage location
> for those things, defined in a "per protocol family" manner.
>
> Luigi has already tried this scheme by defining a
> dummynet specific mbuf type that can be prepended to the
> front of packets. What I s
For work related erasons I've been in the IP stack
(basically just IP actually) recently. It's obvious
that there are re-entrancy problems there.
Here are two examples..
Routed packets:
a packet that is routed, uses a single static 'route' entry...
(In ip_input.c)
Right next to it is a sockadd
Here is a fixed version of this patch. last one used an unitialised
variable.
Note: the whole ipfw/fwd scheme is non re-entrant. to fix it and some
other parts
of the code will require that we gain teh capability of associating
extra state with a packet.. e.g. "this packet has been diverted"
or
Hi all,
I run experiments to measure the stability of router queue length.
In my experiment set up, I have 7 clients and 7 servers connected
to a router via an ELS-100 switch. The 7 clients and 7 servers establish
long-lived TCP connections and saturate the router's 10 Mbit link.
All machines run
ethfw should be implemented as a negraph module...
(all teh hooks are already there)
On Fri, 16 Nov 2001, Mikel King wrote:
> Chrisy Luke wrote:
>
> > Mikel King wrote (on Nov 16):
> > > Just curious, but what's a doddle?
> >
> > It's like a doodle, but with less o's and more d's. :)
> >
> > I
ignore this mail
it was sent in error.. the answer was to a different email
On Fri, 16 Nov 2001, Julian Elischer wrote:
> The person who you really have to speak to is Andre Oppermann
> Unfortunatly he just left his job and so I don't have his new email
> address on me..
> I wrote the basic dri
I believe there's a regedit that you need to perform to enable the
termserver to recognise itself behind the firewall. I can't for the life
of me remember exactly what, but I know it's in their knowledge base
somewhere...
cheers,
mikel
Tony Saign wrote:
> Anyone have any ideas on why this pro
A "doddle" is "a task so easy that you could do it in your sleep"
(BTW the patch has a small bug.. but the fix is trivial.)
On Fri, 16 Nov 2001, Mikel King wrote:
> Just curious, but what's a doddle?
>
> Cheers,
> mikel
>
> Julian Elischer wrote:
>
> > On Thu, 15 Nov 2001, Chrisy Luke wrot
The person who you really have to speak to is Andre Oppermann
Unfortunatly he just left his job and so I don't have his new email
address on me..
I wrote the basic driver for him and he has the legal side of it..
julian
On Fri, 16 Nov 2001, Shoichi Sakane wrote:
> > What about info in regards t
>From the keyboard of Tony Saign, written on Fri, Nov 16, 2001 at 08:27:18AM -0800:
> Anyone have any ideas on why this program wouldn't work through a
> FreeBSD 4.4 system using NAT & IPFW??
>
>{Can connect to
> Internet host running TS or RDP}
>
>From the keyboard of Erik Norvelle, written on Fri, Nov 16, 2001 at 04:54:07AM -0700:
> Lars (and anyone else who can help):
>
> I have attempted to follow your advice, by configuring my machines to use
> IPSEC tunnel mode only. However, I still can't get ping packets to go
> between the two in
>From the keyboard of Smith, Rick, written on Thu, Nov 15, 2001 at 10:50:41PM -0500:
>
> What's the difference between tunnel and transport mode configs in
> racoon ?
To understand the difference between transport-mode (let's say host-to-host)
or tunnel-mode (if one of the machines is a security
Erik Norvelle wrote:
> --- Begin included file --- flush; spdflush;
>
> # Note that the add rules are the same as on Node B! spdadd
> 10.20.0.0/24 192.168.1.0/24 any -P in ipsec
esp/tunnel/xxx.yyy.40.122-xxx.yyy.40.135/require;
>
> spdadd 192.168.1.0/24 10.20.0.0/24 any -P out ipsec
esp/
Chrisy Luke wrote:
> Mikel King wrote (on Nov 16):
> > Just curious, but what's a doddle?
>
> It's like a doodle, but with less o's and more d's. :)
>
> It essentially means "this is easy to do".
>
> Chris.
> --
> == [EMAIL PROTECTED]T: +44 845 333 0122
> == Gl
On Fri, Nov 16, 2001 at 06:27:25AM -0800, CJTT wrote:
> (I'll temporarily remove the VLAN support from the kernel).
> But when this is MFC'd, what will I need to do in order to
> continue seeing all traffic on the main interface
> (while using libpcap (tcpdump))?
>
> Will the VLAN_INPUT_TAG ma
Anyone have any ideas on why this program wouldn't work through a
FreeBSD 4.4 system using NAT & IPFW??
I can connect to systems outside on the Internet, but not internal
systems on the same subnet.
INTERNET---
[1] >> <216.120.x.x>
[2] >> <192.168.1.1>
Mikel King wrote (on Nov 16):
> Just curious, but what's a doddle?
It's like a doodle, but with less o's and more d's. :)
It essentially means "this is easy to do".
Chris.
--
== [EMAIL PROTECTED]T: +44 845 333 0122
== Global IP Network Engineering, Easynet G
Just curious, but what's a doddle?
Cheers,
mikel
Julian Elischer wrote:
> On Thu, 15 Nov 2001, Chrisy Luke wrote:
> > > > only packets already leaving the system can be hijacked and forwarded
> > > > to a 2nd machine. Incoming packets can only be forwarded to local
> > > > addresses/port combin
On Thu, 15 Nov 2001, Brooks Davis wrote:
> For the moment, on stable hosts, that will work. Driver vlan support is
> no longer optional in current and that change will be MFC'd just as soon
> as I get it tested. The right answer is probably to modify the
> VLAN_INPUT_TAG macro to do the bpf stuf
Lars (and anyone else who can help):
I have attempted to follow your advice, by configuring my machines to use
IPSEC tunnel mode only. However, I still can't get ping packets to go
between the two internal networks. My /etc/ipsec.conf files on both
machines are as follows:
--- Begin included f
33 matches
Mail list logo
