Re: [LEDE-DEV] Lack of DNS robustness for openwrt.org

[David Woodhouse]

> Hello,
>
> I apologize for bringing up this long-standing issue at a time where you
> all have need to other issues to take care of.  But it's again become a
> real pressing issue, at least seen from the networks I have a presence in.

We can host it (primary or just secondary) on ns[123].infradead.org if it
helps...

-- 
dwmw2


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

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[David Woodhouse]

On Wed, 2018-02-14 at 22:51 +0100, Alberto Bursi wrote:
> Just change the WAN ssh port number to something in the dynamic port 
> range, pretty much 0 bots scan beyond the few well-known ports
> range, and you save CPU resources too.

We're talking about the default config here though. Please let's not
encourage bogus security-through-obscurity measures in that context.

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[David Woodhouse]

On Wed, 2018-02-14 at 12:34 -0700, Philip Prindeville wrote:
> Once I was messing with firewall settings and accidentally disabled
> the firewall.  Within a few minutes, there were all sorts of password
> attacks on the WAN port.  Having a sufficiently complex password
> slowed things down long enough for me to re-secure the box.

Pfft. If you had a half-decent password, the box was always secure.

If you really care, perhaps roll something like this (which I have in
my /etc/firewall.user) into the default configuration:

for PROTO in iptables ip6tables ; do
   for TABLE in forwarding_rule input_rule; do
  $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --rcheck 
--hitcount 4 --seconds 60 -j LOG --log-prefix "SSH_BRUTE "
  $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --update 
--hitcount 4 --seconds 60 -j REJECT --reject-with tcp-reset
  $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --set -j 
RETURN
   done
done

You have the same "problem" with external access via HTTPS, surely? Are
you planning to ban password access to that too?

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] No wireless on TDW8970 due to lack of PCI_SUPPORT

[David Woodhouse]

I updated my TDW8970 from 17.01.1 to 17.01.3 last night and it came up
without wireless. It looks like I *couldn't* enable kmod-ath9k.

This (adding pci feature) didn't seem to help:

--- a/target/linux/lantiq/xrx200/target.mk
+++ b/target/linux/lantiq/xrx200/target.mk
@@ -1,7 +1,7 @@
 ARCH:=mips
 SUBTARGET:=xrx200
 BOARDNAME:=XRX200
-FEATURES:=squashfs atm nand ubifs
+FEATURES:=squashfs nand pci
 CPU_TYPE:=24kc


This did, but obviously isn't the right solution:

--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -194,7 +194,7 @@ endef
 define KernelPackage/ath
   $(call KernelPackage/mac80211/Default)
   TITLE:=Atheros common driver part
-  DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ar71xx||TARGET_ath25 
+kmod-mac80211
+  DEPENDS+= +kmod-mac80211
   FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath.ko
   MENU:=1
 endef
@@ -222,7 +222,7 @@ define KernelPackage/ath9k-common
   TITLE:=Atheros 802.11n wireless devices (common code for ath9k and ath9k_htc)
   URL:=https://wireless.wiki.kernel.org/en/users/drivers/ath9k
   HIDDEN:=1
-  DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ar71xx +kmod-ath 
+@DRIVER_11N_SUPPORT +@DRIVER_11W_SUPPORT +@KERNEL_RELAY
+  DEPENDS+= +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11W_SUPPORT +@KERNEL_RELAY
   FILES:= \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_common.ko \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_hw.ko
@@ -232,7 +232,7 @@ define KernelPackage/ath9k
   $(call KernelPackage/mac80211/Default)
   TITLE:=Atheros 802.11n PCI wireless cards support
   URL:=https://wireless.wiki.kernel.org/en/users/drivers/ath9k
-  DEPENDS+= @PCI_SUPPORT||TARGET_ar71xx +kmod-ath9k-common
+  DEPENDS+= +kmod-ath9k-common
   FILES:= \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k.ko
   AUTOLOAD:=$(call AutoProbe,ath9k)


Config at http://david.woodhou.se/tdw8970.config-20171005





smime.p7s
Description: S/MIME cryptographic signature
___
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

[David Woodhouse]

On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:
> 
> *) 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

Yes, we can redirect the existing lists to the new ones — so for
example, mail sent to lede-dev will just turn up on the openwrt-dev
list instead. Assuming that's what you meant.

For importing subscribers, if that's what you want to do, I'd be
inclined to send *invitations* not just subscribe people. So each
person will get the 'someone has requested that your address be
subscribed; click here to actually do it' message. We can write our own
blurb to go out at the top of those invitations.

I still haven't worked out if I actually have a vote here or not but
FWIW the rest of the proposal looked good to me.


smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[David Woodhouse]

On Wed, 2017-03-08 at 10:20 -0700, Philip Prindeville wrote:
> 
> Then…  grub reads the raw file system? 

Well, grub has to load the kernel before the kernel is running


smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[David Woodhouse]

On Tue, 2017-03-07 at 17:40 -0700, Philip Prindeville wrote:
> 
> First, obviously, is that kexec needs access to the boot partition to
> reuse the kernel (since most of our architectures support relocatable
> images, there’s no reason that the system kernel and the crash dump
> kernel can’t be one in the same).  Is where does /boot get unmounted,
> and is there an easy way to keep it around a bit longer, at least
> until the init.d scripts have finished running?

Hm, /boot doesn't ever get mounted at all, does it?

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[David Woodhouse]

On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote:
> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
>  wrote:
> > 
> > The sender domain has a DMARC Reject/Quarantine policy which disallows
> > sending mailing list messages using the original "From" header.
> > 
> > To mitigate this problem, the original message has been wrapped
> > automatically by the mailing list software.
> You don't need this and I think you were already instructed on other
> ML not to do so.
> 
> Just include proper From: as the first e-mail of your e-mail body.
> Actually git format-patch can even do that for you.

He didn't do that bit. That's the stupid list configuration. Anthony's
problem was that he was posting from a mail domain with stupid
settings. The list's stupidity is a reaction to that.

Personally, I think we're better off just *rejecting* posts from people
with such broken domains. But I only provide the hosting; I'm not
actively playing BoFH and enforcing my opinions on the list config...

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] [BUG] XRX200 VPE support is broken since conflicting SMP support was introduced

[David Woodhouse]

On Wed, 2017-02-22 at 16:33 +0100, Stefan Koch wrote:
> 
> *IMPORTANT*
> To use VPE at least CONFIG_MIPS_MT_SMP needs to be disabled within 
> xrx200/config-default and nosmp added to the kernel command line
> Without nosmp within command line the full SMP part must be disabled
> 
> *WARNING*
> If SMP and VPE are enabled together you will get strange kernel panics. 
> Because both, SMP and VPE want to use the second CPU core.
> The first commit above that introduces SMP added nosmp to kernel command 
> line. So no funny kernel panics appear. But the VMMC firmware could not 
> be loaded.
> 
> So there a different options to recover FXS support:
> 1) remove SMP support for xrx200
> 2) Disables CONFIG_MIPS_MT_SMP within kernel default configuration that 
> conflicts with the VPE kernel configuration options. I have added a 
> patch as attachment but not tested it without nosmp option and don't 
> know what happens on a device that uses no VPE/VMMC/FXS. But it recovers 
> FXS support successfully.
> 3) Write a new patch

Surely you can still have have SMP support in the kernel; all you need
to do is take the other CPU offline properly before you repurpose it
for VPE?

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] Add firmware for usb-serial-ti-usb

[David Woodhouse]

Signed-off-by: David Woodhouse <dw...@infradead.org>
---
 package/firmware/linux-firmware/ti.mk | 13 +
 1 file changed, 13 insertions(+)

diff --git a/package/firmware/linux-firmware/ti.mk 
b/package/firmware/linux-firmware/ti.mk
index a1e12fc..ba1baa9 100644
--- a/package/firmware/linux-firmware/ti.mk
+++ b/package/firmware/linux-firmware/ti.mk
@@ -23,3 +23,16 @@ define Package/wl18xx-firmware/install
 endef
 $(eval $(call BuildPackage,wl18xx-firmware))
 
+Package/ti-3410-firmware = $(call Package/firmware-default,TI 3410 firmware)
+define Package/ti-3410-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/ti_3410.fw $(1)/lib/firmware
+endef
+$(eval $(call BuildPackage,ti-3410-firmware))
+
+Package/ti-5052-firmware = $(call Package/firmware-default,TI 5052 firmware)
+define Package/ti-5052-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/ti_5052.fw $(1)/lib/firmware
+endef
+$(eval $(call BuildPackage,ti-5052-firmware))
-- 
2.9.3


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

Re: [LEDE-DEV] LEDE v17.01.0 schedule adjusted

[David Woodhouse]

On Wed, 2017-02-15 at 14:03 -0800, Russell Senior wrote:
> 
> I just tried r3499 (master branch), and it works too, 

Nice. Do you want to reinstate the default configuration for it, which
was removed in commit 9e0759ea2? See how I've just done it for Geos.
Wha
t is in /tmp/sysinfo/board_name?

You can configure the baud rate in the Alix2 BIOS, can't you?

> although I do see this stack trace during boot:

Yeah, I saw that. Was ignoring it for now. 

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE v17.01.0 schedule adjusted

[David Woodhouse]

On Wed, 2017-02-15 at 12:52 -0800, Russell Senior wrote:
> I last built on February 1, circa r3226, and that works.

But not with an out-of-the-box configuration anyway, right?


smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE v17.01.0 schedule adjusted

[David Woodhouse]

On Wed, 2017-02-15 at 12:24 -0800, Russell Senior wrote:
> 
> 
> David> In the same PR#840:
> 
> David> b5bec324fb6eecc483e093a231d7d3fc050bf344 x86: Set default baud
> David> rate on Geode images to 115200
> 
> The alix2 (also a Geode) uses 38400 in the BIOS.

Hm. The Geos uses 115200 in the BIOS. Does the alix2 actually work? 

It looks like via-rhine Ethernet support was dropped when the Geode
subtargets were merged, and never added back again until I did it
today. Which means that the default images won't work for alix2 anyway,
right? They do for Geos...

The three Geode-based targets that got merged all had *different*
default baud rates. We just need to pick one, and picking the one
that's default on most boards, most useful, and matches the board that
is actively (if sporadically) being maintained does seem like it's not
the worst idea...



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE v17.01.0 schedule adjusted

[David Woodhouse]

On Wed, 2017-02-15 at 17:14 +, David Woodhouse wrote:
> On Wed, 2017-02-15 at 17:45 +0100, Jo-Philipp Wich wrote:
> > 
> > 
> > To get final fixes into the release please mention Git commits you like
> > to see cherry-picked in to lede-17.01  until Sunday, the 19th.
> 657418db68fe2be89bdba2a147a08168d7a760ba x86: Add configuration back for 
> Traverse Geos
> 27a635f0b487eb54bde58639c80080396bbf1c03 x86: Move Traverse Geos configs into 
> x86 base-files
> add465f1be5d092ef049306ea2a211ff3f82b146 x86: Enable DIAG LED on Geos
> 9a6c9325564439e0c9bb3209931787a492fa8f9b x86: Add board configs for the PC 
> Engines APU2
> 501c2a626533feaec67b54d367fe51ea5cfec699 x86: Add Geos profile for Geode 
> subtarget
> 
> The last one is from https://github.com/lede-project/source/pull/840
> 
> I'd like to change the default serial baud rate to 115200 too... will do that 
> shortly.

In the same PR#840: 

b5bec324fb6eecc483e093a231d7d3fc050bf344 x86: Set default baud rate on Geode 
images to 115200


smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE v17.01.0 schedule adjusted

[David Woodhouse]

On Wed, 2017-02-15 at 17:45 +0100, Jo-Philipp Wich wrote:
> 
> To get final fixes into the release please mention Git commits you like
> to see cherry-picked in to lede-17.01  until Sunday, the 19th.

657418db68fe2be89bdba2a147a08168d7a760ba x86: Add configuration back for 
Traverse Geos
27a635f0b487eb54bde58639c80080396bbf1c03 x86: Move Traverse Geos configs into 
x86 base-files
add465f1be5d092ef049306ea2a211ff3f82b146 x86: Enable DIAG LED on Geos
9a6c9325564439e0c9bb3209931787a492fa8f9b x86: Add board configs for the PC 
Engines APU2
501c2a626533feaec67b54d367fe51ea5cfec699 x86: Add Geos profile for Geode 
subtarget

The last one is from https://github.com/lede-project/source/pull/840

I'd like to change the default serial baud rate to 115200 too... will do that 
shortly.

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] packages: Use https instead of git

[David Woodhouse]

On Wed, 2017-02-15 at 12:27 +, David Woodhouse wrote:
> On Wed, 2017-02-15 at 13:11 +0300, Alexey Brodkin wrote:
> > 
> > 
> > On some [especially corporate] networks non-standard ports are blocked
> > and git is one of them. So switch to more convenient https transport.
> Here's a nickel, kid. Get yourself a proper Internet connection.
> 
> Seriously, better to advocate that users take a cluebat to stupid
> network admins, than to pander to this.
> 
> Make it git-only, and IPv6-only :)

Slightly more seriously, a configuration option for a proxy tool to use
for git might be worthwhile, to save users from having to set it up for
themselves. But then again, users in such broken networks will probably
already have done so, won't they?

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] packages: Use https instead of git

[David Woodhouse]

On Wed, 2017-02-15 at 13:11 +0300, Alexey Brodkin wrote:
> 
> On some [especially corporate] networks non-standard ports are blocked
> and git is one of them. So switch to more convenient https transport.

Here's a nickel, kid. Get yourself a proper Internet connection.

Seriously, better to advocate that users take a cluebat to stupid
network admins, than to pander to this.

Make it git-only, and IPv6-only :)

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: set status led for the gl-* boards

[David Woodhouse]

On Wed, 2017-02-15 at 09:29 +0100, John Crispin wrote:
> 
> > --- a/target/linux/ar71xx/base-files/etc/diag.sh
> > +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> > @@ -63,6 +63,10 @@ get_status_led() {
> > gl-inet)
> > status_led="$board:green:lan"
> > ;;
> > +   gl-ar300m|\
> > +   gl-mifi)
> > +   status_led="$board:lan"
> 
> Hi Wojciech,
> 
> patch is technically correct, however while reviewing it i noticed that
> the boards do not follow the correct naming scheme. normally it should
> be board:color:function. looks like the gl boards are missing the color.
> would you mind re-spinning you patch and also fixing the colors inside
> target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c and
> target/linux/ar71xx/files/arch/mips/ath79/mach-gl-mifi.c

Also... ick, we've got board details hard-coded in /etc/diag.sh, which
is what I just fixed for x86.

Should we promote target/x86/base-files/etc/diag.sh to run *everywhere*
and make things work that way? 

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] x86: Add board configs for the PC Engines APU2

[David Woodhouse]

On Mon, 2017-02-13 at 12:50 +0100, Felix Fietkau wrote:
> 
> Please leave out the /lib/.sh anti-pattern. Just use
> /tmp/sysinfo/board_name directly or (even better) introduce a generic
> function for getting the board name.

Once I stop /etc/diag.sh from having hard-coded board name stuff, we go
back to only one instance of reading /tmp/sysinfo/board_name — so I
dropped that part from https://github.com/lede-project/source/pull/824

Testing seems to show that the diag LED only really works from the
second boot though, since it isn't *configured* during the first boot.


smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] x86: Add board configs for the PC Engines APU2

[David Woodhouse]

On Mon, 2017-02-13 at 02:01 -0600, Chris Blake wrote:
> 
> +get_status_led() {
> +    case $(x86_board_name) in
> +    pc-engines-apu2)
> +    status_led="apu2:green:power"
> +    ;;
> +    esac
> +}

Ick. Why hard-code that and have board-specific stuff in more than one
place, instead of just configuring it with everything else, then
deferring to the configuration? Can't we do something like this
instead?

diff --git a/target/linux/x86/base-files/etc/diag.sh 
b/target/linux/x86/base-files/etc/diag.sh
index 2426161..c51d080 100755
--- a/target/linux/x86/base-files/etc/diag.sh
+++ b/target/linux/x86/base-files/etc/diag.sh
@@ -3,15 +3,26 @@
 # Copyright © 2017 OpenWrt.org
 #
 
+. /lib/functions.sh
 . /lib/functions/leds.sh
 . /lib/x86.sh
 
+match_diag_led() {
+   local name
+   local default
+   local sysfs
+   config_get name "$1" name
+   config_get default "$1" default
+   config_get sysfs "$1" sysfs
+
+   if [ "$name" = "DIAG" -a "$default" = "1" ]; then
+   status_led="$sysfs"
+   fi
+}
+
 get_status_led() {
-case $(x86_board_name) in
-pc-engines-apu2)
-status_led="apu2:green:power"
-;;
-esac
+   config_load system
+   config_foreach match_diag_led led
 }
 
 set_state() {
diff --git a/target/linux/x86/base-files/etc/board.d/01_leds 
b/target/linux/x86/base-files/etc/board.d/01_leds
index 05ddc71..50eac33 100755
--- a/target/linux/x86/base-files/etc/board.d/01_leds
+++ b/target/linux/x86/base-files/etc/board.d/01_leds
@@ -14,11 +14,12 @@ case "$board" in
 pc-engines-apu2)
    ucidef_set_led_netdev "wan" "WAN" "apu2:green:led3" "eth0"
    ucidef_set_led_netdev "lan" "LAN" "apu2:green:led2" "eth1"
+   ucidef_set_led_default "diag" "DIAG" "apu2:green:power" "1"
    ;;
 traverse-technologies-geos)
    ucidef_set_led_netdev "lan" "LAN" "geos:1" "br-lan" "tx rx"
    ucidef_set_led_netdev "wlan" "WiFi" "geos:2" "phy0tpt"
-   ucidef_set_led_default "diag" "DIAG" "geos:3" "0"
+   ucidef_set_led_default "diag" "DIAG" "geos:3" "1"
    ;;
 esac
 board_config_flush


smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] make fail for x86 geode target - 17.01

[David Woodhouse]

On Wed, 2017-02-08 at 16:30 +0530, Nishant Sharma wrote:
> 
> I was able to buid images successfully for x86_64 (APU2) and ar71xx 
> (mikrotik). But no joy with x86 geode.

It worked for me with the config at http://david.woodhou.se/geos.config
(building on x86_64 Fedora 25). At least, it builds an image. I haven't
found the time to do anything other than that.

I do note that I don't expect it to even boot though, as the grub
config seems to say 'root=/dev/sda3' but the rootfs is /dev/sda2...

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ltq-ptm: Support 1508-byte MTU for RFC4638

[David Woodhouse]

On Fri, 2016-10-07 at 15:02 +0100, David Woodhouse wrote:
> Tested with VDSL on TP-Link WD8970, I see full 1500-byte PPP data
> frames, which end up being 1526 byte Ethernet frames (including
> Ethernet+VLAN headers) on the wire.
> 
> Fixes: FS#210

So this got merged, and now it *can* work properly. But it doesn't. I
updated to 17.01 and I'm back to 1492-byte PPP.

I think I had also hacked my local build of the module so that not only
would it *permit* a 1508-byte MTU to be set, but it also *defaulted* to
that.

Now, it defaults to 1500 and needs userspace to *set* an MTU of 1508 on
the ptm0 and ptm0.101 VLAN interfaces... and I can't persuade netifd to
do that. I only get full frames if I set the MTU manually.

What am I missing?

config interface 'vdsl'
option proto 'pppoe'
option username 'xx'
option password 'xx'
option pppd_options 'debug'
option ifname 'ptm0.101'
option mtu '1500'
option ipv6 'auto'

config route6
option interface 'vdsl'
option target '::/0'
option metric '1'

config switch_vlan 'ptm0_101'
option device 'ptm0'
option vlan '101'
option vid '101'

config interface 'aa101'
option ifname 'ptm0.101'
option proto 'none'
option mtu '1508'
option delegate '0'

config interface 'ptm0'
option ifname 'ptm0'
option proto 'none'
option mtu '1508'
option delegate '0'

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

[David Woodhouse]

On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
> 
> - IPv6 support: since that was the focus of CC, at least mention that
>   nothing was intentionally broken (and maybe there were some
>   improvement?)]

What was the IPv6 problem? I updated my VDSL router and separate AP to
17.01 over the weekend, and haven't seen any problems. My ISP does do
prefix delegation and I suppose I *ought* to check that works out of
the box, but haven't looked hard at it yet.

I did have missing *Legacy* IP routing for a while until I finally
noticed, but that was just a configuration issue :)

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] How do you develop (compile) LEDE efficiently?

[David Woodhouse]

On Mon, 2016-11-07 at 01:58 -0800, Russell Senior wrote:
> > > > > > "Rafał" == Rafał Miłecki  writes:
> 
> Rafał> On 7 November 2016 at 00:40, Russell Senior 
>  wrote:
> > 
> > > 
> > > I have a 16-core build box which I connect to over ssh.  I use scp to
> > > move images to devices.  I have a testbed with ethernet connections
> > > to the build box and serial consoles on most if not all of them.
> 
> Rafał> But what about development with modifying files in build_dir?
> Rafał> That's the most tricky part for me.
> 
> I ssh into the build machine and use whatever my favorite editor of the
> moment is (vi or emancs) and modify files.  I don't understand the
> problem.
> 
> I've even been known to load emacs with X11 over a dialup connection
> with ssh X forwarding (20 years ago).  It took a while to start up, but
> was generally pretty responsive once started.  In an environment with
> flakey network, that could be painful.  GNU screen and
> persistent/reconnectable screen sessions on the build machine can help
> smooth things out.

This is what tramp-mode is for.

emacs /buildhost:/home/dwmw2/git/lede/...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Out of tree builds

[David Woodhouse]

Is there a simple trick I'm missing, to build for multiple targets from
the same build tree? 

I'm mostly just manually copying my .config file out of the way and
swapping it for a different one each time — but there's got to be a
better way, surely?

mv .config .config.wndr3800
mv .config.tdw8970 .config
make -j32 oldconfig world

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] ltq-ptm: Support 1508-byte MTU for RFC4638

[David Woodhouse]

Tested with VDSL on TP-Link WD8970, I see full 1500-byte PPP data
frames, which end up being 1526 byte Ethernet frames (including
Ethernet+VLAN headers) on the wire.

Fixes: FS#210

Signed-off-by: David Woodhouse <dw...@infradead.org>

diff --git a/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_adsl.c 
b/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_adsl.c
index dc75b12..b096b0a 100644
--- a/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_adsl.c
+++ b/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_adsl.c
@@ -128,6 +128,7 @@ static int ptm_stop(struct net_device *);
   static unsigned int ptm_poll(int, unsigned int);
   static int ptm_napi_poll(struct napi_struct *, int);
 static int ptm_hard_start_xmit(struct sk_buff *, struct net_device *);
+static int ptm_change_mtu(struct net_device *, int);
 static int ptm_ioctl(struct net_device *, struct ifreq *, int);
 static void ptm_tx_timeout(struct net_device *);
 
@@ -246,7 +247,7 @@ static struct net_device_ops g_ptm_netdev_ops = {
 .ndo_start_xmit  = ptm_hard_start_xmit,
 .ndo_validate_addr   = eth_validate_addr,
 .ndo_set_mac_address = eth_mac_addr,
-.ndo_change_mtu  = eth_change_mtu,
+.ndo_change_mtu  = ptm_change_mtu,
 .ndo_do_ioctl= ptm_ioctl,
 .ndo_tx_timeout  = ptm_tx_timeout,
 };
@@ -451,6 +452,15 @@ PTM_HARD_START_XMIT_FAIL:
 return NETDEV_TX_OK;
 }
 
+static int ptm_change_mtu(struct net_device *dev, int mtu)
+{
+   /* Allow up to 1508 bytes, for RFC4638 */
+if (mtu < 68 || mtu > ETH_DATA_LEN + 8)
+return -EINVAL;
+dev->mtu = mtu;
+return 0;
+}
+
 static int ptm_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
 {
 int ndev;
diff --git a/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c 
b/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c
index 41464e6..bc27c27 100644
--- a/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c
+++ b/package/kernel/lantiq/ltq-ptm/src/ifxmips_ptm_vdsl.c
@@ -74,6 +74,7 @@ static int ptm_stop(struct net_device *);
   static unsigned int ptm_poll(int, unsigned int);
   static int ptm_napi_poll(struct napi_struct *, int);
 static int ptm_hard_start_xmit(struct sk_buff *, struct net_device *);
+static int ptm_change_mtu(struct net_device *, int);
 static int ptm_ioctl(struct net_device *, struct ifreq *, int);
 static void ptm_tx_timeout(struct net_device *);
 
@@ -114,7 +115,7 @@ static struct net_device_ops g_ptm_netdev_ops = {
 .ndo_start_xmit  = ptm_hard_start_xmit,
 .ndo_validate_addr   = eth_validate_addr,
 .ndo_set_mac_address = eth_mac_addr,
-.ndo_change_mtu  = eth_change_mtu,
+.ndo_change_mtu  = ptm_change_mtu,
 .ndo_do_ioctl= ptm_ioctl,
 .ndo_tx_timeout  = ptm_tx_timeout,
 };
@@ -358,6 +359,15 @@ PTM_HARD_START_XMIT_FAIL:
 return 0;
 }
 
+static int ptm_change_mtu(struct net_device *dev, int mtu)
+{
+   /* Allow up to 1508 bytes, for RFC4638 */
+if (mtu < 68 || mtu > ETH_DATA_LEN + 8)
+return -EINVAL;
+dev->mtu = mtu;
+return 0;
+}
+
 static int ptm_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
 {
 ASSERT(dev == g_net_dev[0], "incorrect device");
-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] A request not making IRC necessary to be part of the action

[David Woodhouse]

On Mon, 2016-05-16 at 12:46 +0100, Bruno Randolf wrote:
> On 15/05/16 05:53, Daniel Dickinson wrote:
> > 
> > I'd really appreciate if we could actually use the mailing list for the
> > main communications venue rather than shutting out people not in the
> > European timezones, which is what happens if IRC is the main way to
> > participate in the community.
> > 
> > I have been told that to really be part of the OpenWrt action I should
> > have been on IRC; but I'm not in European timezone so that is not
> > actually a useful suggestion, since most of the most people most
> > relevant to decision-making are in Europe, and I would hope LEDE has a
> > more *inter-continental focus than OpenWrt had.
> Agreed! I don't have time to hang out in IRC channels, usually. Or maybe
> a different working style... (it distracts me too much). Anyhow I think
> all important things and all things which don't need real-time
> interaction should go thru the mailing list, please.

FWIW, IRC doesn't have to have real-time behaviour, and doesn't have to
be constantly distracting.

It's perfectly possible to have IRC conversations with people who are
never awake at the same time as you. You say something, they respond
when they wake up... and you respond when *you* wake up. Just like
email, in fact.

IRC gives you the *option* of real-time conversation, if you happen to
be awake at the same time.

And you don't have to pay attention to the channel all the time; an IRC
client should highlight if your nick is mentioned because someone is
talking you to specifically.

IRC is great for conversations which are more ephemeral, and don't need
to be archived for posterity.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Why technical elitism is contrary to stated goal of community

[David Woodhouse]

On Fri, 2016-05-06 at 11:48 -0400, Daniel Curran-Dickinson wrote:
> > As I said, the issue is not with 'only good bug reports', it's with 'we
> > can ensure only good bug reports by making it a pain to report bugs at all'.
> 
> I'd also like to point out that if the approach is being taken on the
> assumption that on technically advanced people write good reports, then
> I'd like to point out that
> 
> a) There are plenty of technically advanced people who really suck at
> writing good bug reports
> b) There are a goodly number of noobs who given the right
> prompts/prompting can give better bug reports than even many technically
> advanced users who aren't in a).
> c) There are going to be bad bug reports no matter how badly you try to
> avoid it
> d) Making it hard to report bugs means that bugs don't get reported,
> even in cases where all you needed to fix the bug was to know it existed.

All very true. It's also worth noting that if you are "guided" too hard
to include information which you don't have or can't accurately
provide, or which is irrelevant in your specific case, then you often
end up making stuff up and that *detracts* from the quality of the
report.

I have a lot of expense reports where the mandatory "Business purpose?"
field has the simple answer "yes" :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[David Woodhouse]

On Thu, 2016-05-05 at 14:12 -0300, Fernando Frediani wrote:
> Come on. It´s not a big thing and it helps some people to organize
> their mailboxes in the way they prefer.
> We are talking about just 10 extra characters !

You are right. It isn't a big thing. It's just 10 extra characters.

But some of us spend our entire lives sitting in front of an email
client, scanning mailing lists for discussions that are relevant to us
— and on which we can help.

Those 10 extra characters detract from our ability to pick out the
subjects we should pay attention to. And there are *standard* places in
which the same information already exists, instead of abusing the
subject line.

There have been many cases where a thread has had to be brought
explicitly to my attention (by Cc'ing it to me), because I just haven't
*noticed* it otherwise. That happens with and without the subject
prefix, but it happens *more* on lists with a subject prefix.

Again, just personal anecdotal data. But again, it's a down-side that
it's fairly hard for recipients to *avoid* (it's distinctly non-trivial 
to remove even the one list-noise, let alone when it's cross-posted and
gains others), while it's relatively *easy* for those who want it to
actually do things properly or *even* to just add the noise for
themselves at their side. If that's *really* the user-interface that
they want.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[David Woodhouse]

On Thu, 2016-05-05 at 01:37 -0700, David Lang wrote:
> 
> > can this be turned on by subscribers manually for their subscription or
> > is there only one global option ? for the list ?
> 
> I'm pretty sure it's a list-wide option.

Indeed. There are plenty of things that individual subscribers can do,
based on the existing ways of distinguishing list traffic — but Mailman
is mostly designed to deliver the *same* message to multiple
subscribers, so doesn't really offer that as a per-user option on the
list server side.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: List subject prefix?

[David Woodhouse]

On Thu, 2016-05-05 at 10:23 +0300, Hannu Nyman wrote:
> On 5.5.2016 9:59, David Woodhouse wrote:
> > It's the Mailman default, but it is deliberately disabled on this list
> > (as on many other technical lists where the members are expected to be
> > able to drive their email client properly).
> 
> That sounds pretty funny on 2010s when most of us use multiple devices to 
> read mail. The list prefix makes it easier to quickly identify the general 
> nature of a message on tablet/phone screen

Each of us has different use cases, of course. But for me, having it in
a different folder is even easier — since most of the time when I'm not
at a real computer, I don't even want to *see* the list traffic — and
when I'm out of the country, I *certainly* don't want to pay roaming
data rates for downloading it!

It can go into one of the dozens of mailing list folders. On the *rare* 
occasion that I actually do want to look at list traffic from a mobile device, 
it's hardly difficult to switch to that folder (after I make sure I find wifi).

> Sure, we all can tinker with the desktop mail client classification rules, 
> but not all mobile apps are that well adjustable. A short list prefix would 
> make life more easy.

Yeah, filtering on the *client* side only ever made sense in the POP3
days — where you had only one mail client, on only one machine. You
really do want the *server* to put it in the right place on delivery,
not mess around with it afterwards.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[David Woodhouse]

On Thu, 2016-05-05 at 08:13 +0200, John Crispin wrote:
> 
> Hi David,
> 
> some folks would prefer to have the prefix on the 2 lists. I just had a
> look in the mailman settings and failed to quickly spot the location
> where this can be achieved.

Ick, they really ought to be able to handle that locally without
polluting the subject header for everyone. But if you want to turn it
back on, it's in the 'general options' page — the first one when you
log in to the admin interface. About the fourth option down.

Or directly at
http://lists.infradead.org/mailman/admin/lede-adm/?VARHELP=general/subject_prefix

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: List subject prefix?

[David Woodhouse]

On Wed, 2016-05-04 at 17:31 -0400, Aaron Z wrote:
> On many (most?) mailing lists, there is a prefix on all subjects
> which has the list name (such as [OpenWRT-Devel])
> Can this prefix be added for this list (or is that an option that I
> missed when I signed up)?

It's the Mailman default, but it is deliberately disabled on this list
(as on many other technical lists where the members are expected to be
able to drive their email client properly).

There are much better things to filter list traffic on — the SMTP
reverse-path (often in a Return-Path: header after delivery) is most
reliable, or the various standard List-* headers that the list adds,
which kind of work for most of the common cases.

If you really want list traffic in your inbox instead of a separate
folder, and you want to mark it differently, then you should be able to
do that locally instead of polluting the Subject header with redundant
information that obscures the *real* subject that the sender typed, for
everyone.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev