dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
2567

misiek
Premium Member
join:2000-12-25
Round Lake, IL

2 edits

misiek

Premium Member

upstream side (wlan0 and eth0) bridge possible?

Hey guys,

I have a minidlna server running on Debian stable. There are two network adapters installed in the system: a Hawking 802.11g one and a 3Com 3c59x one. The server will eventually be moved to the garage once the kinks are worked out.

All the media contents (pictures mostly) will be served to the clients over the WiFi connection. The wired NIC is installed in order to test the server and work out the bugs.
Running a network cable to the garage is not high on the 'honey-do' list at the moment, hence the need to configure the setup to run wirelessly.

I had both wired and wireless NICs configured with their own separate static IP addresses on the same 192.168.1.0/24 subnet. There is no other subnets in the house.
The issue is that whenever the minidlna server uses WiFi connection, the clients cannot 'see' it most of the time. Running the server over wired connection works 100% of the time and all wired/wireless clients can access the files, but as I mentioned before, I prefer not to run any cables to the garage at this time, so wireless is the preferred option.

My issue is somewhat similar to the situation described here:
»ubuntuforums.org/showthr ··· =2127213
but that person had issues on his LAN side of the server, whereas I am having difficulties on the WAN side.
He bridged wired WAN and wireless LAN interfaces and says that the problems went away.

Edit: He wrote:"So disabling multicast snooping for my bridge resolved the situation."

I'd like to try his approach on the WAN side to see if this would help and this is where the trip down the rabbit hole begins for me.
Created the bridge, added eth0 to it, but when I attempted to add wlan0, Linux complained that 'operation is not permitted'. Googling suggested that placing wlan0 in AP mode with hostapd might help, but all the guides I read so far describe how to create an AP on the LAN side.

Is it even possible to bridge wlan0 and eth0 so that such bridge would act as a WAN port?

Edit: Or, maybe there is a simpler way to achieve this? Open to all suggestions.

Thanks!

misiek

misiek

Premium Member

Anyone?

/shameless bump.

DeHackEd
Bill Ate Tux's Rocket
join:2000-12-07

DeHackEd to misiek

Member

to misiek
You can't bridge a Wifi device unless it's in AP mode. A bridge copies MAC addresses between interfaces and a wireless client can't forge its MAC address - it breaks AP association rules and encryption keys. An AP can do it though. That's why all instances of bridging a wifi device depend on that.

Even so in AP mode you still need to have something handling your encryption, key exchanges, etc.

And finally, when you attach a device (of any type) to a bridge it becomes a switch port, not a router/host port. Switch ports don't have IP addresses. Assign one IP (typically) to br0 - the bridge device itself - instead. br0 becomes your vlan access interface and the bridge will send packets out either the LAN or Wifi ports as appropriate based on MAC addresses like a real switch.

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek

Premium Member

Thanks for the reply.
I am a networking baby and am taking small steps here.
So, basically, I need to put the wlan0 interface into AP mode first, before setting up a bridge, correct?
Is hostapd the way to go?

My current non-working /etc/network/interfaces file:
 
auto lo
iface lo inet loopback
 
iface eth0 inet static
address 192.168.1.202
netmask255.255.255.0
network192.168.1.0
broadcast192.168.1.255
gateway192.168.1.1
 
allow-hotplug wlan0
iface wlan0 inet manual
 
   pre-up   ifconfig $IFACE up
   pre-down ifconfig $IFACE down
 
auto br0
iface br0 inet static
bridge_ports wlan0
address 192.168.1.205
broadcast 192.169.1.255
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1
 
wpa-ssid my_essid 
    wpa-psk some_password
 
 
misiek

misiek

Premium Member

Output of the iw list command, if this helps:

 
Wiphy phy0
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (passive scanning, no IBSS)
* 2472 MHz [13] (20.0 dBm) (passive scanning, no IBSS)
* 2484 MHz [14] (20.0 dBm) (passive scanning, no IBSS)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
max scan IEs length: 2285 bytes
Coverage class: 0 (up to 0m)
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
Available Antennas: TX 0 RX 0
Supported interface modes:
 * IBSS
 * managed
 * AP
 * AP/VLAN
 * WDS
 * monitor
 * mesh point
software interface modes (can always be added):
 * AP/VLAN
 * monitor
interface combinations are not supported
Supported commands:
 * new_interface
 * set_interface
 * new_key
 * new_beacon
 * new_station
 * new_mpath
 * set_mesh_params
 * set_bss
 * authenticate
 * associate
 * deauthenticate
 * disassociate
 * join_ibss
 * join_mesh
 * remain_on_channel
 * set_tx_bitrate_mask
 * action
 * frame_wait_cancel
 * set_wiphy_netns
 * set_channel
 * set_wds_peer
 * connect
 * disconnect
Supported TX frame types:
 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
 * IBSS: 0xd0
 * managed: 0x40 0xd0
 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
 * mesh point: 0xb0 0xc0 0xd0
 * P2P-client: 0x40 0xd0
 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
Device supports RSN-IBSS.
 

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON

1 recommendation

Brano to misiek

MVM

to misiek
Before you jump to conclusion that you need a bridge (which I don't believe it's going to solve the problem) let's look at your current config.
Post output from ifconfig -v and route -v and arp -v.

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek

Premium Member

Thanks, Brano.

Here we go.

ifconfig -v:

br0       Link encap:Ethernet  HWaddr a2:52:94:0b:aa:bb  
          inet addr:192.168.1.205  Bcast:192.169.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a052:94ff:fe0b:2abc/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:918 (918.0 B)
 
eth0      Link encap:Ethernet  HWaddr 00:60:97:d2:aa:bb  
          inet addr:192.168.1.202  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::260:97ff:fed2:2abd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:96 errors:0 dropped:0 overruns:0 frame:0
          TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:20207 (19.7 KiB)  TX bytes:8100 (7.9 KiB)
          Interrupt:11 Base address:0xc400 
 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
wlan0     Link encap:Ethernet  HWaddr 00:0e:3b:04:aa:bb  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 

route -v:

 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         pfsense.local   0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
 

arp -v:

Address                  HWtype  HWaddress           Flags Mask            Iface
pfsense.local            ether   00:e0:c5:51:aa:bb   C                     eth0
192.168.1.197            ether   00:50:8d:ed:aa:bb   C                     eth0
Entries: 2Skipped: 0Found: 2
 

MAC and ipv6 addresses have been partially scrambled.

Would creating a bridge with just one wlan0 adapter simplify things a bit?
quote:
"So disabling multicast snooping for my bridge resolved the situation."

Right now, there are no adapters in the bridge present:

brctl show br0:
quote:
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no

The multicast snooping would take place in the bridge itself. Plausible?

Thanks!

graysonf
MVM
join:1999-07-16
Fort Lauderdale, FL

graysonf

MVM

In the below, the Bcast address is wrong - 169 should be 168.

br0 Link encap:Ethernet HWaddr a2:52:94:0b:aa:bb
inet addr:192.168.1.205 Bcast:192.169.1.255 Mask:255.255.255.0
inet6 addr: fe80::a052:94ff:fe0b:2abc/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:918 (918.0 B)

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek

Premium Member

The eye in your avatar makes a lot of sense,

Fixed, rebooted, but it made no difference.

GILXA1226
MVM
join:2000-12-29
Dayton, OH

GILXA1226

MVM

What are you attempting to accomplish with the bridge? With your wlan0 in AP mode, you will not be able to connect it to a wireless network. This is fine if you will be using your box as a wireless router.

graysonf
MVM
join:1999-07-16
Fort Lauderdale, FL

graysonf to misiek

MVM

to misiek
I am not sure about this, but something is telling me that a bridged interface has no IP address.

One thing I do know for sure is that you can not have two (or more) interfaces in the same machine that define the same network.

DeHackEd
Bill Ate Tux's Rocket
join:2000-12-07

DeHackEd

Member

That is correct bridged interfaces should not have any IP address. (I said so earlier). I suggest "ip addr flush dev eth0"

(While you CAN have two interfaces on the same subnet, it serves little purpose without something like bonding or it would require suitable configuration on the IP stack. Close enough to "don't do it").

Also why do people set a broadcast address? It's automatically set for you if not specified and there's only one valid answer. Let the OS do the work.

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek to GILXA1226

Premium Member

to GILXA1226
said by GILXA1226:

With your wlan0 in AP mode, you will not be able to connect it to a wireless network

I am trying to connect it to a wireless network and stream pictures to DLNA clients (both wired and wireless ones). I was afraid someone was going to say what you did lol.

GILXA1226
MVM
join:2000-12-29
Dayton, OH

GILXA1226

MVM

you could have the DLNA clients connect through the new AP you will have created.

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO
Ubiquiti NanoBeam M5 16

Brano to misiek

MVM

to misiek
In your first post you've just made assumption that you need a bridge without trying to understand what the issue is. Here is what I'd recommend to do:

1) Remove the bridge ... put everything to default config as it was.
2) Configure your eth0 to connect to your lan as you had it before.
3) Configure your wlan0 to connect to your home wifi (set the SSID/WPA as configured on your AP).

Re-post what I've asked for before (ifconfig -v, route -v and arp -v results).

Ping your home gateway (router) via both interfaces and post results here. Do ping -I wlan0 IP_of_your_internet_router and ping -I eth0 IP_of_your_internet_router.

And post output from iwconfig

misiek
Premium Member
join:2000-12-25
Round Lake, IL

1 edit

misiek

Premium Member

@ Brano & everyone else:

Her you go. I don't know if that's possible, but what I am trying to achieve is this:
1) Bridge wlan0 (if necessary, eth0 too) into a br0 bridge.
2) Associate the bridge with an existing AP, assign static address to it and configure it as a WAN port on the DLNA server.
(I am trying to test a hypothesis that disabling multicast snooping in the bridge helps the DLNA server to become 'visible' to all clients on the LAN as indicated by the guy in the Ubuntu thread - refer to my opening statement.)

Are there any other or easier ways to do this?

Thanks!

ifconfig -v :

eth0      Link encap:Ethernet  HWaddr 00:60:97:d2:xx:yy  
          inet addr:192.168.1.202  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::260:97ff:fed2:xxyy/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3389 errors:0 dropped:3 overruns:0 frame:0
          TX packets:1865 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:561185 (548.0 KiB)  TX bytes:255960 (249.9 KiB)
          Interrupt:11 Base address:0xc400 
 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
wlan0     Link encap:Ethernet  HWaddr 00:0e:3b:04:xx:yy  
          inet addr:192.168.1.203  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:3bff:fe04:xxyy/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:593 errors:0 dropped:0 overruns:0 frame:0
          TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:123417 (120.5 KiB)  TX bytes:9901 (9.6 KiB)
 

route -v :

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         pfsense.local   0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0
 

arp -v :

Address                  HWtype  HWaddress           Flags Mask            Iface
pfsense.local            ether   00:e0:c5:51:xx:yy   C                     wlan0
192.168.1.197            ether   00:50:8d:ed:xx:yy   C                     eth0
pfsense.local            ether   00:e0:c5:51:xx:yy   C                     eth0
Entries: 3Skipped: 0Found: 3
 

ping gateway from eth0:

PING 192.168.1.1 (192.168.1.1) from 192.168.1.202 eth0: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.302 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.235 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.172 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=0.181 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=0.176 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=0.188 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=0.201 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=0.222 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=0.186 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=0.193 ms
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8999ms
rtt min/avg/max/mdev = 0.172/0.205/0.302/0.040 ms
 

ping gateway from wlan0:

PING 192.168.1.1 (192.168.1.1) from 192.168.1.203 wlan0: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.23 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.683 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.688 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=0.989 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=0.660 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=0.648 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=0.672 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=0.755 ms
64 bytes from 192.168.1.1: icmp_req=9 ttl=64 time=0.767 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=0.647 ms
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 0.647/0.774/1.239/0.186 ms
 

iwconfig:

wlan0     IEEE 802.11bg  ESSID:"test"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:0E:2E:70:xx:yy   
          Bit Rate=48 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=70/70  Signal level=-17 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:2  Invalid misc:6   Missed beacon:0
 

DeHackEd
Bill Ate Tux's Rocket
join:2000-12-07

DeHackEd

Member

eth0      Link encap:Ethernet  HWaddr 00:60:97:d2:xx:yy
inet addr:192.168.1.202 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::260:97ff:fed2:xxyy/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3389 errors:0 dropped:3 overruns:0 frame:0
TX packets:1865 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:561185 (548.0 KiB) TX bytes:255960 (249.9 KiB)
Interrupt:11 Base address:0xc400

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr 00:0e:3b:04:xx:yy
inet addr:192.168.1.203 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20e:3bff:fe04:xxyy/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:593 errors:0 dropped:0 overruns:0 frame:0
TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:123417 (120.5 KiB) TX bytes:9901 (9.6 KiB)

Is this thing on? I said you don't put IP addresses on interfaces that are bridged. You put the IP on the bridge itself (br0).

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek

Premium Member

said by DeHackEd:

Is this thing on?

No, the bridge has been removed and now only two physical interfaces eth0 and wlan0 are active.

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO
Ubiquiti NanoBeam M5 16

Brano to misiek

MVM

to misiek
I'm still not sure where are you coming with this bridge requirement? Why do you want to bridge it? What are you trying accomplish? What exactly is your issue that triggered this?

Your config seems to be OK. Once you move your PC to garage and wired is not used anymore you can bring eth0 down. That should switch default gateway though wlan0.

At minimal you should do two things:
1) Switch your default gateway through wlan0. (See your route output, now it's going out through eth0)
To test this you can bring down eth0 and do route command again. Default gateway should be routed through wlan0. Then test your media clients if they work.
2) Check your DLNA application to make sure the advertisement goes out through all interfaces or specify wlan0.

graysonf
MVM
join:1999-07-16
Fort Lauderdale, FL

graysonf to misiek

MVM

to misiek
said by misiek:

No, the bridge has been removed and now only two physical interfaces eth0 and wlan0 are active.

And as I said earlier you can not have two interfaces in the same machine that define the same network. You do.

eth0 192.168.1.202/24 and wlan0 192.168.1.203/24 are the same network.

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek

Premium Member

said by graysonf:

you can not have two interfaces in the same machine that define the same network.

Perhaps did not communicate this clearly so apologies for the confusion.
I have a few /etc/network/interfaces* files on the system in order to try them out one by one.
Only one of them is 'active' at any given time.

At the moment of the bridge creation, eth0 was intentionally left out. wlan0 was not assigned a 192.168.1.x address prior to failed attempt to add it to the br0.

All,

How about this idea: set wlan0 to promiscuous mode, create the bridge, add wlan0 to the bridge, assign the bridge its own IP address and finally associate the wireless bridge with the AP?

Doable?
Security concerns?

Thanks for all the replies so far, keep them coming.
As I mentioned before, I am taking baby steps in networking. I can do basic firewall setup, but googling wireless bridges has led me nowhere so far.

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO
Ubiquiti NanoBeam M5 16

1 edit

Brano to graysonf

MVM

to graysonf
said by graysonf:

said by misiek:

No, the bridge has been removed and now only two physical interfaces eth0 and wlan0 are active.

And as I said earlier you can not have two interfaces in the same machine that define the same network. You do.

eth0 192.168.1.202/24 and wlan0 192.168.1.203/24 are the same network.

Yes he can. I have this all the time on my laptop. Both wired and wireless interfaces are on same network. It all becomes a question which one is primary.

Here is a snip from my laptop when both wired and wireless are connected (wired takes the precedence). Now I'm writing this post through wired.

brano@droopy:~ > ifconfig 
eth0      Link encap:Ethernet  HWaddr f0:de:f1:b7:b7:9e  
          inet addr:192.168.10.21  Bcast:192.168.10.255  Mask:255.255.255.0
...cut
wlan0     Link encap:Ethernet  HWaddr 40:25:c2:92:0f:7c  
          inet addr:192.168.10.22  Bcast:192.168.10.255  Mask:255.255.255.0
...cut
 
brano@droopy:~ > route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         usg200.         0.0.0.0         UG    0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 wlan0
192.168.10.0    *               255.255.255.0   U     1      0        0 eth0
192.168.10.0    *               255.255.255.0   U     9      0        0 wlan0
192.168.254.0   *               255.255.255.0   U     0      0        0 eth0
 

And now I remove the wired cable. And writing this through wireless.
The eth0 looses IP obviously because it's through DHCP
eth0      Link encap:Ethernet  HWaddr f0:de:f1:b7:b7:9e  
...cut
wlan0     Link encap:Ethernet  HWaddr 40:25:c2:92:0f:7c  
          inet addr:192.168.10.22  Bcast:192.168.10.255  Mask:255.255.255.0
...cut
 
brano@droopy:~ > route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         usg200          0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 wlan0
192.168.10.0    *               255.255.255.0   U     9      0        0 wlan0
 

But watch how the default gateway interface changed.
Brano

Brano to misiek

MVM

to misiek
Why are you still pushing the bridge? It makes no sense in this scenario to bridge these interfaces. If you're having wireless issues you will have the same wireless issues when you bridge the interfaces. Furthermore when you move the box to the garage and wired is not going to be used what's the point of over complicating the setup.

Focus at the issue at hand. Connectivity issues through wireless.

Bring up wlan0, change the default gateway to be reached through wlan0 (bring down eth0, that will do it) and begin re-testing everything.

Make sure your DLNA application is bound to any/all interfaces or explicitly to wlan0.

Once all this is up, observe what the wireless issues are and post the issues back here. Be clear to describe symptoms. Bridge is not going to solve that.

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek

Premium Member

said by Brano:

Why are you still pushing the bridge?

Because minidlna over wireless = visibility problems APPARENTLY due to multicast snooping being enabled. In bridges, the multicast snooping can ALLEGEDLY be disabled.
I want to test an idea of disabling the multicast snooping in the bridge on the server's WAN side to see if this would solve the visibility issues of the dlna server.
said by Brano:

Focus at the issue at hand. Connectivity issues through wireless.

I can set up wireless access via wlan0 itself just fine.

graysonf
MVM
join:1999-07-16
Fort Lauderdale, FL

graysonf

MVM

99% of the oddball multi-interface configuration scenarios I have run into over the years were solved by plugging an ethernet wireless AP into the LAN switch and being done with it.

Is that something that could/would fit your situation, other than trying to "save" a wireless NIC?

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO
Ubiquiti NanoBeam M5 16

3 edits

Brano to misiek

MVM

to misiek
said by misiek:

said by Brano:

Why are you still pushing the bridge?

Because minidlna over wireless = visibility problems APPARENTLY due to multicast snooping being enabled. In bridges, the multicast snooping can ALLEGEDLY be disabled.
I want to test an idea of disabling the multicast snooping in the bridge on the server's WAN side to see if this would solve the visibility issues of the dlna server.
said by Brano:

Focus at the issue at hand. Connectivity issues through wireless.

I can set up wireless access via wlan0 itself just fine.

So what is the actual problem? ...guess I'm missing something terribly.

The snooping 'might' be an issue on bridged interface, not on single wlan interface. Since you're connecting to an AP via wlan then the snooping is not an issue.

Focus on your AP, check if it's running on latest firmware. Check that it supports multicast and that it's enabled. If it has UPnP option then you may want to enable that too and see if it makes difference.

Mind, most systems disable multicast on wireless adapters because of the degrading performance this usually causes on wireless.

In your scenario, it would be the best just to run the wire to the garage

misiek
Premium Member
join:2000-12-25
Round Lake, IL

misiek

Premium Member

I'm tired today, stopping this for now.

Thanks to all who have replied!
misiek

misiek

Premium Member

I messed up my system and had to rebuild it from scratch, again, with Debian. It behaves strangely, for example, for the life of me, I can't figure it out why it won't allow an un-priviledged used to have write access to a mounted internal scsi drive. Fstab settigns for that drive seem to be correct, according to several forums posts I followed.

Gave up on Debian and installed NAS4Free, haven't tried its dlna server yet, but noticed that when trying to write files to the hard drive (the same that Debian won't allow me to) over nfs protocol, the transfer just stops after a while and the server becomes pretty much unresponsive and I have to reboot it.

Not sure what it all means, just wanted to share what is going on. Perhaps the undelying cause of the issues described in OP is related to the server's hardware. Don't know.

Stopped pursuing the wireless connectivity for now, until I figure out what is going on.

Anyways, I wanted to thank you guys for trying to help me the other day.

Take care.