Modify

Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#10108 closed defect (wontfix)

Bridging: brtcll not supported in Adhoc mode

Reported by: anonymous Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: bridge, adho, brctl Cc:

Description

I have test the latest trunk version (r28225): The problem is that I could not add wlan0 interface to bridge:


root@OpenWrt:/etc/config# brctl addif br-lan wlan0
brctl: bridge br-lan: Operation not supported
root@OpenWrt:/etc/config# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

br-lan no wireless extensions.

wlan0 IEEE 802.11an ESSID:"mesh"

Mode:Ad-Hoc Frequency:5.785 GHz Cell: 00:15:61:90:26:E4
Tx-Power=23 dBm
RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on


root@OpenWrt:/etc/config#

root@OpenWrt:/etc/config# cat network
config interface loopback

option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0


config interface lan

option ifname eth0
option type bridge
option proto static
option ipaddr 10.50.0.55
option netmask 255.255.255.0
option gateway 10.50.0.1

root@OpenWrt:/etc/config# cat wireless
config wifi-device radio0

option type mac80211
option channel 157
option macaddr 00:7f:28:6f:42:65
option hwmode 11na
option htmode HT20
list ht_capab SHORT-GI-40
list ht_capab TX-STBC
list ht_capab RX-STBC1
list ht_capab DSSS_CCK-40
# REMOVE THIS LINE TO ENABLE WIFI:
# option disabled 1


config 'wifi-iface' 'cfg2'

option 'device' 'radio0'
option 'network' 'lan'
option 'mode' 'adhoc'
option 'bssid' '00:15:61:90:26:e4'
#option 'wds' '1'
option 'ssid' 'mesh'
option 'encryption' 'none'

root@OpenWrt:/etc/config#


Thanks a lot for your kind helps

Attachments (0)

Change History (13)

comment:1 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from new to closed

It's not a bug, it's intentional. ad-hoc interfaces cannot be part of a bridge because of protocol limitations.

comment:2 Changed 6 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Thanks for your quick response.

It's not a bug, it's intentional. ad-hoc interfaces cannot be part of a bridge >because of protocol limitations.

Your claim should be questionable, since I can do bridging with Backfire kernel 2.6.32.x as following:

root@Openwrt:/etc/config# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

imq0 no wireless extensions.

imq1 no wireless extensions.

br-lan no wireless extensions.

wlan0 IEEE 802.11abgn ESSID:"*****"

Mode:Ad-Hoc Frequency:5.7 GHz Cell: 5A:91:01:06:5A:7D
Tx-Power=17 dBm
RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off


root@Openwrt:/etc/config# brctl show
bridge name bridge id STP enabled interfaces
br-lan 8000.00804864c7ee no eth0

wlan0

root@Gargoyle:/etc/config#

comment:3 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

2.6.32 did not support preventing interfaces from getting added to a bridge, that's why it appears to work (even though it won't work for devices behind the bridge). My other comment regarding protocol support of bridging is still valid, so please do not reopen this ticket again.

comment:4 Changed 6 years ago by anonymous

Dear

2.6.32 did not support preventing interfaces from getting added to a bridge, that's >why it appears to work (even though it won't work for devices behind the bridge).

I am really confused what means "it appears to work (even though it won't work for devices behind the bridge)" ?!!

In my experiment here, it WORKS, for also all devices behind bridge.
4 bytes from 10.50.0.1: seq=273 ttl=64 time=3.949 ms
64 bytes from 10.50.0.1: seq=274 ttl=64 time=4.444 ms
64 bytes from 10.50.0.1: seq=275 ttl=64 time=3.203 ms
64 bytes from 10.50.0.1: seq=276 ttl=64 time=2.860 ms
C
--- 10.50.0.1 ping statistics ---
277 packets transmitted, 268 packets received, 3% packet loss
round-trip min/avg/max = 0.692/5.627/484.325 ms
root@Openwrt:/# ping 10.50.0.1
PING 10.50.0.1 (10.50.0.1): 56 data bytes
64 bytes from 10.50.0.1: seq=0 ttl=64 time=3.277 ms
64 bytes from 10.50.0.1: seq=1 ttl=64 time=3.991 ms
64 bytes from 10.50.0.1: seq=2 ttl=64 time=3.381 ms
64 bytes from 10.50.0.1: seq=3 ttl=64 time=4.474 ms
64 bytes from 10.50.0.1: seq=4 ttl=64 time=3.548 ms

comment:5 Changed 6 years ago by nbd

Suppose you have a node A behind the bridge, node B on the bridge, node C behind wifi.
Whenever node C sends a packet to node B, it gets an ACK, however when it sends to packets to node A, there is no node that will send an ACK, so it'll keep retransmitting at a low data rate, wasting lots of airtime.

If you don't believe me, try sending data from a node behind wifi to a node behind the bridge using iperf or some other bandwidth intensive test. I'd expect very bad results.

There is not much that can be done about this except prevent people from creating such a bad configuration.

comment:6 Changed 5 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I was using in backfire r32751 a configuration with an adhoc interface bridged. I know normally it shouldn't work, but i use it together with ebtables, to make a repeater, and it works fine.

The problem is that now i want to use the same configuration with trunk r33362 and i noticed this limitation, so i'd like to enable adding adhoc interfaces to bridges.

comment:7 follow-up: Changed 5 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

You can use relayd to create a repeater, similar to how it's used with a client mode interface.

comment:8 in reply to: ↑ 7 Changed 5 years ago by anonymous

Replying to nbd:

You can use relayd to create a repeater, similar to how it's used with a client mode interface.

Thanks for your quick reply!

I've searched for that relayd, but i see it works at layer 3, doesn't it?

Let me explain a bit more what i'm trying to do.

I'm using batman-adv, which works at layer 2, and i need a simple layer 2 repater. So i use a bridge between ethernet and ad hoc wireless. The frames arrive at the wireless interface with it's own MAC address as destination, so there's no problem with 80211. Then with ebtables i change the MAC dst to other MAC, that corresponding to the router connected to the ethernet interface, to make the frames traverse the bridge.

I know it's not a normal configuration, but it works very good for what i'm doing. Maybe you could tell me where to change the code to allow adhoc bridged interfaces? Thanks again!

comment:9 Changed 5 years ago by nbd

OK, then relayd doesn't work, but I already thought of this use case a while ago and wrote a kernel module that you can use as a bridge replacement.
That way you will not have to use ebtables at all.
The package is called trelay (trivial relay). It works like this:

You create a VLAN on your ethernet and configure trelay on that vlan and wlan0.
Then on the other side where you run batman-adv you also create a VLAN interface with the same ID and assign to it the MAC address of the outgoing wlan interface. That way packets should be forwarded in both directions with no MAC address rewriting at all.

comment:10 Changed 5 years ago by anonymous

Excellent! I didn't know about this package, i'll try it!

Just one more question, how do you access to the router once it's working with trelay? With ebtables i defined some rules that accept ip packets instead of changing MAC destinations, that way L2 frames like batman packets are forwarded and ip packets are accepted by the router.

comment:11 Changed 5 years ago by joe@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I would also like the ability to add wlan0 to a bridge in adhoc mode. We use this mode all the time with the mad-wifi driver and it works. We are upgrading hardware and would like to use open-wrt but without adhoc/bridge support we cannot. If this was disabled intentionally will you please tell us where it was disabled? Was it disabled in the brctl command or somewhere in the kernel?

Thank you

comment:12 Changed 5 years ago by jogo

  • Resolution set to wontfix
  • Status changed from reopened to closed

Please don't reopen tickets for asking questions, this isn't a support forum. Use the mailing lists, forums or IRC for that.

comment:13 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.