Matthew N. Dodd writes:
> >- Rejigger the oltr driver to pass its "secret" information using
> > an auxillary mbuf instead of m->m_pkthdr.header.
> >
> > Any comments/objections?
>
> Please look at the 'kluge' that NetBSD uses.
>
> netinet/if_arp.c:
> trh = (stru
> The whole issue of auxiliary dataa (metadata) and protocol specific
> data storage needs to be solved once and for all..
> (we have our own answer in Netgraph but it's a stopgap)
I adopted the openbsd m_tag stuff and jetisoned m_aux entirely. I did this
for many reasons, not the least is that
On Fri, 7 Jun 2002, Archie Cobbs wrote:
>- Rejigger the oltr driver to pass its "secret" information using
> an auxillary mbuf instead of m->m_pkthdr.header.
>
> Any comments/objections?
Please look at the 'kluge' that NetBSD uses.
netinet/if_arp.c:
trh = (struct
On Fri, 7 Jun 2002, Archie Cobbs wrote:
> Hi,
>
> I'd like to get rid of this mbuf field "m->m_pkthdr.header".
> Here are my reasons:
>
> - It's broken. Consider this code:
>
> copy = m_copypacket(m);
> m_freem(m);
>
>Typically m->m_pkthdr.header points into the data area of
Archie Cobbs writes:
> My proposal:
>
>- Replace the obfuscating GETIP() macro in ip_input.c with a variable.
>- Rejigger the oltr driver to pass its "secret" information using
> an auxillary mbuf instead of m->m_pkthdr.header.
On second thought, it seems that GETIP(m) in ip_input.c
On Fri, Jun 07, 2002 at 12:55:53PM -0700, Archie Cobbs wrote:
> Hi,
>
> I'd like to get rid of this mbuf field "m->m_pkthdr.header".
> Here are my reasons:
>
> - It's broken. Consider this code:
>
> copy = m_copypacket(m);
> m_freem(m);
Indeed, this is a bug in m_copypacket(). I
Hi,
I'd like to get rid of this mbuf field "m->m_pkthdr.header".
Here are my reasons:
- It's broken. Consider this code:
copy = m_copypacket(m);
m_freem(m);
Typically m->m_pkthdr.header points into the data area of 'm'.
So now copy->m_pkthdr.header points at the same data, whi
try to setup this (it won't work) your example does not work
ifconfig fxp0 inet 192.168.1.1/24 up
ifconfig fxp0 inet 192.168.1.1/32 alias
ifconfig fxp0 inet 192.168.1.1/32 alias <--- here it will not work anymore
this is the same thing with vlan interfaces under FreeBSD
you can't have more tha
On Fri, 7 Jun 2002, Iasen Kostov wrote:
>
> I think it's possible to use SIOCSIFCAP to tell the kernel not to set
> host route via IFCAP_NOROUTE or something similar which will set
> IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit()
> and if it is set no host route will
I would be equally happy if I could this :
802.11Q
|
--+ +--vlan1--+ +-+
| FreeBSD Box +- fxp0-+--vlan2--+---Port1-+ Switch +--port4--Host3
--+ +--vlan3--+ +---+--+--+ vlan
I think it's possible to use SIOCSIFCAP to tell the kernel not to set
host route via IFCAP_NOROUTE or something similar which will set
IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit()
and if it is set no host route will be added. And ofcourse there should be
a way to set
÷ Fri, 07.06.2002, × 16:33, Christophe Prevotaux ÎÁÐÉÓÁÌ:
> As I have said before I am using VLAN on FreeBSD ,which is obviously
> 802.11Q, connected to a switch configured with VLAN 802.11Q ports attached
> to the FreeBSD Box on one side thru the ethernet interface of that box.
>
> On the other
As I have said before I am using VLAN on FreeBSD ,which is obviously
802.11Q, connected to a switch configured with VLAN 802.11Q ports attached
to the FreeBSD Box on one side thru the ethernet interface of that box.
On the other side on the same swtich I have vlan ports (802.11Q obviously)
which
В Fri, 07.06.2002, в 15:36, Christophe Prevotaux написал:
> All this is very interesting however I don't think this answers my
> question does it ?
I am a bit not understand for what you have use such strange setup.
And you have not provide enough information, to help you
I need as minimum
you
All this is very interesting however I don't think this answers my
question does it ?
On 06 Jun 2002 18:30:04 +0400
"Vladimir B. " Grebenschikov <[EMAIL PROTECTED]> wrote:
> Ð_ Thu, 06.06.2002, в 14:51, Christophe Prevotaux напиÑ_ал:
> > Hello
> >
> > I have a small problem I can't seem
÷ Fri, 07.06.2002, × 04:36, Joe T. ÎÁÐÉÓÁÌ:
> Hi,
>
> Originally, I had created some aliases with the following command:
>
> # ifconfig dc0 alias 192.168.1.111 255.255.255.255
> # ifconfig dc0 alias 192.168.1.112 255.255.255.255
> ...
>
> This worked fine.. i was able to use the aliases for var
÷ Fri, 07.06.2002, × 12:42, Iasen Kostov ÎÁÐÉÓÁÌ:
> Of course I can do that and on 4.6-RC. Just a little patch in
> netinet/in.c . And I wander who and why he put this "route addition check"
> when kernel tries to set host route for the interface. Before it works
> perfect with just a warring.
On Thu, 6 Jun 2002, Marko Zec wrote:
> "Vladimir B. Grebenschikov" wrote:
>
> > ÷ Thu, 06.06.2002, × 18:48, Marko Zec ÎÁÐÉÓÁÌ:
> >
> > > > # ifconfig fxp0 1.1.1.1/24
> > > > # ifconfig vlan0 1.1.1.1/32
> > > > # ifconfig vlan1 1.1.1.1/32
> > > > # ifconfig vlan2 1.1.1.1/32
> > >
> > > This will
÷ Thu, 06.06.2002, × 22:43, Marko Zec ÎÁÐÉÓÁÌ:
> In your original post, you were suggesting to put the same IP/mask on different
> "real" interfaces, not loopback. Could you pls. try to create a couple of vlan
> interfaces (ifconfig vlan0 create...), than configure them with the same IP
> address
19 matches
Mail list logo
