Re: [LEDE-DEV] openwrt and lede - remerge proposal

[David Lang]

On Thu, 11 May 2017, Alberto Bursi wrote:


On 05/11/2017 12:33 AM, Paul Oranje wrote:



Some of the rules has to change, and as we've discussed it with John, one might 
want to send upstream submissions to make OpenWrt show up there like other 
projects do. You might also want to open a private conversation between the 
upstream platform / driver maintainer where having a project email address 
could be useful. Personally I only use my owrt address for FOSS related stuff 
and as far as I know, most people do the same.

LEDE has a rule which says: "Committers being unreachable for three months in a row 
shall get their commit and voting rights revoked in order to retain the ability to do 
majority votes among the remaining active committers." This rule is clearly 
problematic if you would like to extend voting rights to non-coders which I believe we 
want to do. Someone maintaining the wiki or the forums might never commit anything, but 
we do want to get their opinion heard. In the past we didn't make it easy for the 
community to interfere with decisions, I doubt we want to make the same mistake again.

Intentions matter. Nonetheless a rule that tries to prevent that 
non-cooperation can be used as a way to obstruct, should not be set aside by 
intentions; this rule may very well be a sleeping rule that, unhoped for, might 
just be needed when lesser intentions become a problem. While on the other hand 
in the interpretation of a rule, its intention is very relevant and helps to 
apply it to cases that may seem not to fit when interpreted in a (to) narrowly 
strict way.




That's easily dealt with by adding conditions for non-programmers to get
(and also lose) "voting rights", while leaving the current condition for
programmers.


I'm confused, how do the current conditions for comitters not work for other 
contributers? They don't in any way involve the person contributing code, it 
just requires that they are reachable one time in a three month window. If you 
can't respond to one e-mail in three months, then you really aren't part of the 
project any longer.


All it takes is changing the word "Committers" to "Contributers".

The existing method of giving programmers commit/voting privileges will work 
just as well for non-programmers (i.e. a vote of the people who currently have 
voting privileges)


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Alberto Bursi]

On 05/11/2017 12:33 AM, Paul Oranje wrote:
>
>> Some of the rules has to change, and as we've discussed it with John, one 
>> might want to send upstream submissions to make OpenWrt show up there like 
>> other projects do. You might also want to open a private conversation 
>> between the upstream platform / driver maintainer where having a project 
>> email address could be useful. Personally I only use my owrt address for 
>> FOSS related stuff and as far as I know, most people do the same.
>>
>> LEDE has a rule which says: "Committers being unreachable for three months 
>> in a row shall get their commit and voting rights revoked in order to retain 
>> the ability to do majority votes among the remaining active committers." 
>> This rule is clearly problematic if you would like to extend voting rights 
>> to non-coders which I believe we want to do. Someone maintaining the wiki or 
>> the forums might never commit anything, but we do want to get their opinion 
>> heard. In the past we didn't make it easy for the community to interfere 
>> with decisions, I doubt we want to make the same mistake again.
> Intentions matter. Nonetheless a rule that tries to prevent that 
> non-cooperation can be used as a way to obstruct, should not be set aside by 
> intentions; this rule may very well be a sleeping rule that, unhoped for, 
> might just be needed when lesser intentions become a problem. While on the 
> other hand in the interpretation of a rule, its intention is very relevant 
> and helps to apply it to cases that may seem not to fit when interpreted in a 
> (to) narrowly strict way.
>
>

That's easily dealt with by adding conditions for non-programmers to get 
(and also lose) "voting rights", while leaving the current condition for 
programmers.

-Alberto
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Paul Oranje]

Although being someone that’s merely following the developments of this 
project, I want to comment on what’s going on in this thread.
Some of my remarks may strike as not very positive, so please do not take any 
of those personal.
s.y.
Paul

> Op 10 mei 2017, om 11:31 heeft Imre Kaloz  het volgende 
> geschreven:
> 
> On 2017-05-10 00:52, Jo-Philipp Wich wrote:
[cut]

> *) SPI
>>> - TBD post remerge
>> 
>> I'd prefer to tackle this first.
> 
> Before the merge non-OpenWrt people are outsiders from both SPI's and the 
> world's PoV. After the merge everyone can vote on these topics.
This does not feel right. The desire to have the ownership of the domain being 
properly handled before bringing the project - which currently is LEDE - back 
under the openwrt domain name is very reasonable. The fork this have a cause.
If I’ve misunderstood Imre’s position, please tell.

>>> - start pushing to the openwrt organisation
>> 
>> By force-overwriting the history of openwrt/openwrt ?
> 
> No one said it won't cause a bit of pain, but would ease the transition on 
> the long run.
Seems the solution to un-fork may cause more problems than it solves. And all 
that for just the name ?

>>> - update the landing page to have the same look & feel as the current
>>> openwrt landing page
>> 
>> Why?
> 
> Well, we're not wikipedia so it doesn't hurt if the site has at least some 
> CSS ;)
For all value that OWRT was worth, its website's looks weren’t among them.

>>> *) email accounts
>>> - currently there are around ~20 active openwrt.org mail accounts
>>> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
>>> anyone with voting rights can be subscribed to
>>> - ask those people that are no longer active to voluntarily give up
>>> their accounts
>>> - mail addresses may under no conditions be used for any personal
>>> business, consultancy, applying for jobs, ... purposes
>> 
>> According to the rules there shall be no personal mail accounts at all.
>> There should be plenty of time until the actual remerge to fade them out
>> and to set up forwarding elsewhere.
> 
> I hope you agree that a merge means both sides are adopting and need to find 
> some common ground.
All animals are equal, but some animals are more equal than others ...

> Some of the rules has to change, and as we've discussed it with John, one 
> might want to send upstream submissions to make OpenWrt show up there like 
> other projects do. You might also want to open a private conversation between 
> the upstream platform / driver maintainer where having a project email 
> address could be useful. Personally I only use my owrt address for FOSS 
> related stuff and as far as I know, most people do the same.
> 
> LEDE has a rule which says: "Committers being unreachable for three months in 
> a row shall get their commit and voting rights revoked in order to retain the 
> ability to do majority votes among the remaining active committers." This 
> rule is clearly problematic if you would like to extend voting rights to 
> non-coders which I believe we want to do. Someone maintaining the wiki or the 
> forums might never commit anything, but we do want to get their opinion 
> heard. In the past we didn't make it easy for the community to interfere with 
> decisions, I doubt we want to make the same mistake again.
Intentions matter. Nonetheless a rule that tries to prevent that 
non-cooperation can be used as a way to obstruct, should not be set aside by 
intentions; this rule may very well be a sleeping rule that, unhoped for, might 
just be needed when lesser intentions become a problem. While on the other hand 
in the interpretation of a rule, its intention is very relevant and helps to 
apply it to cases that may seem not to fit when interpreted in a (to) narrowly 
strict way.

[cut]
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Hauke Mehrtens]

Thanks for moving this forward.

On 05/08/2017 03:19 PM, John Crispin wrote:
> *) github
.
> 
> - obsolete the lede github org after a grace period of 3-6 months

As long as it does not cost us effort I would like to keep the lede
domains and github project up running for longer.

> *) landing page
> - update the lede landing page to represent the openwrt name
> - update the landing page to have the same look & feel as the current
> openwrt landing page
> - point openwrt.org at the lede landing page

I prefer the LEDE design, but with the news like content on the OpenWrt
page, but I do not really care and will not block the merge about this.
Is someone volunteering to prepare a design which also fulfills Imre's
requirements, I am also asking the non LEDE committers and non OpenWrt
core developers? I am not good at this. ;-)

> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy

I would like to put the sponsorship policy into the back to not block
things, the trademark policy looks OK. Did any lawyer looked at the
trademark policy?

Will someone work on a joint statement which then marks the official
merge? Will the SPI recognize also the LEDE members as OpenWrt members
after such a statement or when will this happen?

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal

[Hauke Mehrtens]

On 05/09/2017 10:12 AM, Hans Dedecker wrote:
> On Tue, May 9, 2017 at 9:50 AM, John Crispin  wrote:
>>
>>
>> On 09/05/17 09:49, Rafał Miłecki wrote:
>>>
>>> On 8 May 2017 at 15:19, John Crispin  wrote:

 *) domain
 - transfer owner ship to SPI for openwrt.org and lede-project.org
 (...)

 *) SPI
 - TBD post remerge
>>>
>>> This is unclear to me. Are we postponing setting rules with SPI on how
>>> they should manage domains? I guess it should be handled at the same
>>> time: specifying rules (majority of votes?) and handling domains.
>>
>> SPi will need a new liaison officer (team). we need to vote on who this will
>> be. apart from that SPI will be pointed at the wiki page listing voters and
>> rules. domains will be handed over to them
> SPI offers different services to projects like accepting donations and
> holding funds, legal assistance, technical services, etc ... Apart
> from handing over the domains do we want to make use of any of the
> services offered by SPI ?
> 
> Further nice to read we convergence again; thx for the effort !

I would like if we take the same services as OpenWrt did in the past
from SPI (Software in the Public Interest) + the DNS / Domain service as
mentioned in this mail.

* SPI holds the OpenWrt trademark for the OpenWrt project
* SPI accepts donations for the OpenWrt project (incl. tax reduction)
* SPI manages the OpenWrt "bank" account
* SPI gave legal advice for the trademark and will help on other topics

OpenWrt had 6040.14 USD in the account at SPI by 1.1.2017, 1621.13 USD
were donated to OpenWrt in the year 2016:
http://www.spi-inc.org/treasurer/reports/201612/#index58h4

In my opinion SPI did a good job and did everything we asked them for
and did not try to take over the project or something like this. ;-)
From my understanding no one has a problem with the SPI, but some people
are a reluctant against some of the other organizations.

We need a new representation at the SPI and should vote about it.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH umdns 2/3] Allow filtering with instance name in service_reply

[Rafał Miłecki]

From: Rafał Miłecki 

This will allow sending replies more flexibly.

Signed-off-by: Rafał Miłecki 
---
 dns.c | 4 ++--
 service.c | 9 ++---
 service.h | 2 +-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/dns.c b/dns.c
index 68a088f..bccaa29 100644
--- a/dns.c
+++ b/dns.c
@@ -369,7 +369,7 @@ parse_question(struct interface *iface, struct sockaddr 
*from, char *name, struc
case TYPE_ANY:
if (!strcmp(name, mdns_hostname_local)) {
dns_reply_a(iface, to, announce_ttl);
-   service_reply(iface, to, NULL, announce_ttl);
+   service_reply(iface, to, NULL, NULL, announce_ttl);
}
break;
 
@@ -386,7 +386,7 @@ parse_question(struct interface *iface, struct sockaddr 
*from, char *name, struc
/* Make sure it's query for the instance name we use */
if (len && len == strlen(umdns_host_label) &&
!strncmp(name, umdns_host_label, len))
-   service_reply(iface, to, dot + 1, announce_ttl);
+   service_reply(iface, to, NULL, dot + 1, 
announce_ttl);
}
break;
 
diff --git a/service.c b/service.c
index e6d9618..67e8f40 100644
--- a/service.c
+++ b/service.c
@@ -152,13 +152,16 @@ service_reply_single(struct interface *iface, struct 
sockaddr *to, struct servic
 }
 
 void
-service_reply(struct interface *iface, struct sockaddr *to, const char *match, 
int ttl)
+service_reply(struct interface *iface, struct sockaddr *to, const char 
*instance, const char *service_domain, int ttl)
 {
struct service *s;
 
vlist_for_each_element(, s, node) {
-   if (!match || !strcmp(s->service, match))
-   service_reply_single(iface, to, s, ttl, 0);
+   if (instance && strcmp(s->instance, instance))
+   continue;
+   if (service_domain && strcmp(s->service, service_domain))
+   continue;
+   service_reply_single(iface, to, s, ttl, 0);
}
 }
 
diff --git a/service.h b/service.h
index 086a0af..db8f374 100644
--- a/service.h
+++ b/service.h
@@ -16,7 +16,7 @@
 
 extern void service_init(int announce);
 extern void service_cleanup(void);
-extern void service_reply(struct interface *iface, struct sockaddr *to, const 
char *match, int ttl);
+extern void service_reply(struct interface *iface, struct sockaddr *to, const 
char *instance, const char *service_domain, int ttl);
 extern void service_announce_services(struct interface *iface, struct sockaddr 
*to, int ttl);
 
 #endif
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH umdns 3/3] Support PTR queries for a specific service

[Rafał Miłecki]

From: Rafał Miłecki 

We should check if queried name starts with a _ to see if it is about a
specific service + domain.

Fixes: 70c66fbbcde86 ("Fix sending replies to PTR questions")
Reported-by: Cristian Morales Vega 
Signed-off-by: Rafał Miłecki 
---
 dns.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/dns.c b/dns.c
index bccaa29..aadfdd8 100644
--- a/dns.c
+++ b/dns.c
@@ -378,15 +378,18 @@ parse_question(struct interface *iface, struct sockaddr 
*from, char *name, struc
dns_reply_a(iface, to, announce_ttl);
service_announce_services(iface, to, announce_ttl);
} else {
-   /* First dot separates instance name from the rest */
-   char *dot = strchr(name, '.');
-   /* Length of queried instance */
-   size_t len = dot ? dot - name : 0;
-
-   /* Make sure it's query for the instance name we use */
-   if (len && len == strlen(umdns_host_label) &&
-   !strncmp(name, umdns_host_label, len))
-   service_reply(iface, to, NULL, dot + 1, 
announce_ttl);
+   if (name[0] == '_') {
+   service_reply(iface, to, NULL, name, 
announce_ttl);
+   } else {
+   /* First dot separates instance name from the 
rest */
+   char *dot = strchr(name, '.');
+
+   if (dot) {
+   *dot = '\0';
+   service_reply(iface, to, name, dot + 1, 
announce_ttl);
+   *dot = '.';
+   }
+   }
}
break;
 
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH umdns 1/3] Store instance name in the struct service

[Rafał Miłecki]

From: Rafał Miłecki 

This will allow using custom instace names in the future. Right now we
always set it to the host-specific label so there is no behavior change.

Signed-off-by: Rafał Miłecki 
---
 service.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/service.c b/service.c
index c8187de..e6d9618 100644
--- a/service.c
+++ b/service.c
@@ -46,6 +46,7 @@ struct service {
time_t t;
 
const char *id;
+   const char *instance;
const char *service;
const uint8_t *txt;
int txt_len;
@@ -74,14 +75,14 @@ static int service_init_announce;
  *
  * Service Instance Name =  .  . 
  *
- * @service_domain: service name (a pair of labels) with domain name appended
+ * @s: service to generate service instance name for
  */
 static const char *
-service_instance_name(const char *service_domain)
+service_instance_name(struct service *s)
 {
static char buffer[256];
 
-   snprintf(buffer, sizeof(buffer), "%s.%s", umdns_host_label, 
service_domain);
+   snprintf(buffer, sizeof(buffer), "%s.%s", s->instance, s->service);
 
return buffer;
 }
@@ -127,7 +128,7 @@ service_timeout(struct service *s)
 static void
 service_reply_single(struct interface *iface, struct sockaddr *to, struct 
service *s, int ttl, int force)
 {
-   const char *host = service_instance_name(s->service);
+   const char *host = service_instance_name(s);
char *service = strstr(host, "._");
time_t t = service_timeout(s);
 
@@ -140,7 +141,7 @@ service_reply_single(struct interface *iface, struct 
sockaddr *to, struct servic
s->t = t;
 
dns_init_answer();
-   service_add_ptr(service_instance_name(s->service), ttl);
+   service_add_ptr(service_instance_name(s), ttl);
dns_send_answer(iface, to, service);
 
dns_init_answer();
@@ -229,6 +230,7 @@ service_load_blob(struct blob_attr *b)
 
s->port = blobmsg_get_u32(_tb[SERVICE_PORT]);
s->id = strcpy(d_id, blobmsg_name(b));
+   s->instance = umdns_host_label;
s->service = strcpy(d_service, 
blobmsg_get_string(_tb[SERVICE_SERVICE]));
s->active = 1;
s->t = 0;
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2 1/3] base-files: add/convert generic board detection scripts

[Piotr Dymacz]

Hello Roman,

On 09.05.2017 22:24, Roman Yeryomin wrote:

On 9 May 2017 at 12:51, Piotr Dymacz  wrote:

Hello Roman,


Hi


Your mail addresses in from header and in SoB line don't match.


is that a problem?


AFAIK, not a big one but in general, yes. Someone would need to fix that 
before merging.


[snip]


diff --git a/package/base-files/files/lib/preinit/03_preinit_board_detect
b/package/base-files/files/lib/preinit/03_preinit_board_detect
new file mode 100644
index 000..739ab02
--- /dev/null
+++ b/package/base-files/files/lib/preinit/03_preinit_board_detect
@@ -0,0 +1,11 @@
+#!/bin/sh
+#
+# Copyright (c) 2017 The Linux Foundation. All rights reserved.



Why LF? Shouldn't you use here your own copyright or none at all?


Probably because that script is actually just a copy from ipq target.


As far as I can see, it's not a 1:1 copy.
Please, use your own copyrights or none at all.


Also I would ask the same question -- why LF? Maybe there is an answer
buried somewhere in the mail list...


It could be just a copy from vendor SDK (QLSDK?).


What's more, does it really make sense for you to copyright shell code which
length is almost the same as the copyright line?


I don't care much about that but technically you are right.
And still, I would make it consistent. So, you can propose a patch
which removes all copyrights from scripts. That could even increase
performance by some us.


I really don't think that you can just drop all copyright lines from 
code if they are already there.


--
Cheers,
Piotr




--
Cheers,
Piotr



+#
+
+do_board_detect()
+{
+   . /lib/board_detect.sh && board_detect
+}
+
+boot_hook_add preinit_main do_board_detect
diff --git a/package/base-files/files/lib/preinit/10_sysinfo
b/package/base-files/files/lib/preinit/10_sysinfo
deleted file mode 100644
index 65b5096..000
--- a/package/base-files/files/lib/preinit/10_sysinfo
+++ /dev/null
@@ -1,10 +0,0 @@
-do_sysinfo_generic() {
-   [ -d /proc/device-tree ] || return
-   mkdir -p /tmp/sysinfo
-   [ -e /tmp/sysinfo/board_name ] || \
-   echo "$(strings /proc/device-tree/compatible | head -1)" >
/tmp/sysinfo/board_name
-   [ ! -e /tmp/sysinfo/model -a -e /proc/device-tree/model ] && \
-   echo "$(cat /proc/device-tree/model)" > /tmp/sysinfo/model
-}
-
-boot_hook_add preinit_main do_sysinfo_generic








___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] dnsmasq: add IPv6 nameserver configuration in server mode

[Arjen de Korte]

When in ra server mode, configure nameservers passed in router
announcements from the dns value (which is already used by odhcpd).

This also fixes FS#677 by using the global IPv6 address of the router
instead of the link local address (if no nameservers are configured).

Signed-off-by: Arjen de Korte 
---
 package/network/services/dnsmasq/files/dnsmasq.init | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 1a1941f1d7..7cad06407f 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -466,6 +466,7 @@ dhcp_add() {
config_get ra "$cfg" ra
config_get ra_management "$cfg" ra_management
config_get ra_preference "$cfg" ra_preference
+   config_get dns "$cfg" dns
 
# Put the router host name on this DHCP served interface address(es)
dhcp_this_host_add "$net" "$ifname" "$ADD_LOCAL_FQDN"
@@ -533,6 +534,15 @@ dhcp_add() {
xappend 
"--dhcp-range=$nettag$dhcp6range,constructor:$ifname,slaac,ra-names,$leasetime"
;;
esac
+
+   if [ -n "$dns" ]; then
+   dnss=""
+   for d in $dns; do append dnss "[$d]" ","; done
+   else
+   dnss="[::]"
+   fi
+
+   dhcp_option_append "option6:dns-server,$dnss" "$networkid"
fi
 
dhcp_option_add "$cfg" "$networkid"
-- 
2.12.2


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal

[Thomas Endt]

> -Ursprüngliche Nachricht-
> Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] Im
> Auftrag von Imre Kaloz
> Gesendet: Mittwoch, 10. Mai 2017 11:36
> 
> On 2017-05-09 18:29, Philip Prindeville wrote:
> 
> 
> 
> > I’d like to suggest one more action item to this list if I can.  It
> would be handy to have a single database for user
> authentication/identification for submitting bugs, editing the Wiki,
> etc.
> >
> > Previously there were too many places where you had to create an
> account.  If we can’t do “single sign-on”, can we at least do “single
> sign-up”?
> >
> > And part of a user’s profile should include their IRC handle
> (assuming they have one).
> 
> I agree, SSO would be way more user friendly. We should look into it
> for sure.


The LEDE wiki and LEDE forum currently offer login via github. Others are 
possible, e.g. Auth0, Google, Doorkeeper, Keycloak, ...

Thomas


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] generic: add support for ZTE MF667[rndis] 19d2:1403

[Bjørn Mork]

Ермошкин А.Ю.  writes:

> This patch adds support for the ZTE usb modem MF667 in rndis/network card 
> mode.
>
> generic/099-usb-cdc_ether-zte-update.patch
> generic/774-net-usb-cdc_ether-quirks-for-zte-mf667.patch

Any reason why the first patch isn't simply a backport of mainline
commit bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")?
 
 
> If debug enabled, kernel printk:
> rndis_host 1-1:1.0: ACM capabilities 02, not really RNDIS?
>
> --
> With regards,
> Alexey
>  mailto:alexey.ermosh...@gmail.com
>
> --- a/drivers/net/usb/cdc_ether.c
> +++ b/drivers/net/usb/cdc_ether.c
> @@ -17,8 +17,8 @@
>   * along with this program; if not, see .
>   */
>  
> -// #define   DEBUG   // error path messages, extra info
> -// #define   VERBOSE // more; success messages
> +#define  DEBUG   // error path messages, extra info
> +#define  VERBOSE // more; success messages
>  
>  #include 
>  #include 

Unrelated debugging.


> @@ -432,6 +432,64 @@ int usbnet_cdc_bind(struct usbnet *dev,
>  }
>  EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
>  
> +static int usbnet_cdc_zte_bind(struct usbnet *dev, struct usb_interface 
> *intf)
> +{
> + int status = usbnet_cdc_bind(dev, intf);
> +
> + if (!status && (dev->net->dev_addr[0] & 0x02))
> + eth_hw_addr_random(dev->net);
> +
> + return status;
> +}
> +
> +/* Make sure packets have correct destination MAC address
> + *
> + * A firmware bug observed on some devices (ZTE MF823/831/910) is that the
> + * device sends packets with a static, bogus, random MAC address (event if
> + * device MAC address has been updated). Always set MAC address to that of 
> the
> + * device.
> + */
> +static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
> +{
> + if (skb->len < ETH_HLEN || !(skb->data[0] & 0x02))
> + return 1;
> +
> + skb_reset_mac_header(skb);
> + ether_addr_copy(eth_hdr(skb)->h_dest, dev->net->dev_addr);
> +
> + return 1;
> +}
> +
> +/* Ensure correct link state
> + *
> + * Some devices (ZTE MF823/831/910) export two carrier on notifications when
> + * connected. This causes the link state to be incorrect. Work around this by
> + * always setting the state to off, then on.
> + */
> +static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
> +{
> + struct usb_cdc_notification *event;
> +
> + if (urb->actual_length < sizeof(*event))
> + return;
> +
> + event = urb->transfer_buffer;
> +
> + if (event->bNotificationType != USB_CDC_NOTIFY_NETWORK_CONNECTION) {
> + usbnet_cdc_status(dev, urb);
> + return;
> + }
> +
> + netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
> +   event->wValue ? "on" : "off");
> +
> + if (event->wValue &&
> + netif_carrier_ok(dev->net))
> + netif_carrier_off(dev->net);
> +
> + usbnet_link_change(dev, !!event->wValue, 0);
> +}
> +
>  static const struct driver_info  cdc_info = {
>   .description =  "CDC Ethernet Device",
>   .flags =FLAG_ETHER | FLAG_POINTTOPOINT,
> @@ -442,6 +500,17 @@ static const struct driver_info  cdc_info
>   .manage_power = usbnet_manage_power,
>  };
>  
> +static const struct driver_info  zte_cdc_info = {
> + .description =  "ZTE CDC Ethernet Device",
> + .flags =FLAG_ETHER | FLAG_POINTTOPOINT,
> + .bind = usbnet_cdc_zte_bind,
> + .unbind =   usbnet_cdc_unbind,
> + .status =   usbnet_cdc_zte_status,
> + .set_rx_mode =  usbnet_cdc_update_filter,
> + .manage_power = usbnet_manage_power,
> + .rx_fixup = usbnet_cdc_zte_rx_fixup,
> +};
> +
>  static const struct driver_info wwan_info = {
>   .description =  "Mobile Broadband Network Device",
>   .flags =FLAG_WWAN,
> @@ -463,6 +532,7 @@ static const struct driver_info wwan_inf
>  #define LENOVO_VENDOR_ID 0x17ef
>  #define NVIDIA_VENDOR_ID 0x0955
>  #define HP_VENDOR_ID 0x03f0
> +#define MICROSOFT_VENDOR_ID  0x045e
>  
>  static const struct usb_device_idproducts[] = {
>  /* BLACKLIST !!
> @@ -650,6 +720,20 @@ static const struct usb_device_idproduc
>   .driver_info = 0,
>  },
>  
> +/* ThinkPad USB-C Dock (based on Realtek RTL8153) */
> +{
> + USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3062, USB_CLASS_COMM,
> + USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
> + .driver_info = 0,
> +},
> +
> +/* ThinkPad Thunderbolt 3 Dock (based on Realtek RTL8153) */
> +{
> + USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3069, USB_CLASS_COMM,
> + USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
> + .driver_info = 0,
> +},
> +
>  /* Lenovo Thinkpad USB 3.0 Ethernet Adapters (based on Realtek RTL8153) */
>  {
>   USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x7205, USB_CLASS_COMM,


These 

Re: [LEDE-DEV] Devolo dLAN pro 500 Wireless+ and PLC (Power-line communication not Programmable logic controller)

[Denis 'GNUtoo' Carikli]

On Mon, 6 Mar 2017 15:10:59 +
Guenther Kelleter  wrote:

> Hi Denis
Hi again,


> You need a firmware image and a PIB (config blob) for the AR7400.
> Unfortunately we're not allowed to redistribute these firmware images
> for legal reasons. So currently it cannot be officially supported.
I know have theses.

Before I didn't find the .dvl firmware update before, so I attempted
other methods to get it.

The issue was that, on the devolo.com website, with javascript enabled,
after selecting the product (Devolo dLAN pro 500 Wireless+) I clicked
on "Display product downloads" and it bringed a page with no product.

Some days ago I retried and instead accidentally waited instead of
clicking on the "Display product downloads" button.

[...]
> If you had the firmware and PIB you could use ampboot or amphost to
> boot the AR7400 after setting gpio13 to 1. Of course the original
> devolo firmware contains PLC firmware and PIB;-)
The issue is that I can't manage to load the PIB:
# ls *.pib *.nvm
2554.pib 2555.pib 2556.pib int6x00.nvm
# brctl delif br-lan eth0
# echo 1 > /sys/class/gpio/gpio13/value
# ifconfig eth0 up
# amptool -i eth0 -Iar
eth0 00:B0:52:00:00:01 Request Version Information
eth0 00:B0:52:00:00:01  AR7400 BootLoader
eth0 00:B0:52:00:00:01 Fetch Device Attributes
eth0 00:B0:52:00:00:01 Device Identity
# ampboot -i eth0 -P 2556.pib -N int6x00.nvm
ampboot: pibfile1 found wrong PIB content in 2556.pib
# amphost -i eth0 -N int6x00.nvm -n oldnvm -P 2556.pib -p oldpib
amphost: pibfile1 found wrong PIB content in 2556.pib

Thanks a lot for your help.

Denis.


pgpoQuuoEn8wn.pgp
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] generic: add support for ZTE MF667[rndis] 19d2:1403

[Ермошкин А . Ю .]

This patch adds support for the ZTE usb modem MF667 in rndis/network card mode.

generic/099-usb-cdc_ether-zte-update.patch
generic/774-net-usb-cdc_ether-quirks-for-zte-mf667.patch

If debug enabled, kernel printk:
rndis_host 1-1:1.0: ACM capabilities 02, not really RNDIS?

--
With regards,
Alexey
 mailto:alexey.ermosh...@gmail.com

099-usb-cdc_ether-zte-update.patch
Description: Binary data


774-net-usb-cdc_ether-quirks-for-zte-mf667.patch
Description: Binary data
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH umdns 3/3] Support specifying instance name in JSON file

[Rafał Miłecki]

On 10 May 2017 at 12:47, Rafał Miłecki  wrote:
> From: Rafał Miłecki 
>
> So far we were using host label as the instance name for every service.
> This change allows specifying it manually and fallbacks to the label for
> backward compatibility.
>
> Signed-off-by: Rafał Miłecki 

Actually we are not ready for this change yet. Function parse_question
and its PTR code assumes we always use host label as an instance name.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions

[Rafał Miłecki]

On 10 May 2017 at 14:20, Cristian Morales Vega  wrote:
>> On 10 May 2017 at 13:14, Rafał Miłecki  wrote:
>>> After reading your comment & analyzing the code: yes. I expect this to break
>>> support for queries you mentioned.
>>>
>>> My problem is that even without this commit or my local fix avahi-browse
>>> still doesn't detect services announced by umdns. I can see answers being
>>> sent so I assume there is something wrong with them.
>>>
>>> I've to debug it further.
>
> See http://lists.infradead.org/pipermail/lede-dev/2017-April/007177.html
> and http://lists.infradead.org/pipermail/lede-dev/2017-April/007188.html
> (yes, I have to improve my email workflow... and I managed to top-post 
> before!)
>
> With those patches it works for me.

Tip of the day: opening UDP port 5353 may help.

Sorry for that mistake. I can see this working now.

-- 
Rafał

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions

[Cristian Morales Vega]

> On 10 May 2017 at 13:14, Rafał Miłecki  wrote:
>> After reading your comment & analyzing the code: yes. I expect this to break
>> support for queries you mentioned.
>>
>> My problem is that even without this commit or my local fix avahi-browse
>> still doesn't detect services announced by umdns. I can see answers being
>> sent so I assume there is something wrong with them.
>>
>> I've to debug it further.

See http://lists.infradead.org/pipermail/lede-dev/2017-April/007177.html
and http://lists.infradead.org/pipermail/lede-dev/2017-April/007188.html
(yes, I have to improve my email workflow... and I managed to top-post before!)

With those patches it works for me.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions

[Cristian Morales Vega]

See http://lists.infradead.org/pipermail/lede-dev/2017-April/007177.html
and http://lists.infradead.org/pipermail/lede-dev/2017-April/007188.html
(yes, I have to improve my email workflow)

With those patches it works for me.


On 10 May 2017 at 13:14, Rafał Miłecki  wrote:
> On 04/21/2017 03:31 PM, Cristian Morales Vega wrote:
>>
>> On 13 February 2017 at 15:42, Rafał Miłecki  wrote:
>>>
>>> From: Rafał Miłecki 
>>>
>>> When we receive PTR question it includes hostname (instance), e.g.:
>>> mdnsd: parse_question (391): Q -> PTR lede._http._tcp.local
>>>
>>> First of all we should check if it matches hostname we use before trying
>>> to reply. Secondly service_reply expects service with domain appended
>>> (without hostname/instance) so we need to strip received string out of
>>> hostname before passing it.
>>>
>>> Signed-off-by: Rafał Miłecki 
>>> ---
>>>  dns.c | 14 --
>>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/dns.c b/dns.c
>>> index 91434f2..dac6f2c 100644
>>> --- a/dns.c
>>> +++ b/dns.c
>>> @@ -367,9 +367,19 @@ parse_question(struct interface *iface, char *name,
>>> struct dns_question *q)
>>> break;
>>>
>>> case TYPE_PTR:
>>> -   if (!strcmp(name, sdudp))
>>> +   if (!strcmp(name, sdudp)) {
>>> service_announce_services(iface, announce_ttl);
>>> -   service_reply(iface, name, announce_ttl);
>>> +   } else {
>>> +   /* First dot separates instance name from the
>>> rest */
>>> +   char *dot = strchr(name, '.');
>>> +   /* Length of queried instance */
>>> +   size_t len = dot ? dot - name : 0;
>>> +
>>> +   /* Make sure it's query for the instance name we
>>> use */
>>> +   if (len && len == strlen(mdns_hostname) &&
>>> +   !strncmp(name, mdns_hostname, len))
>>> +   service_reply(iface, dot + 1,
>>> announce_ttl);
>>> +   }
>>> break;
>>>
>>> case TYPE_:
>>
>>
>>
>> Isn't this failing to take into account the case when there is no
>> hostname?
>>
>> With 480d7bc74eba20c03875aa06c1c25dbdb98e0b12 running on SKWB8:
>>
>> $ sudo systemctl restart avahi-daemon
>> $ avahi-browse -ck '_ssh._tcp'
>> $ avahi-browse -tk '_ssh._tcp'
>> + enp0s25 IPv6 linux-vf7n_ssh._tcp
>>local
>> + enp0s25 IPv4 linux-vf7n_ssh._tcp
>>local
>> $ avahi-browse -atk
>> + enp0s25 IPv6 SKWB8
>> _skhttp._tcp local
>> + enp0s25 IPv6 SKWB8
>> _skjitter._tcp   local
>> + enp0s25 IPv6 SKWB8 _ssh._tcp
>>local
>> + enp0s25 IPv6 linux-vf7n_ssh._tcp
>>local
>> + enp0s25 IPv4 linux-vf7n_ssh._tcp
>>local
>> + enp0s25 IPv4 SKWB8
>> _skhttp._tcp local
>> + enp0s25 IPv4 SKWB8
>> _skjitter._tcp   local
>> + enp0s25 IPv4 SKWB8 _ssh._tcp
>>local
>> + enp0s25 IPv6 linux-vf7n
>> _sftp-ssh._tcp   local
>> + enp0s25 IPv6 linux-vf7n [14:da:e9:f7:1b:95]
>> _workstation._tcplocal
>> + enp0s25 IPv4 linux-vf7n
>> _sftp-ssh._tcp   local
>> + enp0s25 IPv4 linux-vf7n [14:da:e9:f7:1b:95]
>> _workstation._tcplocal
>> $ avahi-browse -ck '_ssh._tcp'
>> + enp0s25 IPv6 SKWB8 _ssh._tcp
>>local
>> + enp0s25 IPv6 linux-vf7n_ssh._tcp
>>local
>> + enp0s25 IPv4 SKWB8 _ssh._tcp
>>local
>> + enp0s25 IPv4 linux-vf7n_ssh._tcp
>>local
>> $ avahi-browse -tk '_ssh._tcp'
>> + enp0s25 IPv6 SKWB8 _ssh._tcp
>>local
>> + enp0s25 IPv6 linux-vf7n_ssh._tcp
>>local
>> + enp0s25 IPv4 SKWB8 _ssh._tcp
>>local
>> + enp0s25 IPv4 linux-vf7n_ssh._tcp
>>local
>> $
>>
>> When running with -d umdns says things like
>>
>> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
>> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
>> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
>> mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
>> mdnsd: parse_question (366): Q -> PTR _services._dns-sd._udp.local
>> mdnsd: dns_send_answer (178): A <- A SKWB8.local
>> mdnsd: dns_send_answer (178): A <-  SKWB8.local
>> mdnsd: dns_send_answer (178): A <- PTR _services._dns-sd._udp.local
>> mdnsd: dns_send_answer (178): A <- PTR _skhttp._tcp.local
>> 

Re: [LEDE-DEV] [PATCH mdns] Fix sending replies to PTR questions

[Rafał Miłecki]

On 04/21/2017 03:31 PM, Cristian Morales Vega wrote:

On 13 February 2017 at 15:42, Rafał Miłecki  wrote:

From: Rafał Miłecki 

When we receive PTR question it includes hostname (instance), e.g.:
mdnsd: parse_question (391): Q -> PTR lede._http._tcp.local

First of all we should check if it matches hostname we use before trying
to reply. Secondly service_reply expects service with domain appended
(without hostname/instance) so we need to strip received string out of
hostname before passing it.

Signed-off-by: Rafał Miłecki 
---
 dns.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/dns.c b/dns.c
index 91434f2..dac6f2c 100644
--- a/dns.c
+++ b/dns.c
@@ -367,9 +367,19 @@ parse_question(struct interface *iface, char *name, struct 
dns_question *q)
break;

case TYPE_PTR:
-   if (!strcmp(name, sdudp))
+   if (!strcmp(name, sdudp)) {
service_announce_services(iface, announce_ttl);
-   service_reply(iface, name, announce_ttl);
+   } else {
+   /* First dot separates instance name from the rest */
+   char *dot = strchr(name, '.');
+   /* Length of queried instance */
+   size_t len = dot ? dot - name : 0;
+
+   /* Make sure it's query for the instance name we use */
+   if (len && len == strlen(mdns_hostname) &&
+   !strncmp(name, mdns_hostname, len))
+   service_reply(iface, dot + 1, announce_ttl);
+   }
break;

case TYPE_:



Isn't this failing to take into account the case when there is no hostname?

With 480d7bc74eba20c03875aa06c1c25dbdb98e0b12 running on SKWB8:

$ sudo systemctl restart avahi-daemon
$ avahi-browse -ck '_ssh._tcp'
$ avahi-browse -tk '_ssh._tcp'
+ enp0s25 IPv6 linux-vf7n_ssh._tcp
   local
+ enp0s25 IPv4 linux-vf7n_ssh._tcp
   local
$ avahi-browse -atk
+ enp0s25 IPv6 SKWB8
_skhttp._tcp local
+ enp0s25 IPv6 SKWB8
_skjitter._tcp   local
+ enp0s25 IPv6 SKWB8 _ssh._tcp
   local
+ enp0s25 IPv6 linux-vf7n_ssh._tcp
   local
+ enp0s25 IPv4 linux-vf7n_ssh._tcp
   local
+ enp0s25 IPv4 SKWB8
_skhttp._tcp local
+ enp0s25 IPv4 SKWB8
_skjitter._tcp   local
+ enp0s25 IPv4 SKWB8 _ssh._tcp
   local
+ enp0s25 IPv6 linux-vf7n
_sftp-ssh._tcp   local
+ enp0s25 IPv6 linux-vf7n [14:da:e9:f7:1b:95]
_workstation._tcplocal
+ enp0s25 IPv4 linux-vf7n
_sftp-ssh._tcp   local
+ enp0s25 IPv4 linux-vf7n [14:da:e9:f7:1b:95]
_workstation._tcplocal
$ avahi-browse -ck '_ssh._tcp'
+ enp0s25 IPv6 SKWB8 _ssh._tcp
   local
+ enp0s25 IPv6 linux-vf7n_ssh._tcp
   local
+ enp0s25 IPv4 SKWB8 _ssh._tcp
   local
+ enp0s25 IPv4 linux-vf7n_ssh._tcp
   local
$ avahi-browse -tk '_ssh._tcp'
+ enp0s25 IPv6 SKWB8 _ssh._tcp
   local
+ enp0s25 IPv6 linux-vf7n_ssh._tcp
   local
+ enp0s25 IPv4 SKWB8 _ssh._tcp
   local
+ enp0s25 IPv4 linux-vf7n_ssh._tcp
   local
$

When running with -d umdns says things like

mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
mdnsd: parse_question (366): Q -> PTR _skhttp._tcp.local
mdnsd: parse_question (366): Q -> PTR _services._dns-sd._udp.local
mdnsd: dns_send_answer (178): A <- A SKWB8.local
mdnsd: dns_send_answer (178): A <-  SKWB8.local
mdnsd: dns_send_answer (178): A <- PTR _services._dns-sd._udp.local
mdnsd: dns_send_answer (178): A <- PTR _skhttp._tcp.local
mdnsd: dns_send_answer (178): A <- SRV SKWB8._skhttp._tcp.local
mdnsd: dns_send_answer (178): A <- TXT SKWB8._skhttp._tcp.local
mdnsd: dns_send_answer (178): A <- PTR _services._dns-sd._udp.local
mdnsd: dns_send_answer (178): A <- PTR _skjitter._tcp.local
mdnsd: dns_send_answer (178): A <- SRV SKWB8._skjitter._tcp.local
mdnsd: dns_send_answer (178): A <- TXT SKWB8._skjitter._tcp.local
mdnsd: dns_send_answer (178): A <- PTR _services._dns-sd._udp.local
mdnsd: dns_send_answer (178): A <- PTR _ssh._tcp.local
mdnsd: dns_send_answer (178): A <- SRV SKWB8._ssh._tcp.local
mdnsd: dns_send_answer (178): A <- TXT SKWB8._ssh._tcp.local

So it's seems it's not answering to the _ssh._tcp 

[LEDE-DEV] [PATCH umdns 1/3] Rename mdns_hostname variable to the umdns_host_label

[Rafał Miłecki]

From: Rafał Miłecki 

In the whole RFC 6762 document "host name" means a fully qualified
domain name. The value we store in this variable is just a first label
of the name so rename it properly to make the code just a bit easier to
follow.

Signed-off-by: Rafał Miłecki 
---
 dns.c | 6 +++---
 service.c | 2 +-
 util.c| 6 +++---
 util.h| 9 -
 4 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/dns.c b/dns.c
index d384f58..68a088f 100644
--- a/dns.c
+++ b/dns.c
@@ -384,8 +384,8 @@ parse_question(struct interface *iface, struct sockaddr 
*from, char *name, struc
size_t len = dot ? dot - name : 0;
 
/* Make sure it's query for the instance name we use */
-   if (len && len == strlen(mdns_hostname) &&
-   !strncmp(name, mdns_hostname, len))
+   if (len && len == strlen(umdns_host_label) &&
+   !strncmp(name, umdns_host_label, len))
service_reply(iface, to, dot + 1, announce_ttl);
}
break;
@@ -395,7 +395,7 @@ parse_question(struct interface *iface, struct sockaddr 
*from, char *name, struc
host = strstr(name, ".local");
if (host)
*host = '\0';
-   if (!strcmp(mdns_hostname, name))
+   if (!strcmp(umdns_host_label, name))
dns_reply_a(iface, to, announce_ttl);
break;
};
diff --git a/service.c b/service.c
index ca70274..8e0e493 100644
--- a/service.c
+++ b/service.c
@@ -72,7 +72,7 @@ service_name(const char *domain)
 {
static char buffer[256];
 
-   snprintf(buffer, sizeof(buffer), "%s.%s", mdns_hostname, domain);
+   snprintf(buffer, sizeof(buffer), "%s.%s", umdns_host_label, domain);
 
return buffer;
 }
diff --git a/util.c b/util.c
index 63f1612..f5cfdb8 100644
--- a/util.c
+++ b/util.c
@@ -35,7 +35,7 @@
 uint8_t mdns_buf[MDNS_BUF_LEN];
 int debug = 0;
 
-char mdns_hostname[HOSTNAME_LEN];
+char umdns_host_label[HOSTNAME_LEN];
 char mdns_hostname_local[HOSTNAME_LEN + 6];
 
 uint32_t
@@ -65,13 +65,13 @@ void get_hostname(void)
 {
struct utsname utsname;
 
-   mdns_hostname[0] = 0;
+   umdns_host_label[0] = 0;
mdns_hostname_local[0] = 0;
 
if (uname() < 0)
return;
 
-   snprintf(mdns_hostname, sizeof(mdns_hostname), "%s", utsname.nodename);
+   snprintf(umdns_host_label, sizeof(umdns_host_label), "%s", 
utsname.nodename);
snprintf(mdns_hostname_local, sizeof(mdns_hostname_local), "%s.local", 
utsname.nodename);
 }
 
diff --git a/util.h b/util.h
index efee5dc..c0db9e7 100644
--- a/util.h
+++ b/util.h
@@ -27,7 +27,14 @@
 
 extern int debug;
 extern uint8_t mdns_buf[MDNS_BUF_LEN];
-extern char mdns_hostname[HOSTNAME_LEN];
+
+/**
+ * The first label of a host's fully qualified domain name
+ *
+ * E.g. just "example" for the domain name example.local.
+ */
+extern char umdns_host_label[HOSTNAME_LEN];
+
 extern char mdns_hostname_local[HOSTNAME_LEN + 6];
 
 extern void get_hostname(void);
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH umdns 3/3] Support specifying instance name in JSON file

[Rafał Miłecki]

From: Rafał Miłecki 

So far we were using host label as the instance name for every service.
This change allows specifying it manually and fallbacks to the label for
backward compatibility.

Signed-off-by: Rafał Miłecki 
---
 service.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/service.c b/service.c
index c8187de..253dec3 100644
--- a/service.c
+++ b/service.c
@@ -34,6 +34,7 @@
 #include "announce.h"
 
 enum {
+   SERVICE_INSTANCE,
SERVICE_SERVICE,
SERVICE_PORT,
SERVICE_TXT,
@@ -46,6 +47,7 @@ struct service {
time_t t;
 
const char *id;
+   const char *instance;
const char *service;
const uint8_t *txt;
int txt_len;
@@ -54,6 +56,7 @@ struct service {
 };
 
 static const struct blobmsg_policy service_policy[__SERVICE_MAX] = {
+   [SERVICE_INSTANCE] = { .name = "instance", .type = BLOBMSG_TYPE_STRING 
},
[SERVICE_SERVICE] = { .name = "service", .type = BLOBMSG_TYPE_STRING },
[SERVICE_PORT] = { .name = "port", .type = BLOBMSG_TYPE_INT32 },
[SERVICE_TXT] = { .name = "txt", .type = BLOBMSG_TYPE_ARRAY },
@@ -74,14 +77,15 @@ static int service_init_announce;
  *
  * Service Instance Name =  .  . 
  *
- * @service_domain: service name (a pair of labels) with domain name appended
+ * @s: service to generate service instance name for
  */
 static const char *
-service_instance_name(const char *service_domain)
+service_instance_name(struct service *s)
 {
+   const char *instance = s->instance ? : umdns_host_label;
static char buffer[256];
 
-   snprintf(buffer, sizeof(buffer), "%s.%s", umdns_host_label, 
service_domain);
+   snprintf(buffer, sizeof(buffer), "%s.%s", instance, s->service);
 
return buffer;
 }
@@ -127,7 +131,7 @@ service_timeout(struct service *s)
 static void
 service_reply_single(struct interface *iface, struct sockaddr *to, struct 
service *s, int ttl, int force)
 {
-   const char *host = service_instance_name(s->service);
+   const char *host = service_instance_name(s);
char *service = strstr(host, "._");
time_t t = service_timeout(s);
 
@@ -140,7 +144,7 @@ service_reply_single(struct interface *iface, struct 
sockaddr *to, struct servic
s->t = t;
 
dns_init_answer();
-   service_add_ptr(service_instance_name(s->service), ttl);
+   service_add_ptr(service_instance_name(s), ttl);
dns_send_answer(iface, to, service);
 
dns_init_answer();
@@ -206,7 +210,7 @@ service_load_blob(struct blob_attr *b)
 {
struct blob_attr *txt, *_tb[__SERVICE_MAX];
struct service *s;
-   char *d_service, *d_id;
+   char *d_instance, *d_service, *d_id;
uint8_t *d_txt;
int rem2;
int txt_len = 0;
@@ -222,6 +226,7 @@ service_load_blob(struct blob_attr *b)
 
s = calloc_a(sizeof(*s),
_id, strlen(blobmsg_name(b)) + 1,
+   _instance, _tb[SERVICE_INSTANCE] ? 
strlen(blobmsg_get_string(_tb[SERVICE_INSTANCE])) + 1 : 0,
_service, strlen(blobmsg_get_string(_tb[SERVICE_SERVICE])) + 
1,
_txt, txt_len);
if (!s)
@@ -229,6 +234,8 @@ service_load_blob(struct blob_attr *b)
 
s->port = blobmsg_get_u32(_tb[SERVICE_PORT]);
s->id = strcpy(d_id, blobmsg_name(b));
+   if (_tb[SERVICE_INSTANCE])
+   s->instance = strcpy(d_instance, 
blobmsg_get_string(_tb[SERVICE_INSTANCE]));
s->service = strcpy(d_service, 
blobmsg_get_string(_tb[SERVICE_SERVICE]));
s->active = 1;
s->t = 0;
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH umdns 2/3] Rename service_name function to the service_instance_name

[Rafał Miłecki]

From: Rafał Miłecki 

This name matches what is really returned by the function according to
the RFC 6763. Also document it while at it.

Signed-off-by: Rafał Miłecki 
---
 service.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/service.c b/service.c
index 8e0e493..c8187de 100644
--- a/service.c
+++ b/service.c
@@ -67,12 +67,21 @@ static struct blob_buf b;
 static VLIST_TREE(services, avl_strcmp, service_update, false, false);
 static int service_init_announce;
 
+/**
+ * service_instance_name - construct Service Instance Name as in RFC 6763
+ *
+ * RFC 6763 specifies Service Instance Names in the following way:
+ *
+ * Service Instance Name =  .  . 
+ *
+ * @service_domain: service name (a pair of labels) with domain name appended
+ */
 static const char *
-service_name(const char *domain)
+service_instance_name(const char *service_domain)
 {
static char buffer[256];
 
-   snprintf(buffer, sizeof(buffer), "%s.%s", umdns_host_label, domain);
+   snprintf(buffer, sizeof(buffer), "%s.%s", umdns_host_label, 
service_domain);
 
return buffer;
 }
@@ -118,7 +127,7 @@ service_timeout(struct service *s)
 static void
 service_reply_single(struct interface *iface, struct sockaddr *to, struct 
service *s, int ttl, int force)
 {
-   const char *host = service_name(s->service);
+   const char *host = service_instance_name(s->service);
char *service = strstr(host, "._");
time_t t = service_timeout(s);
 
@@ -131,7 +140,7 @@ service_reply_single(struct interface *iface, struct 
sockaddr *to, struct servic
s->t = t;
 
dns_init_answer();
-   service_add_ptr(service_name(s->service), ttl);
+   service_add_ptr(service_instance_name(s->service), ttl);
dns_send_answer(iface, to, service);
 
dns_init_answer();
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] GSOC 2017 - Implement NetJSON output in ubus (OpenWRT/LEDE)

[Nemesis]

Hi Arun,

welcome to the community!

Just to provide more information, we have to thank Freifunk for their
help in getting this GSOC slot, here's the abstract that got this
project started:

https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29

Best regards
Federico


On 05/10/2017 11:24 AM, Arun Kumar wrote:
> Hi Developers,
> 
> I am Arunkumar Ravichandran currently admitted for masters program at
> University of California, San Diego. My proposal [1] Implement NetJSON
> output in ubus (OpenWRT/LEDE) has been accepted to the GSOC 2017 and I
> would like to tell more about my proposed project.
> 
> The main aim of this project is to implement parts of the NetJSON[2]
> specification in the OpenWRT/LEDE ecosystem.
> 
> Why NetJSON ??
> NetJSON would allow standardization similar to NETCONF. Since NetJSON
> uses JSON format, it makes the management of configurations done at a
> higher level and larger scale to be automated easily. By using NetJSON
> objects to either produce or collect information, in different
> vendor’s different hardware, it allows the developers to work on their
> ideas faster and in a better way.
> 
> Implementation:
> The support for NETJSON is brought in at the interconnect system-
> ubus[3]. To add support for a new ubus API which allows retrieving
> these two NetJSON object types: DeviceConfiguration[6] and
> DeviceMonitoring[7]. The NetJSON objects are filled in using the
> plugins available in System Configuration Abstraction Layer(SCAL)[4].
> Full project proposal can be read at [5].
> 
> I would welcome further suggestions from the LEDE/ OpenWRT community
> as that would help in implementing this feature sooner and in a better
> way, and also more resilient to multiple data models which are being
> used to represent network configurations.
> 
> [1] 
> https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29
> [2] https://github.com/netjson/netjson
> [3] https://lede-project.org/docs/guide-developer/ubus
> [4] https://github.com/prplfoundation/scal
> [5] 
> https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing
> [6] http://netjson.org/docs/what.html#deviceconfiguration
> [7] http://netjson.org/docs/what.html#devicemonitoring
> 
> Thanks,
> Arun
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal

[Yousong Zhou]

So many items to vote and work on.  I would suggest we sort out those
formal things first, e.g. project rules, umbrella project etc.  I do
not know much about the past history apart from those posts in the
public mailing list.  But if these formal things were the major cause
of the split in the first place, they should be put forward and
tackled first.

Those technical ones are relatively easy for us I guess and not that
urgent anyway because we already have one infrastructure up and
running (not bad and I guess you will also agree) and the other one in
quiescent state for quite a while now.  From what I see it's mostly
just about how to do the name change...

my two cents

Regards,
yousong


On 8 May 2017 at 21:19, John Crispin  wrote:
> Hi,
>
> Felix, Imre and myself had 2 calls last week lasting several hours and
> discussed the following proposal of conditions for a remerge that we would
> like to propose and have people vote on.
>
> *) branding
> - the owrt side sees no option of using the lede brand
>
> - a (minor) majority voted for openwrt as a name over lede whilst most
> people said they did not care
>
> - as the last vote had a 100% ACK for a remerge using the owrt brand is the
> only feasible option
>
> *) domain
> - transfer owner ship to SPI for openwrt.org and lede-project.org
> - add them to the pool of urls at digital ocean
> - post remerge build a setup where we have several DNS servers in various
> locations
> - point git.openwrt.org at the lede git server
> - point bugs.openwrt.org to the lede flyspray instance
> - keep both wikis and forums as is (we should decide post remerge how to
> proceed to avoid these issues blocking the progress)
> - update the lede domain entries for build/download/rsync/... servers so
> that the openwrt domain also points at them
>
> *) SPI
> - TBD post remerge
>
> *) github
> - stop pushing to lede-project organisation
> - start pushing to the openwrt organisation
> - cleanup the list of owners in the openwrt organisation
> - obsolete all issues on the openwrt organisation and close the issue
> tracker
> - go through the open openwrt and lede PRs, pickup whats useful and close
> the rest, asking people to repost (things wont be rebasable anyhow)
> - close the lede PR tracker
> - keep the lede organisation in its current state so that forked trees dont
> get obsoleted
>
> - obsolete the lede github org after a grace period of 3-6 months
>
> *) landing page
> - update the lede landing page to represent the openwrt name
> - update the landing page to have the same look & feel as the current
> openwrt landing page
> - point openwrt.org at the lede landing page
>
> *) trac
> - trac is already readonly, keep content so that search engines can still
> find the it
> - edit the trac html templates, adding a note pointing at the
> bug.openwrt.org instance
>
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts
> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
> anyone with voting rights can be subscribed to
> - ask those people that are no longer active to voluntarily give up their
> accounts
> - mail addresses may under no conditions be used for any personal business,
> consultancy, applying for jobs, ... purposes
>
> - any mail sent from an openwrt.org account needs to adhere the trademark
> policy and should only be used for FOSS purposes
>
>
> *) wiki / forum
> - TBD
> - asking in either forum/wiki will get a biased vote so keep them both
> around
> - start a separate discussion regarding these post remerge
>
> *) LF
> - find out what doubts folks have about LF
> - find out benefits - we would have their hosting and sponsorship ?!
> - start a separate discussion regarding these post remerge
>
> *) git trees
> - rebrand the lede tree to openwrt
> - work out what has happened inside the openwrt tree since the reboot and
> pick up the useful bits (zoltan has done some prior work on this already)
>
> *) mailing list
> - ask david to add the openwrt-adm and openwrt lists
> - announce the switch to the infradead serves, asking people to unsubscribe
> if they have privacy issues with this
> - import the user DB from the current openwrt and lede ML into the 2 new
> mailing lists
> - find out if we can redirect/auto-reply  the existing lists to the new ones
>
> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy
>
> *) timeline
> - refine / vote / agree on the proposal withing the next 2 week
> - work on the action items in the 4 weeks after that
>
> John
> ___
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Imre Kaloz]

On 2017-05-09 18:29, Philip Prindeville wrote:




I’d like to suggest one more action item to this list if I can.  It would be 
handy to have a single database for user authentication/identification for 
submitting bugs, editing the Wiki, etc.

Previously there were too many places where you had to create an account.  If 
we can’t do “single sign-on”, can we at least do “single sign-up”?

And part of a user’s profile should include their IRC handle (assuming they 
have one).


I agree, SSO would be way more user friendly. We should look into it for 
sure.



Best,

Imre

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] GSOC 2017 - Implement NetJSON output in ubus (OpenWRT/LEDE)

[Arun Kumar]

Hi Developers,

I am Arunkumar Ravichandran currently admitted for masters program at
University of California, San Diego. My proposal [1] Implement NetJSON
output in ubus (OpenWRT/LEDE) has been accepted to the GSOC 2017 and I
would like to tell more about my proposed project.

The main aim of this project is to implement parts of the NetJSON[2]
specification in the OpenWRT/LEDE ecosystem.

Why NetJSON ??
NetJSON would allow standardization similar to NETCONF. Since NetJSON
uses JSON format, it makes the management of configurations done at a
higher level and larger scale to be automated easily. By using NetJSON
objects to either produce or collect information, in different
vendor’s different hardware, it allows the developers to work on their
ideas faster and in a better way.

Implementation:
The support for NETJSON is brought in at the interconnect system-
ubus[3]. To add support for a new ubus API which allows retrieving
these two NetJSON object types: DeviceConfiguration[6] and
DeviceMonitoring[7]. The NetJSON objects are filled in using the
plugins available in System Configuration Abstraction Layer(SCAL)[4].
Full project proposal can be read at [5].

I would welcome further suggestions from the LEDE/ OpenWRT community
as that would help in implementing this feature sooner and in a better
way, and also more resilient to multiple data models which are being
used to represent network configurations.

[1] 
https://wiki.freifunk.net/Ideas#Implement_NetJSON_output_in_ubus_.28OpenWRT.2FLEDE.29
[2] https://github.com/netjson/netjson
[3] https://lede-project.org/docs/guide-developer/ubus
[4] https://github.com/prplfoundation/scal
[5] 
https://docs.google.com/document/d/1b6zersOA_GjUqbOjuaXvFd4E40l1MqUXjIyVagLLd08/edit?usp=sharing
[6] http://netjson.org/docs/what.html#deviceconfiguration
[7] http://netjson.org/docs/what.html#devicemonitoring

Thanks,
Arun

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev