Ronald Klop:
> NB: I don't know if my setup fits your setup in relation to where
> "host" traffic originates. My bridge does not have an IP address
> itself.
in this case the problem i identified probably doesn't affect you, but
it would still be useful to know that the changes don't break your
co
Op 04-09-2025 om 14:03 schreef Lexi Winter:
Lexi Winter:
Ronald Klop:
With the story above is the patch still needed? I will test anyway to
see what happens. It is a RPI4, so compiling is a bit slow.
i was able to reproduce the problem here so it's not too important to
test that if it's a has
Lexi Winter:
> Ronald Klop:
> > With the story above is the patch still needed? I will test anyway to
> > see what happens. It is a RPI4, so compiling is a bit slow.
>
> i was able to reproduce the problem here so it's not too important to
> test that if it's a hassle.
there's a better patch at
hi Roland,
Ronald Klop:
> With VLANFILTER disabled epair4a did receive traffic and also
> broadcasts on vlan 3. I don't know if this is expected.
> Interestingly, with VLANFILTER disabled the "untagged 3" interfaces
> also saw broadcast traffic which was not destined for vlan 3.
with vlanfilter
Op 04-09-2025 om 12:52 schreef Lexi Winter:
hi Roland,
Ronald Klop:
member: epair4a flags=143
port 15 priority 128 path cost 2000 vlan protocol 802.1q
based on this configuration, epair4a should neither accept nor send any
traffic.
When I saw my mail again I realize
Ah, after looking into the config of my switch and seeing the nice "untagged 1"
on all interfaces it dawned on me what the config should be.
I now have this bridge:
bridge0: flags=1008843 metric
0 mtu 1500
options=10
ether 58:9c:fc:10:ea:3e
id 00:00:00:00:00:00 priority 32768 hellotime
hi Roland,
Ronald Klop:
>member: epair4a flags=143
>port 15 priority 128 path cost 2000 vlan protocol 802.1q
based on this configuration, epair4a should neither accept nor send any
traffic.
> epair4a still receives all traffic, so also traffic for vlan 3.
however, it see
considered if using the netgraph bridging and vlan support might be a
cleaner solution?
On 7/28/25 12:12 PM, Bjoern A. Zeeb wrote:
Hi,
I wish I would not have had to look into this but I got bitten over
the weekend.
My topology on boot looks simplified for the example) like:
physical interfa
On Mon, 28 Jul 2025, Bjoern A. Zeeb wrote:
Hi,
I wished we would have added vlan filtering/handling generically to
interfaces as a "sub-layer" stacking things properly but that's a
discussion for another decade I fear; but that's where I tink
"bridge went wrong" now.
I am sorry for chosing th
Bjoern A. Zeeb:
> Now there are use cases that duing the liftime of a boot I need to add
> a bridge interface to a vlanN + fanout:
> physical interface
> +--- vlan1 --- bridge0 --- other interface[s]
> +--- vlan2
> +--- vlan3 --- bridge1 --- other interface[s]
>
> And t
Lexi Winter:
> bridge_input() also does a second list walk in GRAB_OUR_PACKETS to find
> traffic destined for the local host, which we could avoid with a sysctl
> to ignore Ethernet traffic for MAC addresses other than the bridge
> itself. this would break configurations where IP addresses are ass
Matthew Grooms:
> > over the last few days i have been doing a bit of work on VLAN filtering
> > for bridge(4), which i thought i'd mention here in case anyone is
> > interested. the purpose of this is to extend the existing bridge VLAN
> > support to make it more generally useful.
>
> Looks awes
On 4/4/25 13:47, Lexi Winter wrote:
hello,
over the last few days i have been doing a bit of work on VLAN filtering
for bridge(4), which i thought i'd mention here in case anyone is
interested. the purpose of this is to extend the existing bridge VLAN
support to make it more generally useful.
> On 28. Oct 2020, at 18:10, D'Arcy Cain wrote:
>
> On 10/28/20 10:27 AM, Michael Gmelin wrote:
>> Can you (afford to) reboot the machine reliably? If so, schedule a reboot
>> using "shutdown -r +10" and then bring down the the interface to see if it
>> makes a difference.
>
> Nope. No dif
On 10/28/20 10:27 AM, Michael Gmelin wrote:
Can you (afford to) reboot the machine reliably? If so, schedule a reboot using
"shutdown -r +10" and then bring down the the interface to see if it makes a
difference.
Nope. No difference.
--
D'Arcy J.M. Cain | Democracy is three wolves
> On 28. Oct 2020, at 12:32, D'Arcy Cain wrote:
>
> On 10/27/20 2:58 PM, Michael Gmelin wrote:
>
> I hope you don't mind but I reverted this conversation back to the list in
> case it gives someone else any ideas.
>
>> Hi,
>> I tried to reproduce the problem on my home network, but things j
On 10/27/20 2:58 PM, Michael Gmelin wrote:
I hope you don't mind but I reverted this conversation back to the list in
case it gives someone else any ideas.
Hi,
I tried to reproduce the problem on my home network, but things just
work as expected.
I could run VMs with IPs off the local netwo
On 11 Sep 2020, at 19:06, Gleb Smirnoff wrote:
> Kristof,
>
> can you please take a look? IMHO, the problem is that with r360345
> the bridge_ioctl() is fully covered by epoch. IMHO, should be either
> more fine grained covered, or use internal locking, because some of
> the code downstream (driv
Hi,
can you please try out this patch? This is configuration event
and we should use sleepable lock to synchronize, not epoch.
On Fri, Sep 11, 2020 at 10:47:41AM +0300, xto...@mm.st wrote:
x> Updating from latest CURRENT snapshot
x> (FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620
Kristof,
can you please take a look? IMHO, the problem is that with r360345
the bridge_ioctl() is fully covered by epoch. IMHO, should be either
more fine grained covered, or use internal locking, because some of
the code downstream (driver ioctls) may sleep.
On Fri, Sep 11, 2020 at 10:47:41AM
On Fri, Sep 11, 2020 at 07:45:09PM +0300, xto...@mm.st wrote:
x> Gleb Smirnoff wrote:
x> >Hi,
x> >
x> > can you please try out this patch? This is configuration event
x> > and we should use sleepable lock to synchronize, not epoch.
x>
x> It didn't help, though I guess my problem is in if_brid
Gleb Smirnoff wrote:
Hi,
can you please try out this patch? This is configuration event
and we should use sleepable lock to synchronize, not epoch.
It didn't help, though I guess my problem is in if_bridge, not if_lagg
which the patch modifies?
On Fri, Sep 11, 2020 at 10:47:41AM +0300,
Hans Petter Selasky wrote:
On 2020-09-11 14:08, Hans Petter Selasky wrote:
I think this is another variant of:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232362
Also adding this one for the record:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609
I see, looks like the proble
On 2020-09-11 14:08, Hans Petter Selasky wrote:
I think this is another variant of:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232362
Also adding this one for the record:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609
--HPS
___
fre
On 2020-09-11 13:47, xto...@mm.st wrote:
xto...@mm.st wrote:
Updating from latest CURRENT snapshot
(FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620 broke the
bridges with igb (I350-T2) for me. Booting to kernel.old and/or
commenting the entries in rc.conf helps.
rc.conf:
cl
xto...@mm.st wrote:
Updating from latest CURRENT snapshot
(FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620 broke the
bridges with igb (I350-T2) for me. Booting to kernel.old and/or
commenting the entries in rc.conf helps.
rc.conf:
cloned_interfaces="bridge0 bridge1 tap0 tap1
Am 04.07.2020 um 20:59 schrieb Ask Bjørn Hansen :
>
> Hi everyone,
>
> I had this working for months until a reboot either got things started up in
> a different order or cleared what I setup by hand (it’s a snowflake
> test/development system at home) and did whatever I’d actually configured.
I finally figured out what is happening. I could use some help fixing the
problem.
The client (behind the virtual Firewall) sends an ARP Request and the
Firewall sends the ARP Request on. ESX is echoing the Request back to the
Firewall, which is causing the Firewall to drop the ARP Reply when
25.07.2019 1:17, Dan Lists wrote:
> Does anyone have any ideas on how to debug this issue?I can build a
> custom kernel or use dtrace if necessary. I'm not familiar with the kernel
> source so I don't really know where to look.
>
> Thanks for any help you can provide.
Did you miss my reply
Does anyone have any ideas on how to debug this issue?I can build a
custom kernel or use dtrace if necessary. I'm not familiar with the kernel
source so I don't really know where to look.
Thanks for any help you can provide.
On Mon, Jul 8, 2019 at 12:19 PM Dan Lists wrote:
>
> On Mon, Jul
I am not running virtualbox. I am still searching for clues to fix this
problem.
On Mon, Jul 8, 2019 at 7:54 PM Joseph Ward
wrote:
> I had this exact issue while virtualbox had a guest network adapter
> bridged to the external interface that the FreeBDS bridge0 interface was
> bridged to. If
I had this exact issue while virtualbox had a guest network adapter
bridged to the external interface that the FreeBDS bridge0 interface was
bridged to. If I shutdown the VMs, ARP magically started working
bidirectionally, and after restarting the VMs it failed again.
My fix was eventually to jus
On Mon, Jul 8, 2019 at 11:22 AM Eugene Grosbein wrote:
> 09.07.2019 0:43, Michael Sierchio wrote:
>
> > On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein
> wrote:
> >
> > 09.07.2019 0:19, Dan Lists wrote:
> >>
> >>> On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio
> >> wrote:
> >>>
> What's
09.07.2019 0:43, Michael Sierchio wrote:
> On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein wrote:
>
> 09.07.2019 0:19, Dan Lists wrote:
>>
>>> On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio
>> wrote:
>>>
What's your firewall ruleset look like? (show, don't tell)
>>> The firewall is off
On Mon, Jul 8, 2019 at 12:43 PM Michael Sierchio wrote:
>
> On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein
> wrote:
>
> 09.07.2019 0:19, Dan Lists wrote:
>>
>> > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio
>> wrote:
>> >
>> >> What's your firewall ruleset look like? (show, don't tell)
>>
On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein wrote:
09.07.2019 0:19, Dan Lists wrote:
>
> > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio
> wrote:
> >
> >> What's your firewall ruleset look like? (show, don't tell)
> > The firewall is off for testing (the machine is only on a private
> ne
09.07.2019 0:19, Dan Lists wrote:
> On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio wrote:
>
>> What's your firewall ruleset look like? (show, don't tell)
> The firewall is off for testing (the machine is only on a private network).
> # ipfw list
> 65535 allow ip from any to any
>> What does
On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio wrote:
> What's your firewall ruleset look like? (show, don't tell)
>
The firewall is off for testing (the machine is only on a private network).
# ipfw list
65535 allow ip from any to any
> What does sysctl report on the interfaces and on ar
What's your firewall ruleset look like? (show, don't tell)
What does sysctl report on the interfaces and on arp?
On Mon, Jul 8, 2019 at 9:15 AM Dan Lists wrote:
> I have a server running FreeBSD 11.2 that I am wanting to use as a bridged
> firewall. I have it set up and it mostly works.
On 22.08.2017 15:48, Boris wrote:
> I own the upstream network and have full access to it.
> It is configured as a simple router interface (Cisco device).
> Before looking at that element (which I am not minimizing in the overall
> issue), shouldn't the VM be able to reach the IP setup on the brid
I own the upstream network and have full access to it.
It is configured as a simple router interface (Cisco device).
Before looking at that element (which I am not minimizing in the overall
issue), shouldn't the VM be able to reach the IP setup on the bridge? At
the moment, that does not work and i
On 22.08.2017 15:39, Boris wrote:
> Ok thanks Eugene.
> net.link.bridge.inherit_mac=1 helped get the connectivity from the bridge
> however, when I start a FreeBSD bhyve VM and attached that to a tap interface
> in the bridge, I don't get connectivity from the VM.
>
> SETUP:
> Gateway - 192.168
Ok thanks Eugene.
net.link.bridge.inherit_mac=1 helped get the connectivity from the bridge
however, when I start a FreeBSD bhyve VM and attached that to a tap
interface in the bridge, I don't get connectivity from the VM.
SETUP:
Gateway - 192.168.0.222/29
Server - 192.168.0.218/29
VM - 192.168.0.
22.08.2017 7:49, Boris пишет:
> Hi all,
>
> I have two environments.
>
> Environment A:
> Server running fresh install of 11.1-RELEASE with bge physical NIC.
> If I just configure a bridge interface, add a physical NIC which has
> working connectivity, say bge3, and add an IP address on the bridg
On 27/05/2016 1:13 AM, John Nielsen wrote:
On May 20, 2016, at 12:30 AM, Aqz wrote:
Hello,
I have a very strange issue with passing ARP traffic through bridge
interface.
I'm using FreeBSD 10.3-REL VMWare virtual machine as bridge between two
networks using the same IP address space. Bridge int
> On May 20, 2016, at 12:30 AM, Aqz wrote:
>
> Hello,
>
> I have a very strange issue with passing ARP traffic through bridge
> interface.
> I'm using FreeBSD 10.3-REL VMWare virtual machine as bridge between two
> networks using the same IP address space. Bridge interface doesn't have IP
> addr
On 12/4/15 6:43 PM, Gary Palmer wrote:
On Fri, Dec 04, 2015 at 03:27:20PM -0500, Jason Van Patten wrote:
Any guidance or suggestions on that one?
Try:
sysrc arpproxy_all=YES
You can remove the sysctl setting as that's what that option does.
According to /etc/rc.d/routing, it looks like th
On Fri, Dec 04, 2015 at 03:27:20PM -0500, Jason Van Patten wrote:
> On 12/4/15 2:06 AM, Aleksandr A Babaylov wrote:
> >
> > sysctl net.link.ether.inet.proxyall=1
>
> This looks like it's working; thanks a bunch! Whoda'thunk you could use
> something like proxy arp to un-break a broken network?
On 12/4/15 2:06 AM, Aleksandr A Babaylov wrote:
sysctl net.link.ether.inet.proxyall=1
This looks like it's working; thanks a bunch! Whoda'thunk you could use
something like proxy arp to un-break a broken network? It appears as
though the above sysctl keeps resetting itself to 0 with *any*
On 12/4/15 2:06 AM, Aleksandr A Babaylov wrote:
May be it is proxy arp from Verison.
Fair assumption. They may be doing that to prevent one Verizon customer
from talking directly to another without routing through them first,
even though each customer is on the same broadcast domain.
sys
On Thu, Dec 03, 2015 at 08:54:10AM -0500, Jason Van Patten wrote:
> Hey gang -
>
> I posted this to the FreeBSD user forums but figured I'd send a message
> off to the list to see if anyone has any input, guidance, or ideas.
> Emailing diagrams around isn't good form (IMHO) but having a diagram
On 12/3/2015 5:24 PM, Jason Van Patten wrote:
Hey gang -
I posted this to the FreeBSD user forums but figured I'd send a message off to the list to see if anyone has any input, guidance, or ideas. Emailing diagrams around isn't good form (IMHO) but having
a diagram handy will help with the disc
On 5/3/14, 4:59 AM, Özkan KIRIK wrote:
And also i tried ng_bpf + ng_eiface conjuction, but ng_bpf doesnt match
"vlan" filter.
With the script below, ng_bpf always calls ifNotMatch hook. When the
pattern is "ip", ng_bpf matches frames have both vlan and ip headers.
I think ng_bpf doesnt process
And also i tried ng_bpf + ng_eiface conjuction, but ng_bpf doesnt match
"vlan" filter.
With the script below, ng_bpf always calls ifNotMatch hook. When the
pattern is "ip", ng_bpf matches frames have both vlan and ip headers.
I think ng_bpf doesnt process ethernet header. Is there a way to proc
On Sun, Mar 4, 2012 at 11:14 PM, Andrew Thompson wrote:
> Here is a patch that changes it but I do not know what may break.
>
Thanks a lot Andrew. So, someone might be relying on interface type of
bridge being IFT_ETHER?
Who can confirm if this is a good patch?
>
> Index: if_bridge.c
> ==
> From: hiren panchasara
>
> I created bridge1 this way:
>
> $ sudo ifconfig bridge create
> Password:
> bridge1
>
> $ ifconfig bridge1
> bridge1: flags=8802 metric 0 mtu 1500
> ether 02:32:c8:92:b6:01
> nd6 options=29
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> max
[ posted to freebsd-net@freebsd.org 2010-10-28 ]
I believe I have now found the answer to my problem.
The rule is simple: You cannot bridge a Desktop virtual NIC. The
reason for this, I believe so far, is that Parallels have only implemented
a simplified version of bridging on their bridged netw
[ posted to freebsd-net@freebsd.org 2010-10-27 ]
More weirdness. Pinging from 192.168.0.2 (Mac OS X) to 192.168.0.220
(VPN client) and monitoring em0 on 192.168.0.8 (the VPN server bridge), I find
that each ping request generates two ICMP echo replies to two different
ethernet addresses. Here is t
>I confirm this problem for another server:
>stable 8 amd64 + vlan + carp
>
>Whenever I join a bridge with a vlan interface:
>
>ifconfig bridge0 addm vlan35
>
>The system soon or later freezes.
>
>This time it has happened after 3 days of normal behavior.
>
>No logs, no dump.
This happens to me
I confirm this problem for another server:
stable 8 amd64 + vlan + carp
Whenever I join a bridge with a vlan interface:
ifconfig bridge0 addm vlan35
The system soon or later freezes.
This time it has happened after 3 days of normal behavior.
No logs, no dump.
On 03.03.2010 12:30, Giulio Fer
Bjoern A. Zeeb wrote:
> On Mon, 30 Jun 2008, Eugene M. Kim wrote:
> > A quick question: Is bridge(4) supposed /not/ to automatically configure an
> > IPv6 link-local address?
>
> yes there is a check for this in the code and if remoed (tried that
> lately) more things go wrong.
>
> > I'm trying
On Mon, 30 Jun 2008, Eugene M. Kim wrote:
Hi,
A quick question: Is bridge(4) supposed /not/ to automatically configure an
IPv6 link-local address?
yes there is a check for this in the code and if remoed (tried that
lately) more things go wrong.
I'm trying to use it to bridge a wired segment
On Dec 17, 2007 3:23 AM, Ivo Vachkov <[EMAIL PROTECTED]> wrote:
>
> On Dec 14, 2007 1:24 AM, Niki Denev <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Is there a reason that when adding member ports to a bridge stp is not
> > enabled by default on them?
> > Wouldn't it be more intuitive to be enabled b
On Dec 14, 2007 1:24 AM, Niki Denev <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there a reason that when adding member ports to a bridge stp is not
> enabled by default on them?
> Wouldn't it be more intuitive to be enabled by default these days?
There are several reasons not to enable STP on a bridge
Julian Elischer wrote:
G E E K wrote:
Did you check if the bridge.ko and ipfw.ko modules are loaded with the
kernel or not?
Regards,
Saleh
From: Antonio Tommasi <[EMAIL PROTECTED]>
To: freebsd-net@freebsd.org
Subject: Bridge transparent proxy
Date: Thu, 24 May 2007 07:06:54 +0200
Hi to
G E E K wrote:
Did you check if the bridge.ko and ipfw.ko modules are loaded with the
kernel or not?
Regards,
Saleh
From: Antonio Tommasi <[EMAIL PROTECTED]>
To: freebsd-net@freebsd.org
Subject: Bridge transparent proxy
Date: Thu, 24 May 2007 07:06:54 +0200
Hi to all i'm trying to instal
Did you check if the bridge.ko and ipfw.ko modules are loaded with the
kernel or not?
Regards,
Saleh
From: Antonio Tommasi <[EMAIL PROTECTED]>
To: freebsd-net@freebsd.org
Subject: Bridge transparent proxy
Date: Thu, 24 May 2007 07:06:54 +0200
Hi to all i'm trying to installa a bridge tran
On 2007-May-11 10:22:43 +0500, [EMAIL PROTECTED] wrote:
>I am using TCP sockets to measure packet transfer. And I am also not
>looking to optimise the link. I just want to know if this is the usual
>behaviour of the freeBSD TCP or bridge when we apply delay and packet
>loss.
This is nothing to do
On 2007-May-08 14:20:27 +0500, [EMAIL PROTECTED] wrote:
>i am using freebox 5.4 as a bridge using dummynet.
...
>When I add delay of 250ms and plr of 0.05 (5%), the packet transfer falls
>to 80Kbit/s.
How are you measuring packet transfer (single TCP socket, multiple TCP
sockets or UDP) and what w
If memory serves me right, Andrea Venturoli wrote:
> Bruce A. Mah wrote:
>
>> You didn't say which bridging driver or version of FreeBSD you're using,
>> but it sounds to me like you're using bridge(4), right?
>
> Yes.
>
>
>
>> This is a
>> fairly well known problem, which I wrote a little bit
Bruce A. Mah wrote:
You didn't say which bridging driver or version of FreeBSD you're using,
but it sounds to me like you're using bridge(4), right?
Yes.
This is a
fairly well known problem, which I wrote a little bit about here:
http://lists.freebsd.org/pipermail/freebsd-net/2004-Decembe
If memory serves me right, Andrea Venturoli wrote:
> Hello.
> I've got the following problem...
> My host is configured like this:
>
> fxp0: internal interface, requires NAT
> rl1: public interface, with static IP
> xl0: bridged to rl1, with some public IP behind
>
> ipfw diverts any traffic thro
Andrew Thompson wrote:
On Thu, Sep 14, 2006 at 04:23:07PM +0200, Jon Otterholm wrote:
Andrew Thompson wrote:
On Thu, Sep 14, 2006 at 10:30:21AM +0200, Jon Otterholm wrote:
Andrew Thompson wrote:
On Wed, Sep 13, 2006 at 08:19:41PM +0200, Jon Otterholm wrote:
>From
On Thu, Sep 14, 2006 at 08:38:02AM +0400, Eygene Ryabinkin wrote:
> Andrew, good day!
>
> > The check for ARP happens before the ipfw layer2 code so it isnt
> > currently possible to filter them.
> >
> > switch (ether_type) {
> > case ETHERTYPE_ARP:
> > case ETHERTYPE_REVA
Andrew, good day!
> The check for ARP happens before the ipfw layer2 code so it isnt
> currently possible to filter them.
>
> switch (ether_type) {
>case ETHERTYPE_ARP:
>case ETHERTYPE_REVARP:
>return (0); /* Automatically pass */
I am a bit confu
On Wed, Sep 13, 2006 at 08:19:41PM +0200, Jon Otterholm wrote:
> Hi.
>
> According to man if_bridge one could filter L2-traffic with ipfw:
>
> From man if_bridge:
> ARP and REVARP packets are forwarded without being filtered and others
> that are not IP nor IPv6 packets are not forwarded
MK> What does sysctl net.inet.ip.check_interface say? Does switching it
MK> off helps?
net.inet.ip.check_interface was 0
Switch it to 1 have no effect. I think WiFi
devices can hear each other through antenna.
But devices have different SSID and IMHO can't
have loop.
--
Best regards,
An
What does sysctl net.inet.ip.check_interface say? Does switching it
off helps?
--
Maxim Konovalov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Iasen Kostov wrote:
Hi,
if I understand next code correctly maximum number of MACs is bound to
maximum number of ports ?!?. Why is that ?
code from net/bridge.c:
c[n_clusters].my_macs = (struct bdg_addr *)
malloc(BDG_MAX_PORTS * sizeof(struct bdg_addr),
M_IFADDR, M_
Vince Hoffman <[EMAIL PROTECTED]> wrote:
>
>
>On Mon, 1 Nov 2004 [EMAIL PROTECTED] wrote:
>
>> Hi everybody!
>>
>> I'm try configure bridge on FreeBSD box.
>>
>> Box configuration:
>> %uname -srp
>>FreeBSD 5.3-RC1 i386
>> %ifconfig
>> xl0: flags=8943 mtu 1500
>>options=9
>>
On Mon, 1 Nov 2004 [EMAIL PROTECTED] wrote:
Hi everybody!
I'm try configure bridge on FreeBSD box.
Box configuration:
%uname -srp
FreeBSD 5.3-RC1 i386
%ifconfig
xl0: flags=8943 mtu 1500
options=9
ether 00:04:79:68:02:e6
media: Ethernet autoselect (none)
status: n
On Sun, 31 Oct 2004, kamal kc wrote:
> I have made a bridge using the Packet Capture Library I set the two nics
> to promiscous mode and transfer packet between the two packet capture
> handles A piece of the code I use for initializing the packet capture
Copying every packet into and out of use
On Sun, Sep 05, 2004 at 10:29:54PM -0700, Luigi Rizzo wrote:
L> > L> I'd rather not apply the patch unless you can show that
L> > L> the current code leads to incorrect behaviour.
L> >
L> > I suspect that packets dropped by bridge_in() called from if_ed will
L> > not be captured by bpf(4). This is
On Sun, Sep 05, 2004 at 02:37:31PM -0700, Matthew Dillon wrote:
> Well, wait a second... are we talking about a lot of packets being
> discarded by the filter in 'normal' operation, or are we talking about
> an attack? Because if we are takling about an attack the LAST ethernet
...
Su
On Mon, Sep 06, 2004 at 03:01:00AM +0400, Gleb Smirnoff wrote:
...
> L> I'd rather not apply the patch unless you can show that
> L> the current code leads to incorrect behaviour.
>
> I suspect that packets dropped by bridge_in() called from if_ed will
> not be captured by bpf(4). This is incorrec
Sam Leffler wrote:
> > No. What will move to pfil_hooks is the firewalling within the bridge
> > code and the layer2 ethernet firewalling. The bridging code as such
> > will stay where it is.
>
> Well, that's what _you_ want to do :). What I started on last year was a
> complete purge of specia
On Sunday 05 September 2004 02:53 pm, Andre Oppermann wrote:
> Gleb Smirnoff wrote:
> > On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
> > L> > I see that bridge callbacks are still living in if_ed.c
> > L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is
> > L> > not corre
On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
L> there are performance reasons to do this way -- grabbing
L> the entire packet is expensive because it is done via programmed
L> I/O, so the current code only grabs the header, does the
L> filtering, and grabs the rest of the packet onl
Gleb Smirnoff wrote:
>
> On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
> L> > I see that bridge callbacks are still living in if_ed.c
> L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is
> L> > not correct.
> L> >
> L> > Bridge code is called from ether_input(), which is
On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
L> > I see that bridge callbacks are still living in if_ed.c
L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is
L> > not correct.
L> >
L> > Bridge code is called from ether_input(), which is
L> > indirectly called from if_ed.
Well, wait a second... are we talking about a lot of packets being
discarded by the filter in 'normal' operation, or are we talking about
an attack? Because if we are takling about an attack the LAST ethernet
device anyone would ever want to use would be ED. i.e. they would be
On Mon, Sep 06, 2004 at 12:52:49AM +0400, Gleb Smirnoff wrote:
> Luigi,
>
> I see that bridge callbacks are still living in if_ed.c
> from FreeBSD 2.x times. See if_ed.c:2816. I think this is
> not correct.
>
> Bridge code is called from ether_input(), which is
> indirectly called from if_ed.c:
On Mon, Aug 30, 2004 at 09:23:23PM -0500, Andrea Venturoli wrote:
A> Just to give an idea, I tested with iperf and this are the results:
A>
A> internal net -> xxx.xxx.xxx.1 6.93 Mb/s
A> internal net -> xxx.xxx.xxx.126.94 Mb/s
A> internet -> xxx.xxx.xxx.1 237 Kb/s
A> internet -
** Reply to note from "Chris Dionissopoulos[freemail]" <[EMAIL PROTECTED]> Tue, 31 Aug
2004 07:01:11 +0300
> Andrea,
> Try something like this as alternative configuration:
Thank you very much for the answer. Unfortunately I didn't want to mess remotely with
this kind of configuration, so I
On Thu, 25 Dec 2003, Bruce A. Mah sent me a useful Christmas present:
> In 4-STABLE, there's a bug that prevents ARP from working correctly on
> unnumbered bridge interfaces when bridging is enabled using the
> bridge.ko module. Basically, there are some checks in the ARP code
> that decide w
If memory serves me right, Ian Smith wrote:
> In short, ifconfig appears unwilling to have two NICs covering the same
> /24. Can this be set up? I'm also at a bit of a loss with the routing,
> so inside packets to the bridge box (ie unbridged packets) are responded
> to on the same interface, an
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes:
>If you have shared interrupts, and one of the interfaces is not up, you
>end up doing a lot of useless calls to sis_stop(), which is terribly
>expensive (it even includes a DELAY(1000) call).
>At the very least, one should add a 'stopped' flag s
[slightly rearranging the Cc list...]
i have read Soren's report, and I think he is probably right
in pointing to the interrupt handling code rhather than the bridging
code. If the 4801 has the "sis" driver, the following lines in
/sys/pci/if_sis.c: sis_intr() might be the cause of the problem:
Robert Watson wrote:
On Wed, 24 Dec 2003, Ian Smith wrote:
What I can't get to is setting up both NICs for the same /24, using
either one or two separate addresses. I'd hoped to get away with one
IP, which some of the docs (and bridge.c, skimmed) led me to believe
that any local IPs of this hos
On Wed, 24 Dec 2003, Ian Smith wrote:
> What I can't get to is setting up both NICs for the same /24, using
> either one or two separate addresses. I'd hoped to get away with one
> IP, which some of the docs (and bridge.c, skimmed) led me to believe
> that any local IPs of this host, on whateve
1 - 100 of 178 matches
Mail list logo
