Re: [OpenWrt-Devel] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread John Crispin 
Hi,

On 27/01/2015 03:49, Matthias Schiffer wrote:
 In larger networks, especially big batman-adv meshes, it may be desirable to
 enable IGMP snooping on every bridge without enabling the multicast querier
 to specifically put the querier on a well-connected node.
 
 This patch adds a new UCI option 'multicast_querier' for bridges which allows
 this. The default is still the value of the 'igmp_snooping' option to maintain
 backwards compatiblity.
 

per-se a good patch but its not reentrant


 Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
 ---
  bridge.c   | 8 +++-
  system-linux.c | 2 +-
  system.h   | 1 +
  3 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/bridge.c b/bridge.c
 index f8478ad..f7dbf61 100644
 --- a/bridge.c
 +++ b/bridge.c
 @@ -32,6 +32,7 @@ enum {
   BRIDGE_ATTR_HELLO_TIME,
   BRIDGE_ATTR_MAX_AGE,
   BRIDGE_ATTR_BRIDGE_EMPTY,
 + BRIDGE_ATTR_MULTICAST_QUERIER,
   __BRIDGE_ATTR_MAX
  };
  
 @@ -45,6 +46,7 @@ static const struct blobmsg_policy 
 bridge_attrs[__BRIDGE_ATTR_MAX] = {
   [BRIDGE_ATTR_MAX_AGE] = { max_age, BLOBMSG_TYPE_INT32 },
   [BRIDGE_ATTR_IGMP_SNOOP] = { igmp_snooping, BLOBMSG_TYPE_BOOL },
   [BRIDGE_ATTR_BRIDGE_EMPTY] = { bridge_empty, BLOBMSG_TYPE_BOOL },
 + [BRIDGE_ATTR_MULTICAST_QUERIER] = { multicast_querier, 
 BLOBMSG_TYPE_BOOL },
  };
  
  static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] 
 = {
 @@ -547,6 +549,7 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
   cfg-stp = false;
   cfg-forward_delay = 2;
   cfg-igmp_snoop = true;
 + cfg-multicast_querier = true;
   cfg-bridge_empty = false;
   cfg-priority = 0x7FFF;
  
 @@ -560,7 +563,10 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
   cfg-priority = blobmsg_get_u32(cur);
  
   if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP]))
 - cfg-igmp_snoop = blobmsg_get_bool(cur);
 + cfg-multicast_querier = cfg-igmp_snoop = 
 blobmsg_get_bool(cur);

i make 1 ubus call and set multicast_querier=0 and then a 2nd call and
set igmp_snoop=1 this will break my prior call.

dont change the above line and then 

 +
 + if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
 + cfg-multicast_querier = blobmsg_get_bool(cur);
  
   if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) {
   cfg-ageing_time = blobmsg_get_u32(cur);
 diff --git a/system-linux.c b/system-linux.c
 index 4737fa6..ef90880 100644
 --- a/system-linux.c
 +++ b/system-linux.c
 @@ -772,7 +772,7 @@ int system_bridge_addbr(struct device *bridge, struct 
 bridge_config *cfg)
   bridge-ifname, cfg-igmp_snoop ? 1 : 0);
  
   
 system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,
 - bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 + bridge-ifname, cfg-multicast_querier ? 1 : 0);
  

change this to

bridge-ifname, (cfg-igmp_snoop  cfg-multicast_querier) ? 1 : 0);

this should not break anything with multiple ubus calls. the default
behavior also wont change as we set cfg-multicast_querier = true;

Please make those changes to the patch and resend it.





   args[0] = BRCTL_SET_BRIDGE_PRIORITY;
   args[1] = cfg-priority;
 diff --git a/system.h b/system.h
 index 9a2326b..94e0dd9 100644
 --- a/system.h
 +++ b/system.h
 @@ -50,6 +50,7 @@ struct bridge_config {
   enum bridge_opt flags;
   bool stp;
   bool igmp_snoop;
 + bool multicast_querier;
   unsigned short priority;
   int forward_delay;
   bool bridge_empty;
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread Matthias Schiffer 
On 01/28/2015 01:59 PM, John Crispin wrote:
 
 
 On 27/01/2015 03:49, Matthias Schiffer wrote:
 In larger networks, especially big batman-adv meshes, it may be desirable to
 enable IGMP snooping on every bridge without enabling the multicast querier
 to specifically put the querier on a well-connected node.

 This patch adds a new UCI option 'multicast_querier' for bridges which allows
 this. The default is still the value of the 'igmp_snooping' option to 
 maintain
 backwards compatiblity.

 Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
 ---
  bridge.c   | 8 +++-
  system-linux.c | 2 +-
  system.h   | 1 +
  3 files changed, 9 insertions(+), 2 deletions(-)

 diff --git a/bridge.c b/bridge.c
 index f8478ad..f7dbf61 100644
 
 [...]
 
 
 @@ -560,7 +563,10 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
  cfg-priority = blobmsg_get_u32(cur);
  
  if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP]))
 -cfg-igmp_snoop = blobmsg_get_bool(cur);
 +cfg-multicast_querier = cfg-igmp_snoop = 
 blobmsg_get_bool(cur);
 +
 +if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
 +cfg-multicast_querier = blobmsg_get_bool(cur);
  
 
 how about this ?
 
   if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP]))
   cfg-igmp_snoop = blobmsg_get_bool(cur);
 
   if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
   cfg-multicast_querier = blobmsg_get_bool(cur);
   else
 cfg-multicast_querier = cfg-igmp_snoop;
 
 
 
 
 
This will break when neither igmp_snoop and multicast_querier is set in
a ubus request, it will overwrite the multicast_querier setting with the
previous igmp_snoop setting. I realized that it is not possible to store
all needed cases in two booleans in the bridge_config (in my first
version I didn't think about dynamic reconfiguration at all...)


 
  if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) {
  cfg-ageing_time = blobmsg_get_u32(cur);
 diff --git a/system-linux.c b/system-linux.c
 index 4737fa6..ef90880 100644
 --- a/system-linux.c
 +++ b/system-linux.c
 @@ -772,7 +772,7 @@ int system_bridge_addbr(struct device *bridge, struct 
 bridge_config *cfg)
  bridge-ifname, cfg-igmp_snoop ? 1 : 0);
  
  
 system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,
 -bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 +bridge-ifname, cfg-multicast_querier ? 1 : 0);
  
  args[0] = BRCTL_SET_BRIDGE_PRIORITY;
  args[1] = cfg-priority;
 diff --git a/system.h b/system.h
 index 9a2326b..94e0dd9 100644
 --- a/system.h
 +++ b/system.h
 @@ -50,6 +50,7 @@ struct bridge_config {
  enum bridge_opt flags;
  bool stp;
  bool igmp_snoop;
 +bool multicast_querier;
  unsigned short priority;
  int forward_delay;
  bool bridge_empty;





signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] fstools / always fires 'uci commit' each reboot

2015-01-28 Thread Bastian Bittorf 
we detected a strange problem in our community-network,
which can be tracked down to
'package/system/fstools/files/fstab.default' which is later
installed to '/etc/uci-defaults/10-fstab' including this:

[ ! -f /etc/config/fstab ]  ( block detect  /etc/config/fstab )

in our routers there is always a '/etc/config/fstab', which
means this scripts fails and later during /etc/init.d/boot
an 'uci commit' is fired because of this, see uci_apply_defaults()

the intention is, to do an 'uci commit' because some scripts have
run in /etc/uci-defaults. this is always true when scripts will
not be deleted after firstrun and causes issues here:

we autoupload a cofiguration.tgz, when something had changed in
/etc/config and because we dynamically do some configurations
during bootup with 'uci set ...' there is always an upload
triggered.

the question is here:

1)
can we change that behaviour for this single script?
(delete it during first run).

or

2)
only fire an 'uci commit' when the checksum of /etc/config has changed?

i dont opened a ticket on tracker, because this is not a real bug.

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread Matthias Schiffer 
On 01/28/2015 01:34 PM, John Crispin wrote:
 
 
 On 28/01/2015 13:30, Matthias Schiffer wrote:
 On 01/28/2015 11:54 AM, John Crispin wrote:
 change this to

 bridge-ifname, (cfg-igmp_snoop  cfg-multicast_querier) ? 1
 : 0);

 this should not break anything with multiple ubus calls. the
 default behavior also wont change as we set
 cfg-multicast_querier = true;

 Please make those changes to the patch and resend it.
 Wouldn't it be better to change the possible values of
 multicast_querier to yes, no and unset? That way it could
 always default to the igmp_snoop value when it is unset, but it
 would be possible to override it in both ways.

 
 do you call this by hand or via webui/rpc ?
At the moment, this is compile-tested only. My only usecase is setting
it in /etc/config/network.

Your suggestion would make it impossible to enable the multicast querier
without also enabling snooping. My intention was to allow all four
combinations of snooping on/off and querier on/off, while having the
querier setting default to the snooping setting (so nothing changes for
people who have set igmp_snoop, but not multicast_querier). While I
don't need the case querier on/snooping off, I don't see why we
shouldn't allow it.



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: fix D-Link DIR-615 rev. C1 WLAN MAC address

2015-01-28 Thread Matthias Schiffer 
Fix the WLAN MAC address to match the one printed on the label by using the
correct address from the ART instead of the address of the LAN interface.

Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-dir-615-c1.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-615-c1.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-615-c1.c
index 425be30..e55a43f 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-615-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-615-c1.c
@@ -38,6 +38,8 @@
 #define DIR_615C1_CONFIG_ADDR  0x1f02
 #define DIR_615C1_CONFIG_SIZE  0x1
 
+#define DIR_615C1_WLAN_MAC_ADDR0x1f3fffb4
+
 static struct gpio_led dir_615c1_leds_gpio[] __initdata = {
{
.name   = d-link:orange:status,
@@ -96,16 +98,16 @@ static void __init dir_615c1_setup(void)
 {
const char *config = (char *) KSEG1ADDR(DIR_615C1_CONFIG_ADDR);
u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff1000);
-   u8 mac[6];
-   u8 *wlan_mac = NULL;
+   u8 mac[ETH_ALEN], wlan_mac[ETH_ALEN];
 
if (ath79_nvram_parse_mac_addr(config, DIR_615C1_CONFIG_SIZE,
   lan_mac=, mac) == 0) {
ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
ath79_init_mac(ath79_eth1_data.mac_addr, mac, 1);
-   wlan_mac = mac;
}
 
+   ath79_parse_ascii_mac((char *) KSEG1ADDR(DIR_615C1_WLAN_MAC_ADDR), 
wlan_mac);
+
ath79_register_mdio(0, DIR_615C1_MDIO_MASK);
 
ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RMII;
-- 
2.2.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Q: autoupload a configuration file

2015-01-28 Thread Bastian Bittorf 
* Dan Therrien dtherri...@gmail.com [28.01.2015 15:40]:
 I would be very interested on how your autoupload of a configuration file 
 works?

// CC'ed openwrt-dev, maybe it's interesting for others too

is mostly the function: watch_configchange()
https://github.com/bittorf/kalua/blob/master/openwrt-addons/etc/kalua/watch#L9

is polluted with our own logic, but you get the idea:
a tar.gz is uploaded via scp (public keys must be on server)
when the hash of /etc/config/* changes...

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread Matthias Schiffer 
On 01/28/2015 11:54 AM, John Crispin wrote:
 Hi,
 
 On 27/01/2015 03:49, Matthias Schiffer wrote:
 In larger networks, especially big batman-adv meshes, it may be desirable to
 enable IGMP snooping on every bridge without enabling the multicast querier
 to specifically put the querier on a well-connected node.

 This patch adds a new UCI option 'multicast_querier' for bridges which allows
 this. The default is still the value of the 'igmp_snooping' option to 
 maintain
 backwards compatiblity.

 
 per-se a good patch but its not reentrant
 
 
 Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
 ---
  bridge.c   | 8 +++-
  system-linux.c | 2 +-
  system.h   | 1 +
  3 files changed, 9 insertions(+), 2 deletions(-)

 diff --git a/bridge.c b/bridge.c
 index f8478ad..f7dbf61 100644
 --- a/bridge.c
 +++ b/bridge.c
 @@ -32,6 +32,7 @@ enum {
  BRIDGE_ATTR_HELLO_TIME,
  BRIDGE_ATTR_MAX_AGE,
  BRIDGE_ATTR_BRIDGE_EMPTY,
 +BRIDGE_ATTR_MULTICAST_QUERIER,
  __BRIDGE_ATTR_MAX
  };
  
 @@ -45,6 +46,7 @@ static const struct blobmsg_policy 
 bridge_attrs[__BRIDGE_ATTR_MAX] = {
  [BRIDGE_ATTR_MAX_AGE] = { max_age, BLOBMSG_TYPE_INT32 },
  [BRIDGE_ATTR_IGMP_SNOOP] = { igmp_snooping, BLOBMSG_TYPE_BOOL },
  [BRIDGE_ATTR_BRIDGE_EMPTY] = { bridge_empty, BLOBMSG_TYPE_BOOL },
 +[BRIDGE_ATTR_MULTICAST_QUERIER] = { multicast_querier, 
 BLOBMSG_TYPE_BOOL },
  };
  
  static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] 
 = {
 @@ -547,6 +549,7 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
  cfg-stp = false;
  cfg-forward_delay = 2;
  cfg-igmp_snoop = true;
 +cfg-multicast_querier = true;
  cfg-bridge_empty = false;
  cfg-priority = 0x7FFF;
  
 @@ -560,7 +563,10 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
  cfg-priority = blobmsg_get_u32(cur);
  
  if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP]))
 -cfg-igmp_snoop = blobmsg_get_bool(cur);
 +cfg-multicast_querier = cfg-igmp_snoop = 
 blobmsg_get_bool(cur);
 
 i make 1 ubus call and set multicast_querier=0 and then a 2nd call and
 set igmp_snoop=1 this will break my prior call.
 
 dont change the above line and then 
 
 +
 +if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
 +cfg-multicast_querier = blobmsg_get_bool(cur);
  
  if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) {
  cfg-ageing_time = blobmsg_get_u32(cur);
 diff --git a/system-linux.c b/system-linux.c
 index 4737fa6..ef90880 100644
 --- a/system-linux.c
 +++ b/system-linux.c
 @@ -772,7 +772,7 @@ int system_bridge_addbr(struct device *bridge, struct 
 bridge_config *cfg)
  bridge-ifname, cfg-igmp_snoop ? 1 : 0);
  
  
 system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,
 -bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 +bridge-ifname, cfg-multicast_querier ? 1 : 0);
  
 
 change this to
 
   bridge-ifname, (cfg-igmp_snoop  cfg-multicast_querier) ? 1 : 0);
 
 this should not break anything with multiple ubus calls. the default
 behavior also wont change as we set cfg-multicast_querier = true;
 
 Please make those changes to the patch and resend it.
Wouldn't it be better to change the possible values of multicast_querier
to yes, no and unset? That way it could always default to the
igmp_snoop value when it is unset, but it would be possible to override
it in both ways.

 
 
 
 
 
  args[0] = BRCTL_SET_BRIDGE_PRIORITY;
  args[1] = cfg-priority;
 diff --git a/system.h b/system.h
 index 9a2326b..94e0dd9 100644
 --- a/system.h
 +++ b/system.h
 @@ -50,6 +50,7 @@ struct bridge_config {
  enum bridge_opt flags;
  bool stp;
  bool igmp_snoop;
 +bool multicast_querier;
  unsigned short priority;
  int forward_delay;
  bool bridge_empty;





signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread John Crispin 


On 27/01/2015 03:49, Matthias Schiffer wrote:
 In larger networks, especially big batman-adv meshes, it may be desirable to
 enable IGMP snooping on every bridge without enabling the multicast querier
 to specifically put the querier on a well-connected node.
 
 This patch adds a new UCI option 'multicast_querier' for bridges which allows
 this. The default is still the value of the 'igmp_snooping' option to maintain
 backwards compatiblity.
 
 Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
 ---
  bridge.c   | 8 +++-
  system-linux.c | 2 +-
  system.h   | 1 +
  3 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/bridge.c b/bridge.c
 index f8478ad..f7dbf61 100644

[...]


 @@ -560,7 +563,10 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
   cfg-priority = blobmsg_get_u32(cur);
  
   if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP]))
 - cfg-igmp_snoop = blobmsg_get_bool(cur);
 + cfg-multicast_querier = cfg-igmp_snoop = 
 blobmsg_get_bool(cur);
 +
 + if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
 + cfg-multicast_querier = blobmsg_get_bool(cur);
  

how about this ?

if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP]))
cfg-igmp_snoop = blobmsg_get_bool(cur);

if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
cfg-multicast_querier = blobmsg_get_bool(cur);
else
  cfg-multicast_querier = cfg-igmp_snoop;






   if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) {
   cfg-ageing_time = blobmsg_get_u32(cur);
 diff --git a/system-linux.c b/system-linux.c
 index 4737fa6..ef90880 100644
 --- a/system-linux.c
 +++ b/system-linux.c
 @@ -772,7 +772,7 @@ int system_bridge_addbr(struct device *bridge, struct 
 bridge_config *cfg)
   bridge-ifname, cfg-igmp_snoop ? 1 : 0);
  
   
 system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,
 - bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 + bridge-ifname, cfg-multicast_querier ? 1 : 0);
  
   args[0] = BRCTL_SET_BRIDGE_PRIORITY;
   args[1] = cfg-priority;
 diff --git a/system.h b/system.h
 index 9a2326b..94e0dd9 100644
 --- a/system.h
 +++ b/system.h
 @@ -50,6 +50,7 @@ struct bridge_config {
   enum bridge_opt flags;
   bool stp;
   bool igmp_snoop;
 + bool multicast_querier;
   unsigned short priority;
   int forward_delay;
   bool bridge_empty;
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread John Crispin 


On 28/01/2015 13:30, Matthias Schiffer wrote:
 On 01/28/2015 11:54 AM, John Crispin wrote:
 Hi,
 
 On 27/01/2015 03:49, Matthias Schiffer wrote:
 In larger networks, especially big batman-adv meshes, it may be
 desirable to enable IGMP snooping on every bridge without
 enabling the multicast querier to specifically put the querier
 on a well-connected node.
 
 This patch adds a new UCI option 'multicast_querier' for
 bridges which allows this. The default is still the value of
 the 'igmp_snooping' option to maintain backwards compatiblity.
 
 
 per-se a good patch but its not reentrant
 
 
 Signed-off-by: Matthias Schiffer
 mschif...@universe-factory.net --- bridge.c   | 8
 +++- system-linux.c | 2 +- system.h   | 1 + 3 files
 changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/bridge.c b/bridge.c index f8478ad..f7dbf61 100644 
 --- a/bridge.c +++ b/bridge.c @@ -32,6 +32,7 @@ enum { 
 BRIDGE_ATTR_HELLO_TIME, BRIDGE_ATTR_MAX_AGE, 
 BRIDGE_ATTR_BRIDGE_EMPTY, + BRIDGE_ATTR_MULTICAST_QUERIER, 
 __BRIDGE_ATTR_MAX };
 
 @@ -45,6 +46,7 @@ static const struct blobmsg_policy
 bridge_attrs[__BRIDGE_ATTR_MAX] = { [BRIDGE_ATTR_MAX_AGE] = {
 max_age, BLOBMSG_TYPE_INT32 }, [BRIDGE_ATTR_IGMP_SNOOP] = {
 igmp_snooping, BLOBMSG_TYPE_BOOL }, 
 [BRIDGE_ATTR_BRIDGE_EMPTY] = { bridge_empty,
 BLOBMSG_TYPE_BOOL }, +  [BRIDGE_ATTR_MULTICAST_QUERIER] = {
 multicast_querier, BLOBMSG_TYPE_BOOL }, };
 
 static const struct uci_blob_param_info
 bridge_attr_info[__BRIDGE_ATTR_MAX] = { @@ -547,6 +549,7 @@
 bridge_apply_settings(struct bridge_state *bst, struct
 blob_attr **tb) cfg-stp = false; cfg-forward_delay = 2; 
 cfg-igmp_snoop = true; +   cfg-multicast_querier = true; 
 cfg-bridge_empty = false; cfg-priority = 0x7FFF;
 
 @@ -560,7 +563,10 @@ bridge_apply_settings(struct bridge_state
 *bst, struct blob_attr **tb) cfg-priority =
 blobmsg_get_u32(cur);
 
 if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP])) -   cfg-igmp_snoop =
 blobmsg_get_bool(cur); +cfg-multicast_querier =
 cfg-igmp_snoop = blobmsg_get_bool(cur);
 
 i make 1 ubus call and set multicast_querier=0 and then a 2nd
 call and set igmp_snoop=1 this will break my prior call.
 
 dont change the above line and then 
 
 + + if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER])) +
 cfg-multicast_querier = blobmsg_get_bool(cur);
 
 if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) { cfg-ageing_time =
 blobmsg_get_u32(cur); diff --git a/system-linux.c
 b/system-linux.c index 4737fa6..ef90880 100644 ---
 a/system-linux.c +++ b/system-linux.c @@ -772,7 +772,7 @@ int
 system_bridge_addbr(struct device *bridge, struct bridge_config
 *cfg) bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 
 system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,

 
-   bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 +   bridge-ifname, cfg-multicast_querier ? 1 : 0);
 
 
 change this to
 
 bridge-ifname, (cfg-igmp_snoop  cfg-multicast_querier) ? 1
 : 0);
 
 this should not break anything with multiple ubus calls. the
 default behavior also wont change as we set
 cfg-multicast_querier = true;
 
 Please make those changes to the patch and resend it.
 Wouldn't it be better to change the possible values of
 multicast_querier to yes, no and unset? That way it could
 always default to the igmp_snoop value when it is unset, but it
 would be possible to override it in both ways.
 

do you call this by hand or via webui/rpc ?





 
 
 
 
 
 args[0] = BRCTL_SET_BRIDGE_PRIORITY; args[1] = cfg-priority; 
 diff --git a/system.h b/system.h index 9a2326b..94e0dd9 100644 
 --- a/system.h +++ b/system.h @@ -50,6 +50,7 @@ struct
 bridge_config { enum bridge_opt flags; bool stp; bool
 igmp_snoop; +   bool multicast_querier; unsigned short priority; 
 int forward_delay; bool bridge_empty;
 
 
 
 
 
 ___ 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] [PATCH] hostapd: backport BSSID black/whitelists

2015-01-28 Thread Stefan Tomanek 
Dies schrieb John Crispin (blo...@openwrt.org):

  Any feedback regarding this backported feature?
 
 this patch is fine, the log file one scares me though as there is no
 log rotate logic.

What kind of log rotate logic do you mean? That can be implemented externally
if needed: just move the old logfile away and send SIGHUP to the hostapd
process, to make it reopen (and recreate) the file.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hostapd: backport BSSID black/whitelists

2015-01-28 Thread Stefan Tomanek 
Dies schrieb Stefan Tomanek (stefan.tomanek+open...@wertarbyte.de):

 This change adds the configuration options bssid_whitelist and
 bssid_blacklist used to limit the AP selection of a network to a
 specified (finite) set or discard certain APs.

Any feedback regarding this backported feature?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hostapd: backport BSSID black/whitelists

2015-01-28 Thread John Crispin 


On 28/01/2015 17:56, Stefan Tomanek wrote:
 Dies schrieb Stefan Tomanek
 (stefan.tomanek+open...@wertarbyte.de):
 
 This change adds the configuration options bssid_whitelist and 
 bssid_blacklist used to limit the AP selection of a network to
 a specified (finite) set or discard certain APs.
 
 Any feedback regarding this backported feature?

this patch is fine, the log file one scares me though as there is no
log rotate logic.

 ___ 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] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread Matthias Schiffer 
On 01/28/2015 11:54 AM, John Crispin wrote:
 Hi,
 
 On 27/01/2015 03:49, Matthias Schiffer wrote:
 In larger networks, especially big batman-adv meshes, it may be desirable to
 enable IGMP snooping on every bridge without enabling the multicast querier
 to specifically put the querier on a well-connected node.

 This patch adds a new UCI option 'multicast_querier' for bridges which allows
 this. The default is still the value of the 'igmp_snooping' option to 
 maintain
 backwards compatiblity.

 
 per-se a good patch but its not reentrant
 
 
 Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
 ---
  bridge.c   | 8 +++-
  system-linux.c | 2 +-
  system.h   | 1 +
  3 files changed, 9 insertions(+), 2 deletions(-)

 diff --git a/bridge.c b/bridge.c
 index f8478ad..f7dbf61 100644
 --- a/bridge.c
 +++ b/bridge.c
 @@ -32,6 +32,7 @@ enum {
  BRIDGE_ATTR_HELLO_TIME,
  BRIDGE_ATTR_MAX_AGE,
  BRIDGE_ATTR_BRIDGE_EMPTY,
 +BRIDGE_ATTR_MULTICAST_QUERIER,
  __BRIDGE_ATTR_MAX
  };
  
 @@ -45,6 +46,7 @@ static const struct blobmsg_policy 
 bridge_attrs[__BRIDGE_ATTR_MAX] = {
  [BRIDGE_ATTR_MAX_AGE] = { max_age, BLOBMSG_TYPE_INT32 },
  [BRIDGE_ATTR_IGMP_SNOOP] = { igmp_snooping, BLOBMSG_TYPE_BOOL },
  [BRIDGE_ATTR_BRIDGE_EMPTY] = { bridge_empty, BLOBMSG_TYPE_BOOL },
 +[BRIDGE_ATTR_MULTICAST_QUERIER] = { multicast_querier, 
 BLOBMSG_TYPE_BOOL },
  };
  
  static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] 
 = {
 @@ -547,6 +549,7 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
  cfg-stp = false;
  cfg-forward_delay = 2;
  cfg-igmp_snoop = true;
 +cfg-multicast_querier = true;
  cfg-bridge_empty = false;
  cfg-priority = 0x7FFF;
  
 @@ -560,7 +563,10 @@ bridge_apply_settings(struct bridge_state *bst, struct 
 blob_attr **tb)
  cfg-priority = blobmsg_get_u32(cur);
  
  if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP]))
 -cfg-igmp_snoop = blobmsg_get_bool(cur);
 +cfg-multicast_querier = cfg-igmp_snoop = 
 blobmsg_get_bool(cur);
 
 i make 1 ubus call and set multicast_querier=0 and then a 2nd call and
 set igmp_snoop=1 this will break my prior call.
 
 dont change the above line and then 
 
 +
 +if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
 +cfg-multicast_querier = blobmsg_get_bool(cur);
  
  if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) {
  cfg-ageing_time = blobmsg_get_u32(cur);
 diff --git a/system-linux.c b/system-linux.c
 index 4737fa6..ef90880 100644
 --- a/system-linux.c
 +++ b/system-linux.c
 @@ -772,7 +772,7 @@ int system_bridge_addbr(struct device *bridge, struct 
 bridge_config *cfg)
  bridge-ifname, cfg-igmp_snoop ? 1 : 0);
  
  
 system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,
 -bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 +bridge-ifname, cfg-multicast_querier ? 1 : 0);
  
 
 change this to
 
   bridge-ifname, (cfg-igmp_snoop  cfg-multicast_querier) ? 1 : 0);
 
 this should not break anything with multiple ubus calls. the default
 behavior also wont change as we set cfg-multicast_querier = true;
 
 Please make those changes to the patch and resend it.
I just re-read the whole function and noticed why I made my change like
this in the first place: all values in bridge_config are always reset to
their defaults at the top of bridge_apply_settings() anyways, not
regarding if the blobmsg contains a new value for the options or not.

Doesn't this mean that all option's values are lost in the case of
multiple ubus calls anyways? Is this intended for bridge devices, or
should this be fixed as well?

I hope I don't misunderstand how this is supposed to work, I'm not
really familar with the way dynamic reconfiguration works in netifd...



 
 
 
 
 
  args[0] = BRCTL_SET_BRIDGE_PRIORITY;
  args[1] = cfg-priority;
 diff --git a/system.h b/system.h
 index 9a2326b..94e0dd9 100644
 --- a/system.h
 +++ b/system.h
 @@ -50,6 +50,7 @@ struct bridge_config {
  enum bridge_opt flags;
  bool stp;
  bool igmp_snoop;
 +bool multicast_querier;
  unsigned short priority;
  int forward_delay;
  bool bridge_empty;





signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] comgt-ncm: Fix NCM protocol

2015-01-28 Thread Cezary Jackiewicz 
Dnia 2015-01-28, o godz. 18:44:47
Matti Laakso malaa...@elisanet.fi napisał(a):

 I'd appreciate if someone with Samsung or Sony-Ericsson modems could
 test this, I was only able to test it with Huawei E3276, E3372 and
 E353.

Hi,
ndis was tested with e3372 and working? On which version of firmware/WebUI?

-- 
Pozdrawiam,
 Cezary Jackiewicz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [ramips] Help supporting Xiaomi MiWiFi Mini (.dts file)

2015-01-28 Thread 郭传鈜 
Someone have posted a good patch for that device:
http://www.right.com.cn/forum/thread-157588-1-1.html
The dts above works fine.
After applying the patch above,you need to edit the following:
reset {
label = reset;
gpios = gpio1 6 0;
linux,code = 0x198;
};
change 0x198 to 0x100
and add the mt76 section in
pcie@1014 {
status = okay;
};


BTW ,the mac address is defined here:
ethernet@1010 {
pinctrl-names = default;
pinctrl-0 = ephy_pins;
mtd-mac-address = factory 0x4;   --
ralink,port-map = w;
};

2015-01-29 7:29 GMT+08:00, Roger Pueyo Centelles open...@rogerpueyo.com:
 Hi,

 Some days ago I received a Xiaomi MiWiFi Mini and I've managed to run
 OpenWrt on it [1] (i.e. trunk OpenWrt, not the very modified stuff the
 vendor provides). I started with this initial patch [2] and I got the
 firmware running, but a couple of things are missing. I need some help with
 the .dts file (attached). The current status is:

 Working: Ethernet, switch, SoC 802.11gbn radio, USB, TTL and sysupgrade

 Partially working: MT7612E 802.11ac

 Not working: LEDs and button

 The problem with the 802.11ac radio is that I can not read the MAC from the
 flash. I always get this message at boot time (with different MACs, of
 course):

 [   14.56] mt76pci :01:00.0: Invalid MAC address, using random
 address 96:a3:a5:fa:a9:2b

 So far I've tried this:

 pcie0 {
 mt76@0,0 {
 reg = 0x 0 0 0 0;
 device_type = pci;
 mediatek,mtd-eeprom = factory 0x8000;
 };
 };

 and also factory 0x but the result is the same. I would say the
 location is correct, because I see three consecutive MAC addresses in the
 factory partition:

 0x0004: 64:09:80:01:66:5D
 0x0028: 64:09:80:01:66:5C
 0x8004: 64:09:80:01:66:5E

 that correspond respectively to SoC_radio, Ethernet and pcie_radio. The
 question is, what is the way to make the mt76 driver use the MAC address
 written in the flash?

 Then, regarding the LEDs, I have tried enabling gpio chips 0, 1, 2 and 3,
 exporting all the gpio numbers, setting the direction to out in all of
 them and switching the values between 0, 1 and 255, but I can not control
 any of the three leds (which are always on). The same problem for the reset
 button, I can not find it anywhere. What else should I try?

 Thank you very much!

 Roger

 [1] http://wiki.openwrt.org/toh/xiaomi/mini
 [2]
 https://github.com/rssnsj/openwrt-xiaomi-mini/blob/master/patches/01-xiaomi-mini.patch

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] fstools / always fires 'uci commit' each reboot

2015-01-28 Thread Lars Kruse 
Hi,

 [..]
 1)
 can we change that behaviour for this single script?
 (delete it during first run).

I guess, that script's execution should be considered successful, even
if /etc/config/fstab already exists. Thus the author just failed to make sure
that the exit code of that script reflects this logic.

I would suggest that
 [ ! -f /etc/config/fstab ]  ( block detect  /etc/config/fstab )
should be changed to:
 [ ! -f /etc/config/fstab ]  block detect  /etc/config/fstab || true
or even better (this does not hide errors in block detect):
 [ -f /etc/config/fstab ] || block detect  /etc/config/fstab

(I do not see the need for the subshell here - thus I removed the brackets)

This would make sure that the script exits successfully if there is the fstab
file or if the block detect execution finished successfully. Thus the script
would be deleted after its first execution (as it should be).

Lars
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [ramips] Help supporting Xiaomi MiWiFi Mini (.dts file)

2015-01-28 Thread Roger Pueyo Centelles 
Hi,

Nice, leds and button are working. I see what I was missing! Thanks :)

Setting mtd-mac-address = factory 0x4 makes eth0 and wlan1 have the same
address, but using 0x28 makes them consecutive (MAC and MAC+1). Doesn't it
make more sense? The mt76pci radio still is getting a random MAC, though.

The dts in the patch above extends the firmware partition further,
overlapping with the last three small partitions of the original firmware.
Maybe it'd be interesting to keep them, in case anybody wants to flash the
factory firmware back?

Regards,

Roger


2015-01-29 0:47 GMT+01:00 郭传鈜 gch981...@gmail.com:

 Sorry I haven't read your mail correctly.I pointed to the ethernet MAC
 address.

 2015-01-29 7:42 GMT+08:00, 郭传鈜 gch981...@gmail.com:
  Someone have posted a good patch for that device:
  http://www.right.com.cn/forum/thread-157588-1-1.html
  The dts above works fine.
  After applying the patch above,you need to edit the following:
reset {
label = reset;
gpios = gpio1 6 0;
linux,code = 0x198;
};
  change 0x198 to 0x100
  and add the mt76 section in
pcie@1014 {
status = okay;
};
 
 
  BTW ,the mac address is defined here:
ethernet@1010 {
pinctrl-names = default;
pinctrl-0 = ephy_pins;
mtd-mac-address = factory 0x4;   --
ralink,port-map = w;
};
 
  2015-01-29 7:29 GMT+08:00, Roger Pueyo Centelles open...@rogerpueyo.com
 :
  Hi,
 
  Some days ago I received a Xiaomi MiWiFi Mini and I've managed to run
  OpenWrt on it [1] (i.e. trunk OpenWrt, not the very modified stuff the
  vendor provides). I started with this initial patch [2] and I got the
  firmware running, but a couple of things are missing. I need some help
  with
  the .dts file (attached). The current status is:
 
  Working: Ethernet, switch, SoC 802.11gbn radio, USB, TTL and sysupgrade
 
  Partially working: MT7612E 802.11ac
 
  Not working: LEDs and button
 
  The problem with the 802.11ac radio is that I can not read the MAC from
  the
  flash. I always get this message at boot time (with different MACs, of
  course):
 
  [   14.56] mt76pci :01:00.0: Invalid MAC address, using random
  address 96:a3:a5:fa:a9:2b
 
  So far I've tried this:
 
  pcie0 {
  mt76@0,0 {
  reg = 0x 0 0 0 0;
  device_type = pci;
  mediatek,mtd-eeprom = factory 0x8000;
  };
  };
 
  and also factory 0x but the result is the same. I would say the
  location is correct, because I see three consecutive MAC addresses in
 the
  factory partition:
 
  0x0004: 64:09:80:01:66:5D
  0x0028: 64:09:80:01:66:5C
  0x8004: 64:09:80:01:66:5E
 
  that correspond respectively to SoC_radio, Ethernet and pcie_radio. The
  question is, what is the way to make the mt76 driver use the MAC address
  written in the flash?
 
  Then, regarding the LEDs, I have tried enabling gpio chips 0, 1, 2 and
 3,
  exporting all the gpio numbers, setting the direction to out in all of
  them and switching the values between 0, 1 and 255, but I can not
 control
  any of the three leds (which are always on). The same problem for the
  reset
  button, I can not find it anywhere. What else should I try?
 
  Thank you very much!
 
  Roger
 
  [1] http://wiki.openwrt.org/toh/xiaomi/mini
  [2]
 
 https://github.com/rssnsj/openwrt-xiaomi-mini/blob/master/patches/01-xiaomi-mini.patch
 
 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [ramips] Help supporting Xiaomi MiWiFi Mini (.dts file)

2015-01-28 Thread 郭传鈜 
Sorry I haven't read your mail correctly.I pointed to the ethernet MAC address.

2015-01-29 7:42 GMT+08:00, 郭传鈜 gch981...@gmail.com:
 Someone have posted a good patch for that device:
 http://www.right.com.cn/forum/thread-157588-1-1.html
 The dts above works fine.
 After applying the patch above,you need to edit the following:
   reset {
   label = reset;
   gpios = gpio1 6 0;
   linux,code = 0x198;
   };
 change 0x198 to 0x100
 and add the mt76 section in
   pcie@1014 {
   status = okay;
   };


 BTW ,the mac address is defined here:
   ethernet@1010 {
   pinctrl-names = default;
   pinctrl-0 = ephy_pins;
   mtd-mac-address = factory 0x4;   --
   ralink,port-map = w;
   };

 2015-01-29 7:29 GMT+08:00, Roger Pueyo Centelles open...@rogerpueyo.com:
 Hi,

 Some days ago I received a Xiaomi MiWiFi Mini and I've managed to run
 OpenWrt on it [1] (i.e. trunk OpenWrt, not the very modified stuff the
 vendor provides). I started with this initial patch [2] and I got the
 firmware running, but a couple of things are missing. I need some help
 with
 the .dts file (attached). The current status is:

 Working: Ethernet, switch, SoC 802.11gbn radio, USB, TTL and sysupgrade

 Partially working: MT7612E 802.11ac

 Not working: LEDs and button

 The problem with the 802.11ac radio is that I can not read the MAC from
 the
 flash. I always get this message at boot time (with different MACs, of
 course):

 [   14.56] mt76pci :01:00.0: Invalid MAC address, using random
 address 96:a3:a5:fa:a9:2b

 So far I've tried this:

 pcie0 {
 mt76@0,0 {
 reg = 0x 0 0 0 0;
 device_type = pci;
 mediatek,mtd-eeprom = factory 0x8000;
 };
 };

 and also factory 0x but the result is the same. I would say the
 location is correct, because I see three consecutive MAC addresses in the
 factory partition:

 0x0004: 64:09:80:01:66:5D
 0x0028: 64:09:80:01:66:5C
 0x8004: 64:09:80:01:66:5E

 that correspond respectively to SoC_radio, Ethernet and pcie_radio. The
 question is, what is the way to make the mt76 driver use the MAC address
 written in the flash?

 Then, regarding the LEDs, I have tried enabling gpio chips 0, 1, 2 and 3,
 exporting all the gpio numbers, setting the direction to out in all of
 them and switching the values between 0, 1 and 255, but I can not control
 any of the three leds (which are always on). The same problem for the
 reset
 button, I can not find it anywhere. What else should I try?

 Thank you very much!

 Roger

 [1] http://wiki.openwrt.org/toh/xiaomi/mini
 [2]
 https://github.com/rssnsj/openwrt-xiaomi-mini/blob/master/patches/01-xiaomi-mini.patch


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH netifd] bridge: allow enabling or disabling the multicast querier independently of IGMP snooping

2015-01-28 Thread John Crispin 


On 28/01/2015 21:31, Matthias Schiffer wrote:
 On 01/28/2015 11:54 AM, John Crispin wrote:
 Hi,
 
 On 27/01/2015 03:49, Matthias Schiffer wrote:
 In larger networks, especially big batman-adv meshes, it may be
 desirable to enable IGMP snooping on every bridge without
 enabling the multicast querier to specifically put the querier
 on a well-connected node.
 
 This patch adds a new UCI option 'multicast_querier' for
 bridges which allows this. The default is still the value of
 the 'igmp_snooping' option to maintain backwards compatiblity.
 
 
 per-se a good patch but its not reentrant
 
 
 Signed-off-by: Matthias Schiffer
 mschif...@universe-factory.net --- bridge.c   | 8
 +++- system-linux.c | 2 +- system.h   | 1 + 3 files
 changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/bridge.c b/bridge.c index f8478ad..f7dbf61 100644 
 --- a/bridge.c +++ b/bridge.c @@ -32,6 +32,7 @@ enum { 
 BRIDGE_ATTR_HELLO_TIME, BRIDGE_ATTR_MAX_AGE, 
 BRIDGE_ATTR_BRIDGE_EMPTY, + BRIDGE_ATTR_MULTICAST_QUERIER, 
 __BRIDGE_ATTR_MAX };
 
 @@ -45,6 +46,7 @@ static const struct blobmsg_policy
 bridge_attrs[__BRIDGE_ATTR_MAX] = { [BRIDGE_ATTR_MAX_AGE] = {
 max_age, BLOBMSG_TYPE_INT32 }, [BRIDGE_ATTR_IGMP_SNOOP] = {
 igmp_snooping, BLOBMSG_TYPE_BOOL }, 
 [BRIDGE_ATTR_BRIDGE_EMPTY] = { bridge_empty,
 BLOBMSG_TYPE_BOOL }, +  [BRIDGE_ATTR_MULTICAST_QUERIER] = {
 multicast_querier, BLOBMSG_TYPE_BOOL }, };
 
 static const struct uci_blob_param_info
 bridge_attr_info[__BRIDGE_ATTR_MAX] = { @@ -547,6 +549,7 @@
 bridge_apply_settings(struct bridge_state *bst, struct
 blob_attr **tb) cfg-stp = false; cfg-forward_delay = 2; 
 cfg-igmp_snoop = true; +   cfg-multicast_querier = true; 
 cfg-bridge_empty = false; cfg-priority = 0x7FFF;
 
 @@ -560,7 +563,10 @@ bridge_apply_settings(struct bridge_state
 *bst, struct blob_attr **tb) cfg-priority =
 blobmsg_get_u32(cur);
 
 if ((cur = tb[BRIDGE_ATTR_IGMP_SNOOP])) -   cfg-igmp_snoop =
 blobmsg_get_bool(cur); +cfg-multicast_querier =
 cfg-igmp_snoop = blobmsg_get_bool(cur);
 
 i make 1 ubus call and set multicast_querier=0 and then a 2nd
 call and set igmp_snoop=1 this will break my prior call.
 
 dont change the above line and then 
 
 + + if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER])) +
 cfg-multicast_querier = blobmsg_get_bool(cur);
 
 if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) { cfg-ageing_time =
 blobmsg_get_u32(cur); diff --git a/system-linux.c
 b/system-linux.c index 4737fa6..ef90880 100644 ---
 a/system-linux.c +++ b/system-linux.c @@ -772,7 +772,7 @@ int
 system_bridge_addbr(struct device *bridge, struct bridge_config
 *cfg) bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 
 system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,

 
-   bridge-ifname, cfg-igmp_snoop ? 1 : 0);
 +   bridge-ifname, cfg-multicast_querier ? 1 : 0);
 
 
 change this to
 
 bridge-ifname, (cfg-igmp_snoop  cfg-multicast_querier) ? 1
 : 0);
 
 this should not break anything with multiple ubus calls. the
 default behavior also wont change as we set
 cfg-multicast_querier = true;
 
 Please make those changes to the patch and resend it.
 I just re-read the whole function and noticed why I made my change
 like this in the first place: all values in bridge_config are
 always reset to their defaults at the top of
 bridge_apply_settings() anyways, not regarding if the blobmsg
 contains a new value for the options or not.
 

yep, i will cook up a patch tomorrow ...

 Doesn't this mean that all option's values are lost in the case of 
 multiple ubus calls anyways? Is this intended for bridge devices,
 or should this be fixed as well?
 

probably not

 I hope I don't misunderstand how this is supposed to work, I'm not 
 really familar with the way dynamic reconfiguration works in
 netifd...
 

me neither :)

 
 
 
 
 
 
 
 args[0] = BRCTL_SET_BRIDGE_PRIORITY; args[1] = cfg-priority; 
 diff --git a/system.h b/system.h index 9a2326b..94e0dd9 100644 
 --- a/system.h +++ b/system.h @@ -50,6 +50,7 @@ struct
 bridge_config { enum bridge_opt flags; bool stp; bool
 igmp_snoop; +   bool multicast_querier; unsigned short priority; 
 int forward_delay; bool bridge_empty;
 
 
 
 
 
 ___ 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] comgt-ncm: Fix NCM protocol

2015-01-28 Thread Matti Laakso 
This patch fixes the NCM protocol by adding the missing ifname
to the netifd script and changing one unintended send statement to
print in runcommand.gcom. It also cleans up logging and makes the
manufacturer names case-insensitive. Furthermore, comgt-ncm should
not depend on the USB-serial-related kernel modules, as the cdc-wdm
control device works without them. There is also no need to depend on
kmod-huawei-cdc-ncm, since other manufacturers (like Sony-Ericsson
and Samsung) which use other kernel modules should also be supported.

I'd appreciate if someone with Samsung or Sony-Ericsson modems could
test this, I was only able to test it with Huawei E3276, E3372 and
E353.

Signed-off-by: Matti Laakso malaa...@elisanet.fi
---
 package/network/utils/comgt/Makefile  |  2 +-
 package/network/utils/comgt/files/ncm.json|  4 +-
 package/network/utils/comgt/files/ncm.sh  | 82 ++-
 package/network/utils/comgt/files/runcommand.gcom |  9 ++-
 4 files changed, 61 insertions(+), 36 deletions(-)

diff --git a/package/network/utils/comgt/Makefile 
b/package/network/utils/comgt/Makefile
index 9ab2f14..500365a 100644
--- a/package/network/utils/comgt/Makefile
+++ b/package/network/utils/comgt/Makefile
@@ -44,7 +44,7 @@ endef
 define Package/comgt-ncm
 $(call Package/comgt/Default)
   TITLE+=NCM 3G/4G Support
-  DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-option +kmod-usb-net 
+kmod-usb-net-cdc-ncm +kmod-usb-net-huawei-cdc-ncm
+  DEPENDS:=+comgt
 endef
 
 define Package/comgt/description
diff --git a/package/network/utils/comgt/files/ncm.json 
b/package/network/utils/comgt/files/ncm.json
index b9b15cd..ea4f984 100644
--- a/package/network/utils/comgt/files/ncm.json
+++ b/package/network/utils/comgt/files/ncm.json
@@ -19,7 +19,7 @@
connect: 
AT^NDISDUP=1,1,\\\${apn}\\\${username:+,\\\$username\\\}${password:+,\\\$password\\\}${auth:+,$auth},
disconnect: AT^NDISDUP=1,0
},
-   SAMSUNG: {
+   samsung: {
initialize: [
AT,
AT+CGREG=2,
@@ -33,7 +33,7 @@
connect: AT+CGATT=1,
disconnect: AT+CGATT=0
},
-   Sony: {
+   sony: {
initialize: [
AT+CFUN=1,
AT+CGDCONT=1,\\\IP\\\,\\\${apn}\\\,
diff --git a/package/network/utils/comgt/files/ncm.sh 
b/package/network/utils/comgt/files/ncm.sh
index 14e421f..2c2835f 100644
--- a/package/network/utils/comgt/files/ncm.sh
+++ b/package/network/utils/comgt/files/ncm.sh
@@ -1,8 +1,10 @@
 #!/bin/sh
 
-. /lib/functions.sh
-. ../netifd-proto.sh
-init_proto $@
+[ -n $INCLUDE_ONLY ] || {
+   . /lib/functions.sh
+   . ../netifd-proto.sh
+   init_proto $@
+}
 
 proto_ncm_init_config() {
no_device=1
@@ -20,34 +22,52 @@ proto_ncm_init_config() {
 proto_ncm_setup() {
local interface=$1
 
-   local manufacturer initialize setmode connect
+   local manufacturer initialize setmode connect ifname devname devpath
 
local device apn auth username password pincode delay mode
json_get_vars device apn auth username password pincode delay mode
 
[ -n $device ] || {
-   echo ncm[$$] No control device specified
+   echo No control device specified
proto_notify_error $interface NO_DEVICE
proto_set_available $interface 0
return 1
}
[ -e $device ] || {
-   echo ncm[$$] Control device not valid
+   echo Control device not valid
proto_set_available $interface 0
return 1
}
[ -n $apn ] || {
-   echo ncm[$$] No APN specified
+   echo No APN specified
proto_notify_error $interface NO_APN
proto_set_available $interface 0
return 1
}
 
+   devname=$(basename $device)
+   case $devname in
+   'tty'*)
+   devpath=$(readlink -f /sys/class/tty/$devname/device)
+   ifname=$( ls $devpath/../../*/net )
+   ;;
+   *)
+   devpath=$(readlink -f /sys/class/usbmisc/$devname/device/)
+   ifname=$( ls $devpath/net )
+   ;;
+   esac
+   [ -n $ifname ] || {
+   echo The interface could not be found.
+   proto_notify_error $interface NO_IFACE
+   proto_set_available $interface 0
+   return 1
+   }
+
[ -n $delay ]  sleep $delay
 
-   manufacturer=`gcom -d $device -s /etc/gcom/getcardinfo.gcom | awk 
'/Manufacturer/ { print $2 }'`
+   manufacturer=`gcom -d $device -s /etc/gcom/getcardinfo.gcom | awk 
'/Manufacturer/ { print tolower($2) }'`
[ $? -ne 0 ]  {
-   echo ncm[$$] Failed to get modem information
+   echo Failed to get modem information
proto_notify_error $interface

Re: [OpenWrt-Devel] QEMU 2.0.0

2015-01-28 Thread Ning Ye 
I just went through the Makefile in qemu and it doesn't seem to be any easy way 
to build just quem-img.  This is because it has depency upon qemu libraries 
which depend on the libraries we don't want.  I guess we will have to stick 
with the current version for now. 

Ning

-Original Message-
From: Florian Fainelli [mailto:f.faine...@gmail.com] On Behalf Of Florian 
Fainelli
Sent: Wednesday, January 21, 2015 6:52 PM
To: Ning Ye; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] QEMU 2.0.0

On 21/01/15 09:08, Ning Ye wrote:
 I am just wondering if anyone maintains QEMU in OpenWRT toolchain.  I 
 want to use QEMU 2.0.0 or later as it fixed VHD virtual disk issues.  
 Of course, it has dependency on other library which is not simple to 
 upgrade. That's where I am stuck now.

Right, we don't want to pull in all of these libraries, can you find a way to 
build qemu-img only, because this is the only thing we use from a qemu 
host-build?

 
 I am currently use QEMU 2.0 separately from OpenWRT build and manually 
 run the tools on my Linux Host to convert and generate VHD images.
 
 Any suggestions would be deeply appreciated.  Thanks.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel