Re: [OpenWrt-Devel] Openvswitch package not available in trunk
Well, OpenVSwitch is a bit behind on kernel support. It's at 3.18 currently. OpenWRT is at 4.1 We'd need to do an upgrade of OVS to get it up to speed. On Tue, Aug 4, 2015 at 12:43 PM, Florian Siebertz florian.siebe...@inf.h-brs.de wrote: Hi, i noticed that the openvswitch package is not available in trunk at the moment. It is not in the precompiled snapshots, neither can it be choosen in 'make menuconfig'. (Yes, i did ./scripts/feeds [update|install] -a). Does anyone know why and when it will be back? Thanks! Florian Siebertz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Openvswitch package not available in trunk
Took some 20-30 minutes to upgrade OVS and test it (with kernel 4.1). Seems to work fine so far. Please monitor this PR; after it's merged it should appear. On Tue, Aug 4, 2015 at 1:37 PM, Alexandru Ardelean ardeleana...@gmail.com wrote: Well, OpenVSwitch is a bit behind on kernel support. It's at 3.18 currently. OpenWRT is at 4.1 We'd need to do an upgrade of OVS to get it up to speed. On Tue, Aug 4, 2015 at 12:43 PM, Florian Siebertz florian.siebe...@inf.h-brs.de wrote: Hi, i noticed that the openvswitch package is not available in trunk at the moment. It is not in the precompiled snapshots, neither can it be choosen in 'make menuconfig'. (Yes, i did ./scripts/feeds [update|install] -a). Does anyone know why and when it will be back? Thanks! Florian Siebertz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] netifd: Fix device usage after free
Prevent new device from being freed in device_replace when device_unlock is called along the function chain triggered by setting the old device as not present Signed-off-by: Hans Dedecker dedec...@gmail.com --- device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/device.c b/device.c index 6f31e36..59a57f4 100644 --- a/device.c +++ b/device.c @@ -704,6 +704,7 @@ device_replace(struct device *dev, struct device *odev) struct device_user *dep, *tmp; bool present = odev-present; + __devlock++; if (present) device_set_present(odev, false); @@ -713,6 +714,8 @@ device_replace(struct device *dev, struct device *odev) safe_list_add(dep-list, dev-users); dep-dev = dev; } + __devlock--; + device_free(odev); if (present) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, Its working, i am able to access internet but there is one problem, When i scan the wireless devices, its gives the list of devices are there nearby, then i connect anyone device, it will connect but my board wifi0 SSID name will change to that router which i connected. I mean LAN side SSID should not change after connecting to WAN SSID. On Tue, Aug 4, 2015 at 12:42 PM, John kerry kerry9...@gmail.com wrote: Hi This is my firewall file: config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'lan' option network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'wan' option network 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' config forwarding option src 'lan' option dest 'wan' config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4' config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT' config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option src_ip 'fe80::/10' option src_port '547' option dest_ip 'fe80::/10' option dest_port '546' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT' config include option path '/etc/firewall.user' config include 'miniupnpd' option type 'script' option path '/usr/share/miniupnpd/firewall.include' option family 'IPv4' option reload '1' On Tue, Aug 4, 2015 at 12:38 PM, Weedy weedy2...@gmail.com wrote: Is there something wrong with the default rules for your use case? Your WiFi interfaces are tagged LAN, things should just work. On 4 Aug 2015 00:07, John kerry kerry9...@gmail.com wrote: Hi, below is the /etc/config/network and /etc/config/wireless changes. */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 interface 'lan' option ifname 'eth0.1 eth1' option type 'bridge' option proto 'static' option ipaddr '192.168.1.5' option netmask '255.255.255.0' config interface 'wan' option ifname 'eth0.2' option proto 'dhcp' config switch option name 'eth0' option reset '1' option enable_vlan '1' config switch_vlan option device 'eth0' option vlan '1' option ports '0t 2 3 4 5' config switch_vlan option device 'eth0' option vlan '2' option ports '0t 1' config switch option name 'eth1' option reset '1' option enable_vlan '1' config switch_vlan option device 'eth1' option vlan '1' option ports '0 1 2 3 4 5' */etc/config/wireless:config wifi-device 'wifi0'option type 'qcawifi'option channel 'auto'option macaddr
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
Hi, Yes i configured the mode as AP. could you please guide how i can add script for another radio. presently my wireless script is as below: *config wifi-device 'wifi0'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:61'option hwmode '11ng'option txpower '19'option htmode 'HT20'config wifi-ifaceoption device 'wifi0'option network 'lan' option mode 'ap'option encryption 'psk2'option ssid 'Test_ap_1'option key **'Test_ap_1'* *config wifi-device 'wifi1'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:62'option hwmode '11na'option txpower '23'option htmode 'HT20'config wifi-ifaceoption device 'wifi1'option network 'lan' option mode 'ap'option ssid 'Test_ap_2'option encryption 'psk2'option key 'test_ap_2'* *How i can change this to make it work.* *Thanks,* On Tue, Aug 4, 2015 at 2:26 PM, David Lang da...@lang.hm wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, Its working, i am able to access internet but there is one problem, When i scan the wireless devices, its gives the list of devices are there nearby, then i connect anyone device, it will connect but my board wifi0 SSID name will change to that router which i connected. I mean LAN side SSID should not change after connecting to WAN SSID. On Tue, Aug 4, 2015 at 12:42 PM, John kerry kerry9...@gmail.com wrote: Hi This is my firewall file: config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'lan' option network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'wan' option network 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' config forwarding option src 'lan' option dest 'wan' config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4' config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT' config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option src_ip 'fe80::/10' option src_port '547' option dest_ip 'fe80::/10' option dest_port '546' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT' config include option path '/etc/firewall.user' config include 'miniupnpd' option type 'script' option path '/usr/share/miniupnpd/firewall.include' option family 'IPv4' option reload '1' On Tue, Aug 4, 2015 at 12:38 PM, Weedy weedy2...@gmail.com wrote: Is there something wrong with the default rules for your use case? Your WiFi interfaces are tagged LAN, things should just work. On 4 Aug 2015 00:07, John kerry kerry9...@gmail.com wrote:
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
you can't create a new radio with a script, you have to have a second radio in the hardware. wifi0 is one radio, wifi1 is the second. configure one as an AP, the other as a client (you probably want to make the client be part of the wan interface/firewall group if it's your connection to the Internet) As I said before, since you don't understand how the configs work, I'd suggest using the GUI to configure them and then look at what the resulting file looks like. A lot of expertise went into making the GUI set the right config options to make pretty complex things happen. David Lang On Tue, 4 Aug 2015, John kerry wrote: Date: Tue, 4 Aug 2015 14:41:38 +0800 From: John kerry kerry9...@gmail.com To: David Lang da...@lang.hm Cc: Weedy weedy2...@gmail.com, N. Leiten nicklei...@gmail.com, OpenWrt Development List openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings Hi, Yes i configured the mode as AP. could you please guide how i can add script for another radio. presently my wireless script is as below: *config wifi-device 'wifi0'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:61'option hwmode '11ng'option txpower '19'option htmode 'HT20'config wifi-ifaceoption device 'wifi0'option network 'lan' option mode 'ap'option encryption 'psk2'option ssid 'Test_ap_1'option key **'Test_ap_1'* *config wifi-device 'wifi1'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:62'option hwmode '11na'option txpower '23'option htmode 'HT20'config wifi-ifaceoption device 'wifi1'option network 'lan' option mode 'ap'option ssid 'Test_ap_2'option encryption 'psk2'option key 'test_ap_2'* *How i can change this to make it work.* *Thanks,* On Tue, Aug 4, 2015 at 2:26 PM, David Lang da...@lang.hm wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, Its working, i am able to access internet but there is one problem, When i scan the wireless devices, its gives the list of devices are there nearby, then i connect anyone device, it will connect but my board wifi0 SSID name will change to that router which i connected. I mean LAN side SSID should not change after connecting to WAN SSID. On Tue, Aug 4, 2015 at 12:42 PM, John kerry kerry9...@gmail.com wrote: Hi This is my firewall file: config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'lan' option network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'wan' option network 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' config forwarding option src 'lan' option dest 'wan' config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4' config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT' config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option src_ip 'fe80::/10' option src_port '547' option dest_ip 'fe80::/10' option dest_port '546' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT' config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type
[OpenWrt-Devel] [PATCH 4/4] netifd: Spawn device events when registering dependency in device_replace
Spawn device events when adding dependency in device_replace so the dependency
installer gets
the actual device status
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
device.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/device.c b/device.c
index 1636611..66eb6d4 100644
--- a/device.c
+++ b/device.c
@@ -534,19 +534,11 @@ static int device_refcount(struct device *dev)
return count;
}
-void device_add_user(struct device_user *dep, struct device *dev)
+static void
+__device_add_user(struct device_user *dep, struct device *dev)
{
struct safe_list *head;
- if (dep-dev == dev)
- return;
-
- if (dep-dev)
- device_remove_user(dep);
-
- if (!dev)
- return;
-
dep-dev = dev;
if (dep-alias)
@@ -567,6 +559,20 @@ void device_add_user(struct device_user *dep, struct
device *dev)
}
}
+void device_add_user(struct device_user *dep, struct device *dev)
+{
+ if (dep-dev == dev)
+ return;
+
+ if (dep-dev)
+ device_remove_user(dep);
+
+ if (!dev)
+ return;
+
+ __device_add_user(dep, dev);
+}
+
void
device_free(struct device *dev)
{
@@ -710,8 +716,7 @@ device_replace(struct device *dev, struct device *odev)
list_for_each_entry_safe(dep, tmp, odev-users.list, list.list) {
device_release(dep);
safe_list_del(dep-list);
- safe_list_add(dep-list, dev-users);
- dep-dev = dev;
+ __device_add_user(dep, dev);
}
__devlock--;
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/4] netifd: Remove obsolete device_set_present in device_replace
New device does not need to be set present as device_check_state called via
device_init
sets the device present after probing the kernel device
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
device.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/device.c b/device.c
index 59a57f4..1636611 100644
--- a/device.c
+++ b/device.c
@@ -702,10 +702,9 @@ static void
device_replace(struct device *dev, struct device *odev)
{
struct device_user *dep, *tmp;
- bool present = odev-present;
__devlock++;
- if (present)
+ if (odev-present)
device_set_present(odev, false);
list_for_each_entry_safe(dep, tmp, odev-users.list, list.list) {
@@ -717,9 +716,6 @@ device_replace(struct device *dev, struct device *odev)
__devlock--;
device_free(odev);
-
- if (present)
- device_set_present(dev, true);
}
void
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] netifd: Fix SEG fault when device cannot be allocated
Signed-off-by: Hans Dedecker dedec...@gmail.com --- device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/device.c b/device.c index b5bee11..6f31e36 100644 --- a/device.c +++ b/device.c @@ -741,6 +741,9 @@ device_reset_old(void) continue; ndev = device_create_default(dev-ifname, dev-external); + if (!ndev) + continue; + device_replace(ndev, dev); } } -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multiple Wi-Fi client/AP interfaces on one radio (was: Change OpenWrt Wifi default settings)
On 2015-08-04 02:26, David Lang wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. This is not necessarily true: with at least some hardware/drivers, it's possible to create multiple virtual interfaces on top of a single radio-- and separate virtual interfaces can in fact operate in different modes (e.g.: one in STA mode, two in AP mode, one in mesh mode...). Assuming that your hardware/driver is capable of supporting multiple virtual interfaces on top of the single physical radio, you can create these interfaces by adding wifi-iface stanzas in /etc/config/wireless, e.g: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' That creates two virtual interfaces using the same physical radio, and bridges them together onto the OpenWrt lan network (which is itself defined in /etc/config/network). I believe you could also have an interface with mode 'sta', but note that it would also need to use the same channel as the other interfaces-- which means that the external AP to which you connect it would also need to use that same channel (11, in the example above). That's where having multiple *radios* helps: you can run them on different frequencies (either completely different bands [2.4 GHz vs. 5 GHz], or on different channels within the same band [e.g. 2.427 GHz = channel 4 vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing less data over a single radio, or to increase compatibility with other APs outside of your control that you might want to connect to. Also note that, if you want to bridge a STA interface onto anything else, it'll need to be in WDS mode _and_ the the AP to which it's connecting will also need to be in WDS mode (note the option wds '1', in my example above), because the standard 3-address mode of Wi-Fi isn't bridgeable (and note that WDS 4-address mode is bridgeable, but not standardised across different platforms--so you're probably OK so long as all of your equipment is running Linux and using the same Wi-Fi driver, but don't expect to bridge a STA interface that's connected non-Linux Wi-Fi router). At least, I've seen this work with Atheros chips. There are some notes in the wiki about how Broadcom chips have their own, different solution implemented in hardware; and about how some drivers don't support this stuff at all -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings
On Tue, 4 Aug 2015, John kerry wrote: I have one doubts, both should be configured either 2.4GHz or 5GHz but for wifi1 in GUI there is no option to change to 2.4GHz. no, one radio is only able to operate on the 2.4GHz band and the other is only able to operate on the 5GHz band. this isn't a configuration item, this is teh physical/electrical properties of the radios. without some rather complicated (and expensive) setup you can't have two radios on te 2.4GHz band in one AP, when one transmits it would defen (if not actually damage) the other you can use one as a client to a remote AP (say the 5GHz band) and then use the other (the 2.4GHz band) to provide service to nearby equipment. I actually just finished setting up this exact configuration to extend service into a nearby building across a parking lot. David Lang Thanks, On Tue, Aug 4, 2015 at 2:56 PM, David Lang da...@lang.hm wrote: you can't create a new radio with a script, you have to have a second radio in the hardware. wifi0 is one radio, wifi1 is the second. configure one as an AP, the other as a client (you probably want to make the client be part of the wan interface/firewall group if it's your connection to the Internet) As I said before, since you don't understand how the configs work, I'd suggest using the GUI to configure them and then look at what the resulting file looks like. A lot of expertise went into making the GUI set the right config options to make pretty complex things happen. David Lang On Tue, 4 Aug 2015, John kerry wrote: Date: Tue, 4 Aug 2015 14:41:38 +0800 From: John kerry kerry9...@gmail.com To: David Lang da...@lang.hm Cc: Weedy weedy2...@gmail.com, N. Leiten nicklei...@gmail.com, OpenWrt Development List openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Change OpenWrt Wifi default settings Hi, Yes i configured the mode as AP. could you please guide how i can add script for another radio. presently my wireless script is as below: *config wifi-device 'wifi0'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:61'option hwmode '11ng'option txpower '19'option htmode 'HT20'config wifi-ifaceoption device 'wifi0'option network 'lan' option mode 'ap'option encryption 'psk2'option ssid 'Test_ap_1'option key **'Test_ap_1'* *config wifi-device 'wifi1'option type 'qcawifi'option channel 'auto'option macaddr '00:03:7f:42:06:62'option hwmode '11na'option txpower '23'option htmode 'HT20'config wifi-ifaceoption device 'wifi1'option network 'lan' option mode 'ap'option ssid 'Test_ap_2'option encryption 'psk2'option key 'test_ap_2'* *How i can change this to make it work.* *Thanks,* On Tue, Aug 4, 2015 at 2:26 PM, David Lang da...@lang.hm wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. David Lang On Tue, 4 Aug 2015, John kerry wrote: Hi, Its working, i am able to access internet but there is one problem, When i scan the wireless devices, its gives the list of devices are there nearby, then i connect anyone device, it will connect but my board wifi0 SSID name will change to that router which i connected. I mean LAN side SSID should not change after connecting to WAN SSID. On Tue, Aug 4, 2015 at 12:42 PM, John kerry kerry9...@gmail.com wrote: Hi This is my firewall file: config defaults option syn_flood '1' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'lan' option network 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' config zone option name 'wan' option network 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' config forwarding option src 'lan' option dest 'wan' config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4' config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT' config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option src_ip 'fe80::/10' option src_port '547' option dest_ip 'fe80::/10'
[OpenWrt-Devel] Openvswitch package not available in trunk
Hi, i noticed that the openvswitch package is not available in trunk at the moment. It is not in the precompiled snapshots, neither can it be choosen in 'make menuconfig'. (Yes, i did ./scripts/feeds [update|install] -a). Does anyone know why and when it will be back? Thanks! Florian Siebertz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] CC: ar71xx: Enable ath10k calibration data loading for EnGenius ESR1750 and EPG500.
Kinda-backport of r46415, though this patch uses the old-style calibration data loading. Signed-off-by: Christian Beier c...@shoutrlabs.com --- .../linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 4 1 file changed, 4 insertions(+) diff --git a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index c827e31..dd3f546 100644 --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -39,6 +39,10 @@ case $FIRMWARE in dlan-pro-1200-ac) ath10kcal_from_file $(find_mtd_part art) 20480 $ath10kcal_tmp ;; + esr1750 | \ + epg5000) + ath10kcal_from_file $(find_mtd_part caldata) 20480 $ath10kcal_tmp + ;; esac ;; -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: update 4.1 to 4.1.4
Changelog:
* https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.4
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
include/kernel-version.mk | 4 +-
...79-add-gpio-func-register-for-QCA955x-SoC.patch | 2 +-
.../813-MIPS-ath79-add-ap147-support.patch | 6 +-
.../140-overlayfs_readdir_locking_fix.patch| 148 -
.../generic/patches-4.1/834-ledtrig-libata.patch | 10 +-
5 files changed, 11 insertions(+), 159 deletions(-)
delete mode 100644
target/linux/generic/patches-4.1/140-overlayfs_readdir_locking_fix.patch
diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index e03590f..9f68716 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -4,11 +4,11 @@ LINUX_RELEASE?=1
LINUX_VERSION-3.18 = .19
LINUX_VERSION-4.0 = .9
-LINUX_VERSION-4.1 = .3
+LINUX_VERSION-4.1 = .4
LINUX_KERNEL_MD5SUM-3.18.19 = a143f9421bd8413752609d0d771c2955
LINUX_KERNEL_MD5SUM-4.0.9 = 40fc5f6e2d718e539b45e6601c71985b
-LINUX_KERNEL_MD5SUM-4.1.3 = 96c2c77b1c54ba01cfd8fc2d13fbf828
+LINUX_KERNEL_MD5SUM-4.1.4 = 32cb4dd9f14d37bf71bafa6ed368f769
ifdef KERNEL_PATCHVER
LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
diff --git
a/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
b/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
index 24ce7d8..23425dc 100644
---
a/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
+++
b/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
@@ -1,6 +1,6 @@
--- a/arch/mips/ath79/gpio.c
+++ b/arch/mips/ath79/gpio.c
-@@ -185,15 +185,27 @@ void __init ath79_gpio_output_select(uns
+@@ -221,15 +221,27 @@ void __init ath79_gpio_output_select(uns
{
void __iomem *base = ath79_gpio_base;
unsigned long flags;
diff --git
a/target/linux/ar71xx/patches-4.1/813-MIPS-ath79-add-ap147-support.patch
b/target/linux/ar71xx/patches-4.1/813-MIPS-ath79-add-ap147-support.patch
index 2ca9a1e..ed0d984 100644
--- a/target/linux/ar71xx/patches-4.1/813-MIPS-ath79-add-ap147-support.patch
+++ b/target/linux/ar71xx/patches-4.1/813-MIPS-ath79-add-ap147-support.patch
@@ -1,6 +1,6 @@
--- a/arch/mips/ath79/Kconfig
+++ b/arch/mips/ath79/Kconfig
-@@ -118,6 +118,19 @@ config ATH79_MACH_AP143
+@@ -138,6 +138,19 @@ config ATH79_MACH_AP143
Say 'Y' here if you want your kernel to support the
Atheros AP143 reference board.
@@ -22,7 +22,7 @@
select SOC_AR913X
--- a/arch/mips/ath79/Makefile
+++ b/arch/mips/ath79/Makefile
-@@ -47,6 +47,7 @@ obj-$(CONFIG_ATH79_MACH_AP121) += mach-
+@@ -49,6 +49,7 @@ obj-$(CONFIG_ATH79_MACH_AP121) += mach-
obj-$(CONFIG_ATH79_MACH_AP132)+= mach-ap132.o
obj-$(CONFIG_ATH79_MACH_AP136)+= mach-ap136.o
obj-$(CONFIG_ATH79_MACH_AP143)+= mach-ap143.o
@@ -32,7 +32,7 @@
obj-$(CONFIG_ATH79_MACH_AP96) += mach-ap96.o
--- a/arch/mips/ath79/machtypes.h
+++ b/arch/mips/ath79/machtypes.h
-@@ -29,6 +29,7 @@ enum ath79_mach_type {
+@@ -31,6 +31,7 @@ enum ath79_mach_type {
ATH79_MACH_AP136_010, /* Atheros AP136-010 reference board */
ATH79_MACH_AP136_020, /* Atheros AP136-020 reference board */
ATH79_MACH_AP143, /* Atheros AP143 reference board */
diff --git
a/target/linux/generic/patches-4.1/140-overlayfs_readdir_locking_fix.patch
b/target/linux/generic/patches-4.1/140-overlayfs_readdir_locking_fix.patch
deleted file mode 100644
index 67dff98..000
--- a/target/linux/generic/patches-4.1/140-overlayfs_readdir_locking_fix.patch
+++ /dev/null
@@ -1,148 +0,0 @@
-Patch by: Miklos Szeredi mik...@szeredi.hu
-
-Some filesystems (e.g. jffs2) lock the same resources for both readdir
-and lookup, leading to a deadlock in ovl_cache_entry_new, which is called
-from the filldir, and calls lookup itself.
-
a/fs/overlayfs/readdir.c
-+++ b/fs/overlayfs/readdir.c
-@@ -23,6 +23,7 @@ struct ovl_cache_entry {
- u64 ino;
- struct list_head l_node;
- struct rb_node node;
-+ struct ovl_cache_entry *next_maybe_whiteout;
- bool is_whiteout;
- char name[];
- };
-@@ -39,7 +40,7 @@ struct ovl_readdir_data {
- struct rb_root root;
- struct list_head *list;
- struct list_head middle;
-- struct dentry *dir;
-+ struct ovl_cache_entry *first_maybe_whiteout;
- int count;
- int err;
- };
-@@ -79,7 +80,7 @@ static struct ovl_cache_entry *ovl_cache
- return NULL;
- }
-
--static struct ovl_cache_entry *ovl_cache_entry_new(struct dentry *dir,
-+static struct ovl_cache_entry *ovl_cache_entry_new(struct ovl_readdir_data
*rdd,
- const char *name, int len,
- u64 ino,
[OpenWrt-Devel] [PATCH 3/4] ipq806x: fix pcie pinmux naming in ipq806x dts
PCIe controller nodes are numbers 0/1/2 in the chipset dtsi file, but
the pinmux nodes are numbers 1/2/3. We'll make it consistent by changing
the pinmux numbering to match the controller's one.
Signed-off-by: Mathieu Olivari math...@codeaurora.org
---
...-qcom-add-pcie-nodes-to-ipq806x-platforms.patch | 31 +-
...RM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch | 10 +++
...-qcom-add-gmac-nodes-to-ipq806x-platforms.patch | 13 -
...-qcom-add-pcie-nodes-to-ipq806x-platforms.patch | 25 +
...RM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch | 4 +--
...-qcom-add-gmac-nodes-to-ipq806x-platforms.patch | 6 ++---
6 files changed, 41 insertions(+), 48 deletions(-)
diff --git
a/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
b/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
index 80ac25f..bdc91fb 100644
---
a/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
+++
b/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
@@ -15,11 +15,11 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
-@@ -30,6 +30,22 @@
+@@ -35,6 +35,22 @@
bias-disable;
};
-+ pcie1_pins: pcie1_pinmux {
++ pcie0_pins: pcie0_pinmux {
+ mux {
+ pins = gpio3;
+ drive-strength = 2;
@@ -27,7 +27,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+ };
+ };
+
-+ pcie2_pins: pcie2_pinmux {
++ pcie1_pins: pcie1_pinmux {
+ mux {
+ pins = gpio48;
+ drive-strength = 2;
@@ -38,7 +38,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
spi_pins: spi_pins {
mux {
pins = gpio18, gpio19, gpio21;
-@@ -133,5 +149,19 @@
+@@ -138,5 +154,19 @@
usb30@1 {
status = ok;
};
@@ -46,14 +46,14 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+ pcie0: pci@1b50 {
+ status = ok;
+ reset-gpio = qcom_pinmux 3 0;
-+ pinctrl-0 = pcie1_pins;
++ pinctrl-0 = pcie0_pins;
+ pinctrl-names = default;
+ };
+
+ pcie1: pci@1b70 {
+ status = ok;
+ reset-gpio = qcom_pinmux 48 0;
-+ pinctrl-0 = pcie2_pins;
++ pinctrl-0 = pcie1_pins;
+ pinctrl-names = default;
+ };
};
@@ -64,7 +64,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
bias-disable;
};
-+ pcie1_pins: pcie1_pinmux {
++ pcie0_pins: pcie0_pinmux {
+ mux {
+ pins = gpio3;
+ drive-strength = 2;
@@ -72,7 +72,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+ };
+ };
+
-+ pcie2_pins: pcie2_pinmux {
++ pcie1_pins: pcie1_pinmux {
+ mux {
+ pins = gpio48;
+ drive-strength = 2;
@@ -80,7 +80,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+ };
+ };
+
-+ pcie3_pins: pcie3_pinmux {
++ pcie2_pins: pcie2_pinmux {
+ mux {
+ pins = gpio63;
+ drive-strength = 2;
@@ -99,21 +99,21 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+ pcie0: pci@1b50 {
+ status = ok;
+ reset-gpio = qcom_pinmux 3 0;
-+ pinctrl-0 = pcie1_pins;
++ pinctrl-0 = pcie0_pins;
+ pinctrl-names = default;
+ };
+
+ pcie1: pci@1b70 {
+ status = ok;
+ reset-gpio = qcom_pinmux 48 0;
-+ pinctrl-0 = pcie2_pins;
++ pinctrl-0 = pcie1_pins;
+ pinctrl-names = default;
+ };
+
+ pcie2:
[OpenWrt-Devel] [PATCHv2 openwrt 1/3] hostapd: Always isolate if brport-multicast_to_unicast is enabled
For the multicast-to-unicast feature of a bridge to function correctly,
it is necessary that all STAs are always isolated on the AP level. The
bridge will take care of reflecting packets back to the AP interface
if necessary and/or no STA isolation wanted by using the hairpin feature
of the bridge.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
package/network/services/hostapd/files/netifd.sh |9 +
1 file changed, 9 insertions(+)
diff --git a/package/network/services/hostapd/files/netifd.sh
b/package/network/services/hostapd/files/netifd.sh
index a3ffd93..b987a63 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -1,3 +1,6 @@
+. /lib/network/config.sh
+. /lib/config/uci.sh
+
wpa_supplicant_add_rate() {
local var=$1
local val=$(($2 / 1000))
@@ -194,9 +197,15 @@ hostapd_set_bss_options() {
set_default uapsd 1
append bss_conf ctrl_interface=/var/run/hostapd
+
+ [ -n $multicast_to_unicast ] || multicast_to_unicast=1
+
if [ $isolate -gt 0 ]; then
append bss_conf ap_isolate=$isolate $N
+ elif [ -n $network_bridge -a $multicast_to_unicast -gt 0 ]; then
+ append bss_conf ap_isolate=1 $N
fi
+
if [ $maxassoc -gt 0 ]; then
append bss_conf max_num_sta=$maxassoc $N
fi
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2 openwrt 3/3] kernel: bridge, multicast-to-unicast: assign src after pskb_may_pull()
A call to pskb_may_pull() might reallocate skb-data. Therefore we
should only assign the src-pointer after any potential reallocations.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
.../645-bridge_multicast_to_unicast.patch | 45 +++-
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index e8be1fd..83f2475 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -100,37 +100,40 @@
struct sk_buff *skb,
u16 vid)
{
-+ const unsigned char *src = eth_hdr(skb)-h_source;
++ unsigned char *src;
struct igmpv3_report *ih;
struct igmpv3_grec *grec;
int i;
-@@ -1008,7 +1031,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -1008,7 +1031,8 @@ static int br_ip4_multicast_igmp3_report
continue;
}
- err = br_ip4_multicast_add_group(br, port, group, vid);
++ src = eth_hdr(skb)-h_source;
+ err = br_ip4_multicast_add_group(br, port, group, vid, src);
if (err)
break;
}
-@@ -1022,6 +1045,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1022,6 +1046,7 @@ static int br_ip6_multicast_mld2_report(
struct sk_buff *skb,
u16 vid)
{
-+ const unsigned char *src = eth_hdr(skb)-h_source;
++ unsigned char *src;
struct icmp6hdr *icmp6h;
struct mld2_grec *grec;
int i;
-@@ -1070,7 +1094,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1069,8 +1094,9 @@ static int br_ip6_multicast_mld2_report(
+ continue;
}
++ src = eth_hdr(skb)-h_source;
err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
- vid);
+ vid, src);
if (err)
break;
}
-@@ -1407,7 +1431,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1407,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
struct net_bridge_port *port,
struct br_ip *group,
struct bridge_mcast_other_query *other_query,
@@ -140,7 +143,7 @@
{
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1457,7 +1482,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1457,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
for (pp = mp-ports;
(p = mlock_dereference(*pp, br)) != NULL;
pp = p-next) {
@@ -149,7 +152,7 @@
continue;
rcu_assign_pointer(*pp, p-next);
-@@ -1491,7 +1516,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1491,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp-ports, br);
p != NULL;
p = mlock_dereference(p-next, br)) {
@@ -158,7 +161,7 @@
continue;
if (!hlist_unhashed(p-mglist)
-@@ -1509,8 +1534,8 @@ out:
+@@ -1509,8 +1536,8 @@ out:
static void br_ip4_multicast_leave_group(struct net_bridge *br,
struct net_bridge_port *port,
@@ -169,7 +172,7 @@
{
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1525,14 +1550,14 @@ static void br_ip4_multicast_leave_group
+@@ -1525,14 +1552,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
br_multicast_leave_group(br, port, br_group, br-ip4_other_query,
@@ -186,7 +189,7 @@
{
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1547,7 +1572,7 @@ static void br_ip6_multicast_leave_group
+@@ -1547,7 +1574,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
br_multicast_leave_group(br, port, br_group, br-ip6_other_query,
@@ -195,55 +198,59 @@
}
#endif
-@@ -1556,6 +1581,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1556,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
struct sk_buff *skb,
u16 vid)
{
-+ const unsigned char *src = eth_hdr(skb)-h_source;
++ unsigned char *src;
struct sk_buff *skb2 = skb;
const struct iphdr *iph;
struct igmphdr *ih;
-@@ -1629,7 +1655,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1629,7 +1657,8 @@ static int br_multicast_ipv4_rcv(struct
case IGMP_HOST_MEMBERSHIP_REPORT:
case IGMPV2_HOST_MEMBERSHIP_REPORT:
[OpenWrt-Devel] [PATCHv2 netifd 3/3] bridge: Allow setting multicast_router option
The multicast_router option of a bridge allows to control the forwarding
behaviour of multicast packets independant of the listener state:
* 0: Only forward if specific listener is present
* 1 (default): Forward if specific listener or a multicast router
was detected (currently only learned via query messages, no MRD
support yet)
* 2: Always forward any multicast traffic on this port
Since MRD is not mandated you might end up with silent multicast routers
(e.g. if your link has more than one multicast router; only one can
become the selected, noisy querier). Here you might need a manual
configuration option like the multicast_router option.
Other scenarios where this can be useful are for instance:
* Segmentation of IGMP/MLD domains together with ebtables
* Dedicated bridge port for monitoring/debugging purposes
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
device.c | 12
device.h |3 +++
system-linux.c | 18 ++
3 files changed, 33 insertions(+)
diff --git a/device.c b/device.c
index b44ccb8..d6e288c 100644
--- a/device.c
+++ b/device.c
@@ -49,6 +49,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX]
= {
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = dadtransmits, .type =
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast,
.type = BLOBMSG_TYPE_BOOL },
+ [DEV_ATTR_MULTICAST_ROUTER] = { .name = multicast_router, .type =
BLOBMSG_TYPE_INT32 },
};
const struct uci_blob_param_list device_attr_list = {
@@ -176,6 +177,7 @@ device_merge_settings(struct device *dev, struct
device_settings *n)
n-dadtransmits = s-flags DEV_OPT_DADTRANSMITS ?
s-dadtransmits : os-dadtransmits;
n-multicast_to_unicast = s-multicast_to_unicast;
+ n-multicast_router = s-multicast_router;
n-flags = s-flags | os-flags;
}
@@ -281,6 +283,14 @@ device_init_settings(struct device *dev, struct blob_attr
**tb)
s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
}
+ if ((cur = tb[DEV_ATTR_MULTICAST_ROUTER])) {
+ s-multicast_router = blobmsg_get_u32(cur);
+ if (s-multicast_router = 0 s-multicast_router = 2)
+ s-flags |= DEV_OPT_MULTICAST_ROUTER;
+ else
+ DPRINTF(Invalid value: %d - (Use 0: never, 1: learn,
2: always)\n, blobmsg_get_u32(cur));
+ }
+
device_set_disabled(dev, disabled);
}
@@ -893,6 +903,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, dadtransmits, st.dadtransmits);
if (st.flags DEV_OPT_MULTICAST_TO_UNICAST)
blobmsg_add_u8(b, multicast_to_unicast,
st.multicast_to_unicast);
+ if (st.flags DEV_OPT_MULTICAST_ROUTER)
+ blobmsg_add_u32(b, multicast_router,
st.multicast_router);
}
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 4344d8a..86a1628 100644
--- a/device.h
+++ b/device.h
@@ -43,6 +43,7 @@ enum {
DEV_ATTR_XPS,
DEV_ATTR_DADTRANSMITS,
DEV_ATTR_MULTICAST_TO_UNICAST,
+ DEV_ATTR_MULTICAST_ROUTER,
__DEV_ATTR_MAX,
};
@@ -86,6 +87,7 @@ enum {
DEV_OPT_MTU6= (1 12),
DEV_OPT_DADTRANSMITS= (1 13),
DEV_OPT_MULTICAST_TO_UNICAST= (1 14),
+ DEV_OPT_MULTICAST_ROUTER= (1 15),
};
/* events broadcasted to all users of a device */
@@ -144,6 +146,7 @@ struct device_settings {
bool xps;
unsigned int dadtransmits;
bool multicast_to_unicast;
+ unsigned int multicast_router;
};
/*
diff --git a/system-linux.c b/system-linux.c
index 944245c..01500a5 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -325,6 +325,13 @@ static void system_bridge_set_hairpin_mode(struct device
*dev, const char *val)
system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode,
dev-ifname, val);
}
+static void system_bridge_set_multicast_router(struct device *dev, const char
*val, bool bridge)
+{
+ system_set_dev_sysctl(bridge ?
/sys/class/net/%s/bridge/multicast_router :
+
/sys/class/net/%s/brport/multicast_router,
+ dev-ifname, val);
+}
+
static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
{
int fd = -1, ret = -1;
@@ -585,6 +592,7 @@ system_bridge_set_wireless(struct device *bridge, struct
device *dev)
int system_bridge_addif(struct device *bridge, struct device *dev)
{
+ char buf[64];
char *oldbr;
int ret = 0;
@@ -595,6 +603,11 @@ int system_bridge_addif(struct device *bridge, struct
device *dev)
if (dev-wireless)
system_bridge_set_wireless(bridge, dev);
+ if (dev-settings.flags
[OpenWrt-Devel] [PATCHv2 openwrt 2/3] Revert kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)
This reverts commit a080e8e1943156168913d0353a2e99d1151102aa.
It did not fix the problem but just hid some symptom. The real issue was
that IGMP/MLD report suppression was not considered for the
multicast-to-unicast feature. A recent netifd which isolates IGMP/MLD
reports between STAs by utilizing AP-isolation and bridge-hairpinning
should have fixed this.
It is perfectly fine to apply multicast-to-unicast to IPv6 Neighbor
Solicitations, too (once that feature is configured correctly).
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
.../645-bridge_multicast_to_unicast.patch | 37 +---
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index 00ad14f..e8be1fd 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -87,19 +87,16 @@
{
struct br_ip br_group;
-@@ -736,7 +758,10 @@ static int br_ip6_multicast_add_group(st
+@@ -736,7 +758,7 @@ static int br_ip6_multicast_add_group(st
br_group.proto = htons(ETH_P_IPV6);
br_group.vid = vid;
- return br_multicast_add_group(br, port, br_group);
-+ if (ipv6_addr_is_solict_mult(group))
-+ src = NULL;
-+
+ return br_multicast_add_group(br, port, br_group, src);
}
#endif
-@@ -965,6 +990,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -965,6 +987,7 @@ static int br_ip4_multicast_igmp3_report
struct sk_buff *skb,
u16 vid)
{
@@ -107,7 +104,7 @@
struct igmpv3_report *ih;
struct igmpv3_grec *grec;
int i;
-@@ -1008,7 +1034,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -1008,7 +1031,7 @@ static int br_ip4_multicast_igmp3_report
continue;
}
@@ -116,7 +113,7 @@
if (err)
break;
}
-@@ -1022,6 +1048,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1022,6 +1045,7 @@ static int br_ip6_multicast_mld2_report(
struct sk_buff *skb,
u16 vid)
{
@@ -124,7 +121,7 @@
struct icmp6hdr *icmp6h;
struct mld2_grec *grec;
int i;
-@@ -1070,7 +1097,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1070,7 +1094,7 @@ static int br_ip6_multicast_mld2_report(
}
err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
@@ -133,7 +130,7 @@
if (err)
break;
}
-@@ -1406,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1407,7 +1431,8 @@ br_multicast_leave_group(struct net_brid
struct net_bridge_port *port,
struct br_ip *group,
struct bridge_mcast_other_query *other_query,
@@ -143,7 +140,7 @@
{
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1456,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1457,7 +1482,7 @@ br_multicast_leave_group(struct net_brid
for (pp = mp-ports;
(p = mlock_dereference(*pp, br)) != NULL;
pp = p-next) {
@@ -152,7 +149,7 @@
continue;
rcu_assign_pointer(*pp, p-next);
-@@ -1490,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1491,7 +1516,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp-ports, br);
p != NULL;
p = mlock_dereference(p-next, br)) {
@@ -161,7 +158,7 @@
continue;
if (!hlist_unhashed(p-mglist)
-@@ -1508,8 +1536,8 @@ out:
+@@ -1509,8 +1534,8 @@ out:
static void br_ip4_multicast_leave_group(struct net_bridge *br,
struct net_bridge_port *port,
@@ -172,7 +169,7 @@
{
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1524,14 +1552,14 @@ static void br_ip4_multicast_leave_group
+@@ -1525,14 +1550,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
br_multicast_leave_group(br, port, br_group, br-ip4_other_query,
@@ -189,7 +186,7 @@
{
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1546,7 +1574,7 @@ static void br_ip6_multicast_leave_group
+@@ -1547,7 +1572,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
br_multicast_leave_group(br, port, br_group, br-ip6_other_query,
@@ -198,7 +195,7 @@
}
#endif
-@@ -1555,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1556,6 +1581,7 @@ static int br_multicast_ipv4_rcv(struct
struct
[OpenWrt-Devel] [PATCH 4/4] ipq806x: fix freeze in PCIe code when booting with an old u-boot
Old bootloader (same ones which have DT disabled) don't perform any PCIe
initialization. The consequence is a freeze during PCIe bring-up on
these old u-boot. Same kernel with a newer bootloaders works fine as
they contain the corresponding PCIe init code.
In this change, we'll add the missing init and make sure the kernel
doesn't rely on some preexisting init to get PCIe to work. That includes
the following changes:
*GPIOs: set function drive strength
*Clocks: add init code for aux ref clocks
*PCIe driver: additional init of the hardware controller
Tested 3.18 and 4.1 on an AP148 with bootloader branch 0.0.1
Signed-off-by: Mathieu Olivari math...@codeaurora.org
---
...-qcom-add-pcie-nodes-to-ipq806x-platforms.patch | 23 +-
.../patches-3.18/114-pcie-add-ctlr-init.patch | 278 +
.../patches-3.18/115-add-pcie-aux-clk-dts.patch| 80 ++
...RM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch | 8 +-
...-qcom-add-gmac-nodes-to-ipq806x-platforms.patch | 8 +-
...-qcom-add-pcie-nodes-to-ipq806x-platforms.patch | 23 +-
.../patches-4.1/114-pcie-add-ctlr-init.patch | 278 +
.../patches-4.1/115-add-pcie-aux-clk-dts.patch | 80 ++
...RM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch | 8 +-
...-qcom-add-gmac-nodes-to-ipq806x-platforms.patch | 10 +-
10 files changed, 761 insertions(+), 35 deletions(-)
create mode 100644
target/linux/ipq806x/patches-3.18/114-pcie-add-ctlr-init.patch
create mode 100644
target/linux/ipq806x/patches-3.18/115-add-pcie-aux-clk-dts.patch
create mode 100644
target/linux/ipq806x/patches-4.1/114-pcie-add-ctlr-init.patch
create mode 100644
target/linux/ipq806x/patches-4.1/115-add-pcie-aux-clk-dts.patch
diff --git
a/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
b/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
index bdc91fb..ed66047 100644
---
a/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
+++
b/target/linux/ipq806x/patches-3.18/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
@@ -15,14 +15,15 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
-@@ -35,6 +35,22 @@
+@@ -35,6 +35,24 @@
bias-disable;
};
+ pcie0_pins: pcie0_pinmux {
+ mux {
+ pins = gpio3;
-+ drive-strength = 2;
++ function = pcie1_rst;
++ drive-strength = 12;
+ bias-disable;
+ };
+ };
@@ -30,7 +31,8 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+ pcie1_pins: pcie1_pinmux {
+ mux {
+ pins = gpio48;
-+ drive-strength = 2;
++ function = pcie2_rst;
++ drive-strength = 12;
+ bias-disable;
+ };
+ };
@@ -38,7 +40,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
spi_pins: spi_pins {
mux {
pins = gpio18, gpio19, gpio21;
-@@ -138,5 +154,19 @@
+@@ -138,5 +156,19 @@
usb30@1 {
status = ok;
};
@@ -60,14 +62,15 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
};
--- a/arch/arm/boot/dts/qcom-ipq8064-db149.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-db149.dts
-@@ -30,6 +30,30 @@
+@@ -30,6 +30,33 @@
bias-disable;
};
+ pcie0_pins: pcie0_pinmux {
+ mux {
+ pins = gpio3;
-+ drive-strength = 2;
++ function = pcie1_rst;
++ drive-strength = 12;
+ bias-disable;
+ };
+ };
@@ -75,7 +78,8 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+ pcie1_pins: pcie1_pinmux {
+ mux {
+ pins = gpio48;
-+ drive-strength = 2;
++ function = pcie2_rst;
++ drive-strength = 12;
+ bias-disable;
+ };
+
[OpenWrt-Devel] [PATCH 2/2] ipq806x: add ethernet (stmmac) support
We forgot to enable the stmmac driver for 4.1 kernel, so ethernet interfaces don't show-up on this kernel. Signed-off-by: Mathieu Olivari math...@codeaurora.org --- target/linux/ipq806x/config-4.1 | 5 + 1 file changed, 5 insertions(+) diff --git a/target/linux/ipq806x/config-4.1 b/target/linux/ipq806x/config-4.1 index ffb0334..e3cff2f 100644 --- a/target/linux/ipq806x/config-4.1 +++ b/target/linux/ipq806x/config-4.1 @@ -271,6 +271,7 @@ CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEON=y CONFIG_NET_FLOW_LIMIT=y +CONFIG_NET_PTP_CLASSIFY=y CONFIG_NET_VENDOR_WIZNET=y CONFIG_NO_BOOTMEM=y CONFIG_NO_HZ=y @@ -332,12 +333,14 @@ CONFIG_POWER_RESET=y # CONFIG_POWER_RESET_BRCMSTB is not set CONFIG_POWER_RESET_MSM=y CONFIG_POWER_SUPPLY=y +CONFIG_PPS=y CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_RCU=y CONFIG_PRINTK_TIME=y CONFIG_PROC_PAGE_MONITOR=y +CONFIG_PTP_1588_CLOCK=y CONFIG_QCOM_BAM_DMA=y CONFIG_QCOM_GSBI=y CONFIG_QCOM_HFPLL=y @@ -379,6 +382,8 @@ CONFIG_SPI_QUP=y CONFIG_SPMI=y CONFIG_SPMI_MSM_PMIC_ARB=y CONFIG_SRCU=y +CONFIG_STMMAC_ETH=y +CONFIG_STMMAC_PLATFORM=y CONFIG_STOP_MACHINE=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_SUSPEND=y -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2 netifd 1/3] bridge: Fix multicast_to_unicast feature by hairpin+isolate
All IGMP and MLD versions suffer from a specific limitation (from a
snooping switch perspective): Report suppression.
Once a listener hears an IGMPv2/3 or MLDv1 report for the same group
itself participates in then it might (if this listener is an IGMPv3 or
MLDv2 listener) or will (if this is an IGMPv1/2 or MLDv1 listener)
refrain from sending its own report.
Therefore we might currently miss such surpressing listeners as they
won't receive the multicast packet with the mangled, unicasted
destination.
Fixing this by first isolating the STAs and giving the bridge more
control over traffic forwarding. E.g. refraining to forward listener
reports to other STAs.
For broadcast and unicast traffic to an STA on the same AP, the hairpin
feature of the bridge will reflect such traffic back to the AP
interface. However, if the AP interface is actually configured to
isolate STAs, then hairpin is kept disabled.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
device.h |1 +
system-linux.c | 26 --
wireless.c | 12 +++-
wireless.h |1 +
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/device.h b/device.h
index ce135ba..373445c 100644
--- a/device.h
+++ b/device.h
@@ -173,6 +173,7 @@ struct device {
bool iface_config;
bool default_config;
bool wireless;
+ bool wireless_isolate;
struct interface *config_iface;
diff --git a/system-linux.c b/system-linux.c
index 9ba13fd..9c4bea6 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -315,6 +315,16 @@ static void system_set_dadtransmits(struct device *dev,
const char *val)
system_set_dev_sysctl(/proc/sys/net/ipv6/conf/%s/dad_transmits,
dev-ifname, val);
}
+static void system_bridge_set_multicast_to_unicast(struct device *dev, const
char *val)
+{
+ system_set_dev_sysctl(/sys/class/net/%s/brport/multicast_to_unicast,
dev-ifname, val);
+}
+
+static void system_bridge_set_hairpin_mode(struct device *dev, const char *val)
+{
+ system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode,
dev-ifname, val);
+}
+
static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
{
int fd = -1, ret = -1;
@@ -556,12 +566,16 @@ static char *system_get_bridge(const char *name, char
*buf, int buflen)
return path + 1;
}
-static void system_bridge_set_wireless(const char *bridge, const char *dev)
+static void
+system_bridge_set_wireless(struct device *dev)
{
- snprintf(dev_buf, sizeof(dev_buf),
-/sys/devices/virtual/net/%s/brif/%s/multicast_to_unicast,
-bridge, dev);
- system_set_sysctl(dev_buf, 1);
+ bool hairpin = true;
+
+ if (dev-wireless_isolate)
+ hairpin = false;
+
+ system_bridge_set_multicast_to_unicast(dev, 1);
+ system_bridge_set_hairpin_mode(dev, hairpin ? 1 : 0);
}
int system_bridge_addif(struct device *bridge, struct device *dev)
@@ -574,7 +588,7 @@ int system_bridge_addif(struct device *bridge, struct
device *dev)
ret = system_bridge_if(bridge-ifname, dev, SIOCBRADDIF, NULL);
if (dev-wireless)
- system_bridge_set_wireless(bridge-ifname, dev-ifname);
+ system_bridge_set_wireless(dev);
return ret;
}
diff --git a/wireless.c b/wireless.c
index fbd6191..337f563 100644
--- a/wireless.c
+++ b/wireless.c
@@ -35,12 +35,14 @@ static const struct uci_blob_param_list wdev_param = {
enum {
VIF_ATTR_DISABLED,
VIF_ATTR_NETWORK,
+ VIF_ATTR_ISOLATE,
__VIF_ATTR_MAX,
};
static const struct blobmsg_policy vif_policy[__VIF_ATTR_MAX] = {
[VIF_ATTR_DISABLED] = { .name = disabled, .type = BLOBMSG_TYPE_BOOL },
[VIF_ATTR_NETWORK] = { .name = network, .type = BLOBMSG_TYPE_ARRAY },
+ [VIF_ATTR_ISOLATE] = { .name = isolate, .type = BLOBMSG_TYPE_BOOL },
};
static const struct uci_blob_param_list vif_param = {
@@ -204,8 +206,10 @@ static void wireless_interface_handle_link(struct
wireless_interface *vif, bool
if (up) {
struct device *dev = device_get(vif-ifname, 2);
- if (dev)
+ if (dev) {
+ dev-wireless_isolate = vif-isolate;
dev-wireless = true;
+ }
}
blobmsg_for_each_attr(cur, vif-network, rem) {
@@ -700,6 +704,12 @@ void wireless_interface_create(struct wireless_device
*wdev, struct blob_attr *d
vif-wdev = wdev;
vif-config = data;
vif-section = section;
+ vif-isolate = false;
+
+ cur = tb[VIF_ATTR_ISOLATE];
+ if (cur blobmsg_get_bool(cur))
+ vif-isolate = blobmsg_get_bool(cur);
+
vlist_add(wdev-interfaces, vif-node, vif-name);
}
diff --git a/wireless.h b/wireless.h
index c5dbb88..476c63e 100644
--- a/wireless.h
+++ b/wireless.h
@@ -77,6 +77,7 @@ struct wireless_interface {
const char *ifname;
[OpenWrt-Devel] [PATCHv2] Fixes regarding bridge multicast-to-unicast feature
Hi, Here are a few patches to fix the issues the multicast-to-unicast feature of the bridge has: IGMP/MLD report suppression could lead to multicast packet loss. Also see ticket #17625 [0]. As previously discussed on this mailing list, AP-isolation together with bridge-hairpinning is a way to make the multicast-to-unicast feature usable even if listeners potentially suppressing reports are present: That way the bridge will get all reports and will have full control on where to forward them. For instance *not* to other STAs (unless there is a multicast router). Furthermore [PATCH netifd 2/3] introduces a netifd option to disable the multicast-to-unicast feature. [PATCH netifd 3/3] is not related to this issue but introduces a handy option (which I would like to make use of for IGMP/MLD domain segmentation). The OpenWRT specific patches should be applied after the netifd patches arrived in OpenWRT. Cheers, Linus [0]: https://dev.openwrt.org/ticket/17625 ~~~ Changelog v2: * Separated introduction of multicast_to_unicast configuration option in separate patch * passing multicast_to_unicast to netifd scripts via json from netifd instead of external uci command calls * Moved multicast_to_unicast uci option to be a bridge instead of bridge member option ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] ipq806x: add support for non-dt enabled ap148 bootloader
Certain AP148 platforms (and derivative) use bootloaders which did not
have DT enabled.
In order to support these old platforms, we'll now make the following
modifications:
*explicitely add the memory node in the AP148 DT: this used to be added
by new u-boot through a run-time patch mechanism. We'll now add it
explicitely so it works on boots which don't support that feature. New
boots will have the node twice, the second one will be ignored.
*add the zImage generation next to the FIT image for AP148.
Other platforms using non-DT enabled bootloaders may want to leverage
this zImage code to generate their own firmare as well.
Signed-off-by: Mathieu Olivari math...@codeaurora.org
---
target/linux/ipq806x/image/Makefile| 10 ++
.../ipq806x/patches-3.18/024-ap148-add-memory-node.patch | 14 ++
.../ipq806x/patches-4.1/024-ap148-add-memory-node.patch| 14 ++
...-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch | 4 ++--
...-dts-qcom-Add-necessary-DT-data-for-Krait-cpufreq.patch | 4 ++--
.../707-ARM-dts-qcom-add-mdio-nodes-to-ap148-db149.patch | 6 +++---
...-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch | 4 ++--
7 files changed, 47 insertions(+), 9 deletions(-)
create mode 100644
target/linux/ipq806x/patches-3.18/024-ap148-add-memory-node.patch
create mode 100644
target/linux/ipq806x/patches-4.1/024-ap148-add-memory-node.patch
diff --git a/target/linux/ipq806x/image/Makefile
b/target/linux/ipq806x/image/Makefile
index 9a1bad8..99e9811 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -8,6 +8,15 @@ UBINIZE_OPTS = -m 2048 -p 128KiB
E2SIZE=$(shell echo $$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024)))
+define Image/BuildKernel/zImage
+ cat $(KDIR)/zImage $(LINUX_DIR)/arch/arm/boot/dts/$(1).dtb
$(KDIR)/zImage-$(1)
+ $(CP) $(KDIR)/zImage-$(1) $(BIN_DIR)/$(IMG_PREFIX)-$(1)-zImage
+ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
+ cat $(KDIR)/zImage-initramfs $(LINUX_DIR)/arch/arm/boot/dts/$(1).dtb
$(KDIR)/zImage-initramfs-$(1)
+ $(CP) $(KDIR)/zImage-initramfs-$(1)
$(BIN_DIR)/$(IMG_PREFIX)-$(1)-zImage-initramfs
+endif
+endef
+
define Image/BuildKernel/FIT
gzip -9n -c $(KDIR)/Image $(KDIR)/Image.gz
$(call CompressLzma,$(KDIR)/Image,$(KDIR)/Image.gz)
@@ -26,6 +35,7 @@ endef
define Image/BuildKernel
$(CP) $(KDIR)/$(IMG_PREFIX)-vmlinux.elf $(BIN_DIR)
$(call Image/BuildKernel/FIT,qcom-ipq8064-ap148)
+ $(call Image/BuildKernel/zImage,qcom-ipq8064-ap148)
$(call Image/BuildKernel/FIT,qcom-ipq8064-db149)
endef
diff --git a/target/linux/ipq806x/patches-3.18/024-ap148-add-memory-node.patch
b/target/linux/ipq806x/patches-3.18/024-ap148-add-memory-node.patch
new file mode 100644
index 000..f026ed9
--- /dev/null
+++ b/target/linux/ipq806x/patches-3.18/024-ap148-add-memory-node.patch
@@ -0,0 +1,14 @@
+--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+@@ -4,6 +4,11 @@
+ model = Qualcomm IPQ8064/AP148;
+ compatible = qcom,ipq8064-ap148, qcom,ipq8064;
+
++ memory@0 {
++ reg = 0x4200 0x1e00;
++ device_type = memory;
++ };
++
+ reserved-memory {
+ #address-cells = 1;
+ #size-cells = 1;
diff --git a/target/linux/ipq806x/patches-4.1/024-ap148-add-memory-node.patch
b/target/linux/ipq806x/patches-4.1/024-ap148-add-memory-node.patch
new file mode 100644
index 000..f026ed9
--- /dev/null
+++ b/target/linux/ipq806x/patches-4.1/024-ap148-add-memory-node.patch
@@ -0,0 +1,14 @@
+--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+@@ -4,6 +4,11 @@
+ model = Qualcomm IPQ8064/AP148;
+ compatible = qcom,ipq8064-ap148, qcom,ipq8064;
+
++ memory@0 {
++ reg = 0x4200 0x1e00;
++ device_type = memory;
++ };
++
+ reserved-memory {
+ #address-cells = 1;
+ #size-cells = 1;
diff --git
a/target/linux/ipq806x/patches-4.1/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
b/target/linux/ipq806x/patches-4.1/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
index e7de2bb..e494d32 100644
---
a/target/linux/ipq806x/patches-4.1/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
+++
b/target/linux/ipq806x/patches-4.1/112-ARM-dts-qcom-add-pcie-nodes-to-ipq806x-platforms.patch
@@ -15,7 +15,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
-@@ -30,6 +30,22 @@
+@@ -35,6 +35,22 @@
bias-disable;
};
@@ -38,7 +38,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
spi_pins: spi_pins {
mux {
pins
[OpenWrt-Devel] [PATCH 1/2] ipq806x: refresh kernel configs
Remove options which have been moved into the generic config ever since. Signed-off-by: Mathieu Olivari math...@codeaurora.org --- target/linux/ipq806x/config-3.18 | 1 - target/linux/ipq806x/config-4.1 | 12 2 files changed, 13 deletions(-) diff --git a/target/linux/ipq806x/config-3.18 b/target/linux/ipq806x/config-3.18 index 4d3b884..f5bd58e 100644 --- a/target/linux/ipq806x/config-3.18 +++ b/target/linux/ipq806x/config-3.18 @@ -410,7 +410,6 @@ CONFIG_WATCHDOG_CORE=y # CONFIG_WIZNET_W5300 is not set # CONFIG_WL_TI is not set # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set -# CONFIG_XEN is not set CONFIG_XPS=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_BCJ=y diff --git a/target/linux/ipq806x/config-4.1 b/target/linux/ipq806x/config-4.1 index e80b632..ffb0334 100644 --- a/target/linux/ipq806x/config-4.1 +++ b/target/linux/ipq806x/config-4.1 @@ -4,7 +4,6 @@ CONFIG_ALIGNMENT_TRAP=y CONFIG_APQ_GCC_8084=y CONFIG_APQ_MMCC_8084=y CONFIG_AR8216_PHY=y -# CONFIG_ARCH_ALPINE is not set CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y CONFIG_ARCH_HAS_ELF_RANDOMIZE=y CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y @@ -243,8 +242,6 @@ CONFIG_KRAIT_L2_ACCESSORS=y CONFIG_LIBFDT=y CONFIG_LOCKUP_DETECTOR=y CONFIG_LOCK_SPIN_ON_OWNER=y -# CONFIG_LZ4_COMPRESS is not set -# CONFIG_LZ4_DECOMPRESS is not set CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_MDIO_BITBANG=y @@ -316,7 +313,6 @@ CONFIG_PHYLIB=y CONFIG_PHY_QCOM_IPQ806X_SATA=y # CONFIG_PHY_QCOM_UFS is not set CONFIG_PINCTRL=y -# CONFIG_PINCTRL_AMD is not set CONFIG_PINCTRL_APQ8064=y # CONFIG_PINCTRL_APQ8084 is not set CONFIG_PINCTRL_IPQ8064=y @@ -334,12 +330,7 @@ CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_POWER_RESET=y # CONFIG_POWER_RESET_BRCMSTB is not set -# CONFIG_POWER_RESET_GPIO is not set -# CONFIG_POWER_RESET_GPIO_RESTART is not set -# CONFIG_POWER_RESET_LTC2952 is not set CONFIG_POWER_RESET_MSM=y -# CONFIG_POWER_RESET_SYSCON is not set -# CONFIG_POWER_RESET_SYSCON_POWEROFF is not set CONFIG_POWER_SUPPLY=y CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y @@ -352,11 +343,9 @@ CONFIG_QCOM_GSBI=y CONFIG_QCOM_HFPLL=y CONFIG_QCOM_SCM=y CONFIG_QCOM_WDT=y -# CONFIG_QORIQ_CPUFREQ is not set CONFIG_RAS=y # CONFIG_RCU_BOOST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=21 -# CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RD_GZIP=y CONFIG_REGMAP=y @@ -427,7 +416,6 @@ CONFIG_WATCHDOG_CORE=y # CONFIG_WIZNET_W5300 is not set # CONFIG_WL_TI is not set # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set -# CONFIG_XEN is not set CONFIG_XPS=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_BCJ=y -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 3-address Wi-Fi bridging (was: Multiple Wi-Fi client/AP interfaces on one radio)
On 4 August 2015 at 23:24, Joshua Judson Rosen jro...@harvestai.com wrote: On 2015-08-04 14:14, Roman Yeryomin wrote: On 4 August 2015 at 17:58, Joshua Judson Rosen jro...@harvestai.com wrote: On 2015-08-04 02:26, David Lang wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. This is not necessarily true: with at least some hardware/drivers, it's possible to create multiple virtual interfaces on top of a single radio-- and separate virtual interfaces can in fact operate in different modes (e.g.: one in STA mode, two in AP mode, one in mesh mode...). Assuming that your hardware/driver is capable of supporting multiple virtual interfaces on top of the single physical radio, you can create these interfaces by adding wifi-iface stanzas in /etc/config/wireless, e.g: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' That creates two virtual interfaces using the same physical radio, and bridges them together onto the OpenWrt lan network (which is itself defined in /etc/config/network). I believe you could also have an interface with mode 'sta', but note that it would also need to use the same channel as the other interfaces-- which means that the external AP to which you connect it would also need to use that same channel (11, in the example above). That's where having multiple *radios* helps: you can run them on different frequencies (either completely different bands [2.4 GHz vs. 5 GHz], or on different channels within the same band [e.g. 2.427 GHz = channel 4 vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing less data over a single radio, or to increase compatibility with other APs outside of your control that you might want to connect to. Also note that, if you want to bridge a STA interface onto anything else, it'll need to be in WDS mode _and_ the the AP to which it's connecting will also need to be in WDS mode (note the option wds '1', in my example above), because the standard 3-address mode of Wi-Fi isn't bridgeable (and note that WDS 4-address mode is bridgeable, but not standardised across different platforms--so you're probably OK so long as all of your equipment is running Linux and using the same Wi-Fi driver, but don't expect to bridge a STA interface that's connected non-Linux Wi-Fi router). At least, I've seen this work with Atheros chips. There are some notes in the wiki about how Broadcom chips have their own, different solution implemented in hardware; and about how some drivers don't support this stuff at all Actually 3-address mode bridging is possible with the help of relayd That's not actually 3-address mode bridging, though-- it's relaying (done entirely through a userspace daemon, which AFAICT actually relays only IPv4, ARP, and DHCP packets). OK, yes technically it's not bridging :) and it even works quite good. But there is an issue (also mentioned in a parallel thread): when client interface cannot connect then AP interface doesn't come up also. Which may not be a problem unless you want to bridge ethernet there also. On the other hand you may not be able to switch the main AP into 4-address mode so relayd is a way out. It may be a solution. When I tried it a few months back (in Barrier Breaker), relayd wasn't really working for me I know that's a terrible (non-)description; I don't specifically remember what seemed to be going wrong, except that there was a lot of traffic not reliably getting through to where it was supposed to, and that it was confusing, and that I was able to slightly improve the situation by fiddling with some of the options that the init-script passed to relayd (IIRC, I had some success using -I on only one interface and -i on the other), but I didn't have time to dig in and actually understand what wasn't working--just switching to 4-address mode and having OpenWrt set up a kernel-level bridge w/ brctl was a more expedient path for me to get something working reliably
[OpenWrt-Devel] [PATCHv2 netifd 2/3] bridge: Allow setting multicast_to_unicast option
With this patch the multicast_to_unicast feature can be disabled for all
wireless interfaces via an according option on the uci bridge interface.
This patch also exports the setting information to wireless handler
scripts. The hostapd script will need that information to determine
whether to enable or disable ap-isolation, for instance.
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
device.c |9 +
device.h |3 +++
scripts/netifd-wireless.sh |1 +
system-linux.c | 13 +
wireless.c |4
5 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/device.c b/device.c
index b5bee11..b44ccb8 100644
--- a/device.c
+++ b/device.c
@@ -48,6 +48,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX]
= {
[DEV_ATTR_RPS] = { .name = rps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = dadtransmits, .type =
BLOBMSG_TYPE_INT32 },
+ [DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast,
.type = BLOBMSG_TYPE_BOOL },
};
const struct uci_blob_param_list device_attr_list = {
@@ -174,6 +175,7 @@ device_merge_settings(struct device *dev, struct
device_settings *n)
s-neigh6reachabletime : os-neigh6reachabletime;
n-dadtransmits = s-flags DEV_OPT_DADTRANSMITS ?
s-dadtransmits : os-dadtransmits;
+ n-multicast_to_unicast = s-multicast_to_unicast;
n-flags = s-flags | os-flags;
}
@@ -274,6 +276,11 @@ device_init_settings(struct device *dev, struct blob_attr
**tb)
s-flags |= DEV_OPT_DADTRANSMITS;
}
+ if ((cur = tb[DEV_ATTR_MULTICAST_TO_UNICAST])) {
+ s-multicast_to_unicast = blobmsg_get_bool(cur);
+ s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
+ }
+
device_set_disabled(dev, disabled);
}
@@ -884,6 +891,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
}
if (st.flags DEV_OPT_DADTRANSMITS)
blobmsg_add_u32(b, dadtransmits, st.dadtransmits);
+ if (st.flags DEV_OPT_MULTICAST_TO_UNICAST)
+ blobmsg_add_u8(b, multicast_to_unicast,
st.multicast_to_unicast);
}
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 373445c..4344d8a 100644
--- a/device.h
+++ b/device.h
@@ -42,6 +42,7 @@ enum {
DEV_ATTR_RPS,
DEV_ATTR_XPS,
DEV_ATTR_DADTRANSMITS,
+ DEV_ATTR_MULTICAST_TO_UNICAST,
__DEV_ATTR_MAX,
};
@@ -84,6 +85,7 @@ enum {
DEV_OPT_XPS = (1 11),
DEV_OPT_MTU6= (1 12),
DEV_OPT_DADTRANSMITS= (1 13),
+ DEV_OPT_MULTICAST_TO_UNICAST= (1 14),
};
/* events broadcasted to all users of a device */
@@ -141,6 +143,7 @@ struct device_settings {
bool rps;
bool xps;
unsigned int dadtransmits;
+ bool multicast_to_unicast;
};
/*
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index c5d8a96..4d81929 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -260,6 +260,7 @@ for_each_interface() {
json_select $_w_iface
if [ -n $_w_types ]; then
json_get_var network_bridge bridge
+ json_get_var multicast_to_unicast multicast_to_unicast
json_select config
json_get_var _w_type mode
json_select ..
diff --git a/system-linux.c b/system-linux.c
index 9c4bea6..944245c 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -567,14 +567,19 @@ static char *system_get_bridge(const char *name, char
*buf, int buflen)
}
static void
-system_bridge_set_wireless(struct device *dev)
+system_bridge_set_wireless(struct device *bridge, struct device *dev)
{
+ bool mcast_to_ucast = true;
bool hairpin = true;
- if (dev-wireless_isolate)
+ if (bridge-settings.flags DEV_OPT_MULTICAST_TO_UNICAST
+ !bridge-settings.multicast_to_unicast)
+ mcast_to_ucast = false;
+
+ if (!mcast_to_ucast || dev-wireless_isolate)
hairpin = false;
- system_bridge_set_multicast_to_unicast(dev, 1);
+ system_bridge_set_multicast_to_unicast(dev, mcast_to_ucast ? 1 : 0);
system_bridge_set_hairpin_mode(dev, hairpin ? 1 : 0);
}
@@ -588,7 +593,7 @@ int system_bridge_addif(struct device *bridge, struct
device *dev)
ret = system_bridge_if(bridge-ifname, dev, SIOCBRADDIF, NULL);
if (dev-wireless)
- system_bridge_set_wireless(dev);
+ system_bridge_set_wireless(bridge, dev);
return ret;
}
diff --git a/wireless.c b/wireless.c
index 337f563..d0d2942 100644
--- a/wireless.c
+++
Re: [OpenWrt-Devel] [PATCH 3/4] ipq806x: fix pcie pinmux naming in ipq806x dts
Rah; sorry about that, it happens fairly often actually. I reworked the
patch list a couple of times and I thought I tried it after the last one.
Thanks for the fix.
-Original Message-
From: Felix Fietkau [mailto:n...@openwrt.org]
Sent: Tuesday, August 04, 2015 4:05 PM
To: Mathieu Olivari; j...@openwrt.org; blo...@openwrt.org
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [PATCH 3/4] ipq806x: fix pcie pinmux naming in ipq806x dts
On 2015-08-04 23:55, Mathieu Olivari wrote:
PCIe controller nodes are numbers 0/1/2 in the chipset dtsi file, but
the pinmux nodes are numbers 1/2/3. We'll make it consistent by
changing the pinmux numbering to match the controller's one.
Signed-off-by: Mathieu Olivari math...@codeaurora.org
---
diff --git
a/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-nodes-to
-ipq806x-platforms.patch
b/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-nodes-to
-ipq806x-platforms.patch
index cce30b0..8d6e77a 100644
---
a/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-nodes-to
-ipq806x-platforms.patch
+++ b/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-node
+++ s-to-ipq806x-platforms.patch
@@ -12,7 +12,7 @@ Signed-off-by: Mathieu Olivari
math...@codeaurora.org
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
-@@ -64,6 +64,16 @@
+@@ -69,6 +69,16 @@
bias-disable;
};
};
@@ -29,7 +29,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
};
gsbi@1630 {
-@@ -201,5 +211,26 @@
+@@ -206,5 +216,26 @@
reg = 4;
};
};
@@ -116,9 +116,9 @@ Signed-off-by: Mathieu Olivari
math...@codeaurora.org
};
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
-@@ -638,5 +638,91 @@
- dr_mode = host;
- };
+@@ -87,6 +87,92 @@
+ clock-frequency = 32768;
+ #clock-cells = 0;
};
+
+nss_common: syscon@0300 {
@@ -207,4 +207,5 @@ Signed-off-by: Mathieu Olivari
math...@codeaurora.org
+status = disabled;
+};
};
- };
+
+ kraitcc: clock-controller {
FYI, this part completely messed up the patch, as it moved the gmac device
tree nodes from /soc to /clocks. I've fixed it up locally and I will commit
the fixed version.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multiple Wi-Fi client/AP interfaces on one radio (was: Change OpenWrt Wifi default settings)
On 4 August 2015 at 17:58, Joshua Judson Rosen jro...@harvestai.com wrote: On 2015-08-04 02:26, David Lang wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. This is not necessarily true: with at least some hardware/drivers, it's possible to create multiple virtual interfaces on top of a single radio-- and separate virtual interfaces can in fact operate in different modes (e.g.: one in STA mode, two in AP mode, one in mesh mode...). Assuming that your hardware/driver is capable of supporting multiple virtual interfaces on top of the single physical radio, you can create these interfaces by adding wifi-iface stanzas in /etc/config/wireless, e.g: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' That creates two virtual interfaces using the same physical radio, and bridges them together onto the OpenWrt lan network (which is itself defined in /etc/config/network). I believe you could also have an interface with mode 'sta', but note that it would also need to use the same channel as the other interfaces-- which means that the external AP to which you connect it would also need to use that same channel (11, in the example above). That's where having multiple *radios* helps: you can run them on different frequencies (either completely different bands [2.4 GHz vs. 5 GHz], or on different channels within the same band [e.g. 2.427 GHz = channel 4 vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing less data over a single radio, or to increase compatibility with other APs outside of your control that you might want to connect to. Also note that, if you want to bridge a STA interface onto anything else, it'll need to be in WDS mode _and_ the the AP to which it's connecting will also need to be in WDS mode (note the option wds '1', in my example above), because the standard 3-address mode of Wi-Fi isn't bridgeable (and note that WDS 4-address mode is bridgeable, but not standardised across different platforms--so you're probably OK so long as all of your equipment is running Linux and using the same Wi-Fi driver, but don't expect to bridge a STA interface that's connected non-Linux Wi-Fi router). At least, I've seen this work with Atheros chips. There are some notes in the wiki about how Broadcom chips have their own, different solution implemented in hardware; and about how some drivers don't support this stuff at all Actually 3-address mode bridging is possible with the help of relayd and it even works quite good. But there is an issue (also mentioned in a parallel thread): when client interface cannot connect then AP interface doesn't come up also. Which may not be a problem unless you want to bridge ethernet there also. On the other hand you may not be able to switch the main AP into 4-address mode so relayd is a way out. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Restore AP scan patch
On 3 August 2015 at 15:11, openwrt-de...@couprie.net openwrt-de...@couprie.net wrote: Hi Dimitry, Does this patch, fix the problem that when a router is a wifi access client and access point. The local access point does not work when de wifi access client is not connected ? This patch only fixes scanning when in AP mode. The problem you are referring to is different and I'm not sure it can be fixed in the right way. Try using 4address mode (aka WDS in hostapd terms). Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 3-address Wi-Fi bridging (was: Multiple Wi-Fi client/AP interfaces on one radio)
On 2015-08-04 14:14, Roman Yeryomin wrote: On 4 August 2015 at 17:58, Joshua Judson Rosen jro...@harvestai.com wrote: On 2015-08-04 02:26, David Lang wrote: A given radio can be either an AP or a client, but not both at once. so if you use a radio to connect to another AP, you are making it a client, and in client mode all it can do is connect to that other AP as shows up as the SSID of that other AP. you can do this with one radio, while using the other radio (assuming you have two) to act as an AP for local clients. This is not necessarily true: with at least some hardware/drivers, it's possible to create multiple virtual interfaces on top of a single radio-- and separate virtual interfaces can in fact operate in different modes (e.g.: one in STA mode, two in AP mode, one in mesh mode...). Assuming that your hardware/driver is capable of supporting multiple virtual interfaces on top of the single physical radio, you can create these interfaces by adding wifi-iface stanzas in /etc/config/wireless, e.g: config wifi-device 'radio0' option type 'mac80211' option channel '11' option hwmode '11g' option path 'platform/ar933x_wmac' option htmode 'HT20' option country 'US' option txpower '20' config wifi-iface 'ap1' option device 'radio0' option mode 'ap' option wds '1' option ssid 'my AP' option network 'lan' config wifi-iface 'mesh1' option device 'radio0' option mode 'mesh' option mesh_id 'my mesh' option network 'lan' That creates two virtual interfaces using the same physical radio, and bridges them together onto the OpenWrt lan network (which is itself defined in /etc/config/network). I believe you could also have an interface with mode 'sta', but note that it would also need to use the same channel as the other interfaces-- which means that the external AP to which you connect it would also need to use that same channel (11, in the example above). That's where having multiple *radios* helps: you can run them on different frequencies (either completely different bands [2.4 GHz vs. 5 GHz], or on different channels within the same band [e.g. 2.427 GHz = channel 4 vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing less data over a single radio, or to increase compatibility with other APs outside of your control that you might want to connect to. Also note that, if you want to bridge a STA interface onto anything else, it'll need to be in WDS mode _and_ the the AP to which it's connecting will also need to be in WDS mode (note the option wds '1', in my example above), because the standard 3-address mode of Wi-Fi isn't bridgeable (and note that WDS 4-address mode is bridgeable, but not standardised across different platforms--so you're probably OK so long as all of your equipment is running Linux and using the same Wi-Fi driver, but don't expect to bridge a STA interface that's connected non-Linux Wi-Fi router). At least, I've seen this work with Atheros chips. There are some notes in the wiki about how Broadcom chips have their own, different solution implemented in hardware; and about how some drivers don't support this stuff at all Actually 3-address mode bridging is possible with the help of relayd That's not actually 3-address mode bridging, though-- it's relaying (done entirely through a userspace daemon, which AFAICT actually relays only IPv4, ARP, and DHCP packets). and it even works quite good. But there is an issue (also mentioned in a parallel thread): when client interface cannot connect then AP interface doesn't come up also. Which may not be a problem unless you want to bridge ethernet there also. On the other hand you may not be able to switch the main AP into 4-address mode so relayd is a way out. It may be a solution. When I tried it a few months back (in Barrier Breaker), relayd wasn't really working for me I know that's a terrible (non-)description; I don't specifically remember what seemed to be going wrong, except that there was a lot of traffic not reliably getting through to where it was supposed to, and that it was confusing, and that I was able to slightly improve the situation by fiddling with some of the options that the init-script passed to relayd (IIRC, I had some success using -I on only one interface and -i on the other), but I didn't have time to dig in and actually understand what wasn't working--just switching to 4-address mode and having OpenWrt set up a kernel-level bridge w/ brctl was a more expedient path for me to get something working reliably at the time. Actually, if anyone can offer guesses as to what my issues with relayd might have actually been, I'd be glad to hear them
Re: [OpenWrt-Devel] [PATCH 3/4] ipq806x: fix pcie pinmux naming in ipq806x dts
On 2015-08-04 23:55, Mathieu Olivari wrote:
PCIe controller nodes are numbers 0/1/2 in the chipset dtsi file, but
the pinmux nodes are numbers 1/2/3. We'll make it consistent by changing
the pinmux numbering to match the controller's one.
Signed-off-by: Mathieu Olivari math...@codeaurora.org
---
diff --git
a/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch
b/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch
index cce30b0..8d6e77a 100644
---
a/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch
+++
b/target/linux/ipq806x/patches-3.18/708-ARM-dts-qcom-add-gmac-nodes-to-ipq806x-platforms.patch
@@ -12,7 +12,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
-@@ -64,6 +64,16 @@
+@@ -69,6 +69,16 @@
bias-disable;
};
};
@@ -29,7 +29,7 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
};
gsbi@1630 {
-@@ -201,5 +211,26 @@
+@@ -206,5 +216,26 @@
reg = 4;
};
};
@@ -116,9 +116,9 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
};
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
-@@ -638,5 +638,91 @@
- dr_mode = host;
- };
+@@ -87,6 +87,92 @@
+ clock-frequency = 32768;
+ #clock-cells = 0;
};
+
+nss_common: syscon@0300 {
@@ -207,4 +207,5 @@ Signed-off-by: Mathieu Olivari math...@codeaurora.org
+status = disabled;
+};
};
- };
+
+ kraitcc: clock-controller {
FYI, this part completely messed up the patch, as it moved the gmac
device tree nodes from /soc to /clocks. I've fixed it up locally and I
will commit the fixed version.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
