Re: [LEDE-DEV] [PATCH 2/3] procd: Don't use syslog before its initialization

[Michal Sojka]

Hi David,

I understand what you're saying and you are right that there can be a
lot of problems (e.g. hangs) due logging. Some comments below.

On Sat, Mar 11 2017, David Lang wrote:
> On Sat, 11 Mar 2017, Michal Sojka wrote:
>
>> On Sat, Mar 11 2017, John Crispin wrote:
>>> On 11/03/17 01:48, Michal Sojka wrote:
 When procd starts a rcS script, it captures its stdout and stderr and
 logs them to syslog. It could happen (and I don't know exactly why),
 that a rcS scripts produces some output before openlog() is called in
 procd. The result is that all subsequent logs from procd are logged
 with ident and PID of some other service that happens to be started at
 that time. I also have no clue why this is happening (bug in musl?),
 but it is very confusing when one tries to debug boot problems.
>>>
>>> is there a way to reliably reproduce this issue ?
>>
>> I can reproduce it reliably with handful of custom packages. I'll try to
>> prepare a more simpler setup where this can be seen.
>
> This sounds like a problem with procd, capturing stdout and stderr and 
> feeding 
> them to syslog could cause a serious problem if the error messages are from 
> the 
> syslog daemon.
>
> it sounds like they are trying to emulate systemd, and that's not always a 
> good 
> thing :-)
>
> sending a bunch of things to syslog before the system is up can also run into 
> problems if the syslog daemon is configured to send the logs to a remote 
> server, 
> and can't reach it yet (all sorts of possible reasons for that).
>
> all sorts of programs spit various garbaage out to stdout or stderr that is 
> meaningless/debug stuff that really should not be turned on for production 
> use, 
> but was missed, this can cause a lot of log messages (and stderr messages in 
> particular tend to be very badly formed)
>
> this sort of thing in the init system needs safeguards, and those need to be 
> thought about.
>
> possibly try to deliver the log to syslog, but throw them away if the attempt 
> blocks

This would require not using syslog(3), but writing a non-blocking
variant of it. That's certainly possible, but I don't know how portable
it should such be for LEDE.

> possibly try to detect that it's starting the syslog daemon and skip 
> delivering 
> logs
>
> poosibly have the startup script for the logging daemon set some lock to turn 
> on 
> this functionality (and leave it up to that script to figure out when to do 
> that)

But the script does not know when the logging daemon is ready. Wouldn't
it be better for the logging daemon to notify procd when it is ready and
procd would start logging via it after that?

> and it should be configurable so that people can turn on/off stdout and/or 
> stderr capturing either per-script and/or globally

Now it's configurable for services, but not for scripts that start the
services.

-Michal

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

[LEDE-DEV] [PATCH v2] procd: Don't use syslog before its initialization

[Michal Sojka]

When procd starts a rcS script, it captures its stdout and stderr and
logs them via syslog(). The problem with that is that the rest of
procd code uses ulog rather than syslog() directly and ulog_open()
doesn't call openlog() immediately, but only after something is logged
with ulog(). This lazy calling of openlog() can result in the
following unwanted behavior:

1) When rcS's stdout/err is logged via syslog(), the log identifier is
   not set yet (due to openlog() not called) and so the log message
   lacks information about source.

2) procd can also log stdout/err from services. When a message from a
   service needs to be logged, ulog_open() is called to change the log
   identifier to match the service name/PID. After logging the service
   messages, ulog_open() is called again the change the identifier
   back to "procd". The lazy call to openlog() means that the messages
   logged directly with syslog() will be logged with the
   identification of the previously logged service and not of the rcS
   script that produced the message.

Both problems are fixed by replacing direct call to syslog() with
ULOG_NOTE, which automatically calls openlog() if needed.

Signed-off-by: Michal Sojka 
---
 rcS.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index 0208a75..4813146 100644
--- a/rcS.c
+++ b/rcS.c
@@ -54,7 +54,7 @@ static void pipe_cb(struct ustream *s, int bytes)
break;
*newline = 0;
len = newline + 1 - str;
-   syslog(LOG_NOTICE, "%s", str);
+   ULOG_NOTE("%s", str);
 #ifdef SHOW_BOOT_ON_CONSOLE
fprintf(stderr, "%s\n", str);
 #endif
-- 
2.11.0


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

Re: [LEDE-DEV] [PATCH 2/3] procd: Don't use syslog before its initialization

[Michal Sojka]

On Sat, Mar 11 2017, Michal Sojka wrote:
> On Sat, Mar 11 2017, John Crispin wrote:
>> On 11/03/17 01:48, Michal Sojka wrote:
>>> When procd starts a rcS script, it captures its stdout and stderr and
>>> logs them to syslog. It could happen (and I don't know exactly why),
>>> that a rcS scripts produces some output before openlog() is called in
>>> procd. The result is that all subsequent logs from procd are logged
>>> with ident and PID of some other service that happens to be started at
>>> that time. I also have no clue why this is happening (bug in musl?),
>>> but it is very confusing when one tries to debug boot problems.
>>
>> is there a way to reliably reproduce this issue ?
>
> I can reproduce it reliably with handful of custom packages. I'll try to
> prepare a more simpler setup where this can be seen.

I've figured out what exactly happened. The fix is correct, but the
commit message can be improved. I'll send v2 patch.

-Michal

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

[LEDE-DEV] [PATCH] Add i2c_801 i2c driver module support

[michael]

From: Michael Marley 

This driver supports the i2c controller on many Intel chipsets.
The patch also adds the i2c_smbus driver upon which i2c_i801
depends.

Signed-off-by: Michael Marley 
---
 package/kernel/linux/modules/i2c.mk | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/package/kernel/linux/modules/i2c.mk 
b/package/kernel/linux/modules/i2c.mk
index 7e85ef3d9d..6fe163ceeb 100644
--- a/package/kernel/linux/modules/i2c.mk
+++ b/package/kernel/linux/modules/i2c.mk
@@ -87,6 +87,21 @@ endef
 
 $(eval $(call KernelPackage,i2c-algo-pcf))
 
+I2C_SMBUS_MODULES:= \
+  CONFIG_I2C_SMBUS:drivers/i2c/i2c-smbus
+
+define KernelPackage/i2c-smbus
+  $(call i2c_defaults,$(I2C_SMBUS_MODULES),55)
+  TITLE:=I2C SMBUS extensions
+  DEPENDS:=kmod-i2c-core
+endef
+
+define KernelPackage/i2c-smbus/description
+ Kernel modules for I2C SMBUS extensions
+endef
+
+$(eval $(call KernelPackage,i2c-smbus))
+
 
 I2C_GPIO_MODULES:= \
   CONFIG_I2C_GPIO:drivers/i2c/busses/i2c-gpio
@@ -202,3 +217,18 @@ define KernelPackage/i2c-mux-pca9541/description
 endef
 
 $(eval $(call KernelPackage,i2c-mux-pca9541))
+
+I2C_I801_MODULES:= \
+  CONFIG_I2C_I801:drivers/i2c/busses/i2c-i801
+
+define KernelPackage/i2c-i801
+  $(call i2c_defaults,$(I2C_I801_MODULES),59)
+  TITLE:=Intel 801 and compatible I2C interfaces
+  DEPENDS:=@PCI_SUPPORT @(x86||x86_64) kmod-i2c-core +kmod-i2c-smbus
+endef
+
+define KernelPackage/i2c-i801/description
+ Kernel module for Intel ICH and PCH i2c controllers
+endef
+
+$(eval $(call KernelPackage,i2c-i801))
-- 
2.11.0


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

[LEDE-DEV] [PATCH] kernel: Add intel_idle driver to x86_64 build

[michael]

From: Michael Marley 

This driver supports CPU-specific idle features on recent Intel
processors.  It does not conflict with the ACPI idle driver and
that driver will continue to be used for unsupported and non-Intel
processors.

Signed-off-by: Michael Marley 
---
 target/linux/x86/64/config-default | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/x86/64/config-default 
b/target/linux/x86/64/config-default
index 04ed3fa8a2..840371c581 100644
--- a/target/linux/x86/64/config-default
+++ b/target/linux/x86/64/config-default
@@ -182,6 +182,7 @@ CONFIG_HYPERV_UTILS=y
 # CONFIG_I7300_IDLE is not set
 # CONFIG_IA32_EMULATION is not set
 CONFIG_ILLEGAL_POINTER_VALUE=0xdead
+CONFIG_INTEL_IDLE=y
 # CONFIG_INTEL_IPS is not set
 # CONFIG_INTEL_MENLOW is not set
 # CONFIG_INTEL_MIC_BUS is not set
-- 
2.11.0


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

[LEDE-DEV] [PATCH] kernel: Add coretemp driver to x86_64 build

[michael]

From: Michael Marley 

The x86_64 build already has the k10temp driver for AMD processors
built in, so this patch adds the coretemp driver for the same
functionality on Intel processors.

Signed-off-by: Michael Marley 
---
 target/linux/x86/64/config-default | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/x86/64/config-default 
b/target/linux/x86/64/config-default
index 35c6a5e711..04ed3fa8a2 100644
--- a/target/linux/x86/64/config-default
+++ b/target/linux/x86/64/config-default
@@ -264,6 +264,7 @@ CONFIG_SCHED_MC=y
 CONFIG_SCHED_SMT=y
 # CONFIG_SCIF_BUS is not set
 CONFIG_SCSI_VIRTIO=y
+CONFIG_SENSORS_CORETEMP=y
 CONFIG_SENSORS_K10TEMP=y
 CONFIG_SERIAL_8250_PNP=y
 CONFIG_SMP=y
-- 
2.11.0


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

[LEDE-DEV] [PATCH] kernel: Add iTCO_wdt watchdog timer module support

[michael]

From: Michael Marley 

This supports the Intel TCO Watchdog Timer Device, which has been
nearly ubiquitous in Intel chipsets for almost 20 years.

Signed-off-by: Michael Marley 
---
 package/kernel/linux/modules/other.mk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index 40869c6bb0..6b7afb75d9 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -1003,3 +1003,18 @@ define KernelPackage/tpm-i2c-atmel/description
 endef
 
 $(eval $(call KernelPackage,tpm-i2c-atmel))
+
+define KernelPackage/iTCO_wdt
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=Intel TCO watchdog timer driver
+  KCONFIG:=CONFIG_ITCO_WDT
+  FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/iTCO_wdt.ko
+  AUTOLOAD:=$(call AutoLoad,40,iTCO_wdt,1)
+endef
+
+define KernelPackage/iTCO_wdt/description
+   This enables the driver for the watchdog timer hardware included in
+   many Intel chipsets.
+endef
+
+$(eval $(call KernelPackage,iTCO_wdt))
-- 
2.11.0


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

[LEDE-DEV] [PATCH 2/2] x86: image: drop unneeded grub call

[Rafał Miłecki]

From: Rafał Miłecki 

It appears there isn't any Image/Build/grub/* define so this step looks
redundant.

Signed-off-by: Rafał Miłecki 
---
 target/linux/x86/image/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index a2df0af301..ef5b3c03c8 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux/x86/image/Makefile
@@ -93,7 +93,6 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
-d "$(KDIR)/grub2" \
-r "hd0,msdos1" \
"$(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).img"
-   $(call Image/Build/grub/$(1))
   endef
 endif
 
-- 
2.11.0


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

[LEDE-DEV] [PATCH 1/2] x86: image: drop unused ROOTDELAY variable

[Rafał Miłecki]

From: Rafał Miłecki 

It's unused since commit 742700719303 ("x86: remove the olpc subtarget,
it has been unmaintained for a long time").

Signed-off-by: Rafał Miłecki 
---
 target/linux/x86/image/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index 965737ac63..a2df0af301 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux/x86/image/Makefile
@@ -97,8 +97,6 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
   endef
 endif
 
-ROOTDELAY=10
-
 define Image/Build/squashfs
dd if=/dev/zero bs=128k count=1 >> $(KDIR)/root.squashfs
 endef
-- 
2.11.0


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

Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[Hans Dedecker]

Hi,

On Wed, Mar 8, 2017 at 10:23 PM, JORDI PALET MARTINEZ
 wrote:
> Hi Hans,
>
> I believe you’re the maintainer of 464XLAT. I want to do demonstrations of 
> OpenWRT/LEDE in scenarios where you run out of IPv4 addresses for the WAN 
> links.
>
> Sorry to write you directly, but I’ve been trying for many hours to find more 
> info as I’m not succeeding to configure a CLAT to work in a very simple 
> scenario.
I've added LEDE development mailing list in CC as the info could be
usefull for other persons who're trying to use 464xlat
>
> The main problem is that I don’t know what are the parameters needed in the 
> network file.
The 464xlat feature is currently broken on LEDE as the 464xlat netifd
logic have been reverted
(https://git.lede-project.org/?p=project/netifd.git;a=commit;h=39d9ceeb96162a83a3f5fa63e6aaa1ccb38caa62)
as it changed the default behavior of user ip rules in unexpected
ways. This can easily be checked by the ip rule list cmd as it should
contain a rule to the prelocal table.
>
> My scenario is quite simple. I’ve a virtual machine with Ubuntu running a 
> DNS64 with bind9 and NAT64 with Jool. This has been tested and is working.
>
> In the router where I want to run CLAT, I’ve:
>
> 1) WAN interface configured only with an IPv6 address (and of course I’ve 
> checked that I can ping from here to the DNS/NAT64 and Internet with IPv6).
> 2) LAN interface with an IPv6 prefix /64, an IPv4 /24 (private), and DHCP and 
> SLAAC running. I can ping with both IPv4 and IPv6 to the router.
>
> I tried both with Luci and editing the network file.
>
> I don’t understand what it means tunlink (is it the WAN with only IPv6 
> interface?). Should I configure additional addresses for the CLAT? According 
> the 464XLAT RFC I need 3 IPv6/prefixes (WAN/LAN/translation).
tunlink is indeed the logical interface on which the 464xlat interface
depends; in this case it's the IPv6 wan interface
>
> By the way, for the NAT64, I’m using the standard prefix 64:ff9b::/96.
>
> Do I need to do any special configuration in the rest of the interfaces or 
> the firewall to make it work?
You need to specify to which firewall zone the 464xlat interface
belongs via the zone UCI parameter; usually this is the wan zone
>
> I hope you have a sample configuration for the network and firewall files 
> that I can understand what I’m doing wrong or missing. It may be something 
> really silly but I’m unable to see it.
>
First you need to verify if you're using a build which still supports
464xlat otherwise even with a correct config it won't work ...

Hans
> Thanks a lot!
>
> By the way, we just submitted a new IETF draft to allow configuring the CLAT 
> (and other protocols related to NAT64 usage) by DHCPv6 options:
>
> https://www.ietf.org/id/draft-li-intarea-nat64-prefix-dhcp-option-00.txt
>
> Regards,
> Jordi
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, including attached files, is prohibited.
>
>
>

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

Re: [LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Paul Oranje]

Small addition (the following may be non-obvious to those not involved in this 
discussion).
Just saw that A_TA does not have renewal (T1) or rebinding (T2) fields and for 
that reason cannot suit a use-case like a IA just for a work shift.
-- 
Paul


> Op 11 mrt. 2017, om 13:21 heeft Paul Oranje  het volgende 
> geschreven:
> 
>> 
>> Op 11 mrt. 2017, om 06:09 heeft Eric Luehrsen  het 
>> volgende geschreven:
>> 
>> On 03/10/2017 09:09 AM, Bjørn Mork wrote:
>>> Eric Luehrsen  writes:
 It appears many other severs and clients dont implement IA_TA. Its a lost 
 option.
>>> Sure. Very few want this feature. We must however assume that those
>>> who do want it will implement it.
>> We must however assume nothing. We may assume something while patiently 
>> waiting for information so we can progress on an idea.
 It should not break "expectations" as this an central administrative
 option.
>>> A client requesting an IA_NA expects a non-temporary address.
>>> 
>> I hate being "legislative" about engineering, but it looks like this is 
>> headed that way, so I'll bite. First in all engineering requirements you 
>> must define your terms. "non-temporary" does not mean "permanent" and it 
>> appears it is carefully avoided as such. In fact the only implied 
>> definition through the chain of RFC is "non-temporary" is just not the 
>> same as "temporary." "temporary" could be summarized as having the 
>> potential for even per connection or per application duration. With that 
>> "non-temporary" can reasonably be defined by the local site 
>> administration as a work shift (8hrs) or something like that.
> rfc3315#section-12 refers to rfc3041 for the definition of temporary 
> addresses.
> The usage of temporary addresses by rfc3041 (Privacy Extensions for Stateless 
> Address Autoconfiguration in IPv6) seems to imply, a contrario, that 
> non-temporary addresses are _not_ to be used for the privacy purposes.
> Strictly logically this implication is incorrect, but still it very much 
> aligns with understandable and reasonable expectations. Anyway, non-temporary 
> isn’t the same as permanent.
> 
>> This means "non-temporary" is a policy decision by the organization 
>> management ("oh no" software engineers cry, "not management"). If 
>> management wants DHCPv6 to provide a single address per user level 
>> machine, then that's their decision to make. If management wants that 
>> each work day or each work shift enumerates all user level machines 
>> differently, then that's their decision to make.  DHCPv6 IA_NA then is 
>> the one and only address that your issued device gets, and it is 
>> different each work day. Static servers may have predefined host 
>> assignments, which I only mention for completeness.
> 
 If central IT doesnt want user base devices to be permanently reachable
 or traceable, then that is their authority to choose.
>>> Definitely.  They can easily achieve this by not providing any IA_NA
>>> adresses.
>> How is that an answer for above management attempting to implement a 
>> particular policy? DHCPv6 IA_TA is not option for (any?) clients. By 
>> your implied definition, a client device would get also an IA_NA that is 
>> "more lasting." It may try to use it, but management doesn't want that. 
>> DHCPv6 without something else leaves devices easily profiled from 
>> external snooping. It's not MAC but not good either. SLAAC exposes the 
>> MAC publicly. SLAAC+privacy is internally difficult to trace, so likely 
>> fail accountability. SLAAC w/ RA rolling hash isn't any more implemented 
>> than IA_TA.
> (mind you, I am not an expert and the following could be utter nonsense).
> Given these use-cases (IAs per work shift etc), why couldn’t these be 
> fulfilled with IA_TA ?
> Both types of associations are within control of the server and hence of 
> whatever management policy, or would the use of IA_NA be necessitated because 
> clients tend not request these ?
> If so, then use of IA_TA is a client policy, and support of those by the 
> DHCPv6 server would be nice. Where the intended enhancement of privacy is a 
> server policy and the client does not request IA_TA, use of IA_NA for this 
> purpose seems alright since whatever address is provided is within the realm 
> of the server for whatever policy it implements thereby.
> 
>>> 
 But on the flip side, central IT doesnt want the insanity of SLAAC
 Privacy all over their network. Consider a fortune 500 company or
 university with accountibilty and traceability in legal or internal
 policy requirements.
 
 RFC are so namef for a reason and a good working model can change them.
>>> OK, I think you just explained your level of understanding.  Thanks
>> I'll pretend that it doesn't mean how it reads.
> I’ve read the sentence a few times over and still cannot make out what would 
> be meant be it. Still given the effort made to 

Re: [LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Paul Oranje]

> Op 11 mrt. 2017, om 06:09 heeft Eric Luehrsen  het 
> volgende geschreven:
> 
> On 03/10/2017 09:09 AM, Bjørn Mork wrote:
>> Eric Luehrsen  writes:
>>> It appears many other severs and clients dont implement IA_TA. Its a lost 
>>> option.
>> Sure. Very few want this feature. We must however assume that those
>> who do want it will implement it.
> We must however assume nothing. We may assume something while patiently 
> waiting for information so we can progress on an idea.
>>> It should not break "expectations" as this an central administrative
>>> option.
>> A client requesting an IA_NA expects a non-temporary address.
>> 
> I hate being "legislative" about engineering, but it looks like this is 
> headed that way, so I'll bite. First in all engineering requirements you 
> must define your terms. "non-temporary" does not mean "permanent" and it 
> appears it is carefully avoided as such. In fact the only implied 
> definition through the chain of RFC is "non-temporary" is just not the 
> same as "temporary." "temporary" could be summarized as having the 
> potential for even per connection or per application duration. With that 
> "non-temporary" can reasonably be defined by the local site 
> administration as a work shift (8hrs) or something like that.
rfc3315#section-12 refers to rfc3041 for the definition of temporary addresses.
The usage of temporary addresses by rfc3041 (Privacy Extensions for Stateless 
Address Autoconfiguration in IPv6) seems to imply, a contrario, that 
non-temporary addresses are _not_ to be used for the privacy purposes.
Strictly logically this implication is incorrect, but still it very much aligns 
with understandable and reasonable expectations. Anyway, non-temporary isn’t 
the same as permanent.

> This means "non-temporary" is a policy decision by the organization 
> management ("oh no" software engineers cry, "not management"). If 
> management wants DHCPv6 to provide a single address per user level 
> machine, then that's their decision to make. If management wants that 
> each work day or each work shift enumerates all user level machines 
> differently, then that's their decision to make.  DHCPv6 IA_NA then is 
> the one and only address that your issued device gets, and it is 
> different each work day. Static servers may have predefined host 
> assignments, which I only mention for completeness.

>>> If central IT doesnt want user base devices to be permanently reachable
>>> or traceable, then that is their authority to choose.
>> Definitely.  They can easily achieve this by not providing any IA_NA
>> adresses.
> How is that an answer for above management attempting to implement a 
> particular policy? DHCPv6 IA_TA is not option for (any?) clients. By 
> your implied definition, a client device would get also an IA_NA that is 
> "more lasting." It may try to use it, but management doesn't want that. 
> DHCPv6 without something else leaves devices easily profiled from 
> external snooping. It's not MAC but not good either. SLAAC exposes the 
> MAC publicly. SLAAC+privacy is internally difficult to trace, so likely 
> fail accountability. SLAAC w/ RA rolling hash isn't any more implemented 
> than IA_TA.
(mind you, I am not an expert and the following could be utter nonsense).
Given these use-cases (IAs per work shift etc), why couldn’t these be fulfilled 
with IA_TA ?
Both types of associations are within control of the server and hence of 
whatever management policy, or would the use of IA_NA be necessitated because 
clients tend not request these ?
If so, then use of IA_TA is a client policy, and support of those by the DHCPv6 
server would be nice. Where the intended enhancement of privacy is a server 
policy and the client does not request IA_TA, use of IA_NA for this purpose 
seems alright since whatever address is provided is within the realm of the 
server for whatever policy it implements thereby.

>> 
>>> But on the flip side, central IT doesnt want the insanity of SLAAC
>>> Privacy all over their network. Consider a fortune 500 company or
>>> university with accountibilty and traceability in legal or internal
>>> policy requirements.
>>> 
>>> RFC are so namef for a reason and a good working model can change them.
>> OK, I think you just explained your level of understanding.  Thanks
> I'll pretend that it doesn't mean how it reads.
I’ve read the sentence a few times over and still cannot make out what would be 
meant be it. Still given the effort made to sensibly discus this subject one 
would be wise to read it positively.
(credo: when a positive explanation exists that is as reasonable as any other, 
pick the positive one)

> 
> - Eric
--
Paul

> ___
> 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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Tino Reichardt]

* Bastian Bittorf  wrote:
> * Bastian Bittorf  [07.03.2017 11:07]:
> > * Tino Reichardt  [06.03.2017 08:24]:
> > > BE AWARE:
> > > My patch seems to work fine, even the dsl modem seems to be correctly
> > > loaded. But it's not tested currently... so please do not flash your
> > > modems, when they are needed currently ;)
> > 
> > Impressive! i will check if pppoe works later and report.
> 
> it seems, that the modem is not initialised correctly,
> there is e.g. no blinking of the led and 'nas0' will not
> come up and so no pppoe...if somebody has an idea, i can test.

I have currently no idea, maybe it's some wrong initialization, but it
may also be some kind of memory problem. I am working on it...

I get this:
...
[  775.828559] [IFX_MEI_IrqHandle 1834]: OMB_REBOOT_INTERRUPT_CODE
[  775.833315] [IFX_MEI_IrqHandle 1834]: OMB_REBOOT_INTERRUPT_CODE
[  777.749566] [DSL_BSP_FWDownload 1615]: 
[  778.080972] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8039 
(Free_Reload)
[  778.087071] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8033 
(Free_Reload)
[  778.094347] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8037 
(Free_Reload)
[  778.101583] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8034 
(Free_Showtime)
[  778.109020] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8035 
(Free_Showtime)
[  778.116453] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 805a 
(Free_Reload)
[  778.123713] [IFX_MEI_DFEMemoryFree 1478]: free 32KB swap buff memory at: 
0x80de
[  778.131301] [IFX_MEI_DFEMemoryAlloc 1498]: image_size = 322840
[  778.137128] [DSL_BSP_FWDownload 1683]: -> IFX_MEI_BarUpdate()
[  778.151843] [DSL_BSP_FWDownload 1615]: 
[  778.161613] [DSL_BSP_FWDownload 1615]: 
[  778.234590] [DSL_BSP_FWDownload 1615]: 
[  778.244549] [DSL_BSP_FWDownload 1615]: 
[  778.250936] [IFX_MEI_Ioctls 2560]: DSL_FIO_BSP_DSL_START
[  778.255039] [IFX_MEI_RunAdslModem 1318]: allocate 32KB swap buff memory at: 
0x80de
[  779.617559] [IFX_MEI_RunAdslModem 1368]: Modem failed to be ready!
[  779.622491] [IFX_MEI_Ioctls 2562]: IFX_MEI_RunAdslModem() error...
-> here is some re-init:
[  780.557929] [DSL_BSP_FWDownload 1615]: 
[  780.737934] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8037 
(Free_Reload)
[  780.744021] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8033 
(Free_Reload)
[  780.751312] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8039 
(Free_Reload)
[  780.758554] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 805a 
(Free_Showtime)
[  780.766004] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 805b 
(Free_Showtime)
[  780.773412] [IFX_MEI_DFEMemoryFree 1461]: Freeing memory 8034 
(Free_Reload)
[  780.780678] [IFX_MEI_DFEMemoryFree 1478]: free 32KB swap buff memory at: 
0x80de
[  780.788265] [IFX_MEI_DFEMemoryAlloc 1498]: image_size = 322840
[  780.794153] [DSL_BSP_FWDownload 1683]: -> IFX_MEI_BarUpdate()
[  781.017962] [DSL_BSP_FWDownload 1615]: 
[  781.027787] [DSL_BSP_FWDownload 1615]: 
[  781.077951] [DSL_BSP_FWDownload 1615]: 
[  781.087580] [DSL_BSP_FWDownload 1615]: 
[  781.093981] [IFX_MEI_Ioctls 2560]: DSL_FIO_BSP_DSL_START
[  781.098084] [IFX_MEI_RunAdslModem 1318]: allocate 32KB swap buff memory at: 
0x80de
[  781.450463] [IFX_MEI_IrqHandle 1856]: Got MODEM_READY_MSG
[  781.454703] [IFX_MEI_IrqHandle 1856]: Got MODEM_READY_MSG
[  781.689228] [IFX_MEI_RunAdslModem 1371]: Modem is ready.
-> here it is ready for some time, but then it gets an re-init...
[  785.584348] [IFX_MEI_IrqHandle 1834]: OMB_REBOOT_INTERRUPT_CODE
[  785.589101] [IFX_MEI_IrqHandle 1834]: OMB_REBOOT_INTERRUPT_CODE


When it works, I will update also the patchset.

-- 
Best regards, TR

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

Re: [LEDE-DEV] [PATCH 2/3] procd: Don't use syslog before its initialization

[Michal Sojka]

On Sat, Mar 11 2017, John Crispin wrote:
> On 11/03/17 01:48, Michal Sojka wrote:
>> When procd starts a rcS script, it captures its stdout and stderr and
>> logs them to syslog. It could happen (and I don't know exactly why),
>> that a rcS scripts produces some output before openlog() is called in
>> procd. The result is that all subsequent logs from procd are logged
>> with ident and PID of some other service that happens to be started at
>> that time. I also have no clue why this is happening (bug in musl?),
>> but it is very confusing when one tries to debug boot problems.
>
> is there a way to reliably reproduce this issue ?

I can reproduce it reliably with handful of custom packages. I'll try to
prepare a more simpler setup where this can be seen.

-Michal

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