Current problem reports assigned to you

[FreeBSD bugmaster]

Current FreeBSD problem reports
Critical problems
Serious problems

S  Submitted   Tracker Resp.   Description
---
o [2005/05/19] ia64/81284  net Unaligned Reference with pf on 5.4/IA64

1 problem total.

Non-critical problems

S  Submitted   Tracker Resp.   Description
---
o [2003/07/11] kern/54383  net [nfs] [patch] NFS root configurations wit

1 problem total.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPC between vimage instances?

[Ragnar Lonn]

Julian Elischer wrote:


Ragnar Lonn wrote:


Hello,

I've been using vimage on FreeBSD 4.11 along with Netgraph to setup a 
system
that simulates many physical client machines for the purpose of 
testing broadband
Internet access hardware. I have hundreds of vimages, each with its 
own ngeth0
network interface connected via Netgraph to a real physical 
interface. It is working
very well indeed but now I'm trying to setup logging from the various 
vimage

instances and have run into problems. Each vimage runs applications that
I want to log the output from in an orderly manner. I'd like to use 
syslog but as
it turns out, the processes inside a vimage cannot communicate with 
the syslogd
in the "default" vimage. I tried logging to the Unix domain socket 
/var/run/log but

that didn't work from within a vimage (other than "default" of course).



did you ask syslog to open sockets in all the chroots?
I assume yes.. I hadn't realised that the vimage code separates
unix domain sockets etc. but I guess that makes sense.



Actually, I don't chroot the vimages as of now. They see the same filesystem
all of them but writing to the syslogd unix domain socket didn't work 
anyhow.

I'm both happy and frustrated at seeing how well separated vimages are
sometimes :-)


As you mention, the usual answer is to get the syslog on each system to
forward everything to one logging system.

you could add a second interface to each vimage just for logging to
keep it separate from the testing..



Hmm, I have avoided this because I didn't want to do a lot of interface
housekeeping. Actually, this leads to another question of mine :-)

Network interfaces can't be removed under FreeBSD, something that
causes me a lot of trouble as I create many interfaces and move them to many
vimages. Then I remove vimages in order to create new ones (reconfigure the
client simulation setup) and the network interfaces get dumped into the 
default

vimage, from where I have to collect them. I cant just create new interfaces
when the setup is to be reconfigured because I can't delete the old 
interfaces.


Or can I?

Example:

ngctl mkpeer . eiface hook ether

...results in [EMAIL PROTECTED] being created. Then I do:

ngctl shutdown ngeth0:

..and the interface is gone. Seems that doing a shutdown actually causes the
interface to get removed, right?  But then I do something like this:

# create [EMAIL PROTECTED]
ngctl mkpeer . eiface hook ether
# create [EMAIL PROTECTED]
ngctl mkpeer . eiface hook ether
# move ngeth1
vimage -i myvimage ngeth1

the interface is moved to [EMAIL PROTECTED] Then I do:

ngctl shutdown ngeth0:
vimage myvimage
vimage -i - ngeth0

...and the interface is moved back to the deafult vimage, BUT it is
named [EMAIL PROTECTED] Even though [EMAIL PROTECTED] has been shutdown
and is nowhere to be seen. This makes me suspect that interfaces aren't
properly removed when I issue a shutdown even though they might seem to
be gone, and I have therefore decided to reuse interfaces, rather than
remove them.

Is this assumption correct?Or is it just a naming issue that won't 
result

in some resource exhaustion eventually if I continue creating, moving
and removing interfaces?

Being able to remove interfaces would be really great. Then I could
create extra logging interfaces in each vimage and not worry about
the cleanup nightmare afterwards. Right now, I have a lot of script
code just to find and reuse old ngeth interfaces sitting around in the
default vimage and if I'm to have two types of those interfaces
(one for logging, that has one underlying netgraph tree structure, and
one for test traffic, using another netgraph tree structure) it would
likely be at least twice as much trouble. That's why I was looking for
some other way of communicating between different vimages.

Regards,

 /Ragnar







___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

MAC address & rc.conf

[Peter]

   Hi,
   My ISP have aauthorization by username, password AND mac address.
   I currently make PPPoE connection from my laptop(win XP) to them.
   However I want to put FreeBSD router in front of my laptop.
   That is why I will need to make MAC address of outgoing ethernet card
   same as my laptop.
   I plan to make bash script(ifconfig down, ifconfig up)  for that
   purpose.
   However I prefer a little bit cleaner solution ...
is there any way I can set MAC address for the network card in
   rc.conf ?
   Thanks :-)))
   Kind regards,
   Peter
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPC between vimage instances?

[Milan Obuch]

On Monday 13 June 2005 13:46, Ragnar Lonn wrote:
> Julian Elischer wrote:
> > Ragnar Lonn wrote:
> >> Hello,
> >>
> >> I've been using vimage on FreeBSD 4.11 along with Netgraph to setup a
> >> system
> >> that simulates many physical client machines for the purpose of
> >> testing broadband
> >> Internet access hardware. I have hundreds of vimages, each with its
> >> own ngeth0
> >> network interface connected via Netgraph to a real physical
> >> interface. It is working
> >> very well indeed but now I'm trying to setup logging from the various
> >> vimage
> >> instances and have run into problems. Each vimage runs applications that
> >> I want to log the output from in an orderly manner. I'd like to use
> >> syslog but as
> >> it turns out, the processes inside a vimage cannot communicate with
> >> the syslogd
> >> in the "default" vimage. I tried logging to the Unix domain socket
> >> /var/run/log but
> >> that didn't work from within a vimage (other than "default" of course).
> >
> > did you ask syslog to open sockets in all the chroots?
> > I assume yes.. I hadn't realised that the vimage code separates
> > unix domain sockets etc. but I guess that makes sense.
>
> Actually, I don't chroot the vimages as of now. They see the same
> filesystem all of them but writing to the syslogd unix domain socket didn't
> work anyhow.
> I'm both happy and frustrated at seeing how well separated vimages are
> sometimes :-)
>

Are you talking about Marko Zec's network virtualisation patch? If yes, then 
you need one simple patch to allow AF_UNIX (named pipes) to work between 
images. I do not have it at hand now, but if you need it, I could search my 
archives...
Regards,
Milan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Carp Suppression

[Josh Kayse]

One last comment,

I managed to fix it so that carp runs on the plip interface by adding:
ifp->if_flags = LINK_STATE_UP;

Here is the diff:

diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c /usr/src/sys/dev/ppbus/if_plip.c
--- /usr.orig/src/sys/dev/ppbus/if_plip.c   Wed Sep 15 11:14:18 2004
+++ /usr/src/sys/dev/ppbus/if_plip.cMon Jun 13 10:05:56 2005
@@ -359,6 +359,7 @@

ppb_wctr(ppbus, IRQENABLE);
ifp->if_flags |= IFF_RUNNING;
+   ifp->if_flags = LINK_STATE_UP;
}
break;



On 6/11/05, Josh Kayse <[EMAIL PROTECTED]> wrote:
> I think I've narrowed it down to the plip interface, but I'm not
> completely sure.  Has anyone gotten carp running over a plip
> interface?
> 
> On 6/10/05, Josh Kayse <[EMAIL PROTECTED]> wrote:
> > I am cross-posting this to -net and -pf because I am not sure where it goes.
> >
> > I am running 2 carp interfaces on a pair of transparent firewalls
> > running FreeBSD 5.4.
> >
> > One of the interfaces is a xl interface and the other is a plip interface.
> >
> > I am having trouble in that the carp interfaces are not failing over
> > between the 2 machines.
> >
> > When I check net.inet.carp.suppress_preempt it returns 1 and I do not
> > understand why that is.
> >
> > Can anyone shed some light on this?
> >
> > If you need any more information, just let me know.
> >
> > Thanks
> >
> > Josh
> > --
> > Joshua Kayse
> > Computer Engineering
> >
> 
> 
> --
> Joshua Kayse
> Computer Engineering
> 


-- 
Joshua Kayse
Computer Engineering
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Carp Suppression

[PSI, Mike Smith]

Hey all,

Honestly I have no idea what this is all about, but saw something in the
change adding "ipf->if_flags=LINK_STATE_UP;" that just seemed really strange
from a programming standpoint. Doesn't this statement "undo" the effects of
the line just before it (ipf->if_flags |= IFF_RUNNING).

Again I have no idea what this is about so it is possible that IFF_RUNNING
bit(s) is part of LINK_STATE_UP bit(s). Just seemed strange and if this is a
problem, catching it early is better than late.

If it is correct as stands, I apologize for questioning it.

Mike Smith


>- Original Message - 
>From: "Josh Kayse" <[EMAIL PROTECTED]>
>
> One last comment,
>
> I managed to fix it so that carp runs on the plip interface by adding:
> ifp->if_flags = LINK_STATE_UP;

> Here is the diff:

> diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c
/usr/src/sys/dev/ppbus/if_plip.c
> --- /usr.orig/src/sys/dev/ppbus/if_plip.c   Wed Sep 15 11:14:18 2004
> +++ /usr/src/sys/dev/ppbus/if_plip.cMon Jun 13 10:05:56 2005
> @@ -359,6 +359,7 @@
>
> ppb_wctr(ppbus, IRQENABLE);
> ifp->if_flags |= IFF_RUNNING;
> +   ifp->if_flags = LINK_STATE_UP;
> }
> break;



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

FreeBSD, AODV and OLSR

[Rae Harbird]

Hi

I want to run some experiments with FreeBSD 4.11-RELEASE  and user-space
AODV and OLSR implementations. Currently, I'm thinking of trying:

UoB JAdhoc v0.21:
http://www.aodv.org/modules.php?op=modload&name=UpDownload&file=index&req=viewdownload&cid=2

and NRL OLSR:
http://pf.itd.nrl.navy.mil/projects.php?name=olsr

Does anyone have any positive / negative experiences of these
implementations with FreeBSD?


Thanks



Rae




--

Rae Harbird



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Carp Suppression

[Yar Tikhiy]

On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote:
> One last comment,
> 
> I managed to fix it so that carp runs on the plip interface by adding:
> ifp->if_flags = LINK_STATE_UP;
> 
> Here is the diff:
> 
> diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c 
> /usr/src/sys/dev/ppbus/if_plip.c
> --- /usr.orig/src/sys/dev/ppbus/if_plip.c   Wed Sep 15 11:14:18 2004
> +++ /usr/src/sys/dev/ppbus/if_plip.cMon Jun 13 10:05:56 2005
> @@ -359,6 +359,7 @@
> 
> ppb_wctr(ppbus, IRQENABLE);
> ifp->if_flags |= IFF_RUNNING;
> +   ifp->if_flags = LINK_STATE_UP;
> }
> break;

I'm afraid you're totally wrong here.

First, I can't see how CARP is supposed to work on a PLIP interface
or any point-to-point interface at all.  CARP is for broadcast
interfaces, such as Ethernet or FDDI, which do ARP.  You seem to miss
the point.

Second, you can't store an arbitrary value into a variable or field
and expect the things to work right.  LINK_STATE_UP simply is not for
ifp->if_flags.  Please make yourself familiar with the basics of
computer programming before offering your patches to the community.

-- 
Yar
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Carp Suppression

[Josh Kayse]

Definitely a typo on my part.  It should be
ifp->if_link_state = LINK_STATE_UP

The reason we are using CARP on a PLIP interface is to allow us to
have redundant connections between 2 transparent bridging firewalls. 
Instead of sending packets over our network, we isolate them onto a
PLIP interface and crossover interface.  We then use ifstaded to
monitor the carp interfaces and shut down bridging on one of the
machines.

I will refrain from submitting any code to the community in the future.

On 6/13/05, Yar Tikhiy <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote:
> > One last comment,
> >
> > I managed to fix it so that carp runs on the plip interface by adding:
> > ifp->if_flags = LINK_STATE_UP;
> >
> > Here is the diff:
> >
> > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c 
> > /usr/src/sys/dev/ppbus/if_plip.c
> > --- /usr.orig/src/sys/dev/ppbus/if_plip.c   Wed Sep 15 11:14:18 2004
> > +++ /usr/src/sys/dev/ppbus/if_plip.cMon Jun 13 10:05:56 2005
> > @@ -359,6 +359,7 @@
> >
> > ppb_wctr(ppbus, IRQENABLE);
> > ifp->if_flags |= IFF_RUNNING;
> > +   ifp->if_flags = LINK_STATE_UP;
> > }
> > break;
> 
> I'm afraid you're totally wrong here.
> 
> First, I can't see how CARP is supposed to work on a PLIP interface
> or any point-to-point interface at all.  CARP is for broadcast
> interfaces, such as Ethernet or FDDI, which do ARP.  You seem to miss
> the point.
> 
> Second, you can't store an arbitrary value into a variable or field
> and expect the things to work right.  LINK_STATE_UP simply is not for
> ifp->if_flags.  Please make yourself familiar with the basics of
> computer programming before offering your patches to the community.
> 
> --
> Yar
> 


-- 
Joshua Kayse
Computer Engineering
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MAC address & rc.conf

[Adam Gregoire]

You need to create a file called start_if.[interface name] and set the
mac there.

Like this:

ebola$ cat /etc/start_if.de0
#!/bin/sh
ifconfig de0 ether c0ffeec0ffee
ifconfig de0 media 10baseT/UTP

Regards,

-- 
Adam Gregoire <[EMAIL PROTECTED]>

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Carp Suppression

[Greg Hennessy]

 
> The reason we are using CARP on a PLIP interface is to allow 
> us to have redundant connections between 2 transparent 
> bridging firewalls. 

CARP is not going to work with a layer 2 firewall. 

> Instead of sending packets over our network, we isolate them 
> onto a PLIP interface and crossover interface.

That not going to work on a point to point connection, the other party
cannot see the carp traffic. 
never mind the overhead that running plip puts on a system, a length of
baling twine would make for a better physical transport.  

>  We then use 
> ifstaded to monitor the carp interfaces and shut down 
> bridging on one of the machines.

Spanning tree is a no brainer for such a setup, pfsync takes care of the
rest. 

http://www.seattlecentral.edu/~dmartin/docs/bridge.html



Greg


> 
> I will refrain from submitting any code to the community in 
> the future.
> 
> On 6/13/05, Yar Tikhiy <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote:
> > > One last comment,
> > >
> > > I managed to fix it so that carp runs on the plip 
> interface by adding:
> > > ifp->if_flags = LINK_STATE_UP;
> > >
> > > Here is the diff:
> > >
> > > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c 
> /usr/src/sys/dev/ppbus/if_plip.c
> > > --- /usr.orig/src/sys/dev/ppbus/if_plip.c   Wed Sep 
> 15 11:14:18 2004
> > > +++ /usr/src/sys/dev/ppbus/if_plip.cMon Jun 13 10:05:56 2005
> > > @@ -359,6 +359,7 @@
> > >
> > > ppb_wctr(ppbus, IRQENABLE);
> > > ifp->if_flags |= IFF_RUNNING;
> > > +   ifp->if_flags = LINK_STATE_UP;
> > > }
> > > break;
> > 
> > I'm afraid you're totally wrong here.
> > 
> > First, I can't see how CARP is supposed to work on a PLIP 
> interface or 
> > any point-to-point interface at all.  CARP is for broadcast 
> > interfaces, such as Ethernet or FDDI, which do ARP.  You 
> seem to miss 
> > the point.
> > 
> > Second, you can't store an arbitrary value into a variable or field 
> > and expect the things to work right.  LINK_STATE_UP simply 
> is not for
> > ifp->if_flags.  Please make yourself familiar with the basics of
> > computer programming before offering your patches to the community.
> > 
> > --
> > Yar
> > 
> 
> 
> --
> Joshua Kayse
> Computer Engineering
> ___
> freebsd-pf@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MAC address & rc.conf

[Brooks Davis]

On Mon, Jun 13, 2005 at 12:49:37PM -0400, Adam Gregoire wrote:
> You need to create a file called start_if.[interface name] and set the
> mac there.
> 
> Like this:
> 
> ebola$ cat /etc/start_if.de0
> #!/bin/sh
> ifconfig de0 ether c0ffeec0ffee
> ifconfig de0 media 10baseT/UTP

This is pretty much what you'll need to do in 4 and 5.  In 6 you can
just put a line like this in /etc/rc.conf:

ifconfig_de0="ether c0ffeec0ffee media 10baseT/UTP DHCP"

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp3jZyhLscjU.pgp
Description: PGP signature

Re: IPC between vimage instances?

[Julian Elischer]

Ragnar Lonn wrote:





As you mention, the usual answer is to get the syslog on each system to
forward everything to one logging system.

you could add a second interface to each vimage just for logging to
keep it separate from the testing..




Hmm, I have avoided this because I didn't want to do a lot of interface
housekeeping. Actually, this leads to another question of mine :-)

Network interfaces can't be removed under FreeBSD, something that
causes me a lot of trouble as I create many interfaces and move them 
to many
vimages. Then I remove vimages in order to create new ones 
(reconfigure the
client simulation setup) and the network interfaces get dumped into 
the default
vimage, from where I have to collect them. I cant just create new 
interfaces
when the setup is to be reconfigured because I can't delete the old 
interfaces.



interface removal in 4.x was nt quite "finished"
there are several viewpoints from which th einterface is not quite removed.
(as you have found)
I can not remember the details as It all changed in 5.x
(though vimage doesn't work in 5.x )



Or can I?

Example:

ngctl mkpeer . eiface hook ether

...results in [EMAIL PROTECTED] being created. Then I do:

ngctl shutdown ngeth0:

..and the interface is gone. Seems that doing a shutdown actually 
causes the

interface to get removed, right?  But then I do something like this:

# create [EMAIL PROTECTED]
ngctl mkpeer . eiface hook ether
# create [EMAIL PROTECTED]
ngctl mkpeer . eiface hook ether
# move ngeth1
vimage -i myvimage ngeth1

the interface is moved to [EMAIL PROTECTED] Then I do:

ngctl shutdown ngeth0:
vimage myvimage
vimage -i - ngeth0

...and the interface is moved back to the deafult vimage, BUT it is
named [EMAIL PROTECTED] Even though [EMAIL PROTECTED] has been shutdown
and is nowhere to be seen. This makes me suspect that interfaces aren't
properly removed when I issue a shutdown even though they might seem to
be gone, and I have therefore decided to reuse interfaces, rather than
remove them.


it's possible that the unit number is stored in the ng_ether driver and 
is therefore
not split for the vimages. so if the code gets a new unit number for 
the  new instance before

removing the old instance, the unit number will be 1 and not 0..

just a quess.




Is this assumption correct?Or is it just a naming issue that won't 
result

in some resource exhaustion eventually if I continue creating, moving
and removing interfaces?

Being able to remove interfaces would be really great. Then I could
create extra logging interfaces in each vimage and not worry about
the cleanup nightmare afterwards. Right now, I have a lot of script
code just to find and reuse old ngeth interfaces sitting around in the
default vimage and if I'm to have two types of those interfaces
(one for logging, that has one underlying netgraph tree structure, and
one for test traffic, using another netgraph tree structure) it would
likely be at least twice as much trouble. That's why I was looking for
some other way of communicating between different vimages.



"use the source Luke"
I know it seems like a lot but the netgraph code and the networking 
interface code are

relatively simple..



Regards,

 /Ragnar







___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Carp Suppression

[Josh Kayse]

On 6/13/05, Greg Hennessy <[EMAIL PROTECTED]> wrote:
> 
> > The reason we are using CARP on a PLIP interface is to allow
> > us to have redundant connections between 2 transparent
> > bridging firewalls.
> 
> CARP is not going to work with a layer 2 firewall.
It's running over the PLIP interface and the crossover cable. 
ifstated will change the advskew of the carp interfaces if one of the
bridging interfaces goes down.
> 
> > Instead of sending packets over our network, we isolate them
> > onto a PLIP interface and crossover interface.
> 
> That not going to work on a point to point connection, the other party
> cannot see the carp traffic.
> never mind the overhead that running plip puts on a system, a length of
> baling twine would make for a better physical transport.
Both firewalls can see the carp information over the PLIP connection,
so I assume it works.
And it wasn't my choice to use the plip interface.
> 
> >  We then use
> > ifstaded to monitor the carp interfaces and shut down
> > bridging on one of the machines.
> 
> Spanning tree is a no brainer for such a setup, pfsync takes care of the
> rest.
> 
We did not want to go with STP because it would not be a self
contained solution.  Now we can use these firewalls anywhere without
having to modify any routers, just plug them in inline and it is set. 
We also wanted to stick with FreeBSD because we have a knowledgebase
already set up for it and we know how to use it.  Unfortunately, there
is no support for STP in freebsd bridging.  Yes, I had already looked
into using pfsync and STP, we also considered just using scripts.

Anyway, I don't want to try and defend myself on our setup.  We have
everything working now and I just wanted to let others know how they
could use carp over PLIP if they so needed to.
> http://www.seattlecentral.edu/~dmartin/docs/bridge.html
> 
> 
> 
> Greg
> 
> 
> >
> > I will refrain from submitting any code to the community in
> > the future.
> >
> > On 6/13/05, Yar Tikhiy <[EMAIL PROTECTED]> wrote:
> > > On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote:
> > > > One last comment,
> > > >
> > > > I managed to fix it so that carp runs on the plip
> > interface by adding:
> > > > ifp->if_flags = LINK_STATE_UP;
> > > >
> > > > Here is the diff:
> > > >
> > > > diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c
> > /usr/src/sys/dev/ppbus/if_plip.c
> > > > --- /usr.orig/src/sys/dev/ppbus/if_plip.c   Wed Sep
> > 15 11:14:18 2004
> > > > +++ /usr/src/sys/dev/ppbus/if_plip.cMon Jun 13 10:05:56 2005
> > > > @@ -359,6 +359,7 @@
> > > >
> > > > ppb_wctr(ppbus, IRQENABLE);
> > > > ifp->if_flags |= IFF_RUNNING;
> > > > +   ifp->if_flags = LINK_STATE_UP;
> > > > }
> > > > break;
> > >
> > > I'm afraid you're totally wrong here.
> > >
> > > First, I can't see how CARP is supposed to work on a PLIP
> > interface or
> > > any point-to-point interface at all.  CARP is for broadcast
> > > interfaces, such as Ethernet or FDDI, which do ARP.  You
> > seem to miss
> > > the point.
> > >
> > > Second, you can't store an arbitrary value into a variable or field
> > > and expect the things to work right.  LINK_STATE_UP simply
> > is not for
> > > ifp->if_flags.  Please make yourself familiar with the basics of
> > > computer programming before offering your patches to the community.
> > >
> > > --
> > > Yar
> > >
> >
> >
> > --
> > Joshua Kayse
> > Computer Engineering
> > ___
> > freebsd-pf@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
> >
> 
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 


-- 
Joshua Kayse
Computer Engineering
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Carp Suppression

[Brooks Davis]

On Mon, Jun 13, 2005 at 01:35:12PM -0400, Josh Kayse wrote:
> On 6/13/05, Greg Hennessy <[EMAIL PROTECTED]> wrote:
> > >  We then use
> > > ifstaded to monitor the carp interfaces and shut down
> > > bridging on one of the machines.
> > 
> > Spanning tree is a no brainer for such a setup, pfsync takes care of the
> > rest.
> > 
> We did not want to go with STP because it would not be a self
> contained solution.  Now we can use these firewalls anywhere without
> having to modify any routers, just plug them in inline and it is set. 
> We also wanted to stick with FreeBSD because we have a knowledgebase
> already set up for it and we know how to use it.  Unfortunately, there
> is no support for STP in freebsd bridging.  Yes, I had already looked
> into using pfsync and STP, we also considered just using scripts.

FYI, we have STP via if_bridge in 6.x.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgpSDiZVFiMmz.pgp
Description: PGP signature

Re: FreeBSD, AODV and OLSR

[spoggle]

You might try the olsr.org  implementation, it's in the 
ports tree under net/olsrd.

I believe it is better tested (via a 50+ node mesh in Berlin) than the NRL 
one. It also has some extensions that are useful, especially the ability to 
incorporate quality metrics and interface preference in routing.

The version in ports can be compiled to use libnet to provide the ability to 
operate on multiple interfaces.

If you try it and run into any problems, please let me know, I am a 
committer to olsr.org  and the originator of the FreeBSD 
port.

dave c

On 6/13/05, Rae Harbird <[EMAIL PROTECTED]> wrote:
> 
> Hi
> 
> I want to run some experiments with FreeBSD 4.11-RELEASE and user-space
> AODV and OLSR implementations. Currently, I'm thinking of trying:
> 
> UoB JAdhoc v0.21:
> 
> http://www.aodv.org/modules.php?op=modload&name=UpDownload&file=index&req=viewdownload&cid=2
> 
> and NRL OLSR:
> http://pf.itd.nrl.navy.mil/projects.php?name=olsr
> 
> Does anyone have any positive / negative experiences of these
> implementations with FreeBSD?
> 
> 
> Thanks
> 
> 
> 
> Rae
> 
> 
> 
> 
> --
> 
> Rae Harbird
> 
> 
> 
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64

[Marcel Moolenaar]

Synopsis: Unaligned Reference with pf on 5.4/IA64

Responsible-Changed-From-To: freebsd-net->freebsd-pf
Responsible-Changed-By: marcel
Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005
Responsible-Changed-Why: 
Move to a more pf-focussed responsible party.

http://www.freebsd.org/cgi/query-pr.cgi?pr=81284
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"