[LEDE-DEV] domain transfer
Hi, it looks like the domain was transfered to a new registrar last night. we are expecting that the contact info will also be updated shortly. John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Running init in a chroot LEDE Image
On 9 August 2017 at 13:44, Nicolas Pace wrote: > Thanks for replying! > > On Wed, 2017-08-09 at 10:09 +0800, Yousong Zhou wrote: >> On 9 August 2017 at 08:01, Mirko Parthey >> wrote: >> > On Tue, Aug 08, 2017 at 11:32:23PM +0300, Nicolas Pace wrote: >> > > I'm trying to run a rootfs chroot on my desktop computer to easen >> > > the >> > > development of userspace applications, but as I'm using ubus I >> > > need a >> > > complete LEDE environment. >> > > > > [snip] > >> > > but I somehow need to call init to >> > > get ubus running (and all of the other supporting systems). >> > > >> > > Any suggestion on how to manually call init? >> > >> > init must be started by the Linux kernel as the first userspace >> > process >> > to ensure it is asssigned pid 1 and gets special privileges for >> > supervising other processes. > > Does it need to run as pid 1 or just as the parent of all the processes > it needs to oversee? > >> > To start another init from a running system, you need some kind of >> > virtualization. I am using qemu/kvm here, managed by virt-manager >> > and >> > libvirtd. This has the advantage of running the LEDE userspace on >> > top >> > of the LEDE kernel instead of the host kernel, which may be missing > >> ./script/qemustart can also be used to quickly start QEMU >> arm/mips/x86 >> instances. > > I've used qemu before... this time I wanted to run it from a chroot > because: > * want to access a wireless device I'm not being able to access from > qemu... a usb wireless adaptor ath9k_htc > * i want to run an LEDE-based system (LibreMesh) on top of already > running systems like Raspbian on a Raspberry-pi or ARMBian on a Banana- > pi. > > I did the chroot and throught it I can access the ath9k_htc device... > so the only pending thing is to run init somehow... or to startup the > essential services manually. > > Regards, Have you tried passing through the USB wireless device to guest machine? Or making an image and run it insider docker? I think there are just too many details involved and isolation provided by virtualisation is really nice in this situation. yousong ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Running init in a chroot LEDE Image
Thanks for replying! On Wed, 2017-08-09 at 10:09 +0800, Yousong Zhou wrote: > On 9 August 2017 at 08:01, Mirko Parthey > wrote: > > On Tue, Aug 08, 2017 at 11:32:23PM +0300, Nicolas Pace wrote: > > > I'm trying to run a rootfs chroot on my desktop computer to easen > > > the > > > development of userspace applications, but as I'm using ubus I > > > need a > > > complete LEDE environment. > > > [snip] > > > but I somehow need to call init to > > > get ubus running (and all of the other supporting systems). > > > > > > Any suggestion on how to manually call init? > > > > init must be started by the Linux kernel as the first userspace > > process > > to ensure it is asssigned pid 1 and gets special privileges for > > supervising other processes. Does it need to run as pid 1 or just as the parent of all the processes it needs to oversee? > > To start another init from a running system, you need some kind of > > virtualization. I am using qemu/kvm here, managed by virt-manager > > and > > libvirtd. This has the advantage of running the LEDE userspace on > > top > > of the LEDE kernel instead of the host kernel, which may be missing > ./script/qemustart can also be used to quickly start QEMU > arm/mips/x86 > instances. I've used qemu before... this time I wanted to run it from a chroot because: * want to access a wireless device I'm not being able to access from qemu... a usb wireless adaptor ath9k_htc * i want to run an LEDE-based system (LibreMesh) on top of already running systems like Raspbian on a Raspberry-pi or ARMBian on a Banana- pi. I did the chroot and throught it I can access the ath9k_htc device... so the only pending thing is to run init somehow... or to startup the essential services manually. Regards, signature.asc Description: This is a digitally signed message part ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Running init in a chroot LEDE Image
On 9 August 2017 at 08:01, Mirko Parthey wrote: > On Tue, Aug 08, 2017 at 11:32:23PM +0300, Nicolas Pace wrote: >> I'm trying to run a rootfs chroot on my desktop computer to easen the >> development of userspace applications, but as I'm using ubus I need a >> complete LEDE environment. >> Using chroot also reduces the turnaround time for code/test cause I can >> just write code and it instantly is loaded on the image. >> >> I donwloaded the image from here: >> http://ci.libremesh.org/196/x86/generic/Generic/lime_default/lede-17.01 >> .2-lime-default-x86-generic-generic-rootfs.tar.gz >> >> Mounted all devices, did chroot... but I somehow need to call init to >> get ubus running (and all of the other supporting systems). >> >> Any suggestion on how to manually call init? > > init must be started by the Linux kernel as the first userspace process > to ensure it is asssigned pid 1 and gets special privileges for > supervising other processes. > > To start another init from a running system, you need some kind of > virtualization. I am using qemu/kvm here, managed by virt-manager and > libvirtd. This has the advantage of running the LEDE userspace on top > of the LEDE kernel instead of the host kernel, which may be missing > some LEDE-specific features. > > Regards, > Mirko > ./script/qemustart can also be used to quickly start QEMU arm/mips/x86 instances. It can be as simple as "./script/qemustart x86 64". Once up, the guest machine will have typical network settings ready and can be accessed through network or other methods as provided by QEMU from host machine. Regards, yousong ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Running init in a chroot LEDE Image
On Tue, Aug 08, 2017 at 11:32:23PM +0300, Nicolas Pace wrote: > I'm trying to run a rootfs chroot on my desktop computer to easen the > development of userspace applications, but as I'm using ubus I need a > complete LEDE environment. > Using chroot also reduces the turnaround time for code/test cause I can > just write code and it instantly is loaded on the image. > > I donwloaded the image from here: > http://ci.libremesh.org/196/x86/generic/Generic/lime_default/lede-17.01 > .2-lime-default-x86-generic-generic-rootfs.tar.gz > > Mounted all devices, did chroot... but I somehow need to call init to > get ubus running (and all of the other supporting systems). > > Any suggestion on how to manually call init? init must be started by the Linux kernel as the first userspace process to ensure it is asssigned pid 1 and gets special privileges for supervising other processes. To start another init from a running system, you need some kind of virtualization. I am using qemu/kvm here, managed by virt-manager and libvirtd. This has the advantage of running the LEDE userspace on top of the LEDE kernel instead of the host kernel, which may be missing some LEDE-specific features. Regards, Mirko ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Running init in a chroot LEDE Image
Hello everyone, Thanks a lot for an amazing project! I'm trying to run a rootfs chroot on my desktop computer to easen the development of userspace applications, but as I'm using ubus I need a complete LEDE environment. Using chroot also reduces the turnaround time for code/test cause I can just write code and it instantly is loaded on the image. I donwloaded the image from here: http://ci.libremesh.org/196/x86/generic/Generic/lime_default/lede-17.01 .2-lime-default-x86-generic-generic-rootfs.tar.gz Mounted all devices, did chroot... but I somehow need to call init to get ubus running (and all of the other supporting systems). Any suggestion on how to manually call init? just calling /sbin/init says the following: tmp# chroot lime /sbin/init WARNING: Variable 'led' does not exist or is not an array/object Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level WARNING: Variable 'led' does not exist or is not an array/object But nothing else. Thanks! signature.asc Description: This is a digitally signed message part ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] wifi and wan ipv6 connectivity
Hi,
for testing I add a hotplug script. Bellow I did copy my test sequence and the
output. There are a few seconds between
the commands. If 'wifi ...' is called, the 2003: address of my wan interface is
gone. The other addresses are still
assigned. If 'ubus ...' is called, the wan interface gets the same 2003:
address back.
Regards,
Hartmut
root@WLAN:~# cat /etc/config/network
...
config interface 'wan'
option ifname 'eth0.7'
option proto 'pppoe'
option username 'y...@t-online.de'
option password ''
option keepalive '10 5'
option pppd_options 'debug'
option persist '1'
option maxfail '50'
option holdoff '5'
...
root@WLAN:~# cat /etc/hotplug.d/iface/99-debug
#!/bin/sh
[ "$INTERFACE" = "wan_6" ] && logger -t DEBUG "hotplug: device='$INTERFACE'
action='$ACTION'"
root@WLAN:~# ifconfig pppoe-wan
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:217.xxx.yyy.zzz P-t-P:87.xxx.yyy.zzz Mask:255.255.255.255
inet6 addr: 2003:::::::/64 Scope:Global
inet6 addr: fe80:::::/10 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:129701 errors:0 dropped:0 overruns:0 frame:0
TX packets:76890 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:149174780 (142.2 MiB) TX bytes:32962821 (31.4 MiB)
root@WLAN:~# wifi reload
root@WLAN:~# logread
...
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: reading
/tmp/resolv.conf.auto
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain test
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain onion
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain localhost
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain local
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain invalid
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain example.net
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain example.org
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using local addresses only
for domain example.com
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using nameserver
217.xxx.yyy.zzz#53
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using nameserver
217.xxx.xxx.xxx#53
Tue Aug 8 17:33:39 2017 daemon.info dnsmasq[7773]: using 3 more local addresses
Tue Aug 8 17:33:39 2017 daemon.notice netifd: Interface 'wan_6' is now down
Tue Aug 8 17:33:39 2017 daemon.notice netifd: Interface 'wan_6' is disabled
Tue Aug 8 17:33:39 2017 daemon.notice netifd: Interface 'wan_6' has link
connectivity loss
Tue Aug 8 17:33:39 2017 daemon.notice netifd: Network alias 'pppoe-wan' link
is up
Tue Aug 8 17:33:39 2017 daemon.notice netifd: Interface 'wan_6' is enabled
Tue Aug 8 17:33:39 2017 daemon.notice netifd: Interface 'wan_6' has link
connectivity
Tue Aug 8 17:33:39 2017 daemon.notice netifd: Interface 'wan_6' is setting up
now
Tue Aug 8 17:33:41 2017 user.notice DEBUG: hotplug: device='wan_6'
action='ifdown'
Tue Aug 8 17:33:41 2017 user.notice ddns-scripts[27798]: dynv6_ipv6: PID
'27798' terminated by 'SIGTERM' at 2017-08-08
17:33
Tue Aug 8 17:33:41 2017 user.notice DEBUG: hotplug: device='wan_6'
action='ifup-failed'
...
root@WLAN:~# ifconfig pppoe-wan
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:217.xxx.yyy.zzz P-t-P:87.xxx.yyy.zzz Mask:255.255.255.255
inet6 addr: fe80:::::/10 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:129722 errors:0 dropped:0 overruns:0 frame:0
TX packets:76916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:149177731 (142.2 MiB) TX bytes:32965765 (31.4 MiB)
root@WLAN:~# ubus call network add_dynamic '{ "name": "wan_6", "ifname":
"@wan", "proto": "dhcpv6", "zone": "wan" }'
root@WLAN:~# ifconfig pppoe-wan
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:217.xxx.yyy.zzz P-t-P:87.xxx.yyy.zzz Mask:255.255.255.255
inet6 addr: 2003:::::::/64 Scope:Global
inet6 addr: fe80:::::/10 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:129871 errors:0 dropped:0 overruns:0 frame:0
TX packets:77068 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:149257479 (142.3 MiB) TX bytes:32988794 (31.4 MiB)
root@WLAN:~# logread
...
Tue Aug 8 17:35:55 2017 daemon.notice netifd: In
Re: [LEDE-DEV] [PATCH] kernel: try to remove TCP_RENO from the kernel.
Hi, On Sat, Aug 05, 2017 at 06:15:46PM -0700, Rosen Penev wrote: > LEDE currently uses CUBIC and not RENO by default. In theory, this > change should remove RENO from the kernel, but it doesn't. Might > as well keep it like this in case something changes. As far as I can tell, Reno is hard-wired in the kernel TCP implementation. So, it's just not possible to disable support for it. I doubt it would significantly reduce the size of the kernel anyway. Baptiste > Signed-off by: Rosen Penev > --- > target/linux/generic/config-3.18 | 2 +- > target/linux/generic/config-4.4 | 2 +- > target/linux/generic/config-4.9 | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/target/linux/generic/config-3.18 > b/target/linux/generic/config-3.18 > index 1e3f0b5abe..de479a79a8 100644 > --- a/target/linux/generic/config-3.18 > +++ b/target/linux/generic/config-3.18 > @@ -867,7 +867,6 @@ CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 > # CONFIG_DEFAULT_RENO is not set > CONFIG_DEFAULT_SECURITY="" > CONFIG_DEFAULT_SECURITY_DAC=y > -CONFIG_DEFAULT_TCP_CONG="cubic" > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > # CONFIG_DELL_SMO8800 is not set > # CONFIG_DEPRECATED_PARAM_STRUCT is not set > @@ -3904,6 +3903,7 @@ CONFIG_TCP_CONG_CUBIC=y > # CONFIG_TCP_CONG_HYBLA is not set > # CONFIG_TCP_CONG_ILLINOIS is not set > # CONFIG_TCP_CONG_LP is not set > +# CONFIG_TCP_RENO is not set > # CONFIG_TCP_CONG_SCALABLE is not set > # CONFIG_TCP_CONG_VEGAS is not set > # CONFIG_TCP_CONG_VENO is not set > diff --git a/target/linux/generic/config-4.4 b/target/linux/generic/config-4.4 > index 1c0af9597f..1c13b89912 100644 > --- a/target/linux/generic/config-4.4 > +++ b/target/linux/generic/config-4.4 > @@ -911,7 +911,6 @@ CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 > # CONFIG_DEFAULT_RENO is not set > CONFIG_DEFAULT_SECURITY="" > CONFIG_DEFAULT_SECURITY_DAC=y > -CONFIG_DEFAULT_TCP_CONG="cubic" > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > # CONFIG_DELL_RBTN is not set > # CONFIG_DELL_SMO8800 is not set > @@ -4112,6 +4111,7 @@ CONFIG_TCP_CONG_CUBIC=y > # CONFIG_TCP_CONG_HYBLA is not set > # CONFIG_TCP_CONG_ILLINOIS is not set > # CONFIG_TCP_CONG_LP is not set > +# CONFIG_TCP_RENO is not set > # CONFIG_TCP_CONG_SCALABLE is not set > # CONFIG_TCP_CONG_VEGAS is not set > # CONFIG_TCP_CONG_VENO is not set > diff --git a/target/linux/generic/config-4.9 b/target/linux/generic/config-4.9 > index 24bbbc0587..06e2c4da4b 100644 > --- a/target/linux/generic/config-4.9 > +++ b/target/linux/generic/config-4.9 > @@ -1008,7 +1008,6 @@ CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 > # CONFIG_DEFAULT_RENO is not set > CONFIG_DEFAULT_SECURITY="" > CONFIG_DEFAULT_SECURITY_DAC=y > -CONFIG_DEFAULT_TCP_CONG="cubic" > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > # CONFIG_DELL_RBTN is not set > # CONFIG_DELL_SMO8800 is not set > @@ -4488,6 +4487,7 @@ CONFIG_TCP_CONG_CUBIC=y > # CONFIG_TCP_CONG_ILLINOIS is not set > # CONFIG_TCP_CONG_LP is not set > # CONFIG_TCP_CONG_NV is not set > +# CONFIG_TCP_CONG_RENO is not set > # CONFIG_TCP_CONG_SCALABLE is not set > # CONFIG_TCP_CONG_VEGAS is not set > # CONFIG_TCP_CONG_VENO is not set signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
