1043ND v1: client mode bridged with lan not working well

Installing and Using OpenWrt
1

Hi all,

I want to bridge via wireless 2 networks, but with my 1043ND I have latency problems and DHCP is not propagating to the remote lan.

One of the strange things is that If i ping main router with a client, I see 1-2 ms of latency; If I ping with this conf from 1043ND, I see from 8 ms to 2 s ping!

This is the conf of my 1043ND that acts as extender:
root@OpenWrt:~# cat /etc/config/igmpproxy

config igmpproxy
	option quickleave 1
#	option verbose [0-2]

config phyint wan
	option network wwan
	list altnet 192.168.1.0/24

config phyint lan
	option network lan
	list altnet 192.168.1.0/24

root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv6 'server'
	option ra 'server'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ath9k'
	option htmode 'HT40'
	option disabled '0'
	option channel '1'
	option country 'US'
	option noscan '1'

config wifi-iface
	option network 'wwan'
	option ssid 'router1'
	option encryption 'psk2'
	option device 'radio0'
	option mode 'sta'
	option bssid 'aa:bb:cc:dd:ee:ff'
	option key 'key'
	option wps_pushbutton '0'
	option noscan '1'

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd3b:cef8:3a61::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option ipaddr '192.168.10.1'
	option gateway '192.168.1.1'
	option dns '8.8.8.8'
	option ip6assign '60'
	option netmask '255.255.255.248'

config interface 'wwan'
	option proto 'static'
	option ipaddr '192.168.1.5'
	option netmask '255.255.255.0'
	option gateway '192.168.1.1'
	option dns '8.8.8.8'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 3 4 5t'

config interface 'stabridge'
	option proto 'relay'
	option network 'wwan lan'
	option ipaddr '192.168.1.5'
2

try this:

wds: https://gist.github.com/braian87b/8a524a8ad74a36407a8f481e9d16a5c9
relayd: https://gist.github.com/braian87b/821e9e4f399918510c55619192a31871

3

for the WDS config, if the main router has no openwrt / lede firmware, could it be a problem?

4

Yes, that means in almost all cases that it's not going to work (WDS is only supported by mac80211 based drivers, if the vendor if using proprietary drivers that won't work).

5

this is not working: as I wrote on my post here [Solved] 1043ND repeater mode not working - #2 by braian87b when I try to start a second wlan interface, all wifi (sta or AP) stops

6

Ok, so as of now I cannot use it

7

It should work, I used that configuration several times with different hw... what build are you using? I head that some builds have problems with relayd.

8

ok, I found some things:

  1. without setting regdomain, I had the problem where I was not able to turn on AP and STA at the same time: maybe because of chan 13?
  2. probably the ping problem is something related to the Vodafone station that I was trying to extend. With a Raspberry PI with raspbian I had the same problem. Today I tried in an other environment, replicating wifi from an ORBI netgear, and everything was working right.

So as of now these problems are solved, but trying to solve the problems, I found that with the vodafone station, even if the router is connected to the network wifi, block the lede repeater in a strange way: I cannot ping or find the lede repeater from an other client directly connected to the vodafone station, but if I connect a client to the repeater I can browse web (with ridicolous speed, like 3-5 mbit instead of 60).

9

That channel has many restrictions, so yes, probably was channel related.

About the ping issue, maybe igmpproxy are failing or even it could be ap isolation problem too or some iptables/firewall rule.
About the slowlyness it could be just limitation of the hw... you really mean mbit? or mbyte? have you tried to put the repeater just a about 3 to 5 meters on the same room with antennas vertical... if you put very far, with walls, signal will degrade, and if you put very close signal will saturate and get noise, and if you put antennaes misaligned you may have unwanted signal bouncing around.

10

Recap of all the tests: The problem is indeed router (vodafone station) related.

3 days ago I tried with some GL.INET AR300M: when the configuration was like repeater not bridged, everything was ok: as soon as I put the repeater in bridge mode with relayd igmproxy etc I experienced the same behaviour of the 1043ND... doing reset of the repeater and reconfiguring it as router did not solve network issues reported above, but using a second GL-INET, or rebooting the vodafone station, made things comes back as normal.

So

I think the problem is related to some spoofing-block algo inside the vodafone station, because this is the only one router that caused me that troubles.

The speed reported above were in mbit. The tests were performed in the same room at 3m between vodafone station and the repeater, with repeater at 1 m above ground, and vodafone station at 2m. I'm a TLC engineer student, so I know what are the saturation / interference problems of the transmitters / receivers, but I wrote here because of the problem not present on the other devices (like smartphones and / or PCs), and the behaviour seemed to be pretty strange.