From dane at aiinet.com Mon Mar 1 05:56:57 2004 From: dane at aiinet.com (Dan Eble) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] update: kernel bcp patch (ppc 2.4.21-pre4) Message-ID: The BCP patch I posted last week was missing the definition of ETH_FCS_LEN. This one includes it. The original message, which includes some explanation, is archived at http://marc.theaimsgroup.com/?l=linux-ppp&r=1&b=200402&w=2 (and many other places, I expect). -- Dan Eble _____ . Software Engineer | _ |/| Applied Innovation Inc. | |_| | | http://www.aiinet.com/ |__/|_|_| -------------- next part -------------- diff -wbBurN linux-2.4.21-pre4/include/linux/if_ether.h linux-ai/include/linux/if_ether.h --- linux-2.4.21-pre4/include/linux/if_ether.h 2004-02-25 08:26:45.000000000 -0500 +++ linux-ai/include/linux/if_ether.h 2004-02-25 08:35:18.000000000 -0500 @@ -31,6 +31,7 @@ #define ETH_ZLEN 60 /* Min. octets in frame sans FCS */ #define ETH_DATA_LEN 1500 /* Max. octets in payload */ #define ETH_FRAME_LEN 1514 /* Max. octets in frame sans FCS */ +#define ETH_FCS_LEN 4 /* Frame Check Sequence Length */ /* * These are the defined Ethernet Protocol ID's. diff -wbBurN linux-2.4.21-pre4/include/linux/ppp_defs.h linux-ai/include/linux/ppp_defs.h --- linux-2.4.21-pre4/include/linux/ppp_defs.h 2004-02-25 08:26:46.000000000 -0500 +++ linux-ai/include/linux/ppp_defs.h 2004-02-25 08:35:18.000000000 -0500 @@ -70,13 +70,16 @@ #define PPP_IPX 0x2b /* IPX protocol */ #define PPP_VJC_COMP 0x2d /* VJ compressed TCP */ #define PPP_VJC_UNCOMP 0x2f /* VJ uncompressed TCP */ +#define PPP_BRIDGE 0x31 /* Bridged LAN traffic or BPDU */ #define PPP_MP 0x3d /* Multilink protocol */ #define PPP_IPV6 0x57 /* Internet Protocol Version 6 */ #define PPP_COMPFRAG 0xfb /* fragment compressed below bundle */ #define PPP_COMP 0xfd /* compressed packet */ +#define PPP_BPDU_IEEE 0x0201 /* IEEE 802.1 (D or G) bridge PDU */ #define PPP_IPCP 0x8021 /* IP Control Protocol */ #define PPP_ATCP 0x8029 /* AppleTalk Control Protocol */ #define PPP_IPXCP 0x802b /* IPX Control Protocol */ +#define PPP_BCP 0x8031 /* Bridging Control Protocol */ #define PPP_IPV6CP 0x8057 /* IPv6 Control Protocol */ #define PPP_CCPFRAG 0x80fb /* CCP at link level (below MP bundle) */ #define PPP_CCP 0x80fd /* Compression Control Protocol */ @@ -174,6 +177,34 @@ time_t recv_idle; /* time since last NP packet received */ }; +/* + * Bridging Control Protocol (BCP) + */ +struct bcp_hdr { + __u8 flags; + __u8 mactype; + __u8 padbyte; /* not used (present when "control" is also) */ + __u8 control; /* 802.4, 802.5, and FDDI only */ +}; +#define BCP_802_3_HDRLEN 2 + +/* + * Fields in bcp_hdr::flags. + */ +#define BCP_LAN_FCS 0x80 /* set when LAN FCS is present */ +#define BCP_ZERO_PAD 0x20 /* set to pad 802.3 to min size */ +#define BCP_PADS_MASK 0x0F /* 0-15 bytes padding before PPP FCS */ + +/* + * Values for bcp_hdr::mactype. + */ +#define BCP_MAC_802_3 0x01 /* 802.3 / Ethernet */ +#define BCP_MAC_802_4 0x02 +#define BCP_MAC_802_5_NC 0x03 /* with non-canonical address */ +#define BCP_MAC_FDDI_NC 0x04 /* with non-canonical address */ +#define BCP_MAC_802_5 0x0B /* with canonical address */ +#define BCP_MAC_FDDI 0x0C /* with canonical address */ + #ifndef __P #ifdef __STDC__ #define __P(x) x diff -wbBurN linux-2.4.21-pre4/drivers/net/ppp_generic.c linux-ai/drivers/net/ppp_generic.c --- linux-2.4.21-pre4/drivers/net/ppp_generic.c 2004-02-25 08:26:18.000000000 -0500 +++ linux-ai/drivers/net/ppp_generic.c 2004-02-25 08:35:08.000000000 -0500 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -37,6 +38,7 @@ #include #include #include +#include #include #include #include @@ -57,7 +59,9 @@ #define NP_IPV6 1 /* Internet Protocol V6 */ #define NP_IPX 2 /* IPX protocol */ #define NP_AT 3 /* Appletalk protocol */ -#define NUM_NP 4 /* Number of NPs. */ +#define NP_BRIDGE 4 /* Bridged LAN packets */ +#define NP_BPDU_IEEE 5 /* IEEE 802.1 (D or G) bridge PDU */ +#define NUM_NP 6 /* Number of NPs. */ #define MPHDRLEN 6 /* multilink protocol header length */ #define MPHDRLEN_SSN 4 /* ditto with short sequence numbers */ @@ -88,6 +92,8 @@ #define ROUNDUP(n, x) (((n) + (x) - 1) / (x)) +struct bcp_device; + /* * Data structure describing one ppp unit. * A ppp unit corresponds to a ppp network interface device @@ -116,6 +122,7 @@ unsigned long last_xmit; /* jiffies when last pkt sent 9c */ unsigned long last_recv; /* jiffies when last pkt rcvd a0 */ struct net_device *dev; /* network interface device a4 */ + struct bcp_device *bcp; /* net. interface for bridging */ #ifdef CONFIG_PPP_MULTILINK int nxchan; /* next channel to send something on */ u32 nxseq; /* next sequence number to send */ @@ -131,6 +138,28 @@ #endif /* CONFIG_PPP_FILTER */ }; +struct bcp_device { + struct net_device dev; /* ->priv points to struct ppp */ + struct net_device_stats stats; /* statistics */ +}; + +/* this looks better than a cast in the code */ +static __inline__ struct bcp_device* dev_to_bcp(struct net_device* dev) +{ + return (struct bcp_device*)dev; +} + +/* this looks better than a cast in the code */ +static __inline__ struct net_device* bcp_to_dev(struct bcp_device* bcp) +{ + return (struct net_device*)bcp; +} + +static __inline__ struct ppp* bcp_to_ppp(struct bcp_device* bcp) +{ + return bcp ? (struct ppp *)bcp_to_dev(bcp)->priv : NULL; +} + /* * Bits in flags: SC_NO_TCP_CCID, SC_CCP_OPEN, SC_CCP_UP, SC_LOOP_TRAFFIC, * SC_MULTILINK, SC_MP_SHORTSEQ, SC_MP_XSHORTSEQ, SC_COMP_TCP, SC_REJ_COMP_TCP. @@ -237,6 +266,9 @@ /* Prototypes. */ static int ppp_unattached_ioctl(struct ppp_file *pf, struct file *file, unsigned int cmd, unsigned long arg); +static int ppp_start_xmit(struct sk_buff *skb, struct net_device *dev); +static int ppp_common_start_xmit(int npi, struct sk_buff *skb, + struct net_device *dev); static void ppp_xmit_process(struct ppp *ppp); static void ppp_send_frame(struct ppp *ppp, struct sk_buff *skb); static void ppp_push(struct ppp *ppp); @@ -268,6 +300,12 @@ static int ppp_connect_channel(struct channel *pch, int unit); static int ppp_disconnect_channel(struct channel *pch); static void ppp_destroy_channel(struct channel *pch); +static int ppp_create_bcp(struct ppp *ppp); +static void ppp_shutdown_bcp(struct ppp *ppp); +static struct net_device_stats *bcp_net_stats(struct net_device *dev); +static int bcp_net_ioctl(struct net_device *, struct ifreq *ifr, int cmd); +static int bcp_net_change_mtu(struct net_device *dev, int new_mtu); +static int bcp_start_xmit(struct sk_buff *skb, struct net_device *dev); /* Translates a PPP protocol number to a NP index (NP == network protocol) */ static inline int proto_to_npindex(int proto) @@ -281,6 +319,10 @@ return NP_IPX; case PPP_AT: return NP_AT; + case PPP_BRIDGE: + return NP_BRIDGE; + case PPP_BPDU_IEEE: + return NP_BPDU_IEEE; } return -EINVAL; } @@ -291,6 +333,8 @@ PPP_IPV6, PPP_IPX, PPP_AT, + PPP_BRIDGE, + PPP_BPDU_IEEE, }; /* Translates an ethertype into an NP index */ @@ -318,6 +362,13 @@ ETH_P_PPPTALK, }; +/* IEEE 802.1D bridge PDU destination address */ +static const __u8 IEEE_802_1D_DSTADDR[ETH_ALEN] = { 1, 0x80, 0xC2, 0, 0, 0 }; + +/* A few bytes that are present when and IEEE 802.1D bridge PDU is + * packed into an IEEE 802.3 frame. */ +static const __u8 IEEE_802_1D_802_3_HDR[] = { 0x42, 0x42, 0x03 }; + /* * Locking shorthand. */ @@ -440,6 +491,10 @@ goto err1; } + /* Increase the priority of control protocol packets so that + * they are not impeded by plain old data packets. */ + skb->priority = TC_PRIO_CONTROL; + skb_queue_tail(&pf->xq, skb); switch (pf->kind) { @@ -642,7 +697,20 @@ if (copy_to_user((void *) arg, &npi, sizeof(npi))) break; } else { + if (i == NP_BRIDGE) { + if (npi.mode == NPMODE_PASS) { + err = ppp_create_bcp(ppp); + if (err < 0) + break; + ppp->npmode[i] = npi.mode; + } else { + ppp->npmode[NP_BRIDGE] = npi.mode; + ppp->npmode[NP_BPDU_IEEE] = npi.mode; + ppp_shutdown_bcp(ppp); + } + } else { ppp->npmode[i] = npi.mode; + } /* we may be able to transmit more packets now (??) */ netif_wake_queue(ppp->dev); } @@ -800,11 +868,18 @@ static int ppp_start_xmit(struct sk_buff *skb, struct net_device *dev) { + int npi = ethertype_to_npindex(ntohs(skb->protocol)); + return ppp_common_start_xmit(npi, skb, dev); +} + +/* Called by PPP and BCP transmission routines. */ +static int +ppp_common_start_xmit(int npi, struct sk_buff *skb, struct net_device *dev) +{ struct ppp *ppp = (struct ppp *) dev->priv; - int npi, proto; + int proto; unsigned char *pp; - npi = ethertype_to_npindex(ntohs(skb->protocol)); if (npi < 0) goto err1; @@ -1104,7 +1179,8 @@ spin_lock_bh(&pch->downl); if (pch->chan) { - if (pch->chan->ops->start_xmit(pch->chan, skb)) + if (skb_queue_len(&pch->file.xq) == 0 + && pch->chan->ops->start_xmit(pch->chan, skb)) ppp->xmit_pending = 0; } else { /* channel got unregistered */ @@ -1411,6 +1487,104 @@ slhc_toss(ppp->vj); } +/* Decapsulate a packet from BCP. */ +static __inline__ struct sk_buff* bcp_decap(struct sk_buff *skb) +{ + /** @todo cope with PADS field in BCP header? */ + + struct net_device *const dev = skb->dev; + __u8 bcp_flags; + + /* Make sure that the data we examine are present. */ + if (!pskb_may_pull(skb, BCP_802_3_HDRLEN)) + goto drop; + + /* Currently, only 802.3/Ethernet bridging is supported. */ + if (((struct bcp_hdr*)skb->data)->mactype != BCP_MAC_802_3) + goto drop; + + bcp_flags = ((struct bcp_hdr*)skb->data)->flags; + + skb_pull(skb, BCP_802_3_HDRLEN); + skb->mac.raw = skb->data; + + /* remove LAN FCS */ + if (bcp_flags & BCP_LAN_FCS) + { + if (skb->len < ETH_FCS_LEN) + goto drop; + skb_trim(skb, skb->len - ETH_FCS_LEN); + } + + /* decompress "Tinygrams" */ + if ((bcp_flags & BCP_ZERO_PAD) && (skb->len < ETH_ZLEN)) { + const int pad_len = ETH_ZLEN - skb->len; + + if ((skb_tailroom(skb) < pad_len) || skb_cloned(skb)) { + struct sk_buff *old_skb = skb; + skb = skb_copy_expand(old_skb, 0, pad_len, GFP_ATOMIC); + kfree_skb(old_skb); + if (!skb) + goto dropped; + } + + skb_put(skb, pad_len); + memset(skb->tail - pad_len, 0, pad_len); + } + + /* Parse the ethernet header. Because of the increased + * hard_header_len, eth_type_trans() skips too much, so push + * some back afterward. */ + skb->protocol = eth_type_trans(skb, dev); + skb_push(skb, dev->hard_header_len - ETH_HLEN); + + return skb; + + drop: + kfree_skb(skb); + dropped: + return 0; +} + +/* Decapsulate an IEEE 802.1 (D or G) PDU. */ +static __inline__ struct sk_buff* bpdu_ieee_decap(struct sk_buff *skb) +{ + struct net_device *const dev = skb->dev; + struct ethhdr *eth; + + if ((skb_headroom(skb) < ETH_HLEN + sizeof(IEEE_802_1D_802_3_HDR)) + || skb_cloned(skb)) { + struct sk_buff *old_skb = skb; + skb = skb_copy_expand(old_skb, + ETH_HLEN + sizeof(IEEE_802_1D_802_3_HDR), + 0, GFP_ATOMIC); + kfree_skb(old_skb); + if (!skb) + goto dropped; + } + + /* Prepend the 802.3 SAP and control byte. */ + memcpy(skb_push(skb, sizeof(IEEE_802_1D_802_3_HDR)), + IEEE_802_1D_802_3_HDR, sizeof(IEEE_802_1D_802_3_HDR)); + + /* Prepend an ethernet header. */ + eth = (struct ethhdr *)skb_push(skb, ETH_HLEN); + memcpy(eth->h_dest, IEEE_802_1D_DSTADDR, ETH_ALEN); + memset(eth->h_source, 0, ETH_ALEN); + eth->h_proto = htons(skb->len - ETH_HLEN); + + /* Parse the ethernet header. Because of the increased + * hard_header_len, eth_type_trans() skips too much, so push + * some back afterward. */ + skb->protocol = eth_type_trans(skb, dev); + skb_push(skb, dev->hard_header_len - ETH_HLEN); + + return skb; + + dropped: + return 0; +} + static void ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb) { @@ -1488,6 +1662,7 @@ } else { /* network protocol frame - give it to the kernel */ + struct net_device *rxdev; #ifdef CONFIG_PPP_FILTER /* check if the packet passes the pass and active filters */ @@ -1511,22 +1686,58 @@ ppp->last_recv = jiffies; #endif /* CONFIG_PPP_FILTER */ - if ((ppp->dev->flags & IFF_UP) == 0 - || ppp->npmode[npi] != NPMODE_PASS) { + switch (npi) { + case NP_BRIDGE: + case NP_BPDU_IEEE: + rxdev = bcp_to_dev(ppp->bcp); + break; + default: + rxdev = ppp->dev; + break; + } + + if ((ppp->npmode[npi] != NPMODE_PASS) + || !rxdev + || (rxdev->flags & IFF_UP) == 0) { kfree_skb(skb); } else { skb_pull(skb, 2); /* chop off protocol */ - skb->dev = ppp->dev; + skb->dev = rxdev; + + switch (npi) { + case NP_BRIDGE: + skb = bcp_decap(skb); + if (!skb) { + ++ppp->bcp->stats.rx_dropped; + goto dropped; + } + ++ppp->bcp->stats.rx_packets; + break; + + case NP_BPDU_IEEE: + skb = bpdu_ieee_decap(skb); + if (!skb) { + ++ppp->bcp->stats.rx_dropped; + goto dropped; + } + ++ppp->bcp->stats.rx_packets; + break; + + default: skb->protocol = htons(npindex_to_ethertype[npi]); skb->mac.raw = skb->data; + break; + } + netif_rx(skb); - ppp->dev->last_rx = jiffies; + rxdev->last_rx = jiffies; } } return; err: kfree_skb(skb); + dropped: ppp_receive_error(ppp); } @@ -2255,6 +2466,8 @@ ppp->file.hdrlen = PPP_HDRLEN - 2; /* don't count proto bytes */ for (i = 0; i < NUM_NP; ++i) ppp->npmode[i] = NPMODE_PASS; + ppp->npmode[NP_BRIDGE] = NPMODE_DROP; + ppp->npmode[NP_BPDU_IEEE] = NPMODE_DROP; INIT_LIST_HEAD(&ppp->channels); spin_lock_init(&ppp->rlock); spin_lock_init(&ppp->wlock); @@ -2316,6 +2529,8 @@ { struct net_device *dev; + ppp_shutdown_bcp(ppp); + down(&all_ppp_sem); ppp_lock(ppp); dev = ppp->dev; @@ -2620,6 +2835,230 @@ *pmap = NULL; } +/* + * Create interface for bridging. + */ +static int +ppp_create_bcp(struct ppp *ppp) +{ + struct bcp_device *bcp; + struct net_device *dev; + int ret; + + /* If it already exists, ignore the request. */ + if (ppp->bcp) + return 0; + + /* create a new BCP dev */ + ret = -ENOMEM; + bcp = kmalloc(sizeof(struct bcp_device), GFP_KERNEL); + if (!bcp) + goto err; + memset(bcp, 0, sizeof(struct bcp_device)); + dev = bcp_to_dev(bcp); + + ether_setup(dev); + + dev->hard_header_len = ppp->dev->hard_header_len + + BCP_802_3_HDRLEN + ETH_HLEN; + + /* ETH_FCS_LEN is not subtracted from the PPP MTU here because + * bcp_start_xmit() never adds the FCS. */ + dev->mtu = ppp->dev->mtu - (BCP_802_3_HDRLEN + ETH_HLEN); + + if (dev->mtu > ETH_DATA_LEN) + dev->mtu = ETH_DATA_LEN; + + dev->hard_start_xmit = bcp_start_xmit; + dev->get_stats = bcp_net_stats; + dev->do_ioctl = bcp_net_ioctl; + dev->change_mtu = bcp_net_change_mtu; + dev->tx_queue_len = 0; /* let PPP device queue packets */ + dev->features |= NETIF_F_DYNALLOC; + sprintf(dev->name, "bcp%d", ppp->file.index); + + rtnl_lock(); + ret = register_netdevice(dev); + rtnl_unlock(); + if (ret != 0) { + printk(KERN_ERR "PPP: couldn't register device %s (%d)\n", + dev->name, ret); + goto err; + } + else { + /* Associate the devices. Since register_netdevice() + * would fail if there were already a bcp device + * registered for this ppp, there is no need to + * worry about overwriting a valid ppp->bcp.dev. */ + ppp_lock(ppp); + ppp->bcp = bcp; + dev->priv = ppp; + ppp_unlock(ppp); + } + + return 0; + + err: + if (bcp) + kfree(bcp); + return ret; +} + +/* + * Take down a bcp interface. + */ +static void +ppp_shutdown_bcp(struct ppp *ppp) +{ + struct bcp_device *bcp; + + ppp_lock(ppp); + bcp = ppp->bcp; + ppp->bcp = 0; + ppp_unlock(ppp); + + if (bcp) { + rtnl_lock(); + dev_close(bcp_to_dev(bcp)); + unregister_netdevice(bcp_to_dev(bcp)); + rtnl_unlock(); + } +} + +static struct net_device_stats * +bcp_net_stats(struct net_device *dev) +{ + struct bcp_device *const bcp = dev_to_bcp(dev); + return &bcp->stats; +} + +static int +bcp_net_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +{ + return -EOPNOTSUPP; +} + +static int +bcp_net_change_mtu(struct net_device *dev, int new_mtu) +{ + /* MTU is negotiated by the PPP daemon and should not be changed. */ + return -EOPNOTSUPP; +} + +/* input: ethernet frame in non-shared skbuff + * output: bcp-encapsulated frame in non-shared and non-cloned skbuff + */ +static __inline__ +struct sk_buff* bcp_encap(struct sk_buff *skb, struct net_device *dev) +{ + struct bcp_hdr *bhdr; + int pad_len; + + /* @todo Calculate FCS? NB: If you add this, be sure to + * change the MTU calculation in ppp_create_bcp() to account + * for it. */ + + /* There is currently no communication from pppd regarding the + * peer's Tinygram-Compression option. Therefore, we always + * pad short frames to minimum Ethernet size in case the peer + * does not support Tinygrams. */ + pad_len = (skb->len < ETH_ZLEN) ? (ETH_ZLEN - skb->len) : 0; + + /* Add a BCP header and pad to minimum frame size. + * + * Observations: + * - Tailroom is always inadequate for short packets like ARP. + * - Headroom is usually adequate, because the kernel usually + * checks dev->hard_header_len; however, it is possible to + * be given a buffer that was originally allocated for another + * device. (I have not seen it during testing.) + * - It is not possible for a buffer to be shared, because + * bcp_start_xmit() calls skb_share_check(). + * - I do not know when a buffer might be cloned; perhaps it + * is possible in a bridging application where the same + * packet needs to be transmitted to multiple interfaces. + */ + if ((skb_tailroom(skb) < pad_len) + || (skb_headroom(skb) < dev->hard_header_len) + || skb_cloned(skb)) { + struct sk_buff *old_skb = skb; + skb = skb_copy_expand(old_skb, + dev->hard_header_len, pad_len, + GFP_ATOMIC); + kfree_skb(old_skb); + if (!skb) + goto dropped; + } + + bhdr = (struct bcp_hdr*)skb_push(skb, BCP_802_3_HDRLEN); + bhdr->flags = 0; /* no LAN FCS, not a tinygram */ + bhdr->mactype = BCP_MAC_802_3; /* 802.3 / Ethernet */ + + return skb; + + dropped: + return 0; +} + +/* input: BPDU ethernet frame in non-shared skbuff + * output: naked BPDU in non-shared and non-cloned skbuff + */ +static __inline__ +struct sk_buff* bpdu_ieee_encap(struct sk_buff *skb, struct net_device *dev) +{ + /* pull off the link header */ + skb_pull(skb, ETH_HLEN + sizeof(IEEE_802_1D_802_3_HDR)); + + if (skb_cloned(skb)) { + struct sk_buff *old_skb = skb; + skb = skb_copy_expand(old_skb, dev->hard_header_len, 0, + GFP_ATOMIC); + kfree_skb(old_skb); + } + + return skb; +} + +static int +bcp_start_xmit(struct sk_buff *skb, struct net_device *dev) +{ + struct bcp_device *const bcp = dev_to_bcp(dev); + struct ppp *const ppp = bcp_to_ppp(bcp); + int npi; + + /* make sure we can push/pull without side effects */ + skb = skb_share_check(skb, GFP_ATOMIC); + if (!skb) + goto dropped; + + /* When configured to encapsulate 802.1D bridge PDUs in the + * obsolete manner of RFC 1638, do it. Otherwise, send it + * like any other packet. */ + if ((ppp->npmode[NP_BPDU_IEEE] == NPMODE_PASS) && + pskb_may_pull(skb, ETH_HLEN + sizeof(IEEE_802_1D_802_3_HDR)) && + (0 == memcmp(skb->data, IEEE_802_1D_DSTADDR, ETH_ALEN)) && + (0 == memcmp(&skb->data[ETH_HLEN], IEEE_802_1D_802_3_HDR, + sizeof(IEEE_802_1D_802_3_HDR)))) { + skb = bpdu_ieee_encap(skb, dev); + npi = NP_BPDU_IEEE; + } else { + skb = bcp_encap(skb, dev); + npi = NP_BRIDGE; + } + + if (!skb) + goto dropped; + + /* send packet through the PPP interface */ + skb->dev = ppp->dev; + ++bcp->stats.tx_packets; + return ppp_common_start_xmit(npi, skb, skb->dev); + + dropped: + ++bcp->stats.tx_dropped; + return 0; +} + /* Module/initialization stuff */ module_init(ppp_init); From software-team at wp.pl Mon Mar 1 08:31:32 2004 From: software-team at wp.pl (Software-team) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] i need some help with compiling bridge module In-Reply-To: <200402282000.i1SK06E28411@mail.osdl.org> References: <200402282000.i1SK06E28411@mail.osdl.org> Message-ID: <20040301173132.6aeedb29@localhost.localdomain> I am trying to improve bridge module towards 802.1w (RSTP) but I am new to kernel and modules programming. I dont want to compile the whole modules every time I make some changes. Could you give me some clues how to set up environment to compile only selected module (bridge 802.1d) for a given kernel version, written in Makefile like: VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 20 EXTRAVERSION =-8 etc. How to make a Makefile so the bridge module could be compiled separately for that kernel (or another)? Thanks for any specyfic help. Software Team From s-luppescu at uchicago.edu Mon Mar 1 09:40:52 2004 From: s-luppescu at uchicago.edu (Stuart Luppescu) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] i need some help with compiling bridge module In-Reply-To: <20040301173132.6aeedb29@localhost.localdomain> References: <200402282000.i1SK06E28411@mail.osdl.org> <20040301173132.6aeedb29@localhost.localdomain> Message-ID: <1078162852.30723.20.camel@musuko.uchicago.edu> On ?, 2004-03-01 at 10:31, Software-team wrote: > I am trying to improve bridge module towards 802.1w (RSTP) but I am new to kernel and modules programming. I dont want to compile the whole modules every time I make some changes. Could you give me some clues how to set up environment to compile only selected module (bridge 802.1d) for a given kernel version, written in Makefile like: > VERSION = 2 > PATCHLEVEL = 4 > SUBLEVEL = 20 > EXTRAVERSION =-8 etc. > How to make a Makefile so the bridge module could be compiled separately for that kernel (or another)? > Thanks for any specyfic help. It's pretty easy. do make menuconfig, and under Networking Options put 'M' where it says 802.1d Ethernet Bridging. Save your config, and then do make dep && make bzImage modules modules_install Move the /usr/src/linux/arch/i386/boot/bzImage to somewhere in /boot (renaming it if you like), make the appropriate modification to lilo.conf (and then rerun lilo) or change /boot/grub/grub.conf and reboot. When it starts up again, just modprobe bridge. I also found that I had to do make mrproper before I could get the bridge module to load. In this case, make sure you save your .config file to somewhere else first, or you'll lose it. HTH. -- Stuart Luppescu -=- s-luppescu .at. uchicago.edu University of Chicago -=- CCSR ???????? -=- Kernel 2.6.3-gentoo-r1 Bilbo's First Law: You cannot count friends that are all packed up in barrels. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.linux-foundation.org/pipermail/bridge/attachments/20040301/72f4696e/attachment.pgp From software-team at wp.pl Mon Mar 1 10:15:46 2004 From: software-team at wp.pl (Software-team) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] problems with compiling kernel modules In-Reply-To: <200402282000.i1SK06E28411@mail.osdl.org> References: <200402282000.i1SK06E28411@mail.osdl.org> Message-ID: <20040301191546.7f0731fa@localhost.localdomain> I finally found a solution to compile kernel module "bridge" with the same (!) kernel headers I once compiled my kernel with success. Makefile contains the same version of kernel (2.4.20, event the same extraersion -8). But when I try to insert that module into a kernel with insmod I get a lot of errors. Could anyone tell me whats wrong? What am I doing wrong? I guess there is some way to compile only a module, not the whole kernel, which is very useful for developers. Does anyone know how to do so? Thanks, there comes my errors.... [root@localhost linux-2.4.20]# insmod net/bridge/bridge.o net/bridge/bridge.o: unresolved symbol __dev_get_by_name_Rsmp_dff2466c net/bridge/bridge.o: unresolved symbol register_netdev_Rsmp_807e44f8 net/bridge/bridge.o: unresolved symbol ether_setup_Rsmp_66797dc6 net/bridge/bridge.o: unresolved symbol eth_type_trans_Rsmp_697fcdb3 net/bridge/bridge.o: unresolved symbol netif_rx_Rsmp_c5346eca net/bridge/bridge.o: unresolved symbol __write_lock_failed net/bridge/bridge.o: unresolved symbol add_timer_Rsmp_a19eacf8 net/bridge/bridge.o: unresolved symbol del_timer_Rsmp_fc62f16d net/bridge/bridge.o: unresolved symbol __out_of_line_bug_Rsmp_8b0fd3c5 net/bridge/bridge.o: unresolved symbol dev_get_by_index_Rsmp_604eff36 net/bridge/bridge.o: unresolved symbol dev_set_promiscuity_Rsmp_c4ed559b net/bridge/bridge.o: unresolved symbol unregister_netdevice_notifier_Rsmp_fe769456 net/bridge/bridge.o: unresolved symbol __generic_copy_to_user_Rsmp_d523fdd3 net/bridge/bridge.o: unresolved symbol skb_over_panic_Rsmp_8f714d09 net/bridge/bridge.o: unresolved symbol skb_under_panic_Rsmp_26d771ad net/bridge/bridge.o: unresolved symbol br_ioctl_hook_Rsmp_1fb9705f net/bridge/bridge.o: unresolved symbol __br_write_unlock_Rsmp_702da97e net/bridge/bridge.o: unresolved symbol __read_lock_failed net/bridge/bridge.o: unresolved symbol __kfree_skb_Rsmp_fb8e515b net/bridge/bridge.o: unresolved symbol printk_Rsmp_1b7d4074 net/bridge/bridge.o: unresolved symbol kfree_Rsmp_037a0cba net/bridge/bridge.o: unresolved symbol unregister_netdev_Rsmp_091a1ac4 net/bridge/bridge.o: unresolved symbol kmalloc_Rsmp_93d4cfe6 net/bridge/bridge.o: unresolved symbol register_netdevice_notifier_Rsmp_63ecad53 net/bridge/bridge.o: unresolved symbol netdev_finish_unregister_Rsmp_d29730a1 net/bridge/bridge.o: unresolved symbol alloc_skb_Rsmp_6505afe0 net/bridge/bridge.o: unresolved symbol do_softirq_Rsmp_f0a529b7 net/bridge/bridge.o: unresolved symbol br_handle_frame_hook_Rsmp_aed5cfaa net/bridge/bridge.o: unresolved symbol irq_stat_Rsmp_ed7388c8 net/bridge/bridge.o: unresolved symbol dev_queue_xmit_Rsmp_38e4c261 net/bridge/bridge.o: unresolved symbol __br_write_lock_Rsmp_13836e40 net/bridge/bridge.o: unresolved symbol jiffies_Rsmp_0da02d67 net/bridge/bridge.o: unresolved symbol skb_clone_Rsmp_b0b1927a From software-team at wp.pl Mon Mar 1 10:45:16 2004 From: software-team at wp.pl (Software Team) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] i need some help with compiling bridge module Message-ID: <404384BC.2010402@wp.pl> On ?, 2004-03-01 at 10:31, Software-team wrote: > I am trying to improve bridge module towards 802.1w (RSTP) but I am new to kernel and modules programming. I dont want to compile the whole modules every time I make some changes. Could you give me some clues how to set up environment to compile only selected module (bridge 802.1d) for a given kernel version, written in Makefile like: > VERSION = 2 > PATCHLEVEL = 4 > SUBLEVEL = 20 > EXTRAVERSION =-8 etc. > How to make a Makefile so the bridge module could be compiled separately for that kernel (or another)? > Thanks for any specyfic help. It's pretty easy. do make menuconfig, and under Networking Options put 'M' where it says 802.1d Ethernet Bridging. Save your config, and then do make dep && make bzImage modules modules_install Move the /usr/src/linux/arch/i386/boot/bzImage to somewhere in /boot (renaming it if you like), make the appropriate modification to lilo.conf (and then rerun lilo) or change /boot/grub/grub.conf and reboot. When it starts up again, just modprobe bridge. I also found that I had to do make mrproper before I could get the bridge module to load. In this case, make sure you save your .config file to somewhere else first, or you'll lose it. HTH. ----------------------------------------------- Yes, What you wrote is sure both right, and simple. But it takes a lot of time. But that is not what I want. I want to compile a bridge module separately, like you compile some modules that come you add later to your kernel (like i did for example with a NTFS module, which I downloaded and compilet separately from my kernel 2.4.20-8). I would like to do the same with Bridge module. I want to make some changes and compile it with kernel headers from my kernel. But I dont want to compile the whole kernel (ang go through that process you described) every time I make some minor changes to the module which uses the same kernel header files. There should be some way to do it, I sure. But I dont know how:( I can bet this, because nobody would write kernel if he should compile it every time one makes some change. This would take ages to finish the project. Still hoping for an answer. Software Team From abhijitk at nortelnetworks.com Mon Mar 1 11:53:18 2004 From: abhijitk at nortelnetworks.com (Abhijit Kumbhare) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Re: i need some help with compiling bridge module Message-ID: <404394AE.9050803@nortelnetworks.com> Skipped content of type multipart/alternative-------------- next part -------------- # -*-makefile-*- # # This file is part of the sample code for the book "Linux Device Drivers", # second edition. It is meant to be generic and is designed to be recycled # by other drivers. The comments should be clear enough. # It partly comes from Linux Makefile, and needs GNU make. # TOPDIR is declared by the Makefile including this file. ifndef TOPDIR TOPDIR = . endif # KERNELDIR can be speficied on the command line or environment ifndef KERNELDIR KERNELDIR = /usr/src/linux-2.4 endif # The headers are taken from the kernel INCLUDEDIR = $(KERNELDIR)/include # We need the configuration file, for CONFIG_SMP and possibly other stuff # (especiall for RISC platforms, where CFLAGS depends on the exact # processor being used). ifeq ($(KERNELDIR)/.config,$(wildcard $(KERNELDIR))/.config) include $(KERNELDIR)/.config else MESSAGE := $(shell echo "WARNING: no .config file in $(KERNELDIR)") endif # ARCH can be speficed on the comdline or env. too, and defaults to this arch # Unfortunately, we can't easily extract if from kernel configuration # (well, we could look athe asm- symlink... don't know if worth the effort) ifndef ARCH ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ -e s/arm.*/arm/ -e s/sa110/arm/) endif # This is useful if cross-compiling. Taken from kernel Makefile (CC changed) AS =$(CROSS_COMPILE)as LD =$(CROSS_COMPILE)ld CC =$(CROSS_COMPILE)gcc CPP =$(CC) -E AR =$(CROSS_COMPILE)ar NM =$(CROSS_COMPILE)nm STRIP =$(CROSS_COMPILE)strip OBJCOPY =$(CROSS_COMPILE)objcopy OBJDUMP =$(CROSS_COMPILE)objdump # The platform-specific Makefiles include portability nightmares. # Some platforms, though, don't have one, so check for existence first ARCHMAKEFILE = $(TOPDIR)/Makefile.$(ARCH) ifeq ($(ARCHMAKEFILE),$(wildcard $(ARCHMAKEFILE))) include $(ARCHMAKEFILE) endif # CFLAGS: all assignments to CFLAGS are inclremental, so you can specify # the initial flags on the command line or environment, if needed. CFLAGS += -Wall -D__KERNEL__ -DMODULE -I$(INCLUDEDIR) ifdef CONFIG_SMP CFLAGS += -D__SMP__ -DSMP endif # Prepend modversions.h if we're running with versioning. ifdef CONFIG_MODVERSIONS CFLAGS += -DMODVERSIONS -include $(KERNELDIR)/include/linux/modversions.h endif #Install dir VERSIONFILE = $(INCLUDEDIR)/linux/version.h VERSION = $(shell awk -F\" '/REL/ {print $$2}' $(VERSIONFILE)) INSTALLDIR = /lib/modules/$(VERSION)/misc -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/x-java-applet Size: 592 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/bridge/attachments/20040301/f6070a26/Makefile.bin From p.kabacinski at wp.pl Mon Mar 1 15:16:28 2004 From: p.kabacinski at wp.pl (=?ISO-8859-2?B?UHJ6ZW15c7NhdyBLYWJhY2nxc2tp?=) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Re: i need some help with compiling bridge module In-Reply-To: <404394AE.9050803@nortelnetworks.com> References: <404394AE.9050803@nortelnetworks.com> Message-ID: <20040302001628.4601d21f@localhost.localdomain> I really appreciate your help. It is working and now I can make changes only to that particular kernel module. I was looking for that information for a couple of days. Once again "thank you". This information is useful for anyone with desire to write ones own kernel module. I should only mention that: 7) there is some mistake; copy your kernel config (usualy /boot/config-2.X.Y-Z) to /us/src/linux-2.X.Y-Z/.config 9) remove any dependencies to other modules (which means remove any declared - in your ".config" file compiler directives (I'm not sure whether its correct in English) like in "my" bridge module: #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) br_fdb_get_hook = NULL; br_fdb_put_hook = NULL; #endif otherwise you will have to compile other modules; On Mon, 01 Mar 2004 11:53:18 -0800 Abhijit Kumbhare wrote: > I ran into the same problem as you did - and am also a linux newbee. I modified the make > files from the book "Linux Device Drivers" by Alessandro Rubini to compile the bridge module > separately in different directory from the linux source (it worked for me on linux 2.4 on a > normal Pentium 450 MHz - I think he has taken care of most of the version dependent stuff). > > You need to do the following to use that way: > > 1) Create a directory somewhere - say > 2) Create a sub-directory in called bridge (say) - so you have /bridge > 3) Copy over the bridge code into /bridge > 4) Copy the file Rules.make (attached) to > 5) Copy the Makefile to /bridge > 6) Change the variable KERNELDIR in Rules.make to your linux source path - I am using Red Hat > Linux so my variable was /usr/src/linux-2.4 > 7) Don't remember whether this is required for bridge module or it complained when I was compiling > some other module - but I had to copy my machine config to $KERNELDIR/.config (for me it was > the file /usr/src/linux-2.4/configs/kernel-2.4.20-i686.config). > 8) Compile in the /bridge directory using make (all, clean, etc.) .... .... From jim.small at eds.com Wed Mar 3 09:18:21 2004 From: jim.small at eds.com (Small, Jim) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Anyone successfully using bridging on a Sparc64 platform with a q fe card? Message-ID: <564DE4477544D411AD2C00508BDF0B6A1DD2AE4C@USAHM018.amer.corp.eds.com> I am currently working on getting bridging working on an Ultra 60 with a qfe card under Debian. I am aware of bridge-utils64 from Ben Collins, but I have had some trouble finding the correct combination of the kernel and library versions. Is anyone successfully using Debian Sparc64 with bridging? If so, could you tell me which kernel version (of 2.4) you are using, where you got it from (generic, Debian specific, etc...), and what versions of libraries (e.g. libc6-sparc64) you are using? Thanks, <> Jim From ramaparvathi at yahoo.com Wed Mar 3 15:41:32 2004 From: ramaparvathi at yahoo.com (rama chandrasekaran) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] (no subject) Message-ID: <20040303234132.1191.qmail@web60301.mail.yahoo.com> Dear Sir, I was trying to install bridge as we are installing scps gateway in our testbed.This requires us to install the bridge. Our Linux version is 2.4.18 ~3 and we are using redhat 7.2 Please let me know which is the bridge I should install and how to configure it. Before configuring the bridge what I should check in my configuration. Thanks for your time, Sincerely Rama ===== I hear and I forget, I see and I remember, I implement and I understand. __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com From ramaparvathi at yahoo.com Wed Mar 3 15:41:42 2004 From: ramaparvathi at yahoo.com (rama chandrasekaran) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Doubt Message-ID: <20040303234142.41334.qmail@web60304.mail.yahoo.com> Dear Sir, I was trying to install bridge as we are installing scps gateway in our testbed.This requires us to install the bridge. Our Linux version is 2.4.18 ~3 and we are using redhat 7.2 Please let me know which is the bridge I should install and how to configure it. Before configuring the bridge what I should check in my configuration. Thanks for your time, Sincerely Rama ===== I hear and I forget, I see and I remember, I implement and I understand. __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com From rajaraman at idealab-india.com Thu Mar 4 03:07:27 2004 From: rajaraman at idealab-india.com (Rajaraman S) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Bridge firewall Message-ID: <000001c401d8$e2532500$0618a8c0@rajaraman> Hi, I'm relatively new to linux world.I'm just trying to setup a bridge firewall between a router and LAN. I've installed Red Hat Linux 9.0 - 2.4.20-8 from installation CDs and upgraded to 2.4.25 successfully. I've patched my kernel to support bridge firewall also loaded ebtables module,so far so good.Now I tried to create a bridge using the code given in the following link http://www.sjdjweis.com/linux/bridging/bridge I ran the script,and then i typed 'brctl show' to check whether the bridge is up.It showed the created bridge but in the next few seconds machine froze completely.I had to restart the machine.I've tried doing the same thing four to five times but each time it froze after i created the bridge.What's happening??? Do I need to upgrade the kernel with any other patch or am I missing something very obvious. Expecting your reply. Thanks & Regards, S.Rajaraman iDeaLab India Pvt Ltd From liste at dgrent.it Thu Mar 4 02:31:24 2004 From: liste at dgrent.it (ndr) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] subscribe Message-ID: <1078396283.4073.2.camel@acerino> From jim.small at eds.com Mon Mar 8 10:40:35 2004 From: jim.small at eds.com (Small, Jim) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Bridging on Sparc64 Message-ID: <564DE4477544D411AD2C00508BDF0B6A1DE4F221@USAHM018.amer.corp.eds.com> Using Kernel 2.4.25 and bridge-utils64, I still can not get bridging working on the Sparc64 platform. Is anyone interested in helping me figure out what's wrong? If so, what can I do? Would I have better luck using 2.6.X? Any comments would be greatly appreciated. <> Jim From wesley at gds.co.za Mon Mar 8 01:45:06 2004 From: wesley at gds.co.za (Wesley GDS) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Permanent after reboot Message-ID: <018001c404f2$0ce0c3b0$6400a8c0@Wesley> Hi there I was just wondering if you could help me. I have set up a bridge between = my two eth cards, works fine. The problem i have is that when i reboot my = PC the bridge is lost. Is there any way i can make this permanent. I am running slackware 9.1 Kind Regards = Wesley Coleman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/2004030= 8/26a6ca40/attachment.htm From Adam.Lewis at motorola.com Wed Mar 10 11:51:54 2004 From: Adam.Lewis at motorola.com (Lewis Adam-CAL022) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Question on time to bring up bridge Message-ID: Skipped content of type multipart/alternative-------------- next part -----= --------- A non-text attachment was scrubbed... Name: Glacier Bkgrd.jpg Type: image/jpeg Size: 2743 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/bridge/attachments/200403= 10/0266b881/GlacierBkgrd.jpg From a.fiorino at chibacity.it Fri Mar 12 05:33:36 2004 From: a.fiorino at chibacity.it (Alessandro Fiorino) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Strange DHCP behaviour with bridging Message-ID: <200403121433.36583.a.fiorino@chibacity.it> Here is the scenario: I have one server with kernel 2.4.24 with a bridge br0 made of 2 interfaces, eth0 and tap0 (the last is an OpenVPN tunnel), and one remote computer connetting through tap0. If I assign a static IP to the remote computer, the bridge works perfecly (so I think the problem is not OpenVPN-related). If I start a DHCPd on the server and I configure the remote client to get the IP from it, something strange happens: if I "sniff" on the br0 interface, I can see the DHCP requests coming from the client (from 0.0.0.0.bootpc to 255.255.255.bootps) and the DHCPd answers going back from ip.of.the.server.bootps to 255.255.255.255.bootpc; also sniffing on eth0 gives the same result, but if I sniff on the tap0 interface, I don't see the replies! So the client never get its own IP. What I'm doing wrong? To add some mistery, sometimes (one try out of 10) the reply flows correctly to the remote client. All the three interfaces (eth0, br0, tap0) doesn't have firewalling enabled, and under /proc ip_forwarding is enabled and rp_filter is disabled for all interfaces. brctl showmacs br0 correctly shows the remote virtual interface MAC address as not local.Both eth0 and tap0 have been configured with ifconfig 0.0.0.0 promisc up. Thanks in advance. Alessandro Fiorino From skkwish at huadun.com.cn Thu Mar 11 21:17:47 2004 From: skkwish at huadun.com.cn (=?GB2312?Q?=C9=EA=EF=BF=EE=F8?=) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] (no subject) Message-ID: <200403120517.i2C5Hj5q006074@fire-2.osdl.org> U2tpcHBlZCBjb250ZW50IG9mIHR5cGUgbXVsdGlwYXJ0L2FsdGVybmF0aXZlLS0tLS0tLS0tLS0t LS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0tClRoaXMgbWFpbCBpcyBwcm9iYWJseSBzcGFtLiAg VGhlIG9yaWdpbmFsIG1lc3NhZ2UgaGFzIGJlZW4gYXR0YWNoZWQKYWxvbmcgd2l0aCB0aGlzIHJl cG9ydCwgc28geW91IGNhbiByZWNvZ25pemUgb3IgYmxvY2sgc2ltaWxhciB1bndhbnRlZAptYWls IGluIGZ1dHVyZS4gIFNlZSBodHRwOi8vc3BhbWFzc2Fzc2luLm9yZy90YWcvIGZvciBtb3JlIGRl dGFpbHMuCgpDb250ZW50IHByZXZpZXc6ICAtLT09PT0AMl9EcmFnb243MzgyNjQ1MzQzNjRfPT09 PUNvbnRlbnQtVHlwZToKICB0ZXh0L3BsYWluOyBjaGFyc2V0PSJHQjIzMTIiIENvbnRlbnQtVHJh bnNmZXItRW5jb2Rpbmc6IDdiaXQgaGkhIE15CiAgbGludXggaXMgMi40LjIwLCBJIGhhdmUgdHdv IEludGVybCBuZXRjYXJkLCBkcml2ZXIgaXMgZTEwMC5vLCB3aGVuIEkKICBhZGQgZXRoMCBhbmQg ZXRoMSB0byBicjAsIGFsbCBpcyByaWdodCwgdGhlbiBJIHJlbW92ZSBldGgwIG9yIGV0aDEgZnJv bQogIGJyMCwgdGhlbiBhZGQsIHJlbW92ZSxhZGQuIHJlcGVhdCBzb21lIHRpbWVzLCBteSBrZXJu ZWwgcGFuaWMsIHNjcmVlbgogIHNob3cgZGV2LmM6IGNhbGwgc2tiX2NoZWNrc3VtX2hlbHAoKTog OTQ3IGNvbmR1Y2UgdGhpcyBwcm9ibGVtLiBbLi4uXSAKCkNvbnRlbnQgYW5hbHlzaXMgZGV0YWls czogICAoNS40MCBwb2ludHMsIDUgcmVxdWlyZWQpCkhUTUxfNDBfNTAgICAgICAgICAoMS4xIHBv aW50cykgIEJPRFk6IE1lc3NhZ2UgaXMgNDAlIHRvIDUwJSBIVE1MCkhUTUxfRk9OVF9GQUNFX09E RCAoMC4xIHBvaW50cykgIEJPRFk6IEhUTUwgZm9udCBmYWNlIGlzIG5vdCBhIGNvbW1vbmx5IHVz ZWQgZmFjZQpIVE1MX01FU1NBR0UgICAgICAgKDAuMSBwb2ludHMpICBCT0RZOiBIVE1MIGluY2x1 ZGVkIGluIG1lc3NhZ2UKSFRNTF9GT05UX0JJRyAgICAgICgwLjIgcG9pbnRzKSAgQk9EWTogRk9O VCBTaXplICsyIGFuZCB1cCBvciAzIGFuZCB1cApIVE1MX1RBR19FWElTVFNfVEJPRFkgKDAuNSBw b2ludHMpICBCT0RZOiBIVE1MIGhhcyAidGJvZHkiIHRhZwpNSU1FX0xPTkdfTElORV9RUCAgKDAu MyBwb2ludHMpICBSQVc6IFF1b3RlZC1wcmludGFibGUgbGluZSBsb25nZXIgdGhhbiA3NiBjaGFy YWN0ZXJzCk1TR19JRF9BRERFRF9CWV9NVEFfMiAoMS4wIHBvaW50cykgICdNZXNzYWdlLUlkJyB3 YXMgYWRkZWQgYnkgYSByZWxheSAoMikKQ0hBUlNFVF9GQVJBV0FZX0hFQURFUlMgKDIuMSBwb2lu dHMpICBBIGZvcmVpZ24gbGFuZ3VhZ2UgY2hhcnNldCB1c2VkIGluIGhlYWRlcnMKCgo= From drkludge at cox.net Sun Mar 14 19:45:56 2004 From: drkludge at cox.net (Greg Morgan) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Permanent after reboot In-Reply-To: <018001c404f2$0ce0c3b0$6400a8c0@Wesley> References: <018001c404f2$0ce0c3b0$6400a8c0@Wesley> Message-ID: <405526F4.5040101@cox.net> Wesley GDS wrote: > Hi there > > I was just wondering if you could help me. I have set up a bridge > between my two eth cards, works fine. The problem i have is that when i > reboot my PC the bridge is lost. Is there any way i can make this > permanent. > > I am running slackware 9.1 There are a set of initialization files or init files in Linux. You will need to write a script. All the steps that you used to create the bridge by hand is what will be stored in this script. The your script will need to be called in runlevel 3 and runlevel 5. This is how Linux systems startup. You may want to search on System V ( as in five ) startup files. Each distro puts their startup file in a different directory. On Redhat systems it is in /etc/rc.d but I am not sure if this is the same for Slackware. I hope this helps, Greg From Joao.Carvalho at fe.up.pt Mon Mar 15 00:27:42 2004 From: Joao.Carvalho at fe.up.pt (Joao Carvalho) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Permanent after reboot In-Reply-To: <405526F4.5040101@cox.net> References: <018001c404f2$0ce0c3b0$6400a8c0@Wesley> <405526F4.5040101@cox.net> Message-ID: <200403150827.43103.Joao.Carvalho@fe.up.pt> just put it in /etc/rc.d/rc.local its simple and it works ;-) if you even so want to use an System V script you will have to create the dirs /etc/rc.d/init.d /etc/rc.d/rc3.d/ /etc/rc.d/rc5.d/ copy the script to init.d and create the links in rc3 and rc5. i would recopmend you using the rc.local just invoke your script. cheers JC On Monday 15 March 2004 03:45, Greg Morgan wrote: > Wesley GDS wrote: > > Hi there > > > > I was just wondering if you could help me. I have set up a bridge > > between my two eth cards, works fine. The problem i have is that when i > > reboot my PC the bridge is lost. Is there any way i can make this > > permanent. > > > > I am running slackware 9.1 > > There are a set of initialization files or init files in Linux. You > will need to write a script. All the steps that you used to create the > bridge by hand is what will be stored in this script. The your script > will need to be called in runlevel 3 and runlevel 5. This is how Linux > systems startup. You may want to search on System V ( as in five ) > startup files. Each distro puts their startup file in a different > directory. On Redhat systems it is in /etc/rc.d but I am not sure if > this is the same for Slackware. > > I hope this helps, > Greg > > _______________________________________________ > Bridge mailing list > Bridge@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/bridge -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joao de Deus Carvalho Phone: +351-225081635 Fax: +351-225081537 Faculdade de Engenharia da Email: Joao.Carvalho@foxlink.org Universidade do Porto PGP Key fingerprint = F9D4 EC6A 2BA2 BCD6 0585 1682 891F 156F 8833 E56E From shemminger at osdl.org Tue Mar 16 11:07:02 2004 From: shemminger at osdl.org (Stephen Hemminger) Date: Wed Apr 18 12:33:58 2007 Subject: [Bridge] Re: Strange DHCP behaviour with bridging In-Reply-To: <20040316082837.1797.qmail@daitarn.register.it> References: <20040316082837.1797.qmail@daitarn.register.it> Message-ID: <20040316110702.589a76e8@dell_ss3.pdx.osdl.net> On Tue, 16 Mar 2004 09:28:37 +0100 wrote: > I sent this message to the briding mailing list, but I didn't get any answer and I can't find how to subscribe; > I think you are the mailing list manager so I send this hoping for better luck. http://lists.osdl.org/mailman/listinfo/bridge > Here is the scenario: I have one server with kernel 2.4.24 with a > bridge br0 made of 2 interfaces, eth0 and tap0 (the last is an OpenVPN > tunnel), and one remote computer connetting through tap0. > > If I assign a static IP to the remote computer, the bridge works perfecly > (so I think the problem is not OpenVPN-related). If I start a DHCPd on the > server and I configure the remote client to get the IP from it, > something strange happens: if I "sniff" on the br0 interface, I can > see the DHCP requests coming from the client (from 0.0.0.0.bootpc to > 255.255.255.bootps) and the DHCPd answers going back from > ip.of.the.server.bootps to 255.255.255.255.bootpc; also sniffing on > eth0 gives the same result, but if I sniff on the tap0 interface, I > don't see the replies! So the client never get its own IP. What I'm > doing wrong? To add some mistery, sometimes (one try out of 10) the > reply flows correctly to the remote client. All the three interfaces > (eth0, br0, tap0) doesn't have firewalling enabled, and under /proc > ip_forwarding is enabled and rp_filter is disabled for all > interfaces. brctl showmacs br0 correctly shows the remote virtual > interface MAC address as not local.Both eth0 and tap0 have been > configured with ifconfig 0.0.0.0 promisc up. So the packet makes it into the tap0 device, but the bridge doesn't know where to send the output. Are you running spanning tree protocol or not? Look at the contents of the forwarding table (brctl showmacs br0) Spanning tree does take a while to settle on startup so it could be that you need to wait about a minute till the bridge starts running. Or may the tap device doesn't have a real hardware mac address is confusing it. From zaikxtox at kaixo.com Tue Mar 16 14:44:09 2004 From: zaikxtox at kaixo.com (Zaikxtox) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Iptables does not filter on 2.4.25 Message-ID: <200403162144.i2GLi99x027617@mail.kaixo.com> An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20040316/cbdeb730/attachment.htm From a.fiorino at chibacity.it Wed Mar 17 00:29:46 2004 From: a.fiorino at chibacity.it (Alessandro Fiorino) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Re: Strange DHCP behaviour with bridging In-Reply-To: <20040316110702.589a76e8@dell_ss3.pdx.osdl.net> References: <20040316082837.1797.qmail@daitarn.register.it> <20040316110702.589a76e8@dell_ss3.pdx.osdl.net> Message-ID: <200403170929.46220.a.fiorino@chibacity.it> On Tuesday 16 March 2004 20:07, you wrote: > > So the packet makes it into the tap0 device, but the bridge doesn't know > where to send the output. Are you running spanning tree protocol or not? No, btrcl showstp br0 says it's disabled > Look at the contents of the forwarding table (brctl showmacs br0) > Spanning tree does take a while to settle on startup so it could be that > you need to wait about a minute till the bridge starts running. > > Or may the tap device doesn't have a real hardware mac > address is confusing it. brctl showmacs br0 shows the mac address of the local virtual tap interface as local, and shows the mac address of the remote virtual interface as remote (which I think it's correct) From mangel at gmx.de Wed Mar 17 09:13:58 2004 From: mangel at gmx.de (Christoph Kaminski) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] bridge wlan-eth Message-ID: <200403171813.58862.mangel@gmx.de> Hi! I have some problems with an bridge between wlan0 and eth0 device... It works and I can from both sides ping the router with the bridge device but I cant ping the devices from other net so I cant ping wlan devs from eth net and other way around the wlan card is an atmel usbw11 from linksys and eth is a intel e100 10/100mbit nic I have configured the bridge according to the how to and dont see any errors in kern.log or somewhere else.... What is wrong? PS: sorry for my english but I hope you can understand what I mean From mrenzmann at web.de Wed Mar 17 09:34:11 2004 From: mrenzmann at web.de (Michael Renzmann) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] bridge wlan-eth In-Reply-To: <200403171813.58862.mangel@gmx.de> References: <200403171813.58862.mangel@gmx.de> Message-ID: <40588C13.1030903@web.de> Hi. Christoph Kaminski wrote: > It works and I can from both sides ping the router with the bridge device but > I cant ping the devices from other net so I cant ping wlan devs from eth net > and other way around > > the wlan card is an atmel usbw11 from linksys and eth is a intel e100 > 10/100mbit nic You'll have two problems: 1. The e100 is said to have a problem with bridging, depending on the driver you use. 2. You need to have your wlan device working in a special mode, which is not available to the atmel-chipsets afaik. This mode is known under many names, such as "Host-AP", "Master-Mode", "AP-Mode" and others. Without this mode, you won't be able to bridge between wlan and lan. The only way to work around this problem then would be to use proxy arp - afair there is a daemon available that cares about the wlan-lan situation in context to proxy arp. You should find it when searching freshmeat.net with "proxy arp" or thelike. Bye, Mike From shemminger at osdl.org Wed Mar 17 09:40:19 2004 From: shemminger at osdl.org (Stephen Hemminger) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] bridge wlan-eth In-Reply-To: <200403171813.58862.mangel@gmx.de> References: <200403171813.58862.mangel@gmx.de> Message-ID: <20040317094019.1e52bea9@dell_ss3.pdx.osdl.net> On Wed, 17 Mar 2004 18:13:58 +0100 Christoph Kaminski wrote: > Hi! > > I have some problems with an bridge between wlan0 and eth0 device... > > It works and I can from both sides ping the router with the bridge device but > I cant ping the devices from other net so I cant ping wlan devs from eth net > and other way around > > the wlan card is an atmel usbw11 from linksys and eth is a intel e100 > 10/100mbit nic > > I have configured the bridge according to the how to and dont see any errors > in kern.log or somewhere else.... > > What is wrong? > > PS: sorry for my english but I hope you can understand what I mean > _______________________________________________ > Bridge mailing list > Bridge@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/bridge More info in bridge FAQ http://bridge.sourceforge.net/faq.html It doesn't work with my Wireless card! This is a known problem, and it is not caused by the bridge code. Many wireless cards don't allow spoofing of the source address. It is a firmware restriction with some chipsets. You might find some information in the bridge mailing list archives to help. -- Stephen Hemminger mailto:shemminger@osdl.org Open Source Development Lab http://developer.osdl.org/shemminger From mark at linux-wlan.com Wed Mar 17 09:40:19 2004 From: mark at linux-wlan.com (Mark S. Mathews) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] bridge wlan-eth In-Reply-To: <200403171813.58862.mangel@gmx.de> References: <200403171813.58862.mangel@gmx.de> Message-ID: The answer to this is in the bridge FAQ at: http://bridge.sourceforge.net/faq.html Have Fun! -M On Wed, 17 Mar 2004, Christoph Kaminski wrote: > Hi! > > I have some problems with an bridge between wlan0 and eth0 device... > > It works and I can from both sides ping the router with the bridge device but > I cant ping the devices from other net so I cant ping wlan devs from eth net > and other way around > > the wlan card is an atmel usbw11 from linksys and eth is a intel e100 > 10/100mbit nic > > I have configured the bridge according to the how to and dont see any errors > in kern.log or somewhere else.... > > What is wrong? > > PS: sorry for my english but I hope you can understand what I mean > _______________________________________________ > Bridge mailing list > Bridge@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/bridge > Mark S. Mathews AbsoluteValue Systems Web: http://www.linux-wlan.com 715-D North Drive e-mail: mark@linux-wlan.com Melbourne, FL 32934 Phone: 321.259.0737 USA Fax: 321.259.0286 From chriss at watertech.com Wed Mar 17 10:00:16 2004 From: chriss at watertech.com (Chris Shaw) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] bridge wlan-eth References: <200403171813.58862.mangel@gmx.de> Message-ID: <006501c40c49$bbf3cec0$7005640a@internal.watertech.com> I know this is off topic but... check out the Jouni Malinen's HostAP driver homepage at: http://hostap.epitest.fi It enables the special "HostAP" functionality of the Harris/Intersil Prism 2/2.5/3 chipset which allows your card to act as a full AP (and also do wireless -> ethernet bridging.) Some Atmels work with this driver, YMMV... -Chris ----- Original Message ----- From: "Christoph Kaminski" To: Sent: Wednesday, March 17, 2004 9:13 AM Subject: [Bridge] bridge wlan-eth > Hi! > > I have some problems with an bridge between wlan0 and eth0 device... > > It works and I can from both sides ping the router with the bridge device but > I cant ping the devices from other net so I cant ping wlan devs from eth net > and other way around > > the wlan card is an atmel usbw11 from linksys and eth is a intel e100 > 10/100mbit nic > > I have configured the bridge according to the how to and dont see any errors > in kern.log or somewhere else.... > > What is wrong? > > PS: sorry for my english but I hope you can understand what I mean > _______________________________________________ > Bridge mailing list > Bridge@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/bridge From zaikxtox at kaixo.com Thu Mar 18 11:35:51 2004 From: zaikxtox at kaixo.com (Zaikxtox) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Iptables does not filter on 2.4.25 - Continued Message-ID: <200403181835.i2IIZpo4031856@mail.kaixo.com> Hello. I have tested again and the default policy for INPUT, FORWARD and OUTPUT is DROP also there is a single rule matching anything as source and anything as destination with action DROP also "cat /proc/sys/net/ipv4/ip_forward " says "0" The connecting machine has a single cable to my bridge, so there is no other way to go trough the net. But netfilter does not stop the trafic!!! i tried with a stock debian 2.4.25 kernel, and a 2.4.25 kernel comiled in house. I have already used bridge + iptables with 2.4.19 kernel, so i know how it should work. some help or know bugs?? is someone used bridge + netfilter on a 2.4.25 kernel and it works please write me! thanks. IVan ________________________________________________ Kaixo! (http://www.kaixo.com) Portal de Euskadi - Euskadiko ataria From jjones at djc.state.id.us Wed Mar 24 18:50:33 2004 From: jjones at djc.state.id.us (Jeremy Jones) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Bridging vlans... Message-ID: <000301c41213$f4a6d7b0$f80210ac@djc.state.id.us> Hi folks, I have an implementation question regarding bridging on a linux box between a catalyst trunk port and a cisco 26something w/802.1q subinterfaces. So right now, there's no vlan trunking going on on the link my bridging firewall sits on, but I'm going to need to bridge two vlans, 4 and 51. My question is this: should the vlan interfaces on the linux firewall be created first, then bridged; or should the bridge interface be created, then vlans bound to that? Here's the first: ip link set eth0 up ip link set eth1 up vconfig set_bind_mode PER_DEVICE vconfig set_name_type DEV_PLUS_VID_NO_PAD vconfig add eth0 4 vconfig add eth1 4 vconfig add eth0 51 vconfig add eth1 51 ip link set eth0.4 up ip link set eth1.4 up ip link set eth0.51 up ip link set eth1.51 up brctl addbr br0 brctl addif br0 eth0.4 brctl addif br0 eth1.4 brctl stp br0 off ip link set br0 up brctl addbr br1 brctl addif br1 eth0.51 brctl addif br1 eth1.51 brctl stp br1 off ip link set br1 up And the second: ip link set eth0 up ip link set eth1 up brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 brctl stp br0 off ip link set br0 up vconfig set_bind_mode PER_KERNEL vconfig set_name_type DEV_PLUS_VID_NO_PAD vconfig add br0 4 vconfig add br0 51 ip link set br0.4 up ip link set br0.51 up I lean towards the first, as it gives me more interfaces to filter, and thus more flexibility with my iptables rules. Just looking for the wisdom of experience... Thanks, Jeremy Jones From linville at tuxdriver.com Thu Mar 25 04:56:08 2004 From: linville at tuxdriver.com (John W. Linville) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Bridging vlans... In-Reply-To: <000301c41213$f4a6d7b0$f80210ac@djc.state.id.us> References: <000301c41213$f4a6d7b0$f80210ac@djc.state.id.us> Message-ID: <4062D6E8.6070804@tuxdriver.com> Jeremy Jones wrote: > question is this: should the vlan interfaces on the linux firewall be > created first, then bridged; or should the bridge interface be created, then > vlans bound to that? > > Here's the first: > > ip link set eth0 up > ip link set eth1 up > vconfig set_bind_mode PER_DEVICE > vconfig set_name_type DEV_PLUS_VID_NO_PAD > vconfig add eth0 4 > vconfig add eth1 4 > vconfig add eth0 51 > vconfig add eth1 51 > And the second: > > ip link set eth0 up > ip link set eth1 up > brctl addbr br0 > brctl addif br0 eth0 > brctl addif br0 eth1 > I lean towards the first, as it gives me more interfaces to filter, and thus Jeremy, I have no specific experience with a situation like yours. But, that won't stop me from rendering an opinion... :-) I, too, would lean toward the first at least partly for the reason you describe. But, you should also consider untagged frames and frames with other VLAN IDs. The second configuration should bridge all frames (tagged or untagged), while the first will only be bridging frames with VLAN IDs of 4 or 51. I'm not sure which is your desired behaviour, but I suspect it is the first configuration which you should prefer. Hth... John -- John W. Linville linville@tuxdriver.com From jjones at djc.state.id.us Thu Mar 25 17:44:51 2004 From: jjones at djc.state.id.us (Jeremy Jones) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Bridging vlans... In-Reply-To: <4062D6E8.6070804@tuxdriver.com> Message-ID: <011a01c412d3$f141fe90$f80210ac@djc.state.id.us> Now, with iptables, under the first scenario (creating 2 vlan interfaces per physical interface, and bridging the vlan interfaces), can I safely DROP everything to, from, or through eth0 & eth1? That is, assuming I don't want to forward any untagged frames. So: iptables -N only_tagged iptables -A only_tagged -j LOG --log-prefix " untagged? " iptables -A only_tagged -j DROP iptables -A INPUT -i eth0 -j only_tagged iptables -A INPUT -i eth1 -j only_tagged iptables -A OUTPUT -i eth0 -j only_tagged iptables -A OUTPUT -i eth1 -j only_tagged iptables -A FORWARD -i eth0 -j only_tagged iptables -A FORWARD -i eth1 -j only_tagged Then do my more granular filtering on the vlan interfaces... (guess this would be something to ask the vlan mailing list people -- but what the heck, this list isn't terribly busy anyway) I imagine I'll have to come up with a fairly complex matrix of --physdev-in, --physdev-out, etc. combinations. Yikes. Jeremy > -----Original Message----- > From: bridge-bounces@lists.osdl.org > [mailto:bridge-bounces@lists.osdl.org] On Behalf Of John W. Linville > Sent: Thursday, March 25, 2004 5:56 AM > To: Jeremy Jones > Cc: bridge@lists.osdl.org > Subject: Re: [Bridge] Bridging vlans... > > > Jeremy, > > I have no specific experience with a situation like yours. But, that > won't stop me from rendering an opinion... :-) > > I, too, would lean toward the first at least partly for the > reason you > describe. But, you should also consider untagged frames and > frames with > other VLAN IDs. The second configuration should bridge all frames > (tagged or untagged), while the first will only be bridging > frames with > VLAN IDs of 4 or 51. I'm not sure which is your desired > behaviour, but > I suspect it is the first configuration which you should prefer. > > Hth... > > John > -- From linville at tuxdriver.com Thu Mar 25 18:32:58 2004 From: linville at tuxdriver.com (John W. Linville) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Bridging vlans... References: <011a01c412d3$f141fe90$f80210ac@djc.state.id.us> Message-ID: <4063965A.103@tuxdriver.com> Again, I'm no expert. I hope someone will correct me if I'm wrong, blah blah blah... To start, I think you should be using ebtables rather than iptables. As I understand things, the ebtables stuff works at Layer-2. I guess your purpose is to log untagged packets? Are packets belonging to VLAN interfaces visible to the parent interface? (It seems intuitive that they would not be, but I really don't know.) If not, then something like what you propose below should work (given ebtables instead of iptables). If the VLAN packets ARE visible on the parent interface, then you will need to do some additional checking to make sure that the frames are actually untagged. You may want to do this anyway so as to differentiate between untagged frames and frames tagged for an "unknown" VLAN. Again, hth... :-) John Jeremy Jones wrote: > Now, with iptables, under the first scenario (creating 2 vlan interfaces per > physical interface, and bridging the vlan interfaces), can I safely DROP > everything to, from, or through eth0 & eth1? That is, assuming I don't want > to forward any untagged frames. > > So: > > iptables -N only_tagged > iptables -A only_tagged -j LOG --log-prefix " untagged? " > iptables -A only_tagged -j DROP > iptables -A INPUT -i eth0 -j only_tagged > iptables -A INPUT -i eth1 -j only_tagged > iptables -A OUTPUT -i eth0 -j only_tagged > iptables -A OUTPUT -i eth1 -j only_tagged > iptables -A FORWARD -i eth0 -j only_tagged > iptables -A FORWARD -i eth1 -j only_tagged > > Then do my more granular filtering on the vlan interfaces... > > (guess this would be something to ask the vlan mailing list people -- but > what the heck, this list isn't terribly busy anyway) > > I imagine I'll have to come up with a fairly complex matrix of --physdev-in, > --physdev-out, etc. combinations. Yikes. > > Jeremy > > >>-----Original Message----- >>From: bridge-bounces@lists.osdl.org >>[mailto:bridge-bounces@lists.osdl.org] On Behalf Of John W. Linville >>Sent: Thursday, March 25, 2004 5:56 AM >>To: Jeremy Jones >>Cc: bridge@lists.osdl.org >>Subject: Re: [Bridge] Bridging vlans... >> >> >>Jeremy, >> >>I have no specific experience with a situation like yours. But, that >>won't stop me from rendering an opinion... :-) >> >>I, too, would lean toward the first at least partly for the >>reason you >>describe. But, you should also consider untagged frames and >>frames with >>other VLAN IDs. The second configuration should bridge all frames >>(tagged or untagged), while the first will only be bridging >>frames with >>VLAN IDs of 4 or 51. I'm not sure which is your desired >>behaviour, but >>I suspect it is the first configuration which you should prefer. >> >>Hth... >> >>John >>-- > > > > > _______________________________________________ > Bridge mailing list > Bridge@lists.osdl.org > http://lists.osdl.org/mailman/listinfo/bridge From amedina at seplade.michoacan.gob.mx Mon Mar 22 13:04:56 2004 From: amedina at seplade.michoacan.gob.mx (amedina@seplade.michoacan.gob.mx) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] bridging interfaces Message-ID: <60300.10.8.7.99.1079989496.squirrel@www.michoacan.gob.mx> Hi: Simple Quiestion...!!! Can I add more than two interfaces to a bridge (br0) like a eth2 or some like that..!!!??? brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 brctl addif br0 eth2 . . etc. thanks..! -- Angel L. Medina Administrador de Red Seplade Gob. del Edo. de Mich. Tel (443)3.22.76.79 From msnitzer at lnxi.com Tue Mar 23 10:59:31 2004 From: msnitzer at lnxi.com (Mike Snitzer) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Re: Strange DHCP behaviour with bridging In-Reply-To: <20040316110702.589a76e8@dell_ss3.pdx.osdl.net>; from shemminger@osdl.org on Tue, Mar 16, 2004 at 11:07:02AM -0800 References: <20040316082837.1797.qmail@daitarn.register.it> <20040316110702.589a76e8@dell_ss3.pdx.osdl.net> Message-ID: <20040323115931.B21457@lnxi.com> On Tue, Mar 16 2004 at 12:07, Stephen Hemminger wrote: > On Tue, 16 Mar 2004 09:28:37 +0100 > wrote: > > Here is the scenario: I have one server with kernel 2.4.24 with a > > bridge br0 made of 2 interfaces, eth0 and tap0 (the last is an OpenVPN > > tunnel), and one remote computer connetting through tap0. > > > > If I assign a static IP to the remote computer, the bridge works perfecly > > (so I think the problem is not OpenVPN-related). If I start a DHCPd on the > > server and I configure the remote client to get the IP from it, > > something strange happens: if I "sniff" on the br0 interface, I can > > see the DHCP requests coming from the client (from 0.0.0.0.bootpc to > > 255.255.255.bootps) and the DHCPd answers going back from > > ip.of.the.server.bootps to 255.255.255.255.bootpc; also sniffing on > > eth0 gives the same result, but if I sniff on the tap0 interface, I > > don't see the replies! So the client never get its own IP. What I'm > > doing wrong? To add some mistery, sometimes (one try out of 10) the > > reply flows correctly to the remote client. All the three interfaces > > (eth0, br0, tap0) doesn't have firewalling enabled, and under /proc > > ip_forwarding is enabled and rp_filter is disabled for all > > interfaces. brctl showmacs br0 correctly shows the remote virtual > > interface MAC address as not local.Both eth0 and tap0 have been > > configured with ifconfig 0.0.0.0 promisc up. > > So the packet makes it into the tap0 device, but the bridge doesn't know > where to send the output. Are you running spanning tree protocol or not? > Look at the contents of the forwarding table (brctl showmacs br0) > Spanning tree does take a while to settle on startup so it could be that > you need to wait about a minute till the bridge starts running. > > Or may the tap device doesn't have a real hardware mac > address is confusing it. Hello, I have been trying to get bridging with tap devices working for a few days; it would appear as though the bridge is unable to properly forward traffic to the remote end of a tap device from another tap (specifically between 2 UMLs). If I enslave 2 tap devices to the bridge and then start 2 UMLs that supply the remote (non-local) ends of the tap the bridge shows: snitm@amstel:~> sudo brctl showmacs br0 port no mac addr is local? ageing timer 1 00:ff:33:9f:43:45 yes 0.00 2 00:ff:91:17:3a:d5 yes 0.00 1 fe:fd:c0:a8:00:02 no 30.74 2 fe:fd:c0:a8:00:03 no 0.27 NOTE: local #1 is tap0 local #2 is tap1 non-local #1 is uml0's eth0 non-local #2 is uml1's eth0 >From within either guest UML I can ping the host but I cannot ping the other guest UML. On the host I can ping each eth0 interface of the guest UMLs. If I go ahead and enslave an ethernet device on the host (making other machines available through that device) the UML guests can't ping those machines either. Meanwhile the bridge (host/umlhost) is able to ping all enslaved members of the switch (local or non-local). I even have iptables MASQ going on the host so that traffic from br0 is routed out eth0 to the greater internet; the guest UMLs can get out to the net fine. SO ultimately attempts to communicate through a tap device to other members of the ethernet bridge fail (except for the bridge's IP and other physical devices on the host machine). My findings with pinging other machines that are available through a eth device that I enslave closely mirror what was describved earlier on this list: http://lists.osdl.org/pipermail/bridge/2004-February/000188.html Any insight into the bridging code's ability to _really_ work with tap devices would be greatly appreciated. I've attached a script that I use to easily start and stop the bridge and tap devices; maybe it could help others trying to reproduce these tap issues with bridging. Regards, Mike FYI. I've subscribed to the bridge list but haven't been approved yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: bridge.sh Type: application/x-sh Size: 2811 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/bridge/attachments/20040323/1c3fb4a6/bridge.sh From jeremy at samnjack.com Wed Mar 24 16:23:19 2004 From: jeremy at samnjack.com (Jeremy Jones) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Bridging vlans Message-ID: <000101c411ff$635df090$f80210ac@djc.state.id.us> Hi folks, I have an implementation question regarding bridging on a linux box between a catalyst trunk port and a cisco 26something w/802.1q subinterfaces. So right now, there's no vlan trunking going on on the link my bridging firewall sits on, but I'm going to need to bridge two vlans, 4 and 51. My question is this: should the vlan interfaces on the linux firewall be created first, then bridged; or should the bridge interface be created, then vlans bound to that? Here's the first: ip link set eth0 up ip link set eth1 up vconfig set_bind_mode PER_DEVICE vconfig set_name_type DEV_PLUS_VID_NO_PAD vconfig add eth0 4 vconfig add eth1 4 vconfig add eth0 51 vconfig add eth1 51 ip link set eth0.4 up ip link set eth1.4 up ip link set eth0.51 up ip link set eth1.51 up brctl addbr br0 brctl addif br0 eth0.4 brctl addif br0 eth1.4 brctl stp br0 off ip link set br0 up brctl addbr br1 brctl addif br1 eth0.51 brctl addif br1 eth1.51 brctl stp br1 off ip link set br1 up And the second: ip link set eth0 up ip link set eth1 up brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 brctl stp br0 off ip link set br0 up vconfig set_bind_mode PER_KERNEL vconfig set_name_type DEV_PLUS_VID_NO_PAD vconfig add br0 4 vconfig add br0 51 ip link set br0.4 up ip link set br0.51 up I lean towards the first, as it gives me more interfaces to filter, and thus more flexibility with my iptables rules. Just looking for the wisdom of experience... Thanks, Jeremy Jones From rein at vankoten.com Thu Mar 25 09:06:33 2004 From: rein at vankoten.com (Rein van Koten) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Mirroring an interface to an other by using bridge ? Message-ID: <000e01c4128b$8c13f9d0$7f619082@simba> Hi, Just wondering.... Currently i'm redesigning an intrusion detection system based on Snort / Li= nux (in this case Fedora Core 1). Datastream is tapped physically by means of single-mode fiber taps from a d= ual path link between router pairs. By using intel single mode fiber cards and bundling the four tapped streams= to one virtual interface with the intel drivers i recreate a virtual mirro= r of the uplinks we are sampling. Works like a charm. However, the created datastream is needed for other measurements as well. W= hat I would like to do is to create a mirror port from the reassembled stre= am. Normally you woud have one or more mirror ports on a switch/router but in t= his case the stream is only complete on the linux box..... Also, as it is not a real stream a 100mb hub cannot be used as fanout (and = this only as long as the aggregated load is below 100MB and is not a pure f= or ids use) Looking for a solution to this I dug into ebtables / bridging and divert me= chanisms currently available in the linux kernels. But I did not find a reference to a real mirror solution. Maybe I'm looking= in the wrong place. Looking at the functionality I think I need, it looks like the bridge modul= e is my closest bet. If the bridge forwards everything without keeping mac tables or sending/rec= eiving arp messages I'm in business..... So, my question: Is it possible to adapt the bridge code so it: - copies all incoming traffic from one interface (in promisc mode) to an ot= her, regardless of mac address etc - does not do any sending itself (no proxyarp, arp, broadcasts etc) - prefferably works one way (a mirror should be read only)? - This as low as can be in the kernel (so not all the way up to ip/eb table= s or high in userspace) In fact this looks like the bridge module without all the more refined stuf= f (keeping tables, proxying etc) Example with the envisioned version of bridge module and brctl: # sniffing / ids on eth1, want to copy all traffic to eth2 for others to us= e without needing access to the IDS environment. # setup bridge brctl addbr brctl addif eth1 brctl addif eth2 # set bridge type to copy thus creating a mirror port brctl mode copy # set the copy direction from eth1 to eth2 (can only be in one direction) brctl setcopy in eth1 brctl setcopy out eth2 # enjoy... so: mode command has options copy or bridge setcopy out provide the option to copy several interfaces' incoming data to= a single (or even multiple?) interfaces. currently I only see a solution like bridging, ebtables/divert replacing in= coming macs with the mac of the sniffer attached to my semi mirror interfac= e, blocking all arp traffic and this only works probably if you know all th= e mac addresses on the link you are sampling (in my case I do because it's = the four mac addresses of the upstream and downstream routers). = Also, possible trouble comes from : - I'm not sure that tools like divert etc work on a virutal interface l= ike the one created when you bundle interfaces. - i/o speed, kernel resources etc I saw that I at least had to hack the divert.o code to remove the check on = interface names starting with "eth" as the intel drivers do not allow a vir= utal interface with a name like eth9... Anyway, I would appreciate your opinion on this or whether you know someone working= along the same lines... I myself am not C savvy enough to rewrite the bridge module without additio= nal input on this idea. And then again, maybe it already exists. Regards, Rein van Koten The Netherlands. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/2004032= 5/0e601cdc/attachment.htm From fgalan at teleline.es Sat Mar 27 08:10:05 2004 From: fgalan at teleline.es (=?iso-8859-1?Q?Ferm=EDn_Gal=E1n?=) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Limitation in virtual bridge number Message-ID: <001901c41415$f8cf2410$f9cd00d5@kastrup> Hello, I would like to know wether the number of virtual bridges that can be created (with 'brctl addbr') is limited to a given number. My question is due to certain tests that I have performed, the number of virtual bridges cann't be greater than 32. Triying to add the 33rd bridge with 'brctl addbr' works, but causes the removal of the oldest one (the first in the 'brctl show' list): the number of existing virtual bridges is never more than 32. As reference, I have performed these tests in a Linux 2.4.21 kernel, with bridge support compiled as module (I can give you more information, if you need it). Where resides the limitation? In the virtual bridge kernel support? In the brctl tool? In the way of compiling? Maybe is a bug? I would like to know how can I create more than 32 virtual bridges (if possible). Thank you very much for your attention! ------- Ferm?n From dataking at cox.net Sun Mar 21 20:34:56 2004 From: dataking at cox.net (D@7@k|N&) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] Sparc Bridge problems Message-ID: <405E6CF0.5040900@cox.net> Hey guys! I'm having a little trouble with a sprc bridge setup. I am running SuSe 7.3 for sparc on a Sun Ultra1 Creator3D. I compiled 2.4.25 kernel with 802.1d Ethernet Bridging support, and installed bridge-utils 0.9.6. I've read all of the documentation that I could find (Bridging FAQ and Bridging HOWTO). But I still get the following errors: brctl addbr br0 brctl addif br0 eth0 bridge br0 doesn't exist! Why not? brctl addbr br0 device br0 already exists; can't create bridge with the same name I've found on other mailing-lists that sparc systems require the bridge-utils64 package, but can only find it for Debian. Any thoughts on what's going on here? If I compiled the utils from source, shouldn't they be the right ones for my system/kernel? Any help would be greatly appreciated. Thanks, Charlie From firefly at netapp.com Mon Mar 22 15:49:09 2004 From: firefly at netapp.com (Feierfeil, Jeff) Date: Wed Apr 18 12:33:59 2007 Subject: [Bridge] br_add_bridge: Package not installed Message-ID: <9CDD2895B84A1C48B8FD80F9820E9C32048582BC@svlexc07.corp.netapp.com> I am having a tough time simply getting the bridging to work with RedHat. Any help would be greatly appreciated. [root@redman root]# brctl addbr br0 br_add_bridge: Package not installed [root@redman temp]# uname -a Linux redman 2.4.21-9.0.1.EL #1 Mon Feb 9 22:44:14 EST 2004 i686 i686 i386 GNU/Linux [root@redman root]# rpm -q --all 'kernel*' kernel-2.4.21-9.0.1.EL kernel-source-2.4.21-9.0.1.EL kernel-pcmcia-cs-3.1.31-13 kernel-utils-2.4-8.37.1 [root@redman temp]# rpm -q --all 'bridge*' bridge-utils-0.9.6-1 [root@redman root]# brctl commands: addbr add bridge addif add interface to bridge delbr delete bridge delif delete interface from bridge show show a list of bridges showmacs show a list of mac addrs showstp show bridge stp info setageing