Levi Ariel-BAL023 | 2 Mar 19:20 2006

bridge MAC address

Hi,

 

I have notice that the bridge gets the “lowest” MAC address of its interfaces.

Function: br_stp_recalculate_bridge_id()

 

Is there a meaning behind this or not?

 

Thanks,

 Ariel

_______________________________________________
Bridge mailing list
Bridge <at> lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge
Stephen Hemminger | 2 Mar 21:31 2006
X-Face

Re: bridge MAC address

On Thu, 2 Mar 2006 20:20:38 +0200
"Levi Ariel-BAL023" <ariel.levi <at> motorola.com> wrote:

> Hi,
> 
>  
> 
> I have notice that the bridge gets the "lowest" MAC address of its
> interfaces.
> 
> Function: br_stp_recalculate_bridge_id()
> 
>  
> 
> Is there a meaning behind this or not?
> 
>  
> 
> Thanks, 
> 
>  Ariel 
> 

It's part of the Spanning Tree Protocol in the 802.1d standard.
In later kernels you can reset the address to be the same as any
of the interfaces being bridged.
_______________________________________________
Bridge mailing list
Bridge <at> lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge
Levi Ariel-BAL023 | 3 Mar 09:03 2006

RE: bridge MAC address


Stephen,

Thanks for your quick respond.

What do you mean by "later kernels"? I curently use kernel 2.4.20
Can I add a ioctl that enables modifying the bridge MAC address?

Thanks,
  Ariel

-----Original Message-----
From: Stephen Hemminger [mailto:shemminger <at> osdl.org] 
Sent: Thursday, March 02, 2006 10:31 PM
To: Levi Ariel-BAL023
Cc: bridge <at> lists.osdl.org
Subject: Re: [Bridge] bridge MAC address

On Thu, 2 Mar 2006 20:20:38 +0200
"Levi Ariel-BAL023" <ariel.levi <at> motorola.com> wrote:

> Hi,
> 
>  
> 
> I have notice that the bridge gets the "lowest" MAC address of its 
> interfaces.
> 
> Function: br_stp_recalculate_bridge_id()
> 
>  
> 
> Is there a meaning behind this or not?
> 
>  
> 
> Thanks,
> 
>  Ariel
> 

It's part of the Spanning Tree Protocol in the 802.1d standard.
In later kernels you can reset the address to be the same as any
of the interfaces being bridged.

_______________________________________________
Bridge mailing list
Bridge <at> lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge
Stephen Hemminger | 3 Mar 16:38 2006

Re: bridge MAC address

On Fri, 3 Mar 2006 10:03:04 +0200
"Levi Ariel-BAL023" <ariel.levi <at> motorola.com> wrote:

> 
> Stephen,
> 
> Thanks for your quick respond.
> 
> What do you mean by "later kernels"? I curently use kernel 2.4.20
> Can I add a ioctl that enables modifying the bridge MAC address?
> 
> Thanks,
>   Ariel
> 

I think I added it for 2.6.15
_______________________________________________
Bridge mailing list
Bridge <at> lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge
Eriberto | 6 Mar 17:45 2006
Picon

IPS HLBR 1.0 released (off-topic)

IPS HLBR - Version 1.0 can detect malicious traffic using regular
expressions

Version 1.0 of Hogwash Light BR, released march 5th 2006, brings two
interesting new features. The first one is the ability of using
regular expressions to detect intrusion attempts and e-mails with
virus or phishing. The second is the use of lists with banned words.

HLBR is an IPS (Intrusion Prevention System) that reads network
traffic in the layer 2 of the OSI model. Since it works like a bridge,
it stays in-line in the network topology and doesn't need an IP
address. So, HLBR is invisible to attackers. Traffic filtering
(including the packets contents) can be done with simple rules.
Version 1.0 can use regular expressions to filter the packets. Below
is an example of rule with regular expressions (please, ignore underIPS 
HLBR - Version 1.0 can detect malicious traffic using regular
expressions

Version 1.0 of Hogwash Light BR, released march 5th 2006, brings two
interesting new features. The first one is the ability of using
regular expressions to detect intrusion attempts and e-mails with
virus or phishing. The second is the use of lists with banned words.

HLBR is an IPS (Intrusion Prevention System) that reads network
traffic in the layer 2 of the OSI model. Since it works like a bridge,
it stays in-line in the network topology and doesn't need an IP
address. So, HLBR is invisible to attackers. Traffic filtering
(including the packets contents) can be done with simple rules.
Version 1.0 can use regular expressions to filter the packets. Below
is an example of rule with regular expressions:

<rule>
ip dst(email)
tcp dst(25)
tcp regex(filename="[^\n]+\.scr")
message=(mailvirus-1-re) .scr attach
action=virus
</rule>

In short, all TCP traffic destined to port 25 of the e-mail server
will be filtered. If the text:

filename="anything_different_of_line_breaks.scr"

is found inside the packet, that means there are an attachment .scr in
the e-mail (virus). So this packet will suffer the action named 'virus'.
This action logs the event, dumps the malicious traffic in tcpdump
format and drops the packet. Below is an example of rule against a type
of buffer overflow attempt against DNS servers:

<rule>
ip dst(dns)
udp dst(53)
udp nocase(|41cd 80c7 062f 6269 6ec7 4604 2f73 6800  89f0 83c0 0889 4608|)
message=(dnsattacks-1) tsl bind attack
action=action1
</rule>

In this case, due to the use of pipe characters (|), HLBR will check
the traffic for the hexadecimal sequence given as an attack signature.

HLBR lets you use rules for blocking attacks against network servers.
In order to fully understand it please read our documentation at
http://hlbr.sourceforge.net/ips-en.html - explanations about the IPS
concept including charts.

HLBR site is at http://hlbr.sourceforge.net.

(Translated from Portuguese by André Bertelli - andre (a) bertelli.name)

lines in s_c_r):

<rule>
ip dst(email)
tcp dst(25)
tcp regex(filename="[^\n]+\.s_c_r")
message=(mailvirus-1-re) .s_c_r attach
action=virus
</rule>

In short, all TCP traffic destined to port 25 of the e-mail server
will be filtered. If the text:

filename="anything_different_of_line_breaks.s_c_r"

is found inside the packet, that means there are an attachment .scr in
the e-mail (virus). So this packet will suffer the action named 'virus'.
This action logs the event, dumps the malicious traffic in tcpdump
format and drops the packet. Below is an example of rule against a type
of buffer overflow attempt against DNS servers:

<rule>
ip dst(dns)
udp dst(53)
udp nocase(|41cd 80c7 062f 6269 6ec7 4604 2f73 6800  89f0 83c0 0889 4608|)
message=(dnsattacks-1) tsl bind attack
action=action1
</rule>

In this case, due to the use of pipe characters (|), HLBR will check
the traffic for the hexadecimal sequence given as an attack signature.

HLBR lets you use rules for blocking attacks against network servers.
In order to fully understand it please read our documentation at
http://hlbr.sourceforge.net/ips-en.html - explanations about the IPS
concept including charts.

HLBR site is at http://hlbr.sourceforge.net.

(Translated from Portuguese by André Bertelli - andre (a) bertelli.name)
Eriberto | 6 Mar 18:34 2006
Picon

IPS HLBR 1.0 released (off-topic)

IPS HLBR - Version 1.0 can detect malicious traffic using regular
expressions

Version 1.0 of Hogwash Light BR, released march 5th 2006, brings two
interesting new features. The first one is the ability of using
regular expressions to detect intrusion attempts and e-mails with
virus or phishing. The second is the use of lists with banned words.

HLBR is an IPS (Intrusion Prevention System) that reads network
traffic in the layer 2 of the OSI model. Since it works like a bridge,
it stays in-line in the network topology and doesn't need an IP
address. So, HLBR is invisible to attackers. Traffic filtering
(including the packets contents) can be done with simple rules.
Version 1.0 can use regular expressions to filter the packets. Below
is an example of rule with regular expressions:

(please see http://hlbr.sourceforge.net/hlbr-rule-1.gif)

In short, all TCP traffic destined to port 25 of the e-mail server
will be filtered. If the text:

filename="anything_different_of_line_breaks.s__c__r"

(please ignore underlines in s__c__r)

is found inside the packet, that means there are an attachment .scr in
the e-mail (virus). So this packet will suffer the action named 'virus'.
This action logs the event, dumps the malicious traffic in tcpdump
format and drops the packet. Below is an example of rule against a type
of buffer overflow attempt against DNS servers:

(please see http://hlbr.sourceforge.net/hlbr-rule-2.gif)

In this case, due to the use of pipe characters (|), HLBR will check
the traffic for the hexadecimal sequence given as an attack signature.

HLBR lets you use rules for blocking attacks against network servers.
In order to fully understand it please read our documentation at
http://hlbr.sourceforge.net/ips-en.html - explanations about the IPS
concept including charts.

HLBR site is at http://hlbr.sourceforge.net.

(Translated from Portuguese by André Bertelli - andre (a) bertelli.name)
Eriberto | 6 Mar 17:09 2006
Picon

IPS HLBR 1.0 released (off-topic)

IPS HLBR - Version 1.0 can detect malicious traffic using regular
expressions

Version 1.0 of Hogwash Light BR, released march 5th 2006, brings two
interesting new features. The first one is the ability of using
regular expressions to detect intrusion attempts and e-mails with
virus or phishing. The second is the use of lists with banned words.

HLBR is an IPS (Intrusion Prevention System) that reads network
traffic in the layer 2 of the OSI model. Since it works like a bridge,
it stays in-line in the network topology and doesn't need an IP
address. So, HLBR is invisible to attackers. Traffic filtering
(including the packets contents) can be done with simple rules.
Version 1.0 can use regular expressions to filter the packets. Below
is an example of rule with regular expressions:

<rule>
ip dst(email)
tcp dst(25)
tcp regex(filename="[^\n]+\.scr")
message=(mailvirus-1-re) .scr attach
action=virus
</rule>

In short, all TCP traffic destined to port 25 of the e-mail server
will be filtered. If the text:

filename="anything_different_of_line_breaks.scr"

is found inside the packet, that means there are an attachment .scr in
the e-mail (virus). So this packet will suffer the action named 'virus'.
This action logs the event, dumps the malicious traffic in tcpdump
format and drops the packet. Below is an example of rule against a type
of buffer overflow attempt against DNS servers:

<rule>
ip dst(dns)
udp dst(53)
udp nocase(|41cd 80c7 062f 6269 6ec7 4604 2f73 6800  89f0 83c0 0889 4608|)
message=(dnsattacks-1) tsl bind attack
action=action1
</rule>

In this case, due to the use of pipe characters (|), HLBR will check
the traffic for the hexadecimal sequence given as an attack signature.

HLBR lets you use rules for blocking attacks against network servers.
In order to fully understand it please read our documentation at
http://hlbr.sourceforge.net/ips-en.html - explanations about the IPS
concept including charts.

HLBR site is at http://hlbr.sourceforge.net.

(Translated from Portuguese by André Bertelli - andre (a) bertelli.name)
Stephen Hemminger | 7 Mar 18:39 2006

Re: IPS HLBR 1.0 released (off-topic)

On Mon, 06 Mar 2006 13:09:59 -0300
Eriberto <eriberto <at> eriberto.pro.br> wrote:

> IPS HLBR - Version 1.0 can detect malicious traffic using regular
> expressions
> 
> Version 1.0 of Hogwash Light BR, released march 5th 2006, brings two
> interesting new features. The first one is the ability of using
> regular expressions to detect intrusion attempts and e-mails with
> virus or phishing. The second is the use of lists with banned words.
> 
> HLBR is an IPS (Intrusion Prevention System) that reads network
> traffic in the layer 2 of the OSI model. Since it works like a bridge,
> it stays in-line in the network topology and doesn't need an IP
> address. So, HLBR is invisible to attackers. Traffic filtering
> (including the packets contents) can be done with simple rules.
> Version 1.0 can use regular expressions to filter the packets. Below
> is an example of rule with regular expressions:
> 
> <rule>
> ip dst(email)
> tcp dst(25)
> tcp regex(filename="[^\n]+\.scr")
> message=(mailvirus-1-re) .scr attach
> action=virus
> </rule>
> 
> In short, all TCP traffic destined to port 25 of the e-mail server
> will be filtered. If the text:
> 
> filename="anything_different_of_line_breaks.scr"
> 
> is found inside the packet, that means there are an attachment .scr in
> the e-mail (virus). So this packet will suffer the action named 'virus'.
> This action logs the event, dumps the malicious traffic in tcpdump
> format and drops the packet. Below is an example of rule against a type
> of buffer overflow attempt against DNS servers:
> 
> <rule>
> ip dst(dns)
> udp dst(53)
> udp nocase(|41cd 80c7 062f 6269 6ec7 4604 2f73 6800  89f0 83c0 0889 4608|)
> message=(dnsattacks-1) tsl bind attack
> action=action1
> </rule>
> 
> In this case, due to the use of pipe characters (|), HLBR will check
> the traffic for the hexadecimal sequence given as an attack signature.
> 
> HLBR lets you use rules for blocking attacks against network servers.
> In order to fully understand it please read our documentation at
> http://hlbr.sourceforge.net/ips-en.html - explanations about the IPS
> concept including charts.
> 
> HLBR site is at http://hlbr.sourceforge.net.
> 
> (Translated from Portuguese by André Bertelli - andre (a) bertelli.name)
> 
>

Ebtables can do the same thing and it does it with in the existing
general netfilter framework.  Or is this just a wrapper on existing netfilters?
_______________________________________________
Bridge mailing list
Bridge <at> lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge
devzero | 12 Mar 16:16 2006
Picon

Re: aoe/vblade on "localhost"

update:

i`m sorry - ignore this post, made a mistake here.

the aoe driver was accidentally bound to both interfaces.

i corrected this and AoE-driver behaves the same as vblade: it sends out packets, but they seem to get
forwarded at all

regards
roland

> -----Ursprüngliche Nachricht-----
> Von: devzero <at> web.de
> Gesendet: 12.03.06 14:10:07
> An: bridge <at> osdl.org
> Betreff: Re: aoe/vblade on "localhost"

> some more info:
> 
> > afaik, after starting, the bridge is in some "learning" state, to see what is on the "left side" and on the
"right side".
> > i`m somewhat unsure if AoE/vblade are sending out enough (or the right?) packets to make the bridge let
them go through (aoe and vblade get aware of each other via broadcast) 
> > 
> > can somebody give an advice on what needs to be taken into account here and what could be done to debug this?
> > regards
> 
> actually, the broadcasts of AoE driver get through from dummy1 to dummy0 - i see 2 packets on dummy0 and
those 2 being forwarded on dummy1
> 
> vserver2:~ # tcpdump -i dummy0 &
> [1] 11302
> vserver2:~ # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on dummy0, link-type EN10MB (Ethernet), capture size 96 bytes
> 
> vserver2:~ # tcpdump -i dummy1 &
> [2] 11303
> vserver2:~ # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on dummy1, link-type EN10MB (Ethernet), capture size 96 bytes
> 
> 14:02:09.887410 6e:d9:cf:4c:9d:df > Broadcast, ethertype Unknown (0x88a2), length 60:
>         0x0000:  1000 ffff ff01 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
> 14:02:09.888004 ca:90:06:04:f6:ec > Broadcast, ethertype Unknown (0x88a2), length 60:
>         0x0000:  1000 ffff ff01 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
> 14:02:09.886699 6e:d9:cf:4c:9d:df > Broadcast, ethertype Unknown (0x88a2), length 60:
>         0x0000:  1000 ffff ff01 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
> 14:02:09.888278 6e:d9:cf:4c:9d:df > Broadcast, ethertype Unknown (0x88a2), length 60:
>         0x0000:  1000 ffff ff01 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
> 
> 
> but - the broadcasts from vblade (connected to dummy0) can only be seen on dummy0, but not on dummy1:
> 
> 
> vserver2:~ # tcpdump -i dummy0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on dummy0, link-type EN10MB (Ethernet), capture size 96 bytes
> 
> 14:04:33.825077 ca:90:06:04:f6:ec > Broadcast, ethertype Unknown (0x88a2), length 32:
>         0x0000:  0800 0000 0001 0000 0000 0020 400a 0010  ............ <at> ...
>         0x0010:  0000                                     ..
> 
> it seems the bridge isn`t forwarding them from dummy0 to dummy1
> 
> i have setup the bridge 2 or 3 times - but it doesn`t seem to work as expected.
> 
> i`m on  SuSE 9.2 with kernel 2.6.8-24.19-default 
> 
> regards
> roland
> 
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: devzero <at> web.de
> > Gesendet: 12.03.06 12:38:49
> > An: bridge <at> osdl.org
> > Betreff: aoe/vblade on "localhost"
> 
> 
> > hello !
> > 
> > i try to use a network technology on one single host, which wasn`t designed for that. 
> > 
> > to give a short overview of what i`m talking about:
> > 
> > AoE is just like a "networked blockdevice" (just like nbd/enbd) - but without tcp/ip. 
> > AoE kernel driver is the "client end" (see this like an iSCSI initiator) - and an etherblade storage
appliance is the "server end" (see this like an iSCSI target)
> > there is a software equivalent to etherblade storage which is called vblade (part of the aoetools
project) - or vblade-kernel (another implementation, but done as a kernel module)
> > 
> > a very nice article about what AoE is can be found at http://www.linuxjournal.com/comment/reply/8149
> > 
> > what i want to do is nicely described in this bugreport by some other person:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336772
> > 
> > i want to connect a AoE driver to vblade on _one_ host and i have tried that mentioned "clever juggling of
network devices" on my system, but i didn`t succedd.
> > 
> > some coraid employee recommended trying linux-bridging - so i created two dummy interfaces (module
dummy.ko), created a bridge "aoe-bridge" and added dummy0 and dummy1 to that bridge.
> > 
> > then i "connected" AoE-driver to dummy0 and vblade server process to dummy1 and would have expected that
this should work.
> > 
> > unfortunately, it failed to work and from what it seems it wasn`t a problem with AoE or vblade but with the
bridge, because i couldn`t see (tcpdump) packets going through into both directions. 
> > 
> > afaik, after starting, the bridge is in some "learning" state, to see what is on the "left side" and on the
"right side".
> > i`m somewhat unsure if AoE/vblade are sending out enough (or the right?) packets to make the bridge let
them go through (aoe and vblade get aware of each other via broadcast) 
> > 
> > can somebody give an advice on what needs to be taken into account here and what could be done to debug this?
> > regards
> > 
> > roland k. 
> > systems engineer
> 
> 

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

_______________________________________________
Bridge mailing list
Bridge <at> lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge
devzero | 12 Mar 12:38 2006
Picon

aoe/vblade on "localhost"

hello !

i try to use a network technology on one single host, which wasn`t designed for that. 

to give a short overview of what i`m talking about:

AoE is just like a "networked blockdevice" (just like nbd/enbd) - but without tcp/ip. 
AoE kernel driver is the "client end" (see this like an iSCSI initiator) - and an etherblade storage
appliance is the "server end" (see this like an iSCSI target)
there is a software equivalent to etherblade storage which is called vblade (part of the aoetools project)
- or vblade-kernel (another implementation, but done as a kernel module)

a very nice article about what AoE is can be found at http://www.linuxjournal.com/comment/reply/8149

what i want to do is nicely described in this bugreport by some other person:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336772

i want to connect a AoE driver to vblade on _one_ host and i have tried that mentioned "clever juggling of
network devices" on my system, but i didn`t succedd.

some coraid employee recommended trying linux-bridging - so i created two dummy interfaces (module
dummy.ko), created a bridge "aoe-bridge" and added dummy0 and dummy1 to that bridge.

then i "connected" AoE-driver to dummy0 and vblade server process to dummy1 and would have expected that
this should work.

unfortunately, it failed to work and from what it seems it wasn`t a problem with AoE or vblade but with the
bridge, because i couldn`t see (tcpdump) packets going through into both directions. 

afaik, after starting, the bridge is in some "learning" state, to see what is on the "left side" and on the
"right side".
i`m somewhat unsure if AoE/vblade are sending out enough (or the right?) packets to make the bridge let them
go through (aoe and vblade get aware of each other via broadcast) 

can somebody give an advice on what needs to be taken into account here and what could be done to debug this?
regards

roland k. 
systems engineer
______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!		
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

_______________________________________________
Bridge mailing list
Bridge <at> lists.osdl.org
https://lists.osdl.org/mailman/listinfo/bridge

Gmane