Re: [PATCH 3/4] hostapd: introduce mbo option

[Andre Valentin]

Hello Stijn!

Am 21.06.22 um 15:36 schrieb Stijn Tintel:

Introduce a new option mbo to toggle Multi Band Operation aka Agile
Multiband for a BSS. As the specification requires APs to support OTA
when FT is supported, force OTA on when FT is enabled.

Signed-off-by: Stijn Tintel 
---
  package/network/services/hostapd/files/hostapd.sh | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index fa344bd2dd..59b3128669 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -304,7 +304,7 @@ hostapd_common_add_bss_config() {
config_add_string wps_device_type wps_device_name wps_manufacturer 
wps_pin
config_add_string multi_ap_backhaul_ssid multi_ap_backhaul_key
  
-	config_add_boolean wnm_sleep_mode wnm_sleep_mode_no_keys bss_transition

+   config_add_boolean wnm_sleep_mode wnm_sleep_mode_no_keys bss_transition 
mbo
config_add_int time_advertisement
config_add_string time_zone
config_add_string vendor_elements
@@ -825,11 +825,17 @@ hostapd_set_bss_options() {
append bss_conf "iapp_interface=$ifname" "$N"
}
  
-	json_get_vars time_advertisement time_zone wnm_sleep_mode wnm_sleep_mode_no_keys bss_transition

+   json_get_vars time_advertisement time_zone wnm_sleep_mode 
wnm_sleep_mode_no_keys bss_transition mbo
set_default bss_transition 0
set_default wnm_sleep_mode 0
set_default wnm_sleep_mode_no_keys 0
  
+	if [ "$enable_ax" -eq 1 ]; then

+   set_default mbo 1
+   else
+   set_default mbo 0
+   fi
+
[ -n "$time_advertisement" ] && append bss_conf 
"time_advertisement=$time_advertisement" "$N"
[ -n "$time_zone" ] && append bss_conf "time_zone=$time_zone" "$N"
if [ "$wnm_sleep_mode" -eq "1" ]; then
@@ -837,6 +843,7 @@ hostapd_set_bss_options() {
[ "$wnm_sleep_mode_no_keys" -eq "1" ] && append bss_conf 
"wnm_sleep_mode_no_keys=1" "$N"
fi
[ "$bss_transition" -eq "1" ] && append bss_conf "bss_transition=1" "$N"
+   [ "$mbo" -eq 1 ] && append bss_conf "mbo=1" "$N"
  
  	json_get_vars ieee80211k rrm_neighbor_report rrm_beacon_report

set_default ieee80211k 0
@@ -883,6 +890,8 @@ hostapd_set_bss_options() {
;;
esac
  
+			[ "$mbo" -eq 1 ] && ft_over_ds=1

+

I'm a bit irritated about that. Why does mbo force this. To my knowledge, 
ft_over_ds=1 forces the roaming to go over the backhaul, not directly to the 
new AP.
So if the client can't reach his old AP, he won't roam.
Is that really correct?


[ -n "$network_ifname" ] && append bss_conf 
"ft_iface=$network_ifname" "$N"
append bss_conf "mobility_domain=$mobility_domain" "$N"
append bss_conf "ft_psk_generate_local=$ft_psk_generate_local" 
"$N"


Kind regards,

André


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

Re: [PATCH] hostapd: ubus: add BSS transtiton request method

[Andre Valentin]

Hi!

I tried this patch and at works as expected. Thank you very much!

André


Am 07.10.21 um 00:27 schrieb David Bauer:
> The existing wnm_disassoc_imminent ubus method only supports issuing a
> bss transition request with the disassoc imminent flag set.
> For use-cases, where the client is requested to roam to another BSS
> without a pending disassoc, this existing method is not suitable.
> 
> Add a new bss_transition_request ubus method, which provides a more
> universal way to dispatch a transition request. It takes the following
> arguments:
> 
> Required:
> addr: String - MAC-address of the STA to send the request to (colon-seperated)
> 
> Optional:
> abridged - Bool - Indicates if the abridged flag is set
> disassociation_imminent: Bool - Whether or not the disassoc_imminent
>  flag is set
> disassociation_timer: I32 - number of TBTTs after which the client will
>   be disassociated
> validity_period: I32 - number of TBTTs after which the beacon
>  candidate list (if included) will be invalid
> neighbors: blob-array - Array of strings containing neighbor reports as
>hex-string
> 
> Signed-off-by: David Bauer 
> ---
>  .../services/hostapd/src/src/ap/ubus.c| 152 +-
>  1 file changed, 112 insertions(+), 40 deletions(-)
> 
> diff --git a/package/network/services/hostapd/src/src/ap/ubus.c 
> b/package/network/services/hostapd/src/src/ap/ubus.c
> index 367e1b652b..1b5c60416f 100644
> --- a/package/network/services/hostapd/src/src/ap/ubus.c
> +++ b/package/network/services/hostapd/src/src/ap/ubus.c
> @@ -1275,60 +1275,30 @@ hostapd_rrm_beacon_req(struct ubus_context *ctx, 
> struct ubus_object *obj,
>  
>  
>  #ifdef CONFIG_WNM_AP
> -enum {
> - WNM_DISASSOC_ADDR,
> - WNM_DISASSOC_DURATION,
> - WNM_DISASSOC_NEIGHBORS,
> - WNM_DISASSOC_ABRIDGED,
> - __WNM_DISASSOC_MAX,
> -};
> -
> -static const struct blobmsg_policy wnm_disassoc_policy[__WNM_DISASSOC_MAX] = 
> {
> - [WNM_DISASSOC_ADDR] = { "addr", BLOBMSG_TYPE_STRING },
> - [WNM_DISASSOC_DURATION] { "duration", BLOBMSG_TYPE_INT32 },
> - [WNM_DISASSOC_NEIGHBORS] { "neighbors", BLOBMSG_TYPE_ARRAY },
> - [WNM_DISASSOC_ABRIDGED] { "abridged", BLOBMSG_TYPE_BOOL },
> -};
>  
>  static int
> -hostapd_wnm_disassoc_imminent(struct ubus_context *ctx, struct ubus_object 
> *obj,
> -   struct ubus_request_data *ureq, const char 
> *method,
> -   struct blob_attr *msg)
> +hostapd_bss_tr_send(struct hostapd_data *hapd, u8 *addr, bool 
> disassoc_imminent, bool abridged,
> + u16 disassoc_timer, u8 validity_period, struct blob_attr 
> *neighbors)
>  {
> - struct hostapd_data *hapd = container_of(obj, struct hostapd_data, 
> ubus.obj);
> - struct blob_attr *tb[__WNM_DISASSOC_MAX];
>   struct blob_attr *cur;
>   struct sta_info *sta;
> - int duration = 10;
> - int rem;
>   int nr_len = 0;
> + int rem;
>   u8 *nr = NULL;
> - u8 req_mode = WNM_BSS_TM_REQ_DISASSOC_IMMINENT;
> - u8 addr[ETH_ALEN];
> -
> - blobmsg_parse(wnm_disassoc_policy, __WNM_DISASSOC_MAX, tb, 
> blob_data(msg), blob_len(msg));
> -
> - if (!tb[WNM_DISASSOC_ADDR])
> - return UBUS_STATUS_INVALID_ARGUMENT;
> -
> - if (hwaddr_aton(blobmsg_data(tb[WNM_DISASSOC_ADDR]), addr))
> - return UBUS_STATUS_INVALID_ARGUMENT;
> -
> - if ((cur = tb[WNM_DISASSOC_DURATION]) != NULL)
> - duration = blobmsg_get_u32(cur);
> + u8 req_mode = 0;
>  
>   sta = ap_get_sta(hapd, addr);
>   if (!sta)
>   return UBUS_STATUS_NOT_FOUND;
>  
> - if (tb[WNM_DISASSOC_NEIGHBORS]) {
> + if (neighbors) {
>   u8 *nr_cur;
>  
> - if (blobmsg_check_array(tb[WNM_DISASSOC_NEIGHBORS],
> + if (blobmsg_check_array(neighbors,
>   BLOBMSG_TYPE_STRING) < 0)
>   return UBUS_STATUS_INVALID_ARGUMENT;
>  
> - blobmsg_for_each_attr(cur, tb[WNM_DISASSOC_NEIGHBORS], rem) {
> + blobmsg_for_each_attr(cur, neighbors, rem) {
>   int len = strlen(blobmsg_get_string(cur));
>  
>   if (len % 2)
> @@ -1344,7 +1314,7 @@ hostapd_wnm_disassoc_imminent(struct ubus_context *ctx, 
> struct ubus_object *obj,
>   }
>  
>   nr_cur = nr;
> - blobmsg_for_each_attr(cur, tb[WNM_DISASSOC_NEIGHBORS], rem) {
> + blobmsg_for_each_attr(cur, neighbors, rem) {
>   int len = strlen(blobmsg_get_string(cur)) / 2;
>  
>   *nr_cur++ = WLAN_EID_NEIGHBOR_REPORT;
> @@ -1361,15 +1331,116 @@ hostapd_wnm_disassoc_imminent(struct ubus_context 
> *ctx, struct ubus_object *obj,
>   if (nr)
>   req_mode |= WNM_BSS_TM_REQ_PREF_CAND_LIST_INCLUDED;
>  
> - if (tb[WNM_DISASSOC_ABRIDGED] && 
> 

Re: Resize of ath79 / ZyXEL NBG6716 kernel partition

[Andre Valentin via openwrt-devel]

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.--- Begin Message ---
Hi!
Am 23.05.21 um 11:05 schrieb Adrian Schmutzler:
> Hi,
> 
>> -Original Message-
>> From: Andre Valentin [mailto:a.valen...@ddimension.net]
>> Sent: Dienstag, 18. Mai 2021 20:11
>> To: OpenWrt Development List 
>> Subject: Resize of ath79 / ZyXEL NBG6716 kernel partition
>>
>> Hi!
>>
>> The NBG6716 has recently been disabled because of size problems with the
>> kernel partition.
>> I'm thinking about extending it to 8MB, shouldn't be a problem.
> 
> Interesting.
> 
> https://github.com/openwrt/openwrt/commit/5d8ea6d34f9f23d4dfff4ffcac8c9599d842c3a8
> 
> I was not aware that we are > 4 MiB for kernel already. Is there anything 
> special about this device (or probably ath79/nand) that causes bigger kernel?

It's a bit more interesting here. ZyXELs bootloader supports uimage lzma but 
only with a kernel size < ~4MB uncompressed or so..
The trick now is to use a uncompressed uimage and let now do jffs2 compress the 
image, which the bootloader supports.
That works, bit is way more unoptimized. This is the reason why we hit that 
limit earlier here.

Kind regards,

André

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Resize of ath79 / ZyXEL NBG6716 kernel partition

[Andre Valentin]

Hi!

>The NBG6716 has recently been disabled because of size problems with the 
>kernel partition.
>I'm thinking about extending it to 8MB, shouldn't be a problem.
>
>But I'm afraid users will brick their device when doing a sysupgrade to the 
>new flash layout.
>First time / in upgrade case it must be installed via manufacturer webif or 
>via bootloader.
>
>What do you propose in these cases?

Please help me solve this problem. Or should I just commit a change for the 
device with a hint in the commit message?
>
>Kind regards,
>
>André



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

Resize of ath79 / ZyXEL NBG6716 kernel partition

[Andre Valentin via openwrt-devel]

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.--- Begin Message ---
Hi!

The NBG6716 has recently been disabled because of size problems with the kernel 
partition.
I'm thinking about extending it to 8MB, shouldn't be a problem.

But I'm afraid users will brick their device when doing a sysupgrade to the new 
flash layout.
First time / in upgrade case it must be installed via manufacturer webif or via 
bootloader.

What do you propose in these cases?

Kind regards,

André

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus

[Andre Valentin]

Hi!

Am 17.05.21 um 12:54 schrieb Bjørn Mork:
> Andre Valentin  writes:
> 
>> There are gaps between the partitions. I can only imagine that this is 
>> because of bad block handling in the bootloader.
>> It seems it uses the end of the flash for reserve and also has holes betwee 
>> partitions for this.
> 
> Yes, that makes sense.
> 
> 
>> Manufacturer implementation:
>> He uses an initramfs image which is stored on Kernel and on Kernel2. Data is 
>> stored on data partition.
>>
>> 1st implementation by Björn:
>> Kernel partition is used for kernel, ubi (rootfs, rootfs_data)
>> -ubi image has to be uploaded separateley.
>> -installation via initramfs image needed
>> -sysupgrade working
>>
>> 2nd implemtation:
>> Kernel partition is used for kernel, rootfs and ubi (rootfs_data)
>> -rootfs is always included
>> -not initramfs installation needed.
>> -sysupgraded working
>>
>> I would prefer the 2nd solution, because it give us a working system after 
>> the initial flash.
>>
>> Modifications needed for 2nd implementation:
>> -mtdsplit_squashfs.c
>> -device specific upgrade flow
>>
>> Bootup processes with 2nd implementation:
>> The image has been flashed with the bootloader.
>> 1. Device boots up kernel.
>> 2. mtdsplit_uimage.c splits the image into parition kernel and rootfs
>> 3. mtdsplit_squashfs.c splits the rootfs parition into rootfs and ubi (see 
>> patch)
>> 4. ubi is initialized and formated if needed
>> 5. system is up
>>
>> What do you think? Use first or second implementation?
> 
> I don't think we can move the ubi partition around.  It needs to
> preserve the wear levelling metadata, or it becomes pointless.  And I
> don't think we want a writable rootfs without wear levelling.

Perhaps you misunterstood me, rootfs is always concatenated to the kernel.
The free space after the rootfs will be used for the UBI partition and only 
rootfs_data.
You're right, metadata will be lost. But is it so important?
> 
> We could have used the first part of your idea, havinng a dynamic split
> between kernel and the read-only rootfs, with a fixed ubi rootfs_data
> partition.  But it would be hard to place that fixed split to suit
> everyone.  The total size to play with isn't that much, with the
> recovery image abusing half the flash.  So we would end up with a rootfs
> and a rootfs_data which are both too small to be useful.

Absolutely!
> 
> There are also some other possible schemes taking advantage of the flash
> reserved for the recovery image.  But they will add some risk of the
> bootloader messing up the rootfs, which I don't think we should expose
> unsuspecting users to.  It's more like something we can do for our own
> personal images.

I tried that before. UBI on the space after rom partition. But after weeks of 
usage, I got funny errors (xz cannot decompress).
ubi never showed any errors in that case.. And I leaf at least 4 eraseblocks 
free at the end.
> 
> All in all, the current scheme was the best I could come up with.
> 
> It would still be possible to do a one-step initial install by creating
> a "factory" image with kernel+rootfs concatenated, like we do for many
> devices.  In fact, I created such an image at first.  And dropped it
> after it softbricked my test device, due to a bad block in the beginning
> of the "Kernel" partition. This caused the "ubi" data to end up at
> unexpected offset, and therefore not found where the kernel was looking
> for it.
Damn, correct. That could happen. I haven't testet it.
> 
> This is not a problem specific to these devices though.  But I think
> that users are better served by clear two-step installation instructions
> than a one-step solution known to brick some devices.
> 
> The NR7101 is the first device I've bought with a bad block in such an
> "unlucky" spot.  It's obviously not common. Still not something we can
> just disregard.
> 

I think the best way would be if we had an initramfs which is able to save 
config on a separate filesystem.
But it wouldn't be supported be the imagebuilder and needs more work.

Not easy..

Kind regards,

André



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

Re: [PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus

[Andre Valentin]

Hi !


Am 15.05.21 um 18:08 schrieb Bjørn Mork:
> [ answering some comments which also apply to the NR7101 ]
> 
> "Adrian Schmutzler"  writes:
> 
>>> +   partition@14 {
>>> +   label = "Kernel";
>>> +   reg = <0x14 0x1ec>;
>>> +   };
>>
>> "ubi" is part of kernel?
> 
> The operator specific firmware I have for the NR7101 does not use any
> rootfs partition at all.  The stock images are huge initramfs
> images. Any retained config is stored separately as a json blob in the
> ubifs formatted "data" partition.
> 
> I assume the same is true for the LTE3301-Plus?
It is!
>  
> The writable "data" partition isn't suitable for a rootfs IMHO.  It's
> tiny, and it's already full of stock/operator specific data which we
> want to retain in case of a revert to stock.
> 
> So I split out part of the "Kernel" partition for our rootfs..
> 
> I still kept the original "Kernel" partition intact so that it is
> possible to revert to stock without having to jump trough hoops.  The
> stock images are much, much larger than we want to reserve for the
> kernel, Typically 14-15 MB.
> 
>>> +
>>> +   partition@54 {
>>> +   label = "ubi";
>>> +   reg = <0x54 0x1ac>;
>>> +   };
>>> +
>>> +   partition@214 {
>>> +   label = "Kernel2";
>>> +   reg = <0x214 0x1ec>;
>>> +   };
>>
>> What's in 0x200 to 0x214? Or did I miscalculate?
> 
> No you didn't.  This is a hole in the stock firmware.  I was a bit
> unsure what to do about it. I left it alone to maintain the 1-to-1
> mapping with bootloader and stock firmware partitions, not wanting to
> risk that either secretly used the hole for something.
> 
> Funny thing is that there was a JFFS2 file system with UCI config files
> at 0x210 on the NR7101.  This was not mapped as a partition by the
> stock firmware, and obviously not mounted.  The contents was quite
> useful as it contained a file with gpio mappings among other stuff.
> Which was another reason I decided not to take this hole in use - the
> factory data in there could be useful.

Didn't notice that. Funny.
> 
> 
> 
Please let us talk about the flash layout:

Original:
partition@0 {
label = "uboot";
reg = <0x0 0x8>; /* 64 KB */
};
partition@8 {
label = "uboot_env";
reg = <0x8 0x8>; /* 64 KB */
};
factory: partition@10 {
label = "factory";
reg = <0x10 0x4>;
};
partition@14 {
label = "Kernel";
reg = <0x14 0x1ec>;
};
partition@214 {
label = "Kernel2";
reg = <0x214 0x1ec>;
};
partition@400 {
label = "wwan";
reg = <0x400 0x10>;
};

partition@410 {
label = "data";
reg = <0x410 0x100>;
};
partition@510 {
label = "rom-d";
reg = <0x510 0x10>;
};
partition@520 {
label = "reserve";
reg = <0x520 0x8>;
};


| uboot | uboot_env | factory | Kernel | Kernel 2 | wwan | data | rom.d | 
reserve

There are gaps between the partitions. I can only imagine that this is because 
of bad block handling in the bootloader.
It seems it uses the end of the flash for reserve and also has holes betwee 
partitions for this.

Manufacturer implementation:
He uses an initramfs image which is stored on Kernel and on Kernel2. Data is 
stored on data partition.

1st implementation by Björn:
Kernel partition is used for kernel, ubi (rootfs, rootfs_data)
-ubi image has to be uploaded separateley.
-installation via initramfs image needed
-sysupgrade working

2nd implemtation:
Kernel partition is used for kernel, rootfs and ubi (rootfs_data)
-rootfs is always included
-not initramfs installation needed.
-sysupgraded working

I would prefer the 2nd solution, because it give us a working system after the 
initial flash.

Modifications needed for 2nd implementation:
-mtdsplit_squashfs.c
-device specific upgrade flow

Bootup processes with 2nd implementation:
The image has been flashed with the bootloader.
1. Device boots up kernel.
2. mtdsplit_uimage.c splits the image into parition kernel and rootfs
3. mtdsplit_squashfs.c splits the rootfs parition into rootfs and ubi (see 
patch)
4. ubi is initialized and formated if needed
5. system is up

What do you think? Use first or 

Re: [PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus

[Andre Valentin]

Hi Adrian!

Please see comments below!

Am 15.05.21 um 16:05 schrieb Adrian Schmutzler:
> Hi,
> 
> comments below.
> 
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of André Valentin
>> Sent: Samstag, 15. Mai 2021 02:12
>> To: openwrt-devel@lists.openwrt.org
>> Cc: avalen...@marcant.net
>> Subject: [PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
>>
>> The ZyXEL LTE3301-Plus is an 4G indoor CPE with 2 external LTE antennas.
>>
>> Specifications:
>>
>>  - SoC: MediaTek MT7621AT
>>  - RAM: 256 MB
>>  - Flash: 128 MB MB NAND (MX30LF1G18AC)
>>  - WiFi: MediaTek MT7615E
>>  - Switch: 4 LAN ports (Gigabit)
>>  - LTE: Quectel EG506 connected by USB3 to SoC
>>  - SIM: 1 micro-SIM slot
>>  - USB: USB3 port
>>  - Buttons: Reset, WPS
>>  - LEDs: Multicolour power, internet, LTE, signal, Wifi, USB
>>  - Power: 12V, 1.5A
>>
>> The device is built as an indoor ethernet to LTE bridge or router with Wifi.
>>
>> UART Serial:
>>
>> 57600N1
>> Located on populated 5 pin header J5:
>>
>>  [o] GND
>>  [ ] key - no pin
>>  [o] 3.3V Vcc
>>  [o] RX
>>  [o] TX
>>
>> For more details about flashing see commit
>> 2449a632084b29632605e5a79ce5d73028eb15dd .
>>
>> Signed-off-by: André Valentin 
>> ---
>>  .../ramips/dts/mt7621_zyxel_lte3301-plus.dts  | 213 ++
>>  target/linux/ramips/image/mt7621.mk   |  16 ++
>>  .../mt7621/base-files/etc/board.d/01_leds |   4 +
>>  .../mt7621/base-files/etc/board.d/02_network  |   3 +
>>  .../base-files/etc/board.d/03_gpio_switches   |   3 +
>>  .../mt7621/base-files/etc/init.d/bootcount|   1 +
>>  .../mt7621/base-files/lib/upgrade/platform.sh |   1 +
>>  7 files changed, 241 insertions(+)
>>  create mode 100644 target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
>>
>> diff --git a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
>> b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
>> new file mode 100644
>> index 00..9f2939bb2b
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
>> @@ -0,0 +1,213 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +
>> +#include "mt7621.dtsi"
>> +
>> +#include 
>> +#include 
>> +
>> +/ {
>> +compatible = "zyxel,lte3301-plus", "mediatek,mt7621-soc";
>> +model = "ZyXEL LTE3301-Plus";
>> +
>> +aliases {
>> +label-mac-device = 
>> +led-boot = _power;
>> +led-failsafe = _power;
>> +led-running = _power;
>> +led-upgrade = _power;
>> +};
>> +
>> +chosen {
>> +bootargs = "console=ttyS0,57600";
>> +};
> 
> IIRC, this is already in the DTSI and can be dropped.
> 
>> +
>> +leds {
>> +compatible = "gpio-leds";
>> +
>> +led_power: power {
>> +label = "lte3301-plus:white:power";
> > drop model from LED labels, keeping just "white:power" etc.

Thanks, fixed!
> 
>> +gpios = < 5 GPIO_ACTIVE_HIGH>;
>> +};
>> +
>> +wifi {
>> +label = "lte3301-plus:white:wifi";
>> +gpios = < 13 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +internet {
>> +label = "lte3301-plus:white:internet";
>> +gpios = < 23 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +usb {
>> +label = "lte3301-plus:white:usb";
>> +gpios = < 24 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +lte {
>> +label = "lte3301-plus:white:lte";
>> +gpios = < 26 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +mobile_green {
>> +label = "lte3301-plus:green:mobile";
>> +gpios = < 31 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +mobile_orange {
>> +label = "lte3301-plus:orange:mobile";
>> +gpios = < 22 GPIO_ACTIVE_LOW>;
>> +};
> 
> Missing empty line between nodes.
Thanks, fixed!
> 
>> +mobile_red {
>> +label = "lte3301-plus:red:mobile";
>> +gpios = < 14 GPIO_ACTIVE_LOW>;
>> +};
>> +};
>> +
>> +keys {
>> +compatible = "gpio-keys";
>> +
>> +reset {
>> +label = "reset";
>> +gpios = < 18 GPIO_ACTIVE_LOW>;
>> +linux,code = ;
>> +};
>> +
>> +wps {
>> +label = "wps";
>> +gpios = < 6 GPIO_ACTIVE_LOW>;
>> +linux,code = ;
>> +};
>> +};
>> +};
>> +
>> + {
>> +status = "okay";
>> +
>> +lte_power {
>> +gpio-hog;
>> +gpios = <27 GPIO_ACTIVE_LOW>;
>> +output-high;
>> +line-name = "lte-power";
>> +};
>> +
>> +usb_power {
>> +gpio-hog;
>> +gpios = <7 GPIO_ACTIVE_HIGH>;

Re: [PATCH 1/2] firmware-utils: zytrx: Add support for ZyXEL LTE3301-Plus

[Andre Valentin]

Am 15.05.21 um 12:00 schrieb Bjørn Mork:
> André Valentin  writes:
> 
>> This adds a new device id to the image tools.
>>
>> Signed-off-by: André Valentin 
>> ---
>>  tools/firmware-utils/src/zytrx.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/firmware-utils/src/zytrx.c 
>> b/tools/firmware-utils/src/zytrx.c
>> index 302efc6010..b3bbbe3c69 100644
>> --- a/tools/firmware-utils/src/zytrx.c
>> +++ b/tools/firmware-utils/src/zytrx.c
>> @@ -96,6 +96,7 @@ static struct board_t {
>>  uint32_t modelid;
>>  } boards[] = {
>>  { "MT7621A", "NR7101", 0x07010001 },
>> +{ "MT7621A", "LTE3301-PLUS", 0x03030001 },
>>  {}
>>  };
> 
> 
> Great!
> 
> But I winder if my initial implementation was a bit on the stupid
> side. We might want to move those two fields out of the code and just
> provide them directly as input parameters instead of this indirect
> mapping.  What do you think?

It think we should move it outside. I expect ZyXEL to produce more of this 
stuff.
> 
> Anyway, good to know that the remaining fields are constant.  In
> particular the magic code "3 6035 122 0\n".  This was identical in your
> stock firmware image?  I wonder what it means...

It is. But a real test with a transition from original firmware has to be done 
yet. Verified is replacement with update via bootloader.
> 
> As you might have noticed, I guessed a lot when writing this tool :-)But the 
> right guess :-) Thank you for your effort in this.
> 
> I got the GPL source drop for the NR7101 from ZyXEL a while later. But
> that didn't help much as the image header tool was provided only as
> binary.  Pretty much expected, and nothing to complain about. They are
> still among the best by providing code that will build a complete
> working image, and including source for all the GPL parts AFAICS.
Yes, that's the reason why we use ZyXEL devices. The always provide full 
source, but with a locked image builder binary.
That's why I could release this so quick after your commit. I just waited for 
someone able to implement the image builder.


Kind regards,

André



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

Re: [PATCH v2] hostapd: enable background scanning in wpa_supplicant_full

[Andre Valentin]

Hi Daniel!

Am 07.10.20 um 02:24 schrieb Daniel Golle:
> Hi Andre,
> 
> On Wed, Sep 16, 2020 at 08:41:03PM +0200, Andre Valentin wrote:
>> Hello!
>>
>> Could someone please take care of this little snippet?
> 
> Apart from this no longer applying due to other changes (trivial
> to fix, I'd had it pulled in anyway), I also stumbled into an issue,
> see below>
>>
>> Kind regards,
>>
>> André
>> Am 09.09.20 um 22:00 schrieb André Valentin:
>>> Activation of autoscanning enables a a wifi client to select the best
>>> accesspoint based on rssi.
>>>
>>> This feature is useful in case you have multiple access points in your range
>>> and you do not want to stick the client on the first one it connected to.
>>> Especially when used with 802.11r this allows seamless transition to the
>>> optimal accesspoints.
>>>
>>> Setting the config value bgscan to -65 will tell wpa_supplicant to try to
>>> connect to an access points with better rssi.
>>>
>>> Example config:
>>> config wifi-iface 'default_radio1'
>>> option device 'radio1'
>>> option mode 'sta'
>>> option ssid 'openwrt'
>>> option encryption 'psk2'
>>> option key 'mykey'
>>> option network 'wlan'
>>> option roam_rssi_threshold '-65'
>>>
>>> The ipk sizes for mipsel_24kc change like this:
>>> old:
>>> wpad-openssl_2020-06-08-5a8b3662-4_mipsel_24kc.ipk 550133
>>>
>>> new:
>>> wpad-openssl_2020-06-08-5a8b3662-5_mipsel_24kc.ipk 551961
>>>
>>> Signed-off-by: André Valentin 
>>> ---
>>>  package/network/services/hostapd/files/hostapd.sh  
>>> | 7 +++
>>>  package/network/services/hostapd/files/wpa_supplicant-full.config  | 6 
>>> +++---
>>>  package/network/services/hostapd/Makefile  | 1 +-
>>>  3 files changed, 11 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/package/network/services/hostapd/files/hostapd.sh 
>>> b/package/network/services/hostapd/files/hostapd.sh
>>> index 88113cd7ce..85299234c2 100644
>>> --- a/package/network/services/hostapd/files/hostapd.sh
>>> +++ b/package/network/services/hostapd/files/hostapd.sh
>>> @@ -272,6 +272,8 @@ hostapd_common_add_bss_config() {
>>> config_add_array operator_icon
>>> config_add_array hs20_conn_capab
>>> config_add_string osu_ssid hs20_wan_metrics hs20_operating_class 
>>> hs20_t_c_filename hs20_t_c_timestamp
>>> +
>>> +   config_add_string roam_rssi_threshold
>>>  }
>>>  
>>>  hostapd_set_vlan_file() {
>>> @@ -1178,6 +1180,11 @@ wpa_supplicant_add_network() {
>>> [ -n "$bssid_blacklist" ] && append network_data 
>>> "bssid_blacklist=$bssid_blacklist" "$N$T"
>>> [ -n "$bssid_whitelist" ] && append network_data 
>>> "bssid_whitelist=$bssid_whitelist" "$N$T"
>>>  
>>> +   [ -n "$roam_rssi_threshold" ] && {
>>> +   json_get_vars roam_rssi_threshold
>>> +   append network_data 
>>> "bgscan=\"simple:120:${roam_rssi_threshold}:600\"" "$N$T"
>>> +   }
>>> +
> 
> This looks odd to me. You are checking the content of the variable and
> then (re-?)loading it?
Don't ask. I noticed this also yesterday. Remember: do not change this seconds 
before publishing.
I will provide a v3 at the weekend,

> 
>>> [ -n "$basic_rate" ] && {
>>> local br rate_list=
>>> for br in $basic_rate; do
>>> diff --git 
>>> a/package/network/services/hostapd/files/wpa_supplicant-full.config 
>>> b/package/network/services/hostapd/files/wpa_supplicant-full.config
>>> index 982f4d5534..d39ee74a8d 100644
>>> --- a/package/network/services/hostapd/files/wpa_supplicant-full.config
>>> +++ b/package/network/services/hostapd/files/wpa_supplicant-full.config
>>> @@ -527,9 +527,9 @@ CONFIG_WNM=y
>>>  #
>>>  # Enabling directly a module will enable autoscan support.
>>>  # For exponential module:
>>> -#CONFIG_AUTOSCAN_EXPONENTIAL=y
>>> +CONFIG_AUTOSCAN_EXPONENTIAL=y
>>>  # For periodic module:
>>> -#CONFIG_AUTOSCAN_PERIODIC=y
>>> +CONFIG_AUTOSCAN_PERIODIC=y
>>>  
>>>  # Password (and passphrase, etc.) backend for external storage
>>>  # T

Re: [PATCH V3 uhttpd] ubus: add new RESTful API

[Andre Valentin]

Hi Rafał!

Am 23.09.20 um 23:37 schrieb Rafał Miłecki:
> On 2020-09-23 23:33, Andre Valentin wrote:
>> I'm experimenting again a bit with the new API. I subscribed to the
>> hostapd events and saw that
>> after some time the connection is still up, but now new events come in.
>> How can I control timeout and make sure, that the subscription
>> connections stays as long as
>> possible online?
> 
> Did you mean "no new events"? Please try:
> [PATCH uhttpd] client: really close connection on timeout
> https://patchwork.ozlabs.org/project/openwrt/patch/20200923104327.14812-1-zaj...@gmail.com/

Thanks for the hint. Will try it and come back. BTW, how long can such a 
subscription persist?
Is it controlled with the "-e" switch?

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH V3 uhttpd] ubus: add new RESTful API

[Andre Valentin]

Hi Rafał!

I'm experimenting again a bit with the new API. I subscribed to the hostapd 
events and saw that
after some time the connection is still up, but now new events come in.
How can I control timeout and make sure, that the subscription connections 
stays as long as
possible online?

Kind regards,

André

Am 14.09.20 um 17:15 schrieb Rafał Miłecki:
> From: Rafał Miłecki 
> 
> Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
> from supporting ubus notifications that don't fit its model.
> 
> Notifications require protocol that allows server to send data without
> being polled. There are two candidates for that:
> 1. Server-sent events
> 2. WebSocket
> 
> The later one is overcomplex for this simple task so ideally uhttps ubus
> should support text-based server-sent events. It's not possible with
> JSON-RPC without violating it. Specification requires server to reply
> with Response object. Replying with text/event-stream is not allowed.
> 
> All above led to designing new API that:
> 1. Uses GET and POST requests
> 2. Makes use of RESTful URLs
> 3. Uses JSON-RPC in cleaner form and only for calling ubus methods
> 
> This new API allows:
> 1. Listing all ubus objects and their methods using GET /list
> 2. Listing object methods using GET /list/
> 3. Listening to object notifications with GET /subscribe/
> 4. Calling ubus methods using POST /call/
> 
> JSON-RPC custom protocol was also simplified to:
> 1. Use "method" member for ubus object method name
>It was possible thanks to using RESTful URLs. Previously "method"
>had to be "list" or "call".
> 2. Reply with Error object on ubus method call error
>This simplified "result" member format as it doesn't need to contain
>ubus result code anymore.
> 
> This patch doesn't break or change the old API. The biggest downside of
> the new API is no support for batch requests. It's cost of using RESTful
> URLs. It should not matter much as uhttpd supports keep alive.
> 
> Example usages:
> 
> 1. Getting all objects and their methods:
> $ curl http://192.168.1.1/ubus/list
> {
>   "dhcp": {
>   "ipv4leases": {
> 
>   },
>   "ipv6leases": {
> 
>   }
>   },
>   "log": {
>   "read": {
>   "lines": "number",
>   "stream": "boolean",
>   "oneshot": "boolean"
>   },
>   "write": {
>   "event": "string"
>   }
>   }
> }
> 
> 2. Getting object methods:
> $ curl http://192.168.1.1/ubus/list/log
> {
>   "read": {
>   "lines": "number",
>   "stream": "boolean",
>   "oneshot": "boolean"
>   },
>   "write": {
>   "event": "string"
>   }
> }
> 
> 3. Subscribing to notifications:
> $ curl http://192.168.1.1/ubus/subscribe/foo
> event: status
> data: {"count":5}
> 
> 4. Calling ubus object method:
> $ curl -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "login",
> "params": {"username": "root", "password": "password" }
> }' http://192.168.1.1/ubus/call/session
> {
>   "jsonrpc": "2.0",
>   "id": 1,
>   "result": {
>   "ubus_rpc_session": "01234567890123456789012345678901",
>   (...)
>   }
> }
> 
> $ curl -H 'Authorization: Bearer 01234567890123456789012345678901' -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "write",
> "params": {"event": "Hello world" }
> }' http://192.168.1.1/ubus/call/log
> {
>   "jsonrpc": "2.0",
>   "id": 1,
>   "result": null
> }
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Use "Authorization" with Bearer for rpcd session id / token
> Treat missing session id as UH_UBUS_DEFAULT_SID
> Fix "result" format (was: "result":{{"foo":"bar"}})
> V3: Treat /ubus/ requests as legacy ones for backward compatibility.
> Previously there were causing 404 (only /ubus was accepted).
> Support requests with search path (e.g. ?foo=bar) by ignoring it.
> This may be used by some clients to avoid caching responses.
> Rebase on the [PATCH uhttpd] ubus: fix blob_buf initialization



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] hostapd: enable background scanning in wpa_supplicant_full

[Andre Valentin]

Hello!

Could someone please take care of this little snippet?

Kind regards,

André
Am 09.09.20 um 22:00 schrieb André Valentin:
> Activation of autoscanning enables a a wifi client to select the best
> accesspoint based on rssi.
> 
> This feature is useful in case you have multiple access points in your range
> and you do not want to stick the client on the first one it connected to.
> Especially when used with 802.11r this allows seamless transition to the
> optimal accesspoints.
> 
> Setting the config value bgscan to -65 will tell wpa_supplicant to try to
> connect to an access points with better rssi.
> 
> Example config:
> config wifi-iface 'default_radio1'
>   option device 'radio1'
>   option mode 'sta'
>   option ssid 'openwrt'
>   option encryption 'psk2'
>   option key 'mykey'
>   option network 'wlan'
>   option roam_rssi_threshold '-65'
> 
> The ipk sizes for mipsel_24kc change like this:
> old:
> wpad-openssl_2020-06-08-5a8b3662-4_mipsel_24kc.ipk 550133
> 
> new:
> wpad-openssl_2020-06-08-5a8b3662-5_mipsel_24kc.ipk 551961
> 
> Signed-off-by: André Valentin 
> ---
>  package/network/services/hostapd/files/hostapd.sh| 7 
> +++
>  package/network/services/hostapd/files/wpa_supplicant-full.config  | 6 
> +++---
>  package/network/services/hostapd/Makefile| 1 +-
>  3 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/package/network/services/hostapd/files/hostapd.sh 
> b/package/network/services/hostapd/files/hostapd.sh
> index 88113cd7ce..85299234c2 100644
> --- a/package/network/services/hostapd/files/hostapd.sh
> +++ b/package/network/services/hostapd/files/hostapd.sh
> @@ -272,6 +272,8 @@ hostapd_common_add_bss_config() {
>   config_add_array operator_icon
>   config_add_array hs20_conn_capab
>   config_add_string osu_ssid hs20_wan_metrics hs20_operating_class 
> hs20_t_c_filename hs20_t_c_timestamp
> +
> + config_add_string roam_rssi_threshold
>  }
>  
>  hostapd_set_vlan_file() {
> @@ -1178,6 +1180,11 @@ wpa_supplicant_add_network() {
>   [ -n "$bssid_blacklist" ] && append network_data 
> "bssid_blacklist=$bssid_blacklist" "$N$T"
>   [ -n "$bssid_whitelist" ] && append network_data 
> "bssid_whitelist=$bssid_whitelist" "$N$T"
>  
> + [ -n "$roam_rssi_threshold" ] && {
> + json_get_vars roam_rssi_threshold
> + append network_data 
> "bgscan=\"simple:120:${roam_rssi_threshold}:600\"" "$N$T"
> + }
> +
>   [ -n "$basic_rate" ] && {
>   local br rate_list=
>   for br in $basic_rate; do
> diff --git 
> a/package/network/services/hostapd/files/wpa_supplicant-full.config 
> b/package/network/services/hostapd/files/wpa_supplicant-full.config
> index 982f4d5534..d39ee74a8d 100644
> --- a/package/network/services/hostapd/files/wpa_supplicant-full.config
> +++ b/package/network/services/hostapd/files/wpa_supplicant-full.config
> @@ -527,9 +527,9 @@ CONFIG_WNM=y
>  #
>  # Enabling directly a module will enable autoscan support.
>  # For exponential module:
> -#CONFIG_AUTOSCAN_EXPONENTIAL=y
> +CONFIG_AUTOSCAN_EXPONENTIAL=y
>  # For periodic module:
> -#CONFIG_AUTOSCAN_PERIODIC=y
> +CONFIG_AUTOSCAN_PERIODIC=y
>  
>  # Password (and passphrase, etc.) backend for external storage
>  # These optional mechanisms can be used to add support for storing passwords
> @@ -600,7 +600,7 @@ CONFIG_IBSS_RSN=y
>  # operations for roaming within an ESS (same SSID). See the bgscan parameter 
> in
>  # the wpa_supplicant.conf file for more details.
>  # Periodic background scans based on signal strength
> -#CONFIG_BGSCAN_SIMPLE=y
> +CONFIG_BGSCAN_SIMPLE=y
>  # Learn channels used by the network and try to avoid bgscans on other
>  # channels (experimental)
>  #CONFIG_BGSCAN_LEARN=y
> diff --git a/package/network/services/hostapd/Makefile 
> b/package/network/services/hostapd/Makefile
> index 8f94dce782..8c264854d7 100644
> --- a/package/network/services/hostapd/Makefile
> +++ b/package/network/services/hostapd/Makefile
> @@ -7,7 +7,7 @@
>  include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=hostapd
> -PKG_RELEASE:=5
> +PKG_RELEASE:=6
>  
>  PKG_SOURCE_URL:=http://w1.fi/hostap.git
>  PKG_SOURCE_PROTO:=git
> 


-- 
Mit freundlichen Grüßen
André Valentin

Systemadministration - Projektkoordination


--
MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net  | 
http://www.global-m2m.com 

Internet * Netzwerk * Mobile Daten

Vorstand:
Thorsten Hojas (Vorsitzender)
Marc-Henrik Delker
Dr. Anja-Christina Padberg
Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238



___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements 

Re: MT7621 Flow Control

[Andre Valentin]

Hello,

it seems that I had another problem when upgrading from 4.14 to 5.4.
In 4.14 network config I had no switch definition and it worked out of the box.
But with 5.4 I need a switch config in network config like that:
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option metric '10'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 6t'

Sorry for the noise.

I could now check one of the bricked devices and found no hint for the FC issue.

Kind regards,

André


Am 06.08.20 um 14:31 schrieb Andre Valentin:
> Hi Jaap,
> 
> 
> Am 06.08.20 um 13:43 schrieb Jaap Buurman:
>> Dear all,
>>
>> I have noticed the flow control work for mt7621 in the following
>> Openwrt patch: 
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0
>>
>> However, the problem that the patch is supposed to fix is still
>> occurring, even in combination with other experimental patches
>> submitted. These experiences can be read about here:
>> https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/
>>
>> However, on this mailing list a user by the name of Kristian claims
>> that disabling flow control helps fix this problem, as can be read
>> here: 
>> https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html
>>
>> From what I understood, he was running many mt7621 devices
>> commercially, with many of them experiencing the issue, which were all
>> fixed with his own flow control patch. My question is why the decision
>> was made to only disable flow control on port 5 in the above mentioned
>> Openwrt patch? AFAIK, Kristian's own patch disables flow control on
>> all of the ports and he claims the issue is fixed for him. Perhaps the
>> current patch should be extended to disable flow control on all ports?
>> What are people's thoughts on this?
> 
> I'm facing the same issue now after upgrading to 5.4 kernel more often than 
> before.
> Every second reboot reboot with 5.4 fails with this timeout error.
> 
>>
>> Yours sincerely,
>>
>> Jaap
> 
> André
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


-- 
Mit freundlichen Grüßen
André Valentin

Systemadministration - Projektkoordination


--
MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net <http://www.marcant.net/> | 
http://www.global-m2m.com <http://www.global-m2m.com/>

Internet * Netzwerk * Mobile Daten

Vorstand:
Thorsten Hojas (Vorsitzender)
Marc-Henrik Delker
Dr. Anja-Christina Padberg
Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238



___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

 




smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: MT7621 Flow Control

[Andre Valentin]

Hi Jaap,


Am 06.08.20 um 13:43 schrieb Jaap Buurman:
> Dear all,
> 
> I have noticed the flow control work for mt7621 in the following
> Openwrt patch: 
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0
> 
> However, the problem that the patch is supposed to fix is still
> occurring, even in combination with other experimental patches
> submitted. These experiences can be read about here:
> https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/
> 
> However, on this mailing list a user by the name of Kristian claims
> that disabling flow control helps fix this problem, as can be read
> here: 
> https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html
> 
> From what I understood, he was running many mt7621 devices
> commercially, with many of them experiencing the issue, which were all
> fixed with his own flow control patch. My question is why the decision
> was made to only disable flow control on port 5 in the above mentioned
> Openwrt patch? AFAIK, Kristian's own patch disables flow control on
> all of the ports and he claims the issue is fixed for him. Perhaps the
> current patch should be extended to disable flow control on all ports?
> What are people's thoughts on this?

I'm facing the same issue now after upgrading to 5.4 kernel more often than 
before.
Every second reboot reboot with 5.4 fails with this timeout error.

> 
> Yours sincerely,
> 
> Jaap

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

[Andre Valentin]

Hi!

Am 04.08.20 um 18:40 schrieb Rafał Miłecki:
> On 04.08.2020 09:43, Andre Valentin wrote:
>> Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
>>> On 31.07.2020 13:02, Andre Valentin wrote:
>>>> this is really great stuff. It would help me to get forward with my wifi 
>>>> controller.
>>>> Could it be possible to subsribe to multiple sources to limit the 
>>>> connections to ubus?
>>>> 2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand 
>>>> right.
>>>
>>> I'm happy someone finds it useful!
>>>
>>> If you mean hostapd.* objects, that's right. That would require you to
>>> use:
>>> /ubus/subscribe/hostapd.wlan0
>>> /ubus/subscribe/hostapd.wlan0-1
>>> /ubus/subscribe/hostapd.wlan1
>>> /ubus/subscribe/hostapd.wlan1-1
>>>
>>> For subscribing to multiple objects we would need to:
>>> 1. Stick to GET due to the way EventSource works
>>> 2. Pick some more generic URL
>>> 3. Adjust output format ("event" and "data" fields)
>>>
>>> So my guess would be something like:
>>>
>>> $ curl 
>>> http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0=hostapd.wlan1
>>
>> Good idea!
>>
>>> event: hostapd.wlan1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan0-1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan1 status
>>> data: {"count":7}
>>>
>>>
>>> Regarding parsing events stream, event names with spaces seem to be OK:
>>> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
>>> field value can use any scalar value other than line break char.
>>
>> Why do you need the status there, is it part of the standard?
> 
> That was meant to separate object name from notification name.
> 
OK, I understand.
> 
>>> We should use some special character as separator of object name and
>>> notification name. It must be something that ubus doesn't use in any of
>>> them. Should space be OK? Or should we use some more fancy char? I
>>> quickly tested space and it seems to work well in Firefox and Chromium.
>>
>> Oh, I'm nut sure. But I think space is fine.
>>
>> Did you use a special uhttpd version. I couldn't apply your patch to the 
>> uhttpd in openwrt master.
> 
> There are few more uhttpd pending patches that I sent, see:
> https://patchwork.ozlabs.org/project/openwrt/list/?series==5824=*=uhttpd==

Okay, will give it a try again at the weekend.

Kind regards,

André




smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Fate of 4.14 targets / samsung odroid HC1 support

[Andre Valentin]

Hi!

Am 04.08.20 um 22:14 schrieb Adrian Schmutzler:
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of Andre Valentin
>> Sent: Dienstag, 4. August 2020 17:48
>> To: openwrt-devel@lists.openwrt.org
>> Subject: Re: Fate of 4.14 targets / samsung odroid HC1 support
>>
>> Hi!
>>
>> I've enabled support for the odoid HC1 in the samsung target a month ago, it
>> only needs generic 5.4 kernel and is a subtarget.
>> https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
>> Only open thing is the boodloader on the sdcard, which is a binary for
>> hardkernel.
> 
> Just had a look, samsung target seems to use a custom nand driver.
> > Based on what I remember from other targets, I don't think this will be fun 
> > to upgrade from 4.14 to 5.4 ...
> 
> And in particular, we would need somebody interested with a device to do that 
> ...
> 
I don't have that device either. I would wait for deletion of the samsung 
target and come back again.

Thanks,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Fate of 4.14 targets / samsung odroid HC1 support

[Andre Valentin]

Hi!

I've enabled support for the odoid HC1 in the samsung target a month ago, it 
only needs generic 5.4 kernel and is a subtarget.
https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
Only open thing is the boodloader on the sdcard, which is a binary for 
hardkernel.

If there is interest I could send a patch.

Otherwise I would keep it private.

Kind regards,

André



Am 04.08.20 um 16:43 schrieb m...@adrianschmutzler.de:
> Hi together,
> 
> with bcm47xx/bcm53xx bumped to 5.4 now (thanks!), we are left we the 
> following targets that (most likely) won't be moved to 5.4 anymore:
> 
> 4.19: cns3xxx
> 4.14: ar71xx, at91, ath25, pistachio, rb532, samsung, uml
> 
> Now, where 20.xx comes closer, I wonder whether we should remove the 4.14 
> targets _before_ branching.
> Those are already two LTS kernel versions behind, the probability that 
> somebody will bump them to an even newer kernel after 20.xx is quite small.
> Despite, if we drop them before the branch, we only have to drop them once. 
> :-)
> After having reminded about the situation of the named targets several times, 
> I don't think anything will change if we wait any longer with this step.
> 
> The only remaining targets with 4.14 support would be ramips and arc770 then.
> 
> Thoughts/opinions?
> 
> Best
> 
> Adrian
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


-- 
Mit freundlichen Grüßen
André Valentin

Systemadministration - Projektkoordination


--
MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net  | 
http://www.global-m2m.com 

Internet * Netzwerk * Mobile Daten

Vorstand:
Thorsten Hojas (Vorsitzender)
Marc-Henrik Delker
Dr. Anja-Christina Padberg
Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238



___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

 




smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

[Andre Valentin]

Hi!

Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
> On 31.07.2020 13:02, Andre Valentin wrote:
>> this is really great stuff. It would help me to get forward with my wifi 
>> controller.
>> Could it be possible to subsribe to multiple sources to limit the 
>> connections to ubus?
>> 2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand 
>> right.
> 
> I'm happy someone finds it useful!
> 
> If you mean hostapd.* objects, that's right. That would require you to
> use:
> /ubus/subscribe/hostapd.wlan0
> /ubus/subscribe/hostapd.wlan0-1
> /ubus/subscribe/hostapd.wlan1
> /ubus/subscribe/hostapd.wlan1-1
> 
> For subscribing to multiple objects we would need to:
> 1. Stick to GET due to the way EventSource works
> 2. Pick some more generic URL
> 3. Adjust output format ("event" and "data" fields)
> 
> So my guess would be something like:
> 
> $ curl http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0=hostapd.wlan1

Good idea!

> event: hostapd.wlan1 status
> data: {"count":5}
> 
> event: hostapd.wlan0-1 status
> data: {"count":5}
> 
> event: hostapd.wlan1 status
> data: {"count":7}
> 
> 
> Regarding parsing events stream, event names with spaces seem to be OK:
> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
> field value can use any scalar value other than line break char.

Why do you need the status there, is it part of the standard?


> We should use some special character as separator of object name and
> notification name. It must be something that ubus doesn't use in any of
> them. Should space be OK? Or should we use some more fancy char? I
> quickly tested space and it seems to work well in Firefox and Chromium.

Oh, I'm nut sure. But I think space is fine.

Did you use a special uhttpd version. I couldn't apply your patch to the uhttpd 
in openwrt master.

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

[Andre Valentin]

Hi Rafel,

this is really great stuff. It would help me to get forward with my wifi 
controller.
Could it be possible to subsribe to multiple sources to limit the connections 
to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand right.

Kind regards,

André

Am 31.07.20 um 06:49 schrieb Rafał Miłecki:
> From: Rafał Miłecki 
> 
> Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
> from supporting ubus notifications that don't fit its model.
> 
> Notifications require protocol that allows server to send data without
> being polled. There are two candidates for that:
> 1. Server-sent events
> 2. WebSocket
> 
> The later one is overcomplex for this simple task so ideally uhttps ubus
> should support text-based server-sent events. It's not possible with
> JSON-RPC without violating it. Specification requires server to reply
> with Response object. Replying with text/event-stream is not allowed.
> 
> All above led to designing new API that:
> 1. Uses GET and POST requests
> 2. Makes use of RESTful URLs
> 3. Uses JSON-RPC in cleaner form and only for calling ubus methods
> 
> This new API allows:
> 1. Listing all ubus objects and their methods using GET /list
> 2. Listing object methods using GET /list/
> 3. Listening to object notifications with GET /subscribe/
> 4. Calling ubus methods using POST /call/
> 
> JSON-RPC custom protocol was also simplified to:
> 1. Use "method" member for ubus object method name
>It was possible thanks to using RESTful URLs. Previously "method"
>had to be "list" or "call".
> 2. Reply with Error object on ubus method call error
>This simplified "result" member format as it doesn't need to contain
>ubus result code anymore.
> 
> This patch doesn't break or change the old API. The biggest downside of
> the new API is no support for batch requests. It's cost of using RESTful
> URLs. It should not matter much as uhttpd supports keep alive.
> 
> Example usages:
> 
> 1. Getting all objects and their methods:
> $ curl http://192.168.1.1/ubus/list
> {
>   "dhcp": {
>   "ipv4leases": {
> 
>   },
>   "ipv6leases": {
> 
>   }
>   },
>   "log": {
>   "read": {
>   "lines": "number",
>   "stream": "boolean",
>   "oneshot": "boolean"
>   },
>   "write": {
>   "event": "string"
>   }
>   }
> }
> 
> 2. Getting object methods:
> $ curl http://192.168.1.1/ubus/list/log
> {
>   "read": {
>   "lines": "number",
>   "stream": "boolean",
>   "oneshot": "boolean"
>   },
>   "write": {
>   "event": "string"
>   }
> }
> 
> 3. Subscribing to notifications:
> $ curl http://192.168.1.1/ubus/subscribe/foo
> event: status
> data: {"count":5}
> 
> 4. Calling ubus object method:
> $ curl -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "login",
> "params": {"username": "root", "password": "password" }
> }' http://192.168.1.1/ubus/call/session
> {
>   "jsonrpc": "2.0",
>   "id": 1,
>   "result": {
>   "ubus_rpc_session": "01234567890123456789012345678901",
>   (...)
>   }
> }
> 
> $ curl -H 'Authorization: Bearer 01234567890123456789012345678901' -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "write",
> "params": {"event": "Hello world" }
> }' http://192.168.1.1/ubus/call/log
> {
>   "jsonrpc": "2.0",
>   "id": 1,
>   "result": null
> }
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Use "Authorization" with Bearer for rpcd session id / token
> Treat missing session id as UH_UBUS_DEFAULT_SID
> Fix "result" format (was: "result":{{"foo":"bar"}})
> ---
>  main.c   |   8 +-
>  ubus.c   | 326 +++
>  uhttpd.h |   5 +
>  3 files changed, 318 insertions(+), 21 deletions(-)
> 
> diff --git a/main.c b/main.c
> index 26e74ec..73e3d42 100644
> --- a/main.c
> +++ b/main.c
> @@ -159,6 +159,7 @@ static int usage(const char *name)
>   "   -U file Override ubus socket path\n"
>   "   -a  Do not authenticate JSON-RPC requests 
> against UBUS session api\n"
>   "   -X  Enable CORS HTTP headers on JSON-RPC 
> api\n"
> + "   -e  Events subscription reconnection time 
> (retry value)\n"
>  #endif
>   "   -x string   URL prefix for CGI handler, default is 
> '/cgi-bin'\n"
>   "   -y alias[=path] URL alias handle\n"
> @@ -262,7 +263,7 @@ int main(int argc, char **argv)
>   init_defaults_pre();
>   signal(SIGPIPE, SIG_IGN);
>  
> - while ((ch = getopt(argc, argv, 
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> + while ((ch = getopt(argc, argv, 
> 

Re: [OpenWrt-Devel] [RFC 0/3] PoC for per-image package sets

[Andre Valentin]

Hi Bjoern,

that looks very interesting. I do have the same problems here with initial 
images and made special .configs for that.

Kind regards,

André


Am 22.04.20 um 22:58 schrieb Bjørn Mork:
> These patches can also be found in a branch here:
> https://github.com/bmork/openwrt/tree/image-packagesets
> 
> Dumping this as-is for discussion.  Not sure I'm capable of, or
> will have time to, finish it.  But I am hoping it is a useful
> start if someone else wants to give it a try.  If not, then I
> guess it isn't a useful enough feature after all.
> 
> The state of this is sort-of working for me, but definitely
> not complete and working for all different build scenarios.
> I have not tested IB or PER_TARGET_ROOTFS builds.  legacy-devices
> haven't been updated at all and are therefore broken. etc.
> 
> To recap the use case:  I have a device where the vendor tftp
> server limits the size of the initial OpenWrt image we can 
> upload. An initramfs image is preferrable due to the ability to
> boot from either of the dual partitions.
> 
> For this reason I wanted to build an initramfs with a limited
> set of packages, without having to reduce the default device
> packages for the other images.
> 
> I have noticed that this use case is not unique.  We have for
> example Build/ubnt-erx-factory-image in mt7621.mk, attempting
> to build an initramfs based image which will fit within
> $(KERNEL_SIZE), which is a tiny 3MB.  This is obviously futile
> and there is therefore no such image on downloads.openwrt.org.
> You can build one yourself by carefully removing packages, but
> it would be nice if we could let the buildbots produce one too.
> 
> Anyway, look at the code and see if my ideas can be used. I'll
> admit that I'm no make Guru...
> 
> The first patch simplifies the current initramfs process, and
> avoids copying the special initramfs /init into the shared
> TARGET_DIR. It still makes a copy of the file to be able to
> set the timestamp though.  I believe this patch is useful by
> itself, and I don't think it breaks anything.  Not mcuh at
> least :-)
> 
> The second patch tries to abuse the per-target rootfs code
> for doing per-image roofs.  The default package set can be
> adjusted by adding packages to an IMAGE_PACKAGES/
> variable.  Or more useful: Packages can be removed by
> prefixing them with a '-'.  As usual, you'll need to resolve
> dependencies manually if other packackes depend on the ones
> you want to remove.
> 
> The third patch is the yuckiest one.  It delays the kernel
> part of the initramfs building until we have some idea about
> images, devices and packages.  It then uses the same 
> per-image rootfs source directory scheme as input for the
> kernel.  I'm not proud of how this curretly looks.  But I had
> to stop here.  
> 
> 
> Bjørn Mork (3):
>   kernel-defaults: refactor initramfs build
>   build: implement per-image package sets
>   build: per-image package set for initramfs
> 
>  include/image.mk   | 33 
>  include/kernel-build.mk|  1 -
>  include/kernel-defaults.mk | 77 ++
>  3 files changed, 53 insertions(+), 58 deletions(-)
> 


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

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Hi Sergio

Am 10.04.20 um 13:36 schrieb Sergio Paracuellos:
>> cat /proc/interrupts new:
>>CPU0   CPU1   CPU2   CPU3
>>   8:  75188  75268  75341  75246  MIPS GIC Local   1  timer
>>   9:  24413  0  0  0  MIPS GIC  63  IPI call
>>  10:  0   4442  0  0  MIPS GIC  64  IPI call
>>  11:  0  0  33324  0  MIPS GIC  65  IPI call
>>  12:  0  0  0   4574  MIPS GIC  66  IPI call
>>  13:   3424  0  0  0  MIPS GIC  67  IPI resched
>>  14:  0   4124  0  0  MIPS GIC  68  IPI resched
>>  15:  0  0   3974  0  MIPS GIC  69  IPI resched
>>  16:  0  0  0   4150  MIPS GIC  70  IPI resched
>>  17:  0  0  0  0  MIPS GIC  19  
>> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
>>  19:829  0  0  0  MIPS GIC  33  ttyS0
>>  20:  0  0  0  0  MIPS GIC  29  xhci-hcd:usb1
>>  21:817  0  0  0  MIPS GIC  10  
>> 1e10.ethernet
>>  23:  0  0  0  0  MIPS GIC  11  mt7615e
>> ERR:  1
>>
>>
>> cat /proc/interrupts old:
>>
>>CPU0   CPU1   CPU2   CPU3
>>   8:  25513  25556  25674  25681  MIPS GIC Local   1  timer
>>   9:  23603  0  0  0  MIPS GIC  63  IPI call
>>  10:  0   4383  0  0  MIPS GIC  64  IPI call
>>  11:  0  0  32117  0  MIPS GIC  65  IPI call
>>  12:  0  0  0   4189  MIPS GIC  66  IPI call
>>  13:   3428  0  0  0  MIPS GIC  67  IPI resched
>>  14:  0   4144  0  0  MIPS GIC  68  IPI resched
>>  15:  0  0   3812  0  MIPS GIC  69  IPI resched
>>  16:  0  0  0   3769  MIPS GIC  70  IPI resched
>>  17:  0  0  0  0  MIPS GIC  19  
>> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
>>  19:   1022  0  0  0  MIPS GIC  33  ttyS0
>>  20:  0  0  0  0  MIPS GIC  29  xhci-hcd:usb1
>>  21:269  0  0  0  MIPS GIC  10  
>> 1e10.ethernet
>>  24:   1131  0  0  0  MIPS GIC  31  mt7615e
>> ERR:  0
>> => Interesting, different interrupts.
> 
> That's weird. Should be the same, AFAICT.
> Needs some investigation but looks like you are not getting interrupts
> at all according to these traces...
> 
> Looking into my gnubee I got also 23, 24 and 25.
> 
> # cat /proc/interrupts
>CPU0   CPU1   CPU2   CPU3
>   7:  0  0  0  0  MIPS   7  timer
>   8:   3537   3346   3296   3351  MIPS GIC Local   1  timer
>   9:   3025  0  0  0  MIPS GIC  63  IPI call
>  10:  0   1209  0  0  MIPS GIC  64  IPI call
>  11:  0  0   2805  0  MIPS GIC  65  IPI call
>  12:  0  0  0   1200  MIPS GIC  66  IPI call
>  13:   1428  0  0  0  MIPS GIC  67  IPI resched
>  14:  0   4136  0  0  MIPS GIC  68  IPI resched
>  15:  0  0872  0  MIPS GIC  69  IPI resched
>  16:  0  0  0666  MIPS GIC  70  IPI resched
>  17:  0  0  0  0  MIPS GIC  19
> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
>  18:138  0  0  0  MIPS GIC  33  ttyS0
>  19:  0  0  0  0  MIPS GIC  27  1e13.sdhci
>  20: 26  0  0  0  MIPS GIC  29  xhci-hcd:usb1
>  21:  7  0  0  0  MIPS GIC  10
> 1e10.ethernet
>  23:  0  0  0  0  MIPS GIC  11
> ahci[:01:00.0]
>  24:  0  0  0  0  MIPS GIC  31
> ahci[:02:00.0]
>  25:279  0  0  0  MIPS GIC  32
> ahci[:03:00.0]
>  26:  0  0  0  0  1e000600.gpio  18  reset
> ERR:  0
> 
> 
>>
>> Diff DTS old to new driver:
>> diff --git b/target/linux/ramips/dts/mt7621.dtsi 
>> a/target/linux/ramips/dts/mt7621.dtsi
>> index 0bf1069b5c..63befa1fdc 100644
>> --- b/target/linux/ramips/dts/mt7621.dtsi
>> +++ a/target/linux/ramips/dts/mt7621.dtsi
>> @@ -557,9 +550,10 @@
>>
>> pcie: pcie@1e14 {
>> compatible = "mediatek,mt7621-pci";
>> -   reg = <0x1e14 0x100
>> -   0x1e142000 0x100>;
>> -
>> +   reg = <0x1e14 0x100 /* host-pci 

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Hi Sergio,

the device has an onboard LTE modem. Tonight I noticed that the originial pci 
driver
must have changed some additional GPIO pins.
After more testing, I found the GPIO and the LTE device now operates again.

But after more testing, I found out that the wifi chip does not fully 
initialize.
new PCI driver:
[0.641632] PCI: CLS 0 bytes, default 32
[1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie
[1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie
[1.242447] mt7621-pci 1e14.pcie: Parsing DT failed
[2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie
[2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie
[2.898180] rt2880-pinmux pinctrl: pcie is already enabled
[2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse things 
back
[2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port 
= 1)
[2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset
[2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup
[2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node 
'/pcie@1e14[0]' - status (0)
[2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset
[2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup
[2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of 
node '/pcie@1e14[1]'
[2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of 
node '/pcie@1e14[1]'
[2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup
[2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found
[2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port 
= 0)
[2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset
[2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup
[2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of 
node '/pcie@1e14[2]'
[2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of 
node '/pcie@1e14[2]'
[2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup
[2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found
[3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
[3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
[3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK)
[3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK)
[3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled
[3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: 0x6000, 
mask/settings: 0xf002
[3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00
[3.244820] pci_bus :00: root bus resource [io  0x1e16-0x1e16]
[3.258527] pci_bus :00: root bus resource [mem 0x6000-0x6fff]
[3.272233] pci_bus :00: root bus resource [bus 00-ff]
[3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400
[3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
[3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020]
[3.320294] pci :00:00.0: supports D1
[3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot
[3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280
[3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit]
[3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited 
by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 link)
[3.395633] pci :00:00.0: PCI bridge to [bus 01-ff]
[3.406073] pci :00:00.0:   bridge window [io  0x-0x0fff]
[3.418220] pci :00:00.0:   bridge window [mem 0x6000-0x600f]
[3.431784] pci :00:00.0:   bridge window [mem 0x6010-0x601f 
pref]
[3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000]
[3.472600] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000]
[3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f]
[3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f 
pref]
[3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020]
[3.527951] pci :00:00.0: BAR 7: assigned [io  0x1e16-0x1e160fff]
[3.541489] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f 
64bit]
[3.556077] pci :00:00.0: PCI bridge to [bus 01]
[3.565975] pci :00:00.0:   bridge window [io  0x1e16-0x1e160fff]
[3.579504] pci :00:00.0:   bridge window [mem 0x6000-0x600f]
[3.593037] pci :00:00.0:   bridge window [mem 0x6010-0x601f 
pref]
[   27.217458] pci :00:00.0: enabling device (0006 -> 0007)
[   27.217158] mt7615e :01:00.0: no of_node; not parsing 

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Hi!

Am 07.04.20 um 17:49 schrieb Bjørn Mork:
> Just remembered an issue on my todo list: There have been some MTU
> handling changes in the kernel networking API.  This affected the
> qmi_wwan QMAP handling.  I am not sure about the current status.  Will
> have to dig a bit more.  But this might be your problem.


That made me set MTU of wwan0 to 1600, and the qmimux* to 1500. No more 
problems anymore.
This should go into documentation, not that anybody makes the same errors. How 
much overhead
does qmux create (for correct calculated MTU offset)?

Thanks you!
Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Am 09.04.20 um 06:48 schrieb Sergio Paracuellos:
> On Thu, Apr 9, 2020 at 6:36 AM Sergio Paracuellos
>  wrote:
>>
>> Hi again,
>>
>> On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos
>>  wrote:
>>>
>>> Hi Andre,
>>>
>>> On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos
>>>  wrote:
>>>>
>>>> Hi André,
>>>>
>>>>
>>>> On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin  
>>>> wrote:
>>>>>
>>>>> Hi Sergio!
>>>>>
>>>>> Am 08.04.20 um 06:28 schrieb Sergio Paracuellos:
>>>>>> Hi Andre,
>>>>>>
>>>>>> On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin  
>>>>>> wrote:
>>>>>>>
>>>>>>> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo  
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> [CC Sergio who worked on upstream PCIE driver]
>>>>>>>>>
>>>>>>>>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin  
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> Currently I'm having some serious problems with the new 5.4 port.
>>>>>>>>>> 1) PCIe
>>>>>>>>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e 
>>>>>>>>>> connected to second bus on the first phy.
>>>>>>>>>> If booting the device, kernel hangs with a RST message, telling the 
>>>>>>>>>> device is not detected. It seems the PCIe bus 1
>>>>>>>>>> cannot be reseted because nothing is connected to bus 0.
>>>>>>>>>> An upport of the old PCI driver reenables the function. I can 
>>>>>>>>>> provide more logs on this if needed.
>>>>>>>>
>>>>>>>> Logs and dmesg traces are always welcome and would be helpful. Both
>>>>>>>> working and not working traces.
>>>>>>>
>>>>>>> Of course, here we go with the old PCIe driver taken from 4.14 openwrt 
>>>>>>> kernel:
>>>>>>> [0.485729] pinctrl core: add 0 pinctrl maps
>>>>>>> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400
>>>>>>> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700
>>>>>>> [0.806088] * Xtal 40MHz *
>>>>>>> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700
>>>>>>> [0.823025] Port 0 N_FTS = 1b102800
>>>>>>> [0.829933] Port 1 N_FTS = 1b105000
>>>>>>> [0.836849] Port 2 N_FTS = 1b102800
>>>>>>> [1.995991] PCIE0 no card, disable it(RST)
>>>>>>> [2.004682] PCIE2 no card, disable it(RST)
>>>>>>> [2.013495]  -> 20107f2
>>>>>>> [2.018328] PCIE1 enabled
>>>>>>> [2.023532] PCI host bridge /pcie@1e14 ranges:
>>>>>>> [2.033045]  MEM 0x6000..0x6fff
>>>>>>> [2.043401]   IO 0x1e16..0x1e16
>>>>>>> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: 
>>>>>>> 0x6000
>>>>>>> [2.091056] PCI host bridge to bus :00
>>>>>>> [2.099131] pci_bus :00: root bus resource [mem 
>>>>>>> 0x6000-0x6fff]
>>>>>>> [2.112734] pci_bus :00: root bus resource [io  0x]
>>>>>>> [2.124486] pci_bus :00: root bus resource [??? 0x flags 
>>>>>>> 0x0]
>>>>>>> [2.137962] pci_bus :00: No busn resource found for root bus, 
>>>>>>> will use [bus 00-ff]
>>>>>>> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400
>>>>>>> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
>>>>>>> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010]
>>>>>>> [2.190585] pci :00:00.0: supports D1
>>>>

Re: [OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?

[Andre Valentin]

Hi Bjoern,

I made a patch for include/image-commands.mk that allows to building squashfs 
initrd images.
The reason for me is that the imagebuilder is unable to generate initramfs 
images.
When building the final images with the imagebuilder you can define which 
packages to include.
Your platform has to use device-tree!

That's the function:
# This take the vanilla kernel, modifies the bootarg of dtb and appends
# the filesystem to the kernel at the given initrd offset
# address (respect kernelsize!).
# Argument 1 : initrd offset
define Build/prepend-initrd-kernel
let \
initrd_offset="$(subst k,* 1024,$(word 1, $(1)))" \
rootfs_size="$$(stat -c%s $@)/4096*4096+4096" \
kernel_size="$$(stat -c%s $(KDIR)/$(KERNEL_NAME))" \
dtb_size_in="$$(stat -c%s $(KDIR)/image-$(firstword 
$(DEVICE_DTS)).dtb )" \
kernel_dtb_size="kernel_size+dtb_size" \
initrd_virtual_addr="$(KERNEL_LOADADDR)+initrd_offset" ; \
if [ $$kernel_dtb_size -ge $$initrd_offset ] ; then \
echo initrd_offset is too small for kernel ; \
exit 1 ; \
fi ; \
bootargs=$$(printf "root=/dev/ram0 rd_start=0x%x rd_size=0x%x 
ramdisk_size=0x%x $(wordlist 2,$(words $(1)),$(1))" \
$$initrd_virtual_addr $$rootfs_size $$rootfs_size ) ; \
cp $(KDIR)/$(KERNEL_NAME) $@.tmp ; \
$(LINUX_DIR)/scripts/dtc/dtc -I dtb -O dts -o - 
$(KDIR)/image-$(firstword $(DEVICE_DTS)).dtb | \
$(TOPDIR)/scripts/patch-dtb-bootargs.pl "$$bootargs" | \
$(LINUX_DIR)/scripts/dtc/dtc -I dts -O dtb -o - - >> $@.tmp ; \
dd if=$@.tmp of=$@.tmp.padded conv=sync bs=$$initrd_offset count=1 ; \
mv $@.tmp.padded $@.tmp ; \
dd if=$@ bs=$$rootfs_size count=1 conv=sync >> $@.tmp ; \
mv $@.tmp $@
endef

Kernel needs following symbols:
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=0

This is the line for image/Makefile or ...
IMAGE/tftpboot-uImage-ramdisk.bin = append-rootfs | prepend-initrd-kernel 
16777216 | lzma | uImage lzma

16777216 is the offset for the initrd in memory (take kernel size into 
account), may be lowered for you.

Kind regards,

André

Am 08.04.20 um 09:26 schrieb Bjørn Mork:
> Tomasz Maciej Nowak  writes:
>
>> In include/kernel-defaults.mk there is
>> INITRAMFS_EXTRA_FILES ?= 
>> $(GENERIC_PLATFORM_DIR)/image/initramfs-base-files.txt.
>> Maybe You could add a logic for ignore files list if they exist. No other
>> solution comes to my mind.
>
> Thanks for the suggestion.  But I believe this file is used directly as
> config to the initramfs builder in the kernel.  Extending the format
> would mean modifying usr/gen_init_cpio.c in the kernel.  That's a bit
> overkill IMHO.
>
> I am probably ending up with the simplest solution: Dropping the large
> firmware package from DEVICE_PACKAGES. Making defconfig images usable
> for first-time installation is much more important than having every
> necessary package included in the defconfig sysupgrade images.
>
>
> Bjørn
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>

-- 
Mit freundlichen Grüßen
André Valentin

Systemadministration - Projektkoordination


--
MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net  | 
http://www.global-m2m.com 

Internet * Netzwerk * Mobile Daten

Vorstand:
Thorsten Hojas (Vorsitzender)
Marc-Henrik Delker
Dr. Anja-Christina Padberg
Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238



___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.





smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Hi Sergio!

Am 08.04.20 um 06:28 schrieb Sergio Paracuellos:
> Hi Andre,
> 
> On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin  wrote:
>>
>> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos:
>>> Hi,
>>>
>>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo  wrote:
>>>>
>>>> [CC Sergio who worked on upstream PCIE driver]
>>>>
>>>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin  
>>>> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> Currently I'm having some serious problems with the new 5.4 port.
>>>>> 1) PCIe
>>>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e 
>>>>> connected to second bus on the first phy.
>>>>> If booting the device, kernel hangs with a RST message, telling the 
>>>>> device is not detected. It seems the PCIe bus 1
>>>>> cannot be reseted because nothing is connected to bus 0.
>>>>> An upport of the old PCI driver reenables the function. I can provide 
>>>>> more logs on this if needed.
>>>
>>> Logs and dmesg traces are always welcome and would be helpful. Both
>>> working and not working traces.
>>
>> Of course, here we go with the old PCIe driver taken from 4.14 openwrt 
>> kernel:
>> [0.485729] pinctrl core: add 0 pinctrl maps
>> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400
>> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700
>> [0.806088] * Xtal 40MHz *
>> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700
>> [0.823025] Port 0 N_FTS = 1b102800
>> [0.829933] Port 1 N_FTS = 1b105000
>> [0.836849] Port 2 N_FTS = 1b102800
>> [1.995991] PCIE0 no card, disable it(RST)
>> [2.004682] PCIE2 no card, disable it(RST)
>> [2.013495]  -> 20107f2
>> [2.018328] PCIE1 enabled
>> [2.023532] PCI host bridge /pcie@1e14 ranges:
>> [2.033045]  MEM 0x6000..0x6fff
>> [2.043401]   IO 0x1e16..0x1e16
>> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: 
>> 0x6000
>> [2.091056] PCI host bridge to bus :00
>> [2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff]
>> [2.112734] pci_bus :00: root bus resource [io  0x]
>> [2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0]
>> [2.137962] pci_bus :00: No busn resource found for root bus, will 
>> use [bus 00-ff]
>> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400
>> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
>> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010]
>> [2.190585] pci :00:00.0: supports D1
>> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot
>> [2.211463] random: fast init done
>> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280
>> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit]
>> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, 
>> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 
>> GT/s x1 link)
>> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
>> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01
>> [2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000]
>> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size 
>> 0x8000]
>> [2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f]
>> [2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010]
>> [2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f 
>> 64bit]
>> [2.366887] pci :00:00.0: PCI bridge to [bus 01]
>> [2.376728] pci :00:00.0:   bridge window [mem 0x6000-0x600f]
>>
>>
>> And this is on 5.4 with the new driver with pcie0 status=disabled:
>> [   30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset
>> [   30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup
>> [   30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup
>> [   30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found
>> [   30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & 
>> CLK)
>> [   30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual 
>> bridges. Exiting...
>> booting goe

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Am 07.04.20 um 20:05 schrieb Sergio Paracuellos:
> Hi,
> 
> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo  wrote:
>>
>> [CC Sergio who worked on upstream PCIE driver]
>>
>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin  wrote:
>>>
>>> Hi!
>>>
>>> Currently I'm having some serious problems with the new 5.4 port.
>>> 1) PCIe
>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e 
>>> connected to second bus on the first phy.
>>> If booting the device, kernel hangs with a RST message, telling the device 
>>> is not detected. It seems the PCIe bus 1
>>> cannot be reseted because nothing is connected to bus 0.
>>> An upport of the old PCI driver reenables the function. I can provide more 
>>> logs on this if needed.
> 
> Logs and dmesg traces are always welcome and would be helpful. Both
> working and not working traces.

Of course, here we go with the old PCIe driver taken from 4.14 openwrt kernel:
[0.485729] pinctrl core: add 0 pinctrl maps
[0.485865] pull PCIe RST: RALINK_RSTCTRL = 400
[0.796015] release PCIe RST: RALINK_RSTCTRL = 700
[0.806088] * Xtal 40MHz *
[0.812829] release PCIe RST: RALINK_RSTCTRL = 700
[0.823025] Port 0 N_FTS = 1b102800
[0.829933] Port 1 N_FTS = 1b105000
[0.836849] Port 2 N_FTS = 1b102800
[1.995991] PCIE0 no card, disable it(RST)
[2.004682] PCIE2 no card, disable it(RST)
[2.013495]  -> 20107f2
[2.018328] PCIE1 enabled
[2.023532] PCI host bridge /pcie@1e14 ranges:
[2.033045]  MEM 0x6000..0x6fff
[2.043401]   IO 0x1e16..0x1e16
[2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: 0x6000
[2.091056] PCI host bridge to bus :00
[2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff]
[2.112734] pci_bus :00: root bus resource [io  0x]
[2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0]
[2.137962] pci_bus :00: No busn resource found for root bus, will use 
[bus 00-ff]
[2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400
[2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
[2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010]
[2.190585] pci :00:00.0: supports D1
[2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot
[2.211463] random: fast init done
[2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280
[2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit]
[2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited 
by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 link)
[2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01
[2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000]
[2.311581] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000]
[2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f]
[2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010]
[2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f 
64bit]
[2.366887] pci :00:00.0: PCI bridge to [bus 01]
[2.376728] pci :00:00.0:   bridge window [mem 0x6000-0x600f]


And this is on 5.4 with the new driver with pcie0 status=disabled:
[   30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset
[   30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup
[   30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup
[   30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found
[   30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK)
[   30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual 
bridges. Exiting...
booting goes on.

And with pcie status=enabled:
[   32.415863] rt2880-pinmux pinctrl: pcie is already enabled
[   32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse things 
back
[   32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port 
= 1)
[   32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port 
= 0)
[   32.571556] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
[   32.582680] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
[   32.693592] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK)
hangs.


DTS Config:
mt7621.dtsi
pcie: pcie@1e14 {
compatible = "mediatek,mt7621-pci";
reg = <0x1e14 0x100 /* host-pci bridge registers */
0x1e142000 0x100/* pcie port 0 RC control registers 
*/
0x1e1

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Am 07.04.20 um 12:16 schrieb Chuanhong Guo:
> [CC Sergio who worked on upstream PCIE driver]
> 
> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin  wrote:
>>
>> Hi!
>>
>> Currently I'm having some serious problems with the new 5.4 port.
>> 1) PCIe
>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e 
>> connected to second bus on the first phy.
>> If booting the device, kernel hangs with a RST message, telling the device 
>> is not detected. It seems the PCIe bus 1
>> cannot be reseted because nothing is connected to bus 0.
>> An upport of the old PCI driver reenables the function. I can provide more 
>> logs on this if needed.
> 
> Hi Sergio:
> You may want to look into this.
> 
>> 2) DSA
>> These are my first experiments with DSA. I've configured 2 bridges:
>> lan: lan1 lan2 lan3 lan4
>> dmz: lan1.20 lan2.20 lan3.20 lan4.20
>>
>> Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 
>> port but does note arrive at the other end.
>>
>> Should this work with DSA on mediathek?
> 
> It's supposed to work so this may be yet another bug upstream.
> 
>> If not, I can offer that I write a patch for traditional swconfig.
> 
> swconfig is considered deprecated so there's no need to do so.
> In fact, this driver under mediatek target also works for mt7621:
> target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x
> 

I already took some patches from there. I'll gonna check if a replacement makes 
a difference.

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Hi!

Am 07.04.20 um 17:49 schrieb Bjørn Mork:
> Just remembered an issue on my todo list: There have been some MTU
> handling changes in the kernel networking API.  This affected the
> qmi_wwan QMAP handling.  I am not sure about the current status.  Will
> have to dig a bit more.  But this might be your problem.

Thank you very much for taking a look!

André


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

Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Hi!

Am 07.04.20 um 16:33 schrieb Bjørn Mork:
> Andre Valentin  writes:
> 
>> 3) Problems with QMI Interfaces
>> QMI is used for mobile phones and interact with the qmi_wwan driver in the 
>> kernel. I had transmit issues,
>> switched the driver back to the 4.14 while still on 5.4. But the same 
>> problem happens again.
>> Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches 
>> somehow are the root cause.
>> Here's the kernel message:
>>
>>
>> [ 4199.444191] [ cut here ]
>> [ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 
>> dev_watchdog+0x2f8/0x300
>> [ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out
> 
> And this is not just an occasional timeout?  The driver hangs completely
> there?

It hangs, no more packets are transmitted over network,
> 
> I don't think there were many qmi_wwan changes between v4.14 and v5.4,
> except for device additions and some fixes which mostly have been
> backported to v4.14-stable. But maybe this is related to your specific
> modem?  Do you have a device ID for that?

The funny thing is, that if I remove all changes from 5.4 qmi_wwan.c and set it 
back to the
4.14 driver, the same happens again. Perhaps the problem is in the muxing code? 
Is that outside
of qmi_wwan.c ?

Only if I disable qmap and use the wwan0 device with only one PDF, it seems to 
be stable over days.
The device is a:
Bus 002 Device 002: ID 2c7c:0306 Quectel Wireless Solutions Co., Ltd. 
EG06/EP06/EM06 LTE-A modem

> Do we know that USB is working on v5.4 BTW?  The MT7621 device I am
> using doesn't have any USB ports, so I can't check that myself.
> 
> Is your modem connected by USB3 or USB2?  Any of
The modem is an integrated USB3 LTE modem. As said, without qmap it works 
stable.
> 
>  lsusb -v
--

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 3
  bMaxPacketSize0 9
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0003 3.0 root hub
  bcdDevice5.04
  iManufacturer   3 Linux 5.4.28 vhci_hcd
  iProduct2 USB/IP Virtual Host Controller
  iSerial 1 vhci_hcd.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   31
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  1x 4 bytes
bInterval  12
bMaxBurst   0
Hub Descriptor:
  bLength  12
  bDescriptorType  42
  nNbrPorts 8
  wHubCharacteristic 0x0001
Per-port power switching
Ganged overcurrent protection
  bPwrOn2PwrGood0 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  bHubDecLat  0.4 micro seconds
  wHubDelay 4 nano seconds
  DeviceRemovable0xff 0xff
 Hub Port Status:
   Port 1: .0200 5Gbps power U0
   Port 2: .0200 5Gbps power U0
   Port 3: .0200 5Gbps power U0
   Port 4: .0200 5Gbps power U0
   Port 5: .0200 5Gbps power U0
   Port 6: .0200 5Gbps power U0
   Port 7: .0200 5Gbps power U0
   Port 8: .0200 5Gbps power U0
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   15
  bNumDeviceCaps  1
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
bDevCapabilityType  3
bmAttributes 0x00
wSpeedsSupported   0x0008
  Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport   3
  Lowest fully-functional device speed is SuperSpeed (5Gbps)
bU1DevExitLat   0 micro seconds
bU2DevExitLat   0 micro seconds
Device Status: 0x0001
  Self Powered

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
 

[OpenWrt-Devel] ramips/mt7621 after 5.4 switch

[Andre Valentin]

Hi!

Currently I'm having some serious problems with the new 5.4 port.
1) PCIe
I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e connected 
to second bus on the first phy.
If booting the device, kernel hangs with a RST message, telling the device is 
not detected. It seems the PCIe bus 1
cannot be reseted because nothing is connected to bus 0.
An upport of the old PCI driver reenables the function. I can provide more logs 
on this if needed.

2) DSA
These are my first experiments with DSA. I've configured 2 bridges:
lan: lan1 lan2 lan3 lan4
dmz: lan1.20 lan2.20 lan3.20 lan4.20

Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 port 
but does note arrive at the other end.

Should this work with DSA on mediathek? If not, I can offer that I write a 
patch for traditional swconfig.

3) Problems with QMI Interfaces
QMI is used for mobile phones and interact with the qmi_wwan driver in the 
kernel. I had transmit issues,
switched the driver back to the 4.14 while still on 5.4. But the same problem 
happens again.
Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches somehow 
are the root cause.
Here's the kernel message:


[ 4199.444191] [ cut here ]
[ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 
dev_watchdog+0x2f8/0x300
[ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out
Mon Apr  6 16:27[ 4199.483839] Modules linked in: qcserial option cdc_mbim 
usb_wwan sierra_net sierra rndis_host qmi_wwan pppoe pl2303 l2tp_ppp 
iptable_nat ipt_REJECT huawei_cdc_ncm ftdi_sio
cdc_subset cdc_ncm cdc_ether cdc_eem xt_u32 xt_time xt_tcpudp xt_tcpmss 
xt_string xt_statistic xt_state xt_socket xt_recent xt_quota xt_policy 
xt_pkttype xt_owner xt_nat xt_multiport xt_mark xt_mac
xt_limit xt_length xt_iprange xt_hl xt_helper xt_hashlimit xt_esp xt_ecn 
xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment 
xt_cluster xt_bpf xt_addrtype xt_TRACE xt_TPROXY
xt_TCPMSS xt_REDIRECT xt_NETMAP xt_MASQUERADE xt_LOG xt_LED xt_HL xt_DSCP xt_CT 
xt_CLASSIFY xor wireguard vhci_hcd usbserial usbnet usblp usbip_host usbip_core 
ts_fsm ts_bm pptp pppox ppp_synctty
ppp_mppe ppp_async nfnetlink_queue nfnetlink_log nf_tproxy_ipv6 nf_tproxy_ipv4 
nf_socket_ipv6 nf_socket_ipv4 nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic 
nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323
nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
:24 2020 kern.wa[ 4199.484081]  nf_conntrack_tftp nf_conntrack_snmp 
nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_irc 
nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast
ts_kmp nf_conntrack_amanda nf_conncount macvlan iptable_raw iptable_mangle 
iptable_filter ipt_ah ipt_ECN ipt_CLUSTERIP ipheth ip6table_raw ip_tables hso 
crc_ccitt cdc_wdm cdc_acm asn1_decoder
arptable_filter arpt_mangle arp_tables fuse sch_teql sch_sfq sch_red sch_prio 
sch_pie sch_multiq sch_gred sch_fq sch_dsmark sch_codel em_text em_nbyte 
em_meta em_cmp act_simple act_police act_pedit
act_ipt act_gact act_csum libcrc32c act_connmark nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex 
cls_route cls_matchall cls_fw cls_flow
cls_basic act_skbedit act_mirred evdev lp i2c_dev ledtrig_usbport ppdev parport 
ledtrig_heartbeat ledtrig_gpio cryptodev xt_set ip_set_list_set 
ip_set_hash_netportnet ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_netiface
rn kernel: [ 419[ 4199.660920]  ip_set_hash_net ip_set_hash_mac 
ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport 
ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac
ip_set_bitmap_ip ip_set nfnetlink ip6t_rt ip6t_mh ip6t_ipv6header ip6t_hbh 
ip6t_frag ip6t_eui64 ip6t_ah nf_log_ipv6 nf_log_common ip6table_mangle 
ip6table_filter ip6_tables ip6t_REJECT x_tables
nf_reject_ipv6 pppoatm ppp_generic slhc msdos bonding ip6_gre ip_gre gre ifb 
dummy nat46 l2tp_ip6 l2tp_ip l2tp_eth ip6_vti ip_vti sit l2tp_netlink l2tp_core 
ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel
ipcomp esp4 ah4 ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel veth tun xfrm_user 
xfrm_ipcomp af_key xfrm_algo vfat fat udf crc_itu_t ntfs isofs dns_resolver 
br2684 atm fscache nls_utf8 nls_iso8859_1
nls_cp850 nls_cp437 nls_cp1250 vxlan udp_tunnel ip6_udp_tunnel wp512 
twofish_generic twofish_common tgr192 tea serpent_generic khazad cast6_generic 
cast5_generic cast_common camellia_generic
blowfish_generic blowfish_common anubis xts
9.444191] --[ 4199.836284]  crypto_user algif_skcipher algif_rng algif_hash 
algif_aead af_alg sha512_generic sha256_generic libsha256 sha1_generic seqiv 
jitterentropy_rng drbg pcbc michael_mic md5
md4 hmac ghash_generic gf128mul gcm echainiv ecb des_generic libdes ctr cmac 
ccm cbc authenc arc4 usb_storage input_polldev leds_gpio xhci_plat_hcd xhci_pci 
xhci_mtk xhci_hcd ledtrig_transient
fsl_mph_dr_of ehci_platform ehci_fsl sd_mod scsi_mod ehci_hcd 
gpio_button_hotplug ext4 mbcache 

[OpenWrt-Devel] [RFC] Support for ZyXEL LTE3301-Plus / Image format known?

[Andre Valentin]

Hi!

I have written support for the LTE3301-Plus device for OpenWRT. But my main 
problem is that
Zyxel only gave me an binary imagebuilder. If anybody is interested I can 
provide the needed
OpenWRT patch and the binary. Perhaps someone is able to decompile it and back 
or even
better, the format is known :-)

_SPECS:_
4 Cores (HT)
MT7621
128MB Flash, ~60MB usable
256MB RAM
4x switched ethernet ports
1x MT7615E Wifi
1x USB3
1x Quectel LTE modem

_Dump of image head_
  30 52 44 48 00 00 01 7c  00 40 00 00 ab 7d 80 2e  |0RDH...|.@...}..|
0010  35 2e 30 2e 30 2e 30 0a  00 00 00 00 00 00 00 00  |5.0.0.0.|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0030  0a 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0050  00 3f fe 84 00 00 00 00  00 00 00 00 00 00 00 00  |.?..|
0060  33 20 36 30 33 35 20 31  32 32 20 30 0a 00 00 00  |3 6035 122 0|
0070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0100  00 00 00 00 4d 54 37 36  32 31 41 00 4c 54 45 33  |MT7621A.LTE3|
0110  33 30 31 2d 50 4c 55 53  00 00 00 00 03 03 00 01  |301-PLUS|
0120  00 00 00 00 00 00 00 00  31 2e 30 30 28 41 42 51  |1.00(ABQ|
0130  55 2e 31 29 43 30 00 00  00 00 00 00 00 00 00 00  |U.1)C0..|
0140  00 00 00 00 00 00 00 00  31 2e 30 30 28 41 42 51  |1.00(ABQ|
0150  55 2e 31 29 43 30 00 00  00 00 00 00 00 00 00 00  |U.1)C0..|
0160  00 00 00 00 00 00 00 00  00 00 00 00 72 11 ad 2f  |r../|
0170  00 00 00 00 9d 11 5b c6  00 00 00 00 27 05 19 56  |..[.'..V|



Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] v5.4 as next kernel / ipq806x

[Andre Valentin]

Hello,

I also did several tests on the 4.19 ipq806x (NBG6817). I noticed that VPN 
throuput (IPsec Performance) dropped to 30% with exactly the same config 
(kernel and openwrt), kernel crypto and arm crypto
stuff tested.
Also the whole system feels a bit slowier. Timers (clock, ddr) in dts have been 
compared, also checked in the running system. I'm a fan of 419, but this needs 
be solved before and I have no clue where
to look. Any ideas?

Kind regards,

André

Am 30.10.19 um 22:16 schrieb Stefan Lippers-Hollmann:
> Hi
> 
> On 2019-10-30, Adrian Schmutzler wrote:
>> 1. We currently have work-in-progress 4.19 support PRs for ramips,
>> ipq806x and bcm63xx, still with considerable work to do at least for
>> the first two (IIRC).
> 
> Kernel 4.19 has been working fine on ipq806x (nbg6817) for me so far,
> I've been using it a for couple of months now and the pending pull
> request[0] is functional. Yes, there might be further optimization steps
> possible, but none of that is necessary to switch ipq806x from v4.14 to
> v4.19 now'ish (routing throughput is already significantly better in
> v4.19, jumbo frames no longer crash stmmac, so I do consider the current
> state of the v4.19 patches for ipq806x to be an improvement over v4.14).
> 
> Regards
>   Stefan Lippers-Hollmann
> 
> [0]   https://github.com/openwrt/openwrt/pull/2472
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 





smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QMI data mode cannot set raw-ip due to active device

[Andre Valentin]

Hi Shannon,

I use a hotplug script to change the driver to raw-ip. This works fine for me.

Kind regars,

André

On 23.09.19 19:16, Shannon Barber wrote:
> I'm doing several builds and testing different devices and this issue is 
> persistent on the x86_64 build for the PC Engine APU hardware.
> (I did not encounter it on the Espressobin v7 hardware.)
> 
> I have several modems but I am testing with a Sierra Wireless MC7455 which 
> seems to be a popular one that is also raw-ip only.
> As a quick-fix bringing the interface down and back up where the 
> /lib/netifd/proto/qmi.sh script attempts to change-over to raw-ip seems to 
> work but I'm not certain if its "the right way" to fix this
> issue. It seems to take a while so I think it's retrying later and working 
> the second time.
> 
> 
>                 echo "Device does not support 802.3 mode. Informing driver of 
> raw-ip only for $ifname .."
>                 ifconfig $ifname down
>                 echo "Y" > /sys/class/net/$ifname/qmi/raw_ip
>                 ifconfig $ifname up
> 
> 
> Some snippets from the kernel log:
> 
> [    8.744638] qmi_wwan 1-1.3:1.8: cdc-wdm0: USB WDM device
> [    8.751778] qmi_wwan 1-1.3:1.8 wwan0: register 'qmi_wwan' at 
> usb-:00:13.0-1.3, WWAN/QMI device, fa:8c:eb:d2:d5:df
> [    8.765196] qmi_wwan 1-1.3:1.10: cdc-wdm1: USB WDM device
> [    8.772501] qmi_wwan 1-1.3:1.10 wwan1: register 'qmi_wwan' at 
> usb-:00:13.0-1.3, WWAN/QMI device, fa:8c:eb:d2:d5:df
> [    8.784460] usbcore: registered new interface driver qmi_wwan
> [    8.793076] usbcore: registered new interface driver rndis_host
> [    8.800987] usbcore: registered new interface driver sierra
> [    8.806989] usbserial: USB Serial support registered for Sierra USB modem
> ...
> [   13.569617] qmi_wwan 1-1.3:1.8 wwan0: Cannot change a running device
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] rpcd: file: add path based read/write/exec ACL checks

[Andre Valentin]

On 21.09.19 20:16, Andre Valentin wrote:
> Hi!
> 
> Im using file extension to get extra status from my device. But after the 
> change above, the calls over uhttpd are rejected with permission denied.

I've added a grant session call over http, it works now again.

Kind regards,

André




smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] rpcd: file: add path based read/write/exec ACL checks

[Andre Valentin]

Hi!

Im using file extension to get extra status from my device. But after the 
change above, the calls over uhttpd are rejected with permission denied.

Currently I have this ACL:
# cat /usr/share/rpcd/acl.d/superuser.json
{
"superuser": {
"description": "Super user access role",
"read": {
"ubus": {
"*": [ "*" ]
},
"uci": [ "*" ],
"file": [ "*" ]
},
"write": {
"ubus": {
"*": [ "*" ]
},
"uci": [ "*" ],
"file": [ "*" ]
},
"exec": {
"file": [ "*" ]
}
}
}

What do I have to do to enable access again, without calling ubus session grant 
like in the commit?
Thank you!

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] kernel: bump 4.19 to 4.19.72 broke ath79

[Andre Valentin]

Hi!

It seems the kernel bump broke ath79 compilation. The problem lies in
target/linux/ath79/patches-4.19/0028-MIPS-ath79-drop-machfiles.patch

It cannot be applied anymore. I tried a quick fix, but there seems to be a 
bigger change.

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding UCI for multi-point GRE on OpenWRT

[Andre Valentin]

Hi!

What about setting peeraddr to 0.0.0.0 ?

Kind regards,

André

Am 22.08.19 um 09:21 schrieb pothuganti sridhar:
> Hello All,
> 
> I am trying to implement DMVPN with OpenWRT. That requires multipoint GRE 
> tunnels. In case of the multipoint GRE tunnel, the remote endpoint/peer 
> address will be resolved dynamically using NHRPD
> protocol/daemon.
> 
> I have gone through the GRE documentation at the following link.
> 
> https://openwrt.org/docs/guide-user/network/tunneling_interface_protocols 
>  
> In the above documentation, it is mentioned that "peeraddr" is the must 
> require field. 
> 
> Is anyone tried to create multipoint GRE using UCI? 
> 
> To make it(peeraddr) optional field, what are the changes required?
> 
> Any points will be helpful.
> 
> Thanks in advance.
> 
> Regards,
> Sridhar
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


-- 
Mit freundlichen Grüßen
André Valentin

Systemadministration - Projektkoordination


--
MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net  | 
http://www.global-m2m.com 

Internet * Netzwerk * Mobile Daten

Vorstand:
Thorsten Hojas (Vorsitzender)
Marc-Henrik Delker
Dr. Anja-Christina Padberg
Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238



___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

 




smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/3] netsupport: improve xfrm module support

[Andre Valentin]

Hi!
Am 15.06.19 um 21:35 schrieb Hans Dedecker:
> Hi,
> 
> On Fri, Jun 14, 2019 at 1:10 PM André Valentin  wrote:
>>
>> -switch to module autoprobe
>> -exclude 4.9 kernel
>>
>> Signed-off-by: André Valentin 
>> ---
>>  package/kernel/linux/modules/netsupport.mk | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/kernel/linux/modules/netsupport.mk 
>> b/package/kernel/linux/modules/netsupport.mk
>> index 20616d9af6..9732ee0d73 100644
>> --- a/package/kernel/linux/modules/netsupport.mk
>> +++ b/package/kernel/linux/modules/netsupport.mk
>> @@ -386,10 +386,10 @@ $(eval $(call KernelPackage,ip6-vti))
>>  define KernelPackage/xfrm-interface
>>SUBMENU:=$(NETWORK_SUPPORT_MENU)
>>TITLE:=IPsec XFRM Interface
>> -  DEPENDS:=+kmod-ipsec4 +kmod-ipsec6 @!LINUX_4_14
>> +  DEPENDS:=+kmod-ipsec4 +kmod-ipsec6 @!LINUX_4_14 @!LINUX_4_9
> Is there a reason why you want to exclude kernel version 4.9 as in
> master all targets will be switched to 4.19 and afaik no targets will
> use 4.9


It was Hauke Mehrtens wish, so I'm a bit in between.

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts

[Andre Valentin]

Hi Hans!!
Am 11.06.19 um 22:16 schrieb Hans Dedecker:
> Hi,
> 
> On Mon, Jun 10, 2019 at 8:10 PM Andre Valentin  wrote:
>>
>> Hi Hans,
>>
>> after testing xfrm tunnels a bit I found to big differences compared to 
>> other convential tunnels.
>> 1) xfrm tunnel interfaces cannot be replaced with netlink
>> 2) xfrm tunnel interfaces DO NOT vanish if parent is deleted
>>
>> This leads to some errors and a loop in interface creation. With the changes 
>> below,
>> it works smoothly when not bound to ppp interfaces (using lan instead), see:
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14255): Command 
>> failed: Unknown error
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is now down
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is setting 
>> up now
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14281): Command 
>> failed: Unknown error
>> and so on
>>>> What do you think?
> The description is a bit cryptic to me; could you explain what works
> and what does not work and why ?
Sorry for being cryptic, I tend to that;-) Okay, I do the following:
# ifup xfrm0
... use it
# ifdown xfrm0
The interface still exists (checked with ip link)

Now I'll do ifup again and this happens endlessly:
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14255): Command 
>> failed: Unknown error
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is now down
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is setting 
>> up now
>> Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14281): Command 
>> failed: Unknown error

In netifd the xfrm0 interface is created with the REPLACE flag, but that does 
not seem to work, it cannot be recreated and fails.
The result is the upper error repeating.
That's why I think about the call to "ip link delete xfrm0" before 
proto_init_update call and in the teardown call.

André


> 
> Hans
>>
>> Kind regards,
>>
>> André
>>
>>
>> Am 09.06.19 um 21:27 schrieb Hans Dedecker:
>>> On Sat, Jun 8, 2019 at 1:48 PM André Valentin  wrote:
>>>>
>>>> This package adds scripts for xfrm interfaces support.
>>>> Example configuration via /etc/config/network:
>>>>
>>>> config interface 'xfrm0'
>>>> option proto 'xfrm'
>>>> option mtu '1300'
>>>> option zone 'VPN'
>>>> option tunlink 'wan'
>>>> option ifid 30
>>>>
>>>> config interface 'xfrm0_static'
>>>> option proto 'static'
>>>> option ifname '@xfrm0'
>>>> option ip6addr 'fe80::1/64'
>>>> option ipaddr '10.0.0.1/30'
>>>>
>>>> Now set in strongswan IPsec policy:
>>>> if_id_in = 30
>>>> if_id_out = 30
>>>> ---
>>>>  package/network/config/xfrm/Makefile  | 38 ++
>>>>  package/network/config/xfrm/files/xfrm.sh | 65 
>>>> +++
>>>>  2 files changed, 103 insertions(+)
>>>>  create mode 100644 package/network/config/xfrm/Makefile
>>>>  create mode 100755 package/network/config/xfrm/files/xfrm.sh
>>>>
>>>> diff --git a/package/network/config/xfrm/Makefile 
>>>> b/package/network/config/xfrm/Makefile
>>>> new file mode 100644
>>>> index 00..efc90cf318
>>>> --- /dev/null
>>>> +++ b/package/network/config/xfrm/Makefile
>>>> @@ -0,0 +1,38 @@
>>>> +
>>>> +include $(TOPDIR)/rules.mk
>>>> +
>>>> +PKG_NAME:=xfrm
>>>> +PKG_VERSION:=1
>>>> +PKG_RELEASE:=1
>>>> +PKG_LICENSE:=GPL-2.0
>>>> +
>>>> +include $(INCLUDE_DIR)/package.mk
>>>> +
>>>> +define Package/xfrm/Default
>>>> +  SECTION:=net
>>>> +  CATEGORY:=Network
>>>> +  MAINTAINER:=Andre Valentin 
>>>> +endef
>>>> +
>>>> +define Package/xfrm
>>>> +$(call Package/xfrm/Default)
>>>> +  TITLE:=XFRM IPsec Tunnel Interface config support
>>>> +  DEPENDS:=+kmod-xfrm-interface
>>>> +endef
>>>> +
>>>> +define Package/xfrm/description
>>>> + XFRM IPsec Tunnel Interface config support (IPv4 and IPv6) in 
>>>> /etc/config/network.
>>>> +endef
>>>> +
>>>> +define Build/Compile
>>>> +

Re: [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts

[Andre Valentin]

Hi Hans,

after testing xfrm tunnels a bit I found to big differences compared to other 
convential tunnels.
1) xfrm tunnel interfaces cannot be replaced with netlink
2) xfrm tunnel interfaces DO NOT vanish if parent is deleted

This leads to some errors and a loop in interface creation. With the changes 
below,
it works smoothly when not bound to ppp interfaces (using lan instead), see:
Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14255): Command failed: 
Unknown error
Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is now down
Mon Jun 10 11:42:06 2019 daemon.notice netifd: Interface 'xfrm0' is setting up 
now
Mon Jun 10 11:42:06 2019 daemon.notice netifd: xfrm0 (14281): Command failed: 
Unknown error
and so on

What do you think?

Kind regards,

André


Am 09.06.19 um 21:27 schrieb Hans Dedecker:
> On Sat, Jun 8, 2019 at 1:48 PM André Valentin  wrote:
>>
>> This package adds scripts for xfrm interfaces support.
>> Example configuration via /etc/config/network:
>>
>> config interface 'xfrm0'
>> option proto 'xfrm'
>> option mtu '1300'
>> option zone 'VPN'
>> option tunlink 'wan'
>> option ifid 30
>>
>> config interface 'xfrm0_static'
>> option proto 'static'
>> option ifname '@xfrm0'
>> option ip6addr 'fe80::1/64'
>> option ipaddr '10.0.0.1/30'
>>
>> Now set in strongswan IPsec policy:
>> if_id_in = 30
>> if_id_out = 30
>> ---
>>  package/network/config/xfrm/Makefile  | 38 ++
>>  package/network/config/xfrm/files/xfrm.sh | 65 
>> +++
>>  2 files changed, 103 insertions(+)
>>  create mode 100644 package/network/config/xfrm/Makefile
>>  create mode 100755 package/network/config/xfrm/files/xfrm.sh
>>
>> diff --git a/package/network/config/xfrm/Makefile 
>> b/package/network/config/xfrm/Makefile
>> new file mode 100644
>> index 00..efc90cf318
>> --- /dev/null
>> +++ b/package/network/config/xfrm/Makefile
>> @@ -0,0 +1,38 @@
>> +
>> +include $(TOPDIR)/rules.mk
>> +
>> +PKG_NAME:=xfrm
>> +PKG_VERSION:=1
>> +PKG_RELEASE:=1
>> +PKG_LICENSE:=GPL-2.0
>> +
>> +include $(INCLUDE_DIR)/package.mk
>> +
>> +define Package/xfrm/Default
>> +  SECTION:=net
>> +  CATEGORY:=Network
>> +  MAINTAINER:=Andre Valentin 
>> +endef
>> +
>> +define Package/xfrm
>> +$(call Package/xfrm/Default)
>> +  TITLE:=XFRM IPsec Tunnel Interface config support
>> +  DEPENDS:=+kmod-xfrm-interface
>> +endef
>> +
>> +define Package/xfrm/description
>> + XFRM IPsec Tunnel Interface config support (IPv4 and IPv6) in 
>> /etc/config/network.
>> +endef
>> +
>> +define Build/Compile
>> +endef
>> +
>> +define Build/Configure
>> +endef
>> +
>> +define Package/xfrm/install
>> +   $(INSTALL_DIR) $(1)/lib/netifd/proto
>> +   $(INSTALL_BIN) ./files/xfrm.sh $(1)/lib/netifd/proto/xfrm.sh
>> +endef
>> +
>> +$(eval $(call BuildPackage,xfrm))
>> diff --git a/package/network/config/xfrm/files/xfrm.sh 
>> b/package/network/config/xfrm/files/xfrm.sh
>> new file mode 100755
>> index 00..df28d38613
>> --- /dev/null
>> +++ b/package/network/config/xfrm/files/xfrm.sh
>> @@ -0,0 +1,65 @@
>> +#!/bin/sh
>> +
>> +[ -n "$INCLUDE_ONLY" ] || {
>> +   . /lib/functions.sh
>> +   . /lib/functions/network.sh
>> +   . ../netifd-proto.sh
>> +   init_proto "$@"
>> +}
>> +
>> +proto_xfrm_setup() {
>> +   local cfg="$1"
>> +   local mode="xfrm"
>> +
>> +   local tunlink ifid mtu zone
>> +   json_get_vars tunlink ifid mtu zone
>> +
if exists .. ip link del "$cfg"

>> +   proto_init_update "$cfg" 1
>> +
>> +   proto_add_tunnel
>> +   json_add_string mode "$mode"
>> +   json_add_int mtu "${mtu:-1280}"
>> +
>> +   [ -z "$tunlink" ] && {
>> +   proto_notify_error "$cfg" NO_TUNLINK
>> +   proto_block_restart "$cfg"
>> +   exit
>> +   }
>> +   json_add_string link "$tunlink"
>> +
>> +   [ -z "$ifid" ] && {
>> +   proto_notify_error "$cfg" NO_IFID
>> +   proto_block_restart "$cfg"
>> +   exit
>> +   }
>> +   json_add

Re: [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts

[Andre Valentin]

Hi Hans!

Am 09.06.19 um 21:27 schrieb Hans Dedecker:
> On Sat, Jun 8, 2019 at 1:48 PM André Valentin  wrote:
>>
>> This package adds scripts for xfrm interfaces support.
>> Example configuration via /etc/config/network:
>>
>> config interface 'xfrm0'
>> option proto 'xfrm'
>> option mtu '1300'
>> option zone 'VPN'
>> option tunlink 'wan'
>> option ifid 30
>>
>> config interface 'xfrm0_static'
>> option proto 'static'
>> option ifname '@xfrm0'
>> option ip6addr 'fe80::1/64'
>> option ipaddr '10.0.0.1/30'
>>
>> Now set in strongswan IPsec policy:
>> if_id_in = 30
>> if_id_out = 30
>> ---
>>  package/network/config/xfrm/Makefile  | 38 ++
>>  package/network/config/xfrm/files/xfrm.sh | 65 
>> +++
>>  2 files changed, 103 insertions(+)
>>  create mode 100644 package/network/config/xfrm/Makefile
>>  create mode 100755 package/network/config/xfrm/files/xfrm.sh
>>
>> diff --git a/package/network/config/xfrm/Makefile 
>> b/package/network/config/xfrm/Makefile
>> new file mode 100644
>> index 00..efc90cf318
>> --- /dev/null
>> +++ b/package/network/config/xfrm/Makefile
>> @@ -0,0 +1,38 @@
>> +
>> +include $(TOPDIR)/rules.mk
>> +
>> +PKG_NAME:=xfrm
>> +PKG_VERSION:=1
>> +PKG_RELEASE:=1
>> +PKG_LICENSE:=GPL-2.0
>> +
>> +include $(INCLUDE_DIR)/package.mk
>> +
>> +define Package/xfrm/Default
>> +  SECTION:=net
>> +  CATEGORY:=Network
>> +  MAINTAINER:=Andre Valentin 
>> +endef
>> +
>> +define Package/xfrm
>> +$(call Package/xfrm/Default)
>> +  TITLE:=XFRM IPsec Tunnel Interface config support
>> +  DEPENDS:=+kmod-xfrm-interface
>> +endef
>> +
>> +define Package/xfrm/description
>> + XFRM IPsec Tunnel Interface config support (IPv4 and IPv6) in 
>> /etc/config/network.
>> +endef
>> +
>> +define Build/Compile
>> +endef
>> +
>> +define Build/Configure
>> +endef
>> +
>> +define Package/xfrm/install
>> +   $(INSTALL_DIR) $(1)/lib/netifd/proto
>> +   $(INSTALL_BIN) ./files/xfrm.sh $(1)/lib/netifd/proto/xfrm.sh
>> +endef
>> +
>> +$(eval $(call BuildPackage,xfrm))
>> diff --git a/package/network/config/xfrm/files/xfrm.sh 
>> b/package/network/config/xfrm/files/xfrm.sh
>> new file mode 100755
>> index 00..df28d38613
>> --- /dev/null
>> +++ b/package/network/config/xfrm/files/xfrm.sh
>> @@ -0,0 +1,65 @@
>> +#!/bin/sh
>> +
>> +[ -n "$INCLUDE_ONLY" ] || {
>> +   . /lib/functions.sh
>> +   . /lib/functions/network.sh
>> +   . ../netifd-proto.sh
>> +   init_proto "$@"
>> +}
>> +
>> +proto_xfrm_setup() {
>> +   local cfg="$1"
>> +   local mode="xfrm"
>> +
>> +   local tunlink ifid mtu zone
>> +   json_get_vars tunlink ifid mtu zone
>> +
>> +   proto_init_update "$cfg" 1
>> +
>> +   proto_add_tunnel
>> +   json_add_string mode "$mode"
>> +   json_add_int mtu "${mtu:-1280}"
>> +
>> +   [ -z "$tunlink" ] && {
>> +   proto_notify_error "$cfg" NO_TUNLINK
>> +   proto_block_restart "$cfg"
>> +   exit
>> +   }
>> +   json_add_string link "$tunlink"
>> +
>> +   [ -z "$ifid" ] && {
>> +   proto_notify_error "$cfg" NO_IFID
>> +   proto_block_restart "$cfg"
>> +   exit
>> +   }
>> +   json_add_object 'data'
>> +   [ -n "$ifid" ] && json_add_int ifid "$ifid"
>> +   json_close_object
>> +
>> +   proto_close_tunnel
>> +
>> +   proto_add_data
>> +   [ -n "$zone" ] && json_add_string zone "$zone"
>> +   proto_close_data
>> +
>> +   proto_send_update "$cfg"
>> +}
>> +
>> +proto_xfrm_teardown() {
>> +   local cfg="$1"
>> +}
>> +
>> +proto_xfrm_init_config() {
>> +   no_device=1
>> +   available=1
>> +
>> +   proto_config_add_int "mtu"
>> +   proto_config_add_string "tunlink"
>> +   proto_config_add_string "zone"
>> +   proto_config_add_int "ifid"
>> +}
>> +
>> +
>> +[ -n "$INCLUDE_ONLY" ] || {
>> +   [ -f /lib/modules/$(uname -r)/xfrm_interface.ko -o -d 
>> /sys/module/xfrm_interface ] && add_protocol xfrm
> I missed the check for /sys/module/xfrm_interface in my initial
> review; is there any specific reason for this additional check beside
> the xfrm_interface.ko check ?

Of course. I often test or run these images inside containers. In that case, 
all modules are preloaded on the host.
The check would fail cause of different kernel versions and not allow to use 
xfrm interfaces.

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/3] netifd: add xfrm interface support scripts

[Andre Valentin]

Hello Hans!

Am 06.06.19 um 22:40 schrieb Hans Dedecker:
> Hi,
> 
> Comments inline
Thanks for your hints. I will provide an updates version.

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/3] Add xfrm interface support

[Andre Valentin]

Hi!

the new strongswan release 5.8.0 supports these xfrm interfaces.

Kind regards,

André

Am 06.06.19 um 15:50 schrieb André Valentin:
> This adds support for xfrm interfaces. These interfaces are used as tunnel
> interfaces for IPsec allowing route-based tunnels.
> Compared to vti, xfrm interfaces do not need endpoints. This is optimal for
> dynamic IP address setups.
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] linux/net: Add dependency for crypto echainiv module on 4.4

[Andre Valentin]

Hi!
Am 12.02.2016 um 09:27 schrieb John Crispin:
> Hi,
> 
> 
> 
> On 30/01/2016 23:15, André Valentin wrote:
>> This dependency is needed to be able to create ipsec xfrm states.
>>
>> Signed-off-by: André Valentin 
>> ---
>>  package/kernel/linux/modules/netsupport.mk | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/package/kernel/linux/modules/netsupport.mk 
>> b/package/kernel/linux/modules/netsupport.mk
>> index 0215722..39491aa 100644
>> --- a/package/kernel/linux/modules/netsupport.mk
>> +++ b/package/kernel/linux/modules/netsupport.mk
>> @@ -286,7 +286,7 @@ IPSEC-m:= \
>>  define KernelPackage/ipsec
>>SUBMENU:=$(NETWORK_SUPPORT_MENU)
>>TITLE:=IPsec related modules (IPv4 and IPv6)
>> -  DEPENDS:=+kmod-crypto-authenc +kmod-crypto-iv +kmod-crypto-des 
>> +kmod-crypto-hmac +kmod-crypto-md5 +kmod-crypto-sha1 +kmod-crypto-deflate 
>> +kmod-crypto-cbc
>> +  DEPENDS:=+kmod-crypto-authenc +kmod-crypto-iv +kmod-crypto-des 
>> +kmod-crypto-hmac +kmod-crypto-md5 +kmod-crypto-sha1 +kmod-crypto-deflate 
>> +kmod-crypto-cbc +LINUX_4_4:kmod-crypto-echainiv
> 
> Hi,
> 
> should this not use the -ge syntax ? right now this wont work on v4.5
Do you have an example of this? I grepped package/linux for DEPENDS, but could 
not find a hint.

Kind regards,

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

Re: [OpenWrt-Devel] [PATCH RFC 2/2] modules/netsupport: Add MPLS support / size

[Andre Valentin]

Hi!

Am 30.01.2016 um 23:20 schrieb Felix Fietkau:
> On 2016-01-30 23:14, André Valentin wrote:
>> Add needed modules for MPLS support.
>>
>> Signed-off-by: André Valentin 
>> ---
>>  package/kernel/linux/modules/netsupport.mk | 23 +++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/package/kernel/linux/modules/netsupport.mk 
>> b/package/kernel/linux/modules/netsupport.mk
>> index 446996e..0215722 100644
>> --- a/package/kernel/linux/modules/netsupport.mk
>> +++ b/package/kernel/linux/modules/netsupport.mk
>> @@ -1029,3 +1029,26 @@ define KernelPackage/rxrpc/description
>>  endef
>>  
>>  $(eval $(call KernelPackage,rxrpc))
>> +
>> +define KernelPackage/mpls
>> +  SUBMENU:=$(NETWORK_SUPPORT_MENU)
>> +  TITLE:=MPLS support
>> +  KCONFIG:= \
>> +CONFIG_MPLS \
>> +CONFIG_NET_MPLS_GSO=m \
>> +CONFIG_MPLS_ROUTING=m \
>> +CONFIG_MPLS_IPTUNNEL=m
>> +  FILES:= \
>> +$(LINUX_DIR)/net/mpls/mpls_gso.ko \
>> +$(LINUX_DIR)/net/mpls/mpls_iptunnel.ko \
>> +$(LINUX_DIR)/net/mpls/mpls_router.ko
>> +  AUTOLOAD:=$(call AutoLoad,30,mpls_router mpls_iptunnel mpls_gso)
>> +  DEPENDS:=+@KERNEL_MPLS +@KERNEL_LWTUNNEL 
>> +endef
> Since this is causing some code to be built into the kernel image,
> please do a measurement of how much it adds.

Sorry, forgot this. Here are the numbers:

Size of the modules:
mpls_gso.ko:3101 Bytes
mpls_iptunnel:  4367 Bytes
mpls_router:   17451 Bytes
---
modules total: 24.3 KiB

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

Re: [OpenWrt-Devel] [PATCH 1/2] linux/crypto: Add echainiv module provided by 4.4 kernels

[Andre Valentin]

Hi!

This module add 4526 Bytes uncompressed.

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

Re: [OpenWrt-Devel] [PATCH RFC 1/2] config: add MPLS and LWTunnel support

[Andre Valentin]

Hi!

Am 31.01.2016 um 00:42 schrieb Andre Valentin:
> Hi Felix,
> 
> thanks for taking a look. I had the problem that without this selection the
> iproute2 "ip route" does not support the new route "encap" parameter. It seems
> to detect the support in the kernel. Same is with GRE, also available for 
> LWTUNNEL,
> but it is now missing in iproute2. GRE is build as a module.
> I'm pretty sure I cleaned everything by removing every stuff in 
> build_dir/target*
> Do you have an idea how to solve this?

I will do a full clean and test the newly build iproute2 tomorrow again.

Kind regards,

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

Re: [OpenWrt-Devel] [PATCH] vlandev: Add support for setting a unique MAC on a VLAN interface

[Andre Valentin]

Hi Felix,

Am 29.01.2016 um 13:33 schrieb Felix Fietkau:
> On 2016-01-29 13:15, André Valentin wrote:
>> Hi Felix,
>>
>> thanks for the hint. Did you configure the MAC in the interface section?
>> I suggest I had a wrongly created MAC on my first tries which resulted in 
>> kernel not accepting it.
> I configured it in the device section - in fact I simply copy
> your exact example config text ;)

It works.. Argh. Stupid MAC generator that gave me bad MACs... That made me 
extend the code...

Kind regards,

André

P.S.: Don't ever use this one:
http://www.miniwebtool.com/mac-address-generator/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ar71xx with kernel 4.4 on WZR-HP-AG300H

[Andre Valentin]

Hi!

I've got some problems with new 4.4 kernel on ar711 with my WZR-HP-AG300H. 
Please just take this as a notice, I know it's testing ;-)
If you need more testing, I'm available.

André

Here's the log:

console=ttyS0,115200 root=31:03 rootfstype=jffs2 init=/sbin/init
mtdparts=ar7100-nor0:256k(u-boot),64k(u-boot-env),1152k@384k(uImage),6592k@1536k(rootfs),64k@320k(ART),64k@8128k(properties),8192k@8192k(flash1),M
## Booting image at bf06 ...
   Image Name:   MIPS OpenWrt Linux-4.4
   Created:  2016-01-30  21:45:43 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:1402157 Bytes =  1.3 MB
   Load Address: 8006
   Entry Point:  8006
   Verifying Checksum ... crc32_fw: bf060040 - bf1b656c (len:0015652d) calc...
crc32_fw: range1 bf060040 - bf1b656c
OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 8006) ...
## Giving linux memsize in bytes, 134217728

Starting kernel ...

[0.00] Linux version 4.4.0 (avalen...@nixdevel.ad.ddimension.net) (gcc 
version 5.2.0 (OpenWrt GCC 5.2.0 r48531) ) #1 Sat Jan 30 21:45:32 UTC 2016
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019374 (MIPS 24Kc)
[0.00] SoC: Atheros AR7161 rev 2
[0.00] Determined physical RAM map:
[0.00]  memory: 0800 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] No valid device tree found, continuing without
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x07ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 0x-0x07ff]
[0.00] Reserving 0MB of memory at 0MB for crashkernel
[0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 
bytes
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32512
[0.00] Kernel command line:  board=WZR-HP-AG300H console=ttyS0,115200 
rootfstype=squashfs,jffs2 noinitrd
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Writing ErrCtl register=
[0.00] Readback ErrCtl register=
[0.00] Memory: 125064K/131072K available (3127K kernel code, 156K 
rwdata, 648K rodata, 284K init, 213K bss, 6008K reserved, 0K cma-reserved)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:51
[0.00] Clocks: CPU:680.000MHz, DDR:340.000MHz, AHB:170.000MHz, 
Ref:40.000MHz
[0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, 
max_idle_ns: 5621354254 ns
[0.08] sched_clock: 32 bits at 340MHz, resolution 2ns, wraps every 
6316128254ns
[0.007737] Calibrating delay loop... 452.19 BogoMIPS (lpj=2260992)
[0.070375] pid_max: default: 32768 minimum: 301
[0.075074] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.081595] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.089325] Initializing cgroup subsys io
[0.093284] Initializing cgroup subsys devices
[0.097666] Initializing cgroup subsys freezer
[0.102081] Initializing cgroup subsys net_cls
[0.106505] Initializing cgroup subsys pids
[0.111981] devtmpfs: initialized
[0.115925] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.126352] NET: Registered protocol family 16
[0.131647] MIPS: machine is Buffalo WZR-HP-AG300H/WZR-600DHP
[2.777559] registering PCI controller with io_map_base unset
[2.790904] PCI host bridge to bus :00
[2.794968] pci_bus :00: root bus resource [mem 0x1000-0x16ff]
[2.801754] pci_bus :00: root bus resource [io  0x]
[2.807306] pci_bus :00: root bus resource [??? 0x flags 0x0]
[2.814050] pci_bus :00: No busn resource found for root bus, will use 
[bus 00-ff]
[2.822006] pci :00:11.0: fixup device configuration
[2.828688] pci :00:12.0: fixup device configuration
[2.835385] pci :00:11.0: BAR 0: assigned [mem 0x1000-0x1000]
[2.842075] pci :00:12.0: BAR 0: assigned [mem 0x1001-0x1001]
[2.848856] pci :00:11.0: using irq 40 for pin 1
[2.853756] pci :00:12.0: using irq 41 for pin 1
[2.859447] clocksource: Switched to clocksource MIPS
[2.868345] NET: Registered protocol family 2
[2.873464] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[2.880397] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[2.886667] TCP: Hash tables configured 

Re: [OpenWrt-Devel] [PATCH RFC 1/2] config: add MPLS and LWTunnel support

[Andre Valentin]

Hi Felix,

thanks for taking a look. I had the problem that without this selection the
iproute2 "ip route" does not support the new route "encap" parameter. It seems
to detect the support in the kernel. Same is with GRE, also available for 
LWTUNNEL,
but it is now missing in iproute2. GRE is build as a module.
I'm pretty sure I cleaned everything by removing every stuff in 
build_dir/target*
Do you have an idea how to solve this?

Kind regards,

André


Am 30.01.2016 um 23:19 schrieb Felix Fietkau:
> On 2016-01-30 23:14, André Valentin wrote:
>> Add support for MPLS and Lighweight tunnel to openwrt kernel config.
>>
>> Signed-off-by: André Valentin 
>> ---
>>  config/Config-kernel.in | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/config/Config-kernel.in b/config/Config-kernel.in
>> index c93bbde..0bc1687 100644
>> --- a/config/Config-kernel.in
>> +++ b/config/Config-kernel.in
>> @@ -184,6 +184,14 @@ config KERNEL_MAGIC_SYSRQ
>>  bool "Compile the kernel with SysRq support"
>>  default y
>>  
>> +config KERNEL_LWTUNNEL
>> +bool "Compile the kernel with LWTUNNEL support"
>> +default n
>> +
>> +config KERNEL_MPLS
>> +bool "Compile the kernel with MPLS support"
>> +default n
>> +
> Putting these here and selecting them from your kmod-* package doesn't
> make any sense. Please stick to using KCONFIG.
> 
> - Felix
> 


-- 
Mit freundlichen Grüßen
André Valentin

Systemadministration - Projektkoordination


--
MarcanT GmbH, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net  | 
http://www.global-m2m.com 

Internet * Netzwerk * Mobile Daten
Citrix Silver Solution Advisor

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238



___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] vlandev: Add support for setting a unique MAC on a VLAN interface

[Andre Valentin]

Am 24.01.2016 um 20:47 schrieb André Valentin:
> There are cases where you need a different MAC on a VLAN interface, i.e. if
> if have move than one connection to a switch. A later change of the MAC
> is not possible on VLAN interfaces, so it has to be done on creation.
> The new macaddr option allows to set a unique MAC for a VLAN interface.
> Example:
> config device 'testvl'
> option type '8021ad'
> option name 'testvl'
> option ifname 'eth0'
> option vid '106'
> option macaddr 'f2:48:00:89:45:4c'
> 
> config interface 'testif'
> option ifname 'testvl'
> option proto 'none'
> option auto '1'

Wiki now inlcudes vlandev and the new macaddr option.
https://wiki.openwrt.org/doc/uci/network#devices

Kind regards,

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

Re: [OpenWrt-Devel] [PATCH] vlandev: Add support for setting a unique MAC on a VLAN interface

[Andre Valentin]

Am 24.01.2016 um 21:34 schrieb Gio:
> On Sunday 24 January 2016 20:47:26 André Valentin wrote:
>> There are cases where you need a different MAC on a VLAN interface, i.e. if
>> if have move than one connection to a switch. A later change of the MAC
>> is not possible on VLAN interfaces, so it has to be done on creation.
>> The new macaddr option allows to set a unique MAC for a VLAN interface.
> 
> I am the author of vlandev stuff are you sure that this doesn't break 
> assumptions made by linux kernel networking stack?
> 
> Some time ago i have done some testing (not enough probably) about changing 
> mac address on a vlan and the vlan interface stopped receiving packets, I 
> think that linux kernel was assuming the vlan and the untagged interface have 
> the same mac address my setup was like this
> 
> 
> 
> 
> My experience was that if eth0 and eth0.10 had differents mac, eth0.10 didn't 
> receiving packets, this may be caused by eth0 being in a bridge
> 
> To overcome this i tried multiple permutations with macvlan in the middle but 
> none of them worked :(
> 
> one of the permutation was this
> 
> 
> 
> if i remember well i could not create the macvlan0 interface since eth0 was 
> in 
> the bridge :(
The upper setup was exact that what I not wanted ;-)

I know that there are problems if you create a bridge on the untagged VLAN and
also on tagged ones depending on the kernel version. Personally I do not use 
such
setup because of its instability.
But with the documented setup below I have no problems, it's verified with 
several
ar71xx devices.

Kind regards,

Andre


> 
> Cheers!
> 
>> Example:
>> config device 'testvl'
>> option type '8021ad'
>> option name 'testvl'
>> option ifname 'eth0'
>> option vid '106'
>> option macaddr 'f2:48:00:89:45:4c'
>>
>> config interface 'testif'
>> option ifname 'testvl'
>> option proto 'none'
>> option auto '1'
>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] 090-backport_netfilter_rtcache.patch and IPsec routing/connection errors/packet loss

[Andre Valentin]

Hi!

If I enable this patch/module, I get strange errors with my OpenWRT based IPsec 
router. Packets are accepted and then lost, and not encrypted. Only the first 
comes through, especially if stateless
protocolls (udp, icmp) are used.

This system used multiple routing tables and rules generated by myself, 
strongswan and netifd.

If interested I can provide a testing ground and help in debugging.
Simply unload the module nf_conntrack_rtcache.ko helped immediately and the 
packet loss disappared.

With kind regards,

André



Mit freundlichen Grüßen
 André Valentin
Systemadministrator
--
MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net | http://www.global-m2m.com

Internet * Netzwerk * Mobile Daten
Citrix Silver Solution Advisor

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Oopses on ZyXEL NBG6716 (atheros)

[Andre Valentin]

 [ipv6]
[ 1842.82]
[ 1842.82]
Code: 00c42021  8882  98820003 8844 98440003  7c84d800  1085  
  8c640040
info dnsmasq[960[ 1843.24] ---[ end trace 5ca961b41da45ecb ]---
7]: forwarded www.heise.de to 20[ 1843.25] Kernel panic - not syncing: 
Fatal exception in interrupt

Kind regards,

Andre

On 27.11.2014 08:57, Andre Valentin wrote:
 Hi!

 thanks for your offer. Please wait a week for me the test it, just to proove 
 it. I will post here and in the ticket.

 Kind regards,

 André


 On 27.11.2014 08:28, John Crispin wrote:
 Hi,

 do we need only this -
 http://patchwork.ozlabs.org/patch/349076/

 or all 6 from the series ?

   John




Mit freundlichen Grüßen
 André Valentin
Systemadministrator
--
MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net | http://www.global-m2m.com

Internet * Netzwerk * Mobile Daten
Citrix Silver Solution Advisor

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Oopses on ZyXEL NBG6716 (atheros)

[Andre Valentin]

Hi!

Thanks for the hint. I could  now isoliate it to this bug:
https://dev.openwrt.org/ticket/18325

Kind regards,

André

On 25.11.2014 16:23, John Crispin wrote:
 build an image with KALLSYMS please and send a new log


Mit freundlichen Grüßen
 André Valentin
Systemadministrator
--
Internet * Netzwerk * Mobile Daten
Citrix Silver Solution Advisor

Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax -18
URL: http://www.marcant.net | http://www.global-m2m.com

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
CONFIDENTIALITY NOTICE
The contents of this email are confidential to the ordinary user of the email
address to which it was addressed and may also be privileged. If you are not
the addressee of this email you may not copy, forward, disclose or otherwise
use it or any part of it in any form whatsoever. If you have received this
email in error please email the sender by replying to this message.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Oopses on ZyXEL NBG6716 (atheros)

[Andre Valentin]

Hi!

thanks for your offer. Please wait a week for me the test it, just to proove 
it. I will post here and in the ticket.

Kind regards,

André


On 27.11.2014 08:28, John Crispin wrote:
 Hi,

 do we need only this -
 http://patchwork.ozlabs.org/patch/349076/

 or all 6 from the series ?

   John



Mit freundlichen Grüßen
 André Valentin
Systemadministrator
--
Internet * Netzwerk * Mobile Daten
Citrix Silver Solution Advisor

Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax -18
URL: http://www.marcant.net | http://www.global-m2m.com

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
CONFIDENTIALITY NOTICE
The contents of this email are confidential to the ordinary user of the email
address to which it was addressed and may also be privileged. If you are not
the addressee of this email you may not copy, forward, disclose or otherwise
use it or any part of it in any form whatsoever. If you have received this
email in error please email the sender by replying to this message.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Oopses on ZyXEL NBG6716 (atheros)

[Andre Valentin]

Hi!

Since 3.10.58 I notice reboots of the system. I logged the oopses, but cannot 
see a source. Please take a look if you have an idea what the heck this causes:
---
[   57.66] icmp6_send: no reply to icmp error
[   57.66] icmp6_send: no reply to icmp error
[   57.66] CPU 0 Unable to handle kernel paging request at virtual address 
0260, epc == 8ef687e0, ra == 8e302664
[   57.68] Oops[#1]:
[   57.68] CPU: 0 PID: 5009 Comm: jsonfilter Not tainted 3.14.18 #3
[   57.68] task: 8c04 ti: 8dd92000 task.ti: 8dd92000
[   57.68] $ 0   :  0001  8dec60e0
[   57.68] $ 4   : 8dee9e40 000a  0001
[   57.68] $ 8   : 20030068 fd000f88 b4672046 27b36626
[   57.68] $12   : 0002 0002a300  
[   57.68] $16   : 8dee9e40 0001 8dee9e40 
[   57.68] $20   : 0001 0004 0001 0003
[   57.68] $24   :  8ef77590
[   57.68] $28   : 8dd92000 8dd93b58 ff62 8e302664
[   57.68] Hi: 0001
[   57.68] Lo: 
[   57.68] epc   : 8ef687e0 0x8ef687e0
[   57.68] Not tainted
[   57.68] ra: 8e302664 0x8e302664
[   57.68] Status: 1100fc03 KERNEL EXL IE
[   57.68] Cause : 0088
[   57.68] BadVA : 0260
[   57.68] PrId  : 00019750 (MIPS 74Kc)
[   57.68] Modules linked in: gpio_button_hotplug qcserial option 
iptable_nat ip6table_nat cdc_mbim ath9k usb_wwan sierra_net sierra rndis_host 
qmi_wwan pppoe pl2303 nf_nat_pptp nf_nat_ipv6
nf_nat_ipv4 nf_nat_amanda nf_conntrack_pptp nf_conntrack_ipv6 nf_conntrack_ipv4 
nf_conntrack_amanda l2tp_ppp huawei_cdc_ncm ftdi_sio cdc_subset cdc_ncm 
cdc_ether cdc_eem ath9k_common xt_time xt_tcpudp
xt_tcpmss xt_string xt_statistic xt_state xt_socket xt_recent xt_quota 
xt_policy xt_pkttype xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit 
xt_length xt_iprange xt_id xt_hl xt_helper xt_hashlimit
xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes 
xt_comment xt_addrtype xt_TPROXY xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_HL 
xt_DSCP xt_CT xt_CLASSIFY usbserial usbnet usblp
ts_kmp ts_fsm ts_bm pppox ppp_synctty ppp_mppe ppp_async nfnetlink_log 
nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_proto_gre nf_nat_irc 
nf_nat_h323 nf_nat_ftp nf_defrag_ipv6 nf_defrag_ipv4
nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_proto_gre 
nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp 
nf_conntrack_broadcast iptable_raw iptable_mangle
iptable_filter ipt_ah ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_ECN ip_tables 
gspca_sonixj gspca_sonixb gspca_main crc_ccitt cdc_wdm cdc_acm ath9k_hw 
arptable_filter arpt_mangle arp_tables fuse sch_teql
sch_tbf sch_sfq sch_red sch_prio sch_netem sch_htb sch_gred sch_dsmark 
sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police act_ipt 
act_connmark act_skbedit act_mirred em_u32 cls_u32
cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress v4l2_common videodev 
evdev ath mac80211 cfg80211 compat siit ledtrig_usbdev xt_LED ledtrig_morse 
ledtrig_heartbeat ledtrig_gpio xt_set
ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net 
ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ip 
ip_set_bitmap_port ip_set_bitmap_ipmac
ip_set_bitmap_ip ip_set nfnetlink ip6t_NPT ip6t_MASQUERADE nf_nat nf_conntrack 
ip6t_REJECT ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
pppoatm ppp_generic slhc msdos ip6_gre
ip_gre gre ifb dummy l2tp_ip l2tp_eth ip_vti sit l2tp_netlink l2tp_core ipcomp6 
xfrm6_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet esp6 ah6 
ipcomp xfrm4_tunnel xfrm4_mode_tunnel
xfrm4_mode_transport xfrm4_mode_beet esp4 ah4 ipip ip6_tunnel tunnel6 tunnel4 
ip_tunnel veth tun af_key xfrm_user xfrm_ipcomp xfrm_algo vfat fat udf 
crc_itu_t ntfs isofs br2684 atm fscache ipv6
chainiv eseqiv crypto_wq algif_skcipher algif_hash af_alg sha256_generic 
sha1_generic krng rng md5 hmac ecb des_generic cbc authenc aead arc4 
crypto_blkcipher usb_storage input_polldev ohci_platform
ohci_hcd ledtrig_transient ehci_pci ehci_platform ehci_hcd sd_mod scsi_mod ext4 
jbd2 mbcache button_hotplug input_core usbcore nls_base usb_common mii 
crypto_hash [last unloaded: ath10k_core]
[   57.68] Process jsonfilter (pid: 5009, threadinfo=8dd92000, 
task=8c04, tls=77663440)
[   57.68] Stack : 8efbf6b0 c10abda0 0028 8dcf5000   
 8dcf5000
  ff62  0004 0a00be48 c10a8000 8dee9e40 3a01 
c10c8588
  c10c8000 8dee9e40 80375a64 8dee9e40  0001 0004 
8dee9e40
  0001 8e302664 8dd93c48 80375a64 8dee9e40  8ee858dc 
0004
  0001 8dd93c48 80375a64 801f372c 8ef29e80 0004 80375a5c 
8dcf5000
  ...
[   57.68] Call Trace:[8e302664] 0x8e302664
[   57.68] [8ee858dc] 0x8ee858dc
[   

Re: [OpenWrt-Devel] Barrier Breaker 14.07 Final

[Andre Valentin]

Hi!

Thank you very much for this great work!

André



Mit freundlichen Grüßen
André Valentin
Systemadministrator
--
Internet * Netzwerk * Mobile Daten
Citrix Silver Solution Advisor

Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax -18
URL: http://www.marcant.net | http://www.global-m2m.com

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
CONFIDENTIALITY NOTICE
The contents of this email are confidential to the ordinary user of the email
address to which it was addressed and may also be privileged. If you are not
the addressee of this email you may not copy, forward, disclose or otherwise
use it or any part of it in any form whatsoever. If you have received this
email in error please email the sender by replying to this message.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx: Update to 3.14 [Flash Erasing / Bandwidth ]

[Andre Valentin]

Hi Daniel,

thanks for the hint. I will check it the next days. I'm now a bit busy.
Also I noticed that TCP throughput went from 15MBit/s PPPoE to 6 MBit/s.
It seems it is about codel, because all streams get the same rate, if using 
multiple.
I jut want to share my expierence with 3.14 so the developer has some hints.

Kind regards,

On 10.08.2014 15:00, Daniel Golle wrote:

Hi Andre,

there were some changes related to fastmap, I suspect that
commit c22301ad4fa0f4cf71e9c877d072e6f07a0bf682
UBI: fastmap: fix backward compatibility with image_seq
or something related might cause the problem you observe.

How excactly did you flash the image to the device?

Cheers

Daniel

On Sat, Aug 09, 2014 at 08:54:42PM +0200, Andre Valentin wrote:

Hi Daniel!

Please take a look at this (old kernel 3.10)
[3.42] UBI: attaching mtd8 to ubi0
[3.57] UBI: EOF marker found, PEBs from 105 will be erased
[3.58] UBI: scanning is finished
[3.61] UBI: attached mtd8 (name ubiroot, size 249 MiB) to ubi0
[3.61] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[3.62] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[3.63] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[3.63] UBI: good PEBs: 1992, bad PEBs: 0, corrupted PEBs: 0
[3.64] UBI: user volume: 2, internal volumes: 1, max. volumes count: 128
[3.65] UBI: max/mean erase counter: 0/0, WL threshold: 4096, image 
sequence number: 975457251
[3.66] UBI: available PEBs: 791, total reserved PEBs: 1201, PEBs 
reserved for bad PEB handling: 40
[3.67] UBI: background thread ubi_bgt0d started, PID 274
[3.68] mtd: device 9 (rootfs) set to be root filesystem

And here the new one:
[3.53] UBI: auto-attach mtd8
[3.53] UBI: attaching mtd8 to ubi0
[3.85] UBI error: scan_peb: bad image sequence number 811584292 in PEB 
224, expected 1326740447
[3.86] Erase counter header dump:
[3.86]  magic  0x55424923
[3.86]  version1
[3.87]  ec 1
[3.87]  vid_hdr_offset 2048
[3.87]  data_offset4096
[3.88]  image_seq  811584292
[3.88]  hdr_crc0xa455ffb3
[3.88] erase counter header hexdump:
[3.89] UBI error: ubi_attach_mtd_dev: failed to attach mtd8, error -22
[3.90] UBI error: ubi_auto_attach: cannot attach mtd8

Are you sure about this? This Flash image is about 25 MiB, like the old one. So 
PEB 224 is in the area where ubi should erase all.
Seems to me that the erasing of the additional space is not done.
Also the message about the EOF marker is not displayed. Has there something 
changed between 3.10 and 3.14?

Kind regards,

André




--
Mit freundlichen Grüßen,
André Valentin
Projektkoordination / Systemadministration

MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax -18
URL: http://www.marcant.net | http://www.global-m2m.com

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
CONFIDENTIALITY NOTICE
The contents of this email are confidential to the ordinary user of the
email address to which it was addressed and may also be privileged. If
you are not the addressee of this email you may not copy, forward,
disclose or otherwise use it or any part of it in any form whatsoever.
If you have received this email in error please email the sender by
replying to this message.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ar71xx: Update to 3.14

[Andre Valentin]

Hi Felix!

I saw that you upgraded ar71xx to 3.14. I tested it immediateley, of course. It 
seems there is a problem with ubi. Please take a look at this:

[0.00] Linux version 3.14.16 (avalentin@varus) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r42002) ) #1 Fri Aug 8 11:52:10 CEST 2014
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019750 (MIPS 74Kc)
[0.00] SoC: Qualcomm Atheros QCA9558 rev 0
[0.00] Determined physical RAM map:
[0.00]  memory: 0800 @  (usable)
[0.00] User-defined physical RAM map:
[0.00]  memory: 1000 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x0fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x0fff]
[0.00] Reserving 0MB of memory at 0MB for crashkernel
[0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 
bytes
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 65024
[0.00] Kernel command line:  board=NBG6716 console=ttyS0,115200 
mtdparts=spi0.0:256k(u-boot)ro,64k(env)ro,64k(RFdata)ro,-(nbu);ar934x-nfc:2048k(zyxel_rfsd),2048k(romd),1024k(header),2048k(kernel),-(ubi)
 mem=256M rootfstype=squashfs noinitrd
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Writing ErrCtl register=
[0.00] Readback ErrCtl register=
[0.00] Memory: 255864K/262144K available (2701K kernel code, 126K 
rwdata, 360K rodata, 196K init, 193K bss, 6280K reserved)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:51
[0.00] Clocks: CPU:720.000MHz, DDR:600.000MHz, AHB:200.000MHz, 
Ref:40.000MHz
[0.00] Calibrating delay loop... 358.80 BogoMIPS (lpj=1794048)
[0.06] pid_max: default: 32768 minimum: 301
[0.06] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.07] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.07] NET: Registered protocol family 16
[0.08] MIPS: machine is Zyxel NBG6716
[0.13] ar724x-pci ar724x-pci.0: PCIe link is down
[0.13] registering PCI controller with io_map_base unset
[0.14] registering PCI controller with io_map_base unset
[0.55] bio: create slab bio-0 at 0
[0.55] PCI host bridge to bus :00
[0.56] pci_bus :00: root bus resource [mem 0x1000-0x11ff]
[0.56] pci_bus :00: root bus resource [io  0x]
[0.57] pci_bus :00: No busn resource found for root bus, will use 
[bus 00-ff]
[0.57] PCI host bridge to bus :01
[0.58] pci_bus :01: root bus resource [mem 0x1200-0x13ff]
[0.58] pci_bus :01: root bus resource [io  0x0001]
[0.59] pci_bus :01: No busn resource found for root bus, will use 
[bus 01-ff]
[0.59] pci :01:00.0: BAR 0: assigned [mem 0x1200-0x121f 
64bit]
[0.60] pci :01:00.0: BAR 6: assigned [mem 0x1220-0x1220 
pref]
[0.60] pci :01:00.0: using irq 41 for pin 1
[0.61] Switched to clocksource MIPS
[0.61] NET: Registered protocol family 2
[0.62] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[0.62] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[0.63] TCP: Hash tables configured (established 2048 bind 2048)
[0.64] TCP: reno registered
[0.64] UDP hash table entries: 256 (order: 0, 4096 bytes)
[0.64] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[0.65] NET: Registered protocol family 1
[0.66] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.67] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[0.68] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) 
(CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[0.69] msgmni has been set to 499
[0.69] io scheduler noop registered
[0.70] io scheduler deadline registered (default)
[0.70] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[0.73] serial8250.0: ttyS0 at MMIO 0x1802 (irq = 11, base_baud = 
250) is a 16550A
[0.74] console [ttyS0] enabled
[0.74] console [ttyS0] enabled
[0.75] bootconsole [early0] disabled
[0.75] bootconsole [early0] disabled
[0.76] m25p80 spi0.0: found mx25l12805d, expected m25p80
[0.76] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
[0.77] 4 cmdlinepart partitions found on MTD device spi0.0
[

Re: [OpenWrt-Devel] Help with SysupgradeNAND

[Andre Valentin]

Hi!

I also noticed after upgrading that routers with jffs2 in ubi (rootfs_data) are 
not
supported anymore. The jffs2 is not mounted after an upgrade,
resulting in loss of configuration. I had to clear rootfs_data
to be able to mount it again as ubifs. That's okay if you know it!

I noticed a second issue. hostapd (running in some kind of dfs loop) was not 
killed
by sysupgrade nand. That resulted in breaking the upgrade. System rebooted with 
old image.
I personnaly added a check in sysupgrade if it runs below upgraded and if
that's true, I kill _all_ processes. If interested I could publish the patch.

A third point is the upgrade itself. I the rootfs image grows, and rootfs_data
has all the remaining space aligned, it will not work because rootfs cannot 
grow.
Perhaps rootfs_data should always be recreated in the update process. If 
interested
I could also supply a patch.

Kind regards,

André


On 09.07.2014 09:02, John Crispin wrote:



On 09/07/2014 08:42, Ben Mulvihill wrote:

Hello Daniel,

I have got SysupgradeNAND working on the BTHOMEHUBV2B with an
all-ubifs rootfs, with a patch which I'll submit in another email,
  once I've recompiled with the latest trunk and made sure that
everything is working, but in the meantime I have a question: am I
  right in thinking that the only type of overlay supported is
squashfs + ubifs, not squashfs + jffs2 ?



ubifs is jffs3 essentially, a jffs2 with nand awareness added ...
correct me if i am wrong ...






Thanks,

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


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




--
Mit freundlichen Grüßen,
André Valentin
Projektkoordination / Systemadministration

MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax -18
URL: http://www.marcant.net | http://www.global-m2m.com

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
CONFIDENTIALITY NOTICE
The contents of this email are confidential to the ordinary user of the
email address to which it was addressed and may also be privileged. If
you are not the addressee of this email you may not copy, forward,
disclose or otherwise use it or any part of it in any form whatsoever.
If you have received this email in error please email the sender by
replying to this message.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Help with SysupgradeNAND

[Andre Valentin]

On 09.07.2014 09:48, John Crispin wrote:

i think using squash+ubifs is a better option as we dont need to use
the gluebi layer anymore. this makes the whole setup a lot nice i
think. that is why jffs2 support for nand is gone. however i am open
to hear use cases for why jffs2 support should be added for nand.


No, not from me. I want it simple and not another layer. I think this is
the best solution.

I will send the proposed patches for sysupgrade today, perhaps the rootfs_data
part later.

Kind regards,

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

Re: [OpenWrt-Devel] Status of DFS in OpenWrt - ath9k

[Andre Valentin]

Hi!

this should also be in your .config
# CONFIG_ATH_USER_REGD is not set
See http://wireless.kernel.org/en/users/Drivers/ath10k - Limitations 3/3

Kind regards,

André



On 04.07.2014 16:29, Jacek Kikiewicz wrote:

Hello,

I have CONFIG_PACKAGE_ATH_DFS=y and still cannot use this... any idea how / 
what should be debugged?

..

   CONFIG_PACKAGE_ATH_DFS=y

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

Re: [OpenWrt-Devel] ar71xx/nbg6716 image generation and installation

[Andre Valentin]

Hi!

you have to edit target/linux/ar71xx/Makefile and remove broken from one of 
the first line. I recommend the squashfs image.

André

On 30.05.2014 17:17, Alejandro Mery wrote:



On 30/05/14 14:45, Alejandro Mery wrote:



On 30/05/14 14:33, Jacek Kikiewicz wrote:

select target profile zyxel ( there is no your model but they might be
all together) and re-build


didn't help :(


I'm starting to understand the problem. the device I want is defined in
target/linux/ar71xx/nand/profiles/zyxel.mk

but I'm not allowed to choose the nand subtarget or ar71xx, only generic and 
mikrotik.

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

Re: [OpenWrt-Devel] [PATCH 3/3] bcm53xx_brcm: add sysupgrade support

[Andre Valentin]

Hi !

On 23.05.2014 15:03, Daniel wrote:

I built a quite feature-complete and by now well-working sysupgrade for the 
oxnas fork
https://www.gitorious.org/openwrt-oxnas/openwrt-oxnas/source/8d0f5e4025d5d9d2c129914b59c03d7c2cde5d93:target/linux/oxnas/base-files/lib/upgrade/platform.sh


That looks good!


I re-based it to use your sysupgrade -s code instead of the SIGUSR2-hack I was
using before -- works great.


Nice to hear that you used it and that it works !


The script handles both, combined kernel+rootfs images as well as ubnized
images. Other targets where e.g. kernel needs to be started in bare NAND
rather than inside an ubi volume due to the lack of bootloader support, this
can easily be added by having do_upgrade_combined white the kernel via
nandwrite and initialize the filesystems in UBI.


Perfect.  That make life a lot easier for me. Did you already think about moving
the generic stuff to the some kind of ubi include for /lib/upgrade ? Would make
sense, specially for newer boards.

--

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

Re: [OpenWrt-Devel] [PATCH 0/3] RFC: Enable sysupgrade on ubifs rootfs

[Andre Valentin]

Hi!

On 23.05.2014 15:08, John Crispin wrote:

Hi,

is this neccessary ? should a forced detach not be enough ? that is
why we added the forced detach ioctl.

could you try to use ubi detach rootfs instead of unmount ?

Damn, I did not notice this. I have to use a different kernel source..
Thanks for the hint, I'll keep you posted!

--

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

Re: [OpenWrt-Devel] [PATCH 0/3] RFC: Enable sysupgrade on ubifs rootfs

[Andre Valentin]

Hi!

On 23.05.2014 16:12, John Crispin wrote:


ok, i will rework the series and merge the first 2 patches in the next
days.

i noticed the series passes the cmdline of sysupgrade which is a bit
ugly so i will change that to using imagename + preserve_settings or
similar


That sounds good:-) Can't wait to see it! If I can support just tell!

--

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

Re: [OpenWrt-Devel] [PATCH 1/3] procd: add support for running sysupgrade as PID 1

[Andre Valentin]

Hi !

On 23.05.2014 15:16, Felix Fietkau wrote:

- submit it as a patch to procd git instead of openwrt
- rename the command to 'exec' or something like that. It could be used
for more than just sysupgrade.
- make arguments a string array and maybe combine it with command
- maybe add an optional attribute for the directory to chdir() into
(because of what daniel pointed out wrt. relative image path)


Thanks for taking a look. I totally agree to the points you made. I also was
unsure if this exec as init function should be some kind of general
stuff. The first thing I thought of was resizing the rootfs volume, or
swapping it,...
But I will not continue the generic part as you perhaps read.

--

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

Re: [OpenWrt-Devel] [PATCH 3/3] bcm53xx_brcm: add sysupgrade support

[Andre Valentin]

Hi!

I thought about how I could get some kind of transaction safety. I only found 
this solution:
-Look if there is enough extra space for rootfs+sysupgrade.tgz+safety
-If yes, create a temporary volume and push the image into it
-Mount it
-Copy sysupgrade.tgz to its root
-unmount it
-update kernel
-If all steps above are successfull, make an atomic name change 
rootfs-_temp_image_
-Remove the old, renamed rootfs

What do you think, does this make sense in a failsafe way?
But I did not find a solution if there is not enough free space for an 
temporary image..

André

On 22.05.2014 22:16, André Valentin wrote:


Signed-off-by: André Valentin avalen...@marcant.net
---
  .../base-files/lib/upgrade/platform.sh |  108 

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

[OpenWrt-Devel] bcm53xx: Netgear R7000 problems

[Andre Valentin]

Hello!

I saw that there is support for the Netgear R6250 in openwrt. So I thought 
maybe the R7000 is not so far from being support. It's not ;-)
After I modified the R6250 config in openwrt to allow the initramfs image to be flashed. First problem I then saw is that the image loads fine, but on serial I get only rubbish. But the luck was on my 
side, the device responded to ping and allowed me a login.


This is the CFE boot log:

CFE for Foxconn Router R7000 version: v1.0.21
Build Date: Wed Aug  7 19:11:17 CST 2013
Init Arena
Init Devs.
Boot up from NAND flash...
Bootcode Boot partition size = 524288(0x8)
DDR Clock: 800 MHz
Info: DDR frequency set from clkfreq=1000,*800*
et0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 6.37.15.1 (r407936)
CPU type 0x0: 1000MHz
Tot mem: 262144 KBytes

Device eth0:  hwaddr C4-04-15-5B-C4-66, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Loader:raw Filesys:tftp Dev:eth0 File:192.168.1.2:vmlinuz Options:(null)
Loading: TFTP error 1: File not found
Failed.
Could not load 192.168.1.2:vmlinuz: Network protocol error
Checking crc...Loader:raw Filesys:raw Dev:nflash0.os File: Options:(null)
Loading: ... 2113986 bytes read
Entry at 0x8000
Closing network.
Starting program at 0x8000

And now the dmesg:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.10.36 (avalentin@varus) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.01 r40555) ) #24 SMP Mon May 12 21:30:34 CEST 2014
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: BCM5301X, model: Netgear R6250 V1 (BCM4708)
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] On node 0 totalpages: 32768
[0.00] free_area_init_node: node 0, pgdat c060d240, node_mem_map 
c064b000
[0.00]   Normal zone: 256 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 32768 pages, LIFO batch:7
[0.00] PERCPU: Embedded 7 pages/cpu @c074f000 s6784 r8192 d13696 u32768
[0.00] pcpu-alloc: s6784 r8192 d13696 u32768 alloc=8*4096
[0.00] pcpu-alloc: [0] 0 [0] 1
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32512
[0.00] Kernel command line: console=ttyS0,115200
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 128MB = 128MB total
[0.00] Memory: 123416k/123416k available, 7656k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xc880 - 0xff00   ( 872 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc02d6db4   (2876 kB)
[0.00]   .init : 0xc02d7000 - 0xc0606a80   (3263 kB)
[0.00]   .data : 0xc0608000 - 0xc061ee88   (  92 kB)
[0.00].bss : 0xc061ee88 - 0xc064ac54   ( 176 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] sched_clock: 32 bits at 400MHz, resolution 2ns, wraps every 
10737ms
[0.000227] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816)
[0.090046] pid_max: default: 32768 minimum: 301
[0.090201] Mount-cache hash table entries: 512
[0.091418] CPU: Testing write buffer coherency: ok
[0.091709] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.091780] Setting up static identity map for 0xc0010ef0 - 0xc0010f24
[0.092829] CPU1: failed to boot: -38
[0.092865] Brought up 1 CPUs
[0.092877] SMP: Total of 1 processors activated (1594.16 BogoMIPS).
[0.092884] CPU: All CPU(s) started in SVC mode.
[0.101230] NET: Registered protocol family 16
[0.101667] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.102704] L310 cache controller enabled
[0.102724] l2x0: 16 ways, CACHE_ID 0x41c8, AUX_CTRL 0x0a13, Cache 
size: 262144 B
[0.111556] bio: create slab bio-0 at 0
[0.113982] Switching to clocksource arm_global_timer
[0.116878] NET: Registered protocol family 2
[0.117442] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[0.117479] TCP bind hash table entries: 1024 (order: 1, 8192 bytes)
[0.117505] TCP: Hash tables configured (established 1024 bind 1024)
[0.117572] TCP: reno registered
[0.117595] UDP hash table entries: 256 (order: 1, 8192 bytes)
[0.117638] UDP-Lite hash table entries: 

Re: [OpenWrt-Devel] [PATCH][Lantiq] Add ath9k eeprom and pci fixup support

[Andre Valentin]

Hi Álvaro,

I get the following errors when I try to apply:
patching file 
target/linux/lantiq/patches-3.7/0122-MIPS-lantiq-adds-pcie-driver.patch

Hunk #8 FAILED at 248.
Hunk #9 FAILED at 1861.
Hunk #10 FAILED at 2002.
Hunk #12 FAILED at 2693.
Hunk #13 FAILED at 3177.
5 out of 21 hunks FAILED -- saving rejects to file 
target/linux/lantiq/patches-3.7/0122-MIPS-lantiq-adds-pcie-driver.patch.rej


Any ideas?

Regards,

André


Am 17.01.2013 13:59, schrieb Álvaro Fernández Rojas:

On linux 3.3, the fixup forced the regdomain to 0x67, causing low TX power.
This patch only corrects checksum, the rest of the EEPROM isn't changed.

Looks like patches hadn't been refreshed on this platform.



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

Re: [OpenWrt-Devel] [lantiq] kernel 3.7 update

[Andre Valentin]

Hi John,

I'm working with your new lantiq support and I have some problems.
First is that I get really bad performance on tun/tap devices with
openvpn. Minimal traffic through the devices is no problem, but if I
push a kernel over the line, I get response times in 40s range. There's
no load on the system..
If i do not use VPN, I get normal rates.
I checked everything. With the old kernel everything is as before.

Second is that netlink is somehow broken?? I get these errors:
Jan 10 21:37:15 firewall daemon.info syslog: 14[KNL] received netlink
error: Protocol not supported (120)
Jan 10 21:37:15 firewall daemon.info syslog: 14[KNL] unable to add SAD
entry with SPI c2c90d24

All corresponding modules are loaded for IPsec.

Do you have an idea?

André

On 15.12.2012 11:56, John Crispin wrote:
 Hi,
 
 i pushed the lantiq 3.7 kernel support last night.
 
 This is a rather big update as we are now running arch/lantiq/ on an
 almost fully upstreamed kernel with devicetree support.
 
 The following boards don't have a devicetree file yet due to lack of
 time / test hardware (help and hardware welcome!)
 
 ARV3527P GIGASX76X ARV4519PW BTHOMEHUBV2B BTHOMEHUBV3A WBMR P2601HNFX H201L
 
 
 Changelog :
 * adds devicetree support
 * updated usb driver
 * updated atm driver
 * added ptm driver
 * added deu driver (crypto engine)
 * unified leds/button names and handling (WIP)
 * proper amazon se support with 1 supported device (and i have 2 more on
 my desk that i will port soonish)
 * new uboot tree (thanks daniel)
 * asterisk support for TAPI (we dropped owsip)
 
 Known issues :
 * USB root hub registers as 1.1 (i only just noticed)
 * spi fails to come up on DGN3500
 * ralink pci wifi seems broken (a802/w303V/wav218)
 * svip / falcon are pending to be tested/fixed for 3.7
 * usif / spi drivers exist but need to be moved from platform to
 devicetree API
 * cpufreq driver exists but needs to be ported
 
 
 I am looking for people to donate me more units !
 * anything with AR10 inside it
 * my bufallo WBMR died i need a new one
 * fritzboxes would be welcome (i only have the 3370 and 7320)
 * speedport w723V (i believe this is VR9 based)
 * ARV7519RW22 - vdsl cpe orange/spain
 * there are a few huawei units with AR9/VR9
 * there are a few vdsl units from ZTE with VR9
 * i still dont have a ARV4519 (vodafone/italy?)
 
 Last but not least, if anyone wants to send me a xmas present, i am
 looking for a sponsor for one of these toys -
 http://www.saleae.com/logic16
 
 John
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Buffalo wbmr/lantiq kernel panik

[Andre Valentin]

Hi Lika,

after compiling it with symbols enabled it looks even worse:

Starting kernel ...

[0.00] Linux version 3.6.6 (avalentin@varus) (gcc version 4.6.4
20121001 (prerelease) (Linaro GCC 4.6-2012.10) ) #1 Fri Nov 9 20:54:50
CET 2012
[0.00] SoC: AR9 rev 1.2
[0.00] bootconsole [early0] enabled
[0.00] CPU revision is: 0001954c (MIPS 34Kc)
[0.00] DTB has bad magic, ignoring builtin OF DTB
[0.00] Determined physical RAM map:
[0.00]  memory: 0002a000 @ 00303000 (usable after init)
[0.00] Kernel panic - not syncing: Failed to load core nodess
from devicetree
[0.00] Rebooting in 1 seconds..

Perhaps I should wait for better support... Or could help somehow ?

André
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel