Julian, good day.
> >+.Pp
> >+The packets destined to the bridging host will be seen by the filter
> >+on the interface with the MAC address equal to the packet's destination
> >+MAC. Be prepated to the situation when some of the bridge members are
> >sharing
>
> prepated to ?
> prepared for? ??
Doug Barton wrote:
>
> If it's reasonable to conclude that we want all the firewalls to start
> before netif, I see two ways to accomplish that. One would be to have
> netif REQUIRE ipfilter, pf, and ipfw. In some ways I think this is
> cleaner, but netif already has a pretty long REQUIRE line. The
The reason the drivers drop their locks is
that the network stack frequently holds locks over calls to driver output
routines. As a result, driver locks tend to follow network stack locks in the
lock order--at least, for drivers that have a single lock covering both send
and receive paths (quite
[ Re-locating this thread from -stable. ]
Mark Andrews wrote:
On Saturday 17 March 2007 03:58, Mark Andrews wrote:
nothing goes to this machine because by default everything is blocked
until
you permit it
You're absolutely correct, however your original post seems to have
taken many of us by
Aniruddha Bohra wrote:
Hi,
In two drivers, fxp and em, the assumptions about entering the
ether_input routine are different.
From em_rxeof:
#ifdef DEVICE_POLLING
EM_UNLOCK()
(*ifp->if_input)()
EM_UNLOCK()
#else
(*ifp->if_input)()
#endif
While in fxp:
FXP_UNLOCK()
(*ifp->if_input)()
FXP_LOC
On 3/17/07, Max Laier <[EMAIL PROTECTED]> wrote:
On Saturday 17 March 2007 20:30, Andrew Pantyukhin wrote:
> On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Can someone please explain the difference between Wireshark
> > and Wireshark-lite. I would like to install a packet sniffer
>
On Saturday 17 March 2007 20:30, Andrew Pantyukhin wrote:
> On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Can someone please explain the difference between Wireshark
> > and Wireshark-lite. I would like to install a packet sniffer
> > on my FreeBSD box for CLI only.
>
> lite = cli on
The change itself is very simple;
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=1.95&r2=1.96
This change is necessary before IPv4 address scope and source selection
policy may be implemented.
Does anyone see any potential problems with this? It is possible that
there
I have just committed reference counting for multicast structures in p4.
Change list number is 116036.
This should fix the problems with pfsync and carp since the scalability
fixes for IPv4 multicast last September. A further cumulative fix for
pfsync is present in this branch.
Basic testing
On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Can someone please explain the difference between Wireshark
and Wireshark-lite. I would like to install a packet sniffer
on my FreeBSD box for CLI only.
lite = cli only
___
freebsd-net@freebsd.o
Good day.
Tue, Mar 13, 2007 at 08:50:29AM +0300, Eygene Ryabinkin wrote:
> Sure. And that is why all switches that can bear the IP on their
> interfaces have distinct MACs for each interface or/and the only
> one interface can have the IP. And that is why I am going to
> add the paragraph to the
On Saturday 17 March 2007 19:16, [EMAIL PROTECTED] wrote:
> Can someone please explain the difference between Wireshark and
> Wireshark-lite. I would like to install a packet sniffer on my FreeBSD
> box for CLI only. Thanks,
What's wrong with tcpdump(8)? Other than that building either the real o
Can someone please explain the difference between Wireshark and Wireshark-lite.
I would like to install a packet sniffer on my FreeBSD box for CLI only.
Thanks,
Manuel Ochoa CCNP MCSA MCSE MCDBA
I will not fake my way through life!
___
Thanks to anyone who had a think about this one.
It appears the cause is a bit simpler than thought. Quite simply, the
hosting centre have apparantly allocated the IP addresses to someone else
so whilst there is something responding, it isn't actually the right
machine.
Numpties. :)
Regards,
Colin.
On Sat, 17 Mar 2007, Colin Waring wrote:
> Basically, .a and .d respond to pings and pass all traffic
> .b and .c respond to pings but don't appear to pass any other traffic.
>
> IPF is compiled but I've completely turned it off for testing
If you run one tcpdump on lo0 and another on em0 an
Max Laier wrote:
On Saturday 17 March 2007 07:38, Alex Povolotsky wrote:
Does anyone have any positive experience with Intel WiFi adapter on
Lenovo R60 with FreeBSD 6.X?
That would be the 3945abg part, right? In that case you want the driver
from here: http://www.clearchain.com/wiki/
On Saturday 17 March 2007 07:38, Alex Povolotsky wrote:
> Does anyone have any positive experience with Intel WiFi adapter on
> Lenovo R60 with FreeBSD 6.X?
That would be the 3945abg part, right? In that case you want the driver
from here: http://www.clearchain.com/wiki/Wpi
> Native driver or n
I'm sure I wrote out some more info than that but apparently not. I must
be getting confused as I did a description somewhere else, sorry!
Basically, .a and .d respond to pings and pass all traffic
.b and .c respond to pings but don't appear to pass any other traffic.
IPF is compiled but I've com
Somewhere around Sat, Mar 17, 2007 at 14:10 , the world stopped
and listened as Colin Waring graced us with this profound tidbit
of wisdom that would fulfill the enjoyment of future generations:
> Hi folks,
> Been running into brick walls since last night on this one.
> Situation is that our serv
On Sat, 17 Mar 2007, Colin Waring wrote:
> Hi folks,
> Been running into brick walls since last night on this one.
> Situation is that our server has 6.1-RELEASE on it with four IP addresses.
>
> The section of rc.conf is this:
>
> ifconfig_em0="inet a.a.a.a netmask 255.255.255.0"
> ifcon
Hi folks,
Been running into brick walls since last night on this one.
Situation is that our server has 6.1-RELEASE on it with four IP addresses.
The section of rc.conf is this:
ifconfig_em0="inet a.a.a.a netmask 255.255.255.0"
ifconfig_em0_alias0="inet a.a.a.b netmask 255.255.255.255"
ifconfig_em
On Fri, 16 Mar 2007, Aniruddha Bohra wrote:
Robert Watson wrote:
I can't speak to the details of the above, but can speak generally on the
issue of the link layer input path and locking. There is no assumption
that the caller will provide serialization, and fully concurrent input from
mul
22 matches
Mail list logo
