Re: openwrt developer / paid work
On 6/2/21 5:41 AM, Philip Prindeville wrote: On Jun 1, 2021, at 5:27 PM, Embedded Devel wrote: On 6/2/21 3:45 AM, Philip Prindeville wrote: This was advertised as "paid work". I'm still waiting to be paid. keep waiting, you accomplished nothing really, and billed $8,000.00 USD over 2 months and we are no further now then we were when you started. If youd like I can do a line count of changes from start to finish, the previous developer accomplished more in 10 hours, and hes been paid. And we already hired a new one prior to these emails. It seems like you dont know OpenWRT as well as you claim. This is all Im going to say publicly about it. This was a business to business deal and has no recourse being on a public mailing list, trying to accomplish what? embarrass us? Wount work, If it embarrasses anyone, it will be you. Also remember, There is an NDA in place you signed, be very careful. 8k is not much for a freelancing expert. That's 40 hours... One must consider the big amount of time one has to put into staying in tune with the developments which is in my case 90% of my work and the more specialized one is the more an hour must cost to cover the time without proper jobs. Furthermore software development is psychically draining which needs compensation. So if you think that's too much, you may think about either learning it yourself or whether your revenue is too low. You could also think about outsourcing your work to third-world- countries, but they will possibly fool you. There's an anecdote about that in Germany: A machine in a factory crashed and the engineer who designed it was in retirement. They needed to bring him back from retirement. When he came to the factory, he took a piece of chalk, made a mark and left after 5 minutes. He sent an invoice with a very high price. So the company asked for a listing of costs. He replied: Piece of chalk - 1 Mark Knowing where to do the mark - 5 Mark That's reality... You can't expect experts to do your slave labor. By the way... If you build up on open source software, what are you expecting? Imagine you'd have to build the software from ground up. Hiring open source developers is the cheapest thing you can get products to the market with... There are just so many wannabe start-up sucker companies with bad attitudes towards the engineers. They all go bankrupt. Line counts don’t take into consideration the amount of time to bring up software on a new platform that’s supposed to be portable but in fact isn’t. If you’re going to solicit in a public forum, then it should be known that the terms advertised were not in fact accurate. Yes, there’s an NDA. Nothing strategic or proprietary has been disclosed. And any civil legal proceedings would enter into the public record. And pursing legal action internationally would cost you more than I’ve billed. I think you need to be even more careful. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openwrt developer / paid work
> On Jun 1, 2021, at 5:27 PM, Embedded Devel wrote: > > > > On 6/2/21 3:45 AM, Philip Prindeville wrote: >> This was advertised as "paid work". I'm still waiting to be paid. > keep waiting, you accomplished nothing really, and billed $8,000.00 USD over > 2 months and we are no further now then we were when you started. If youd > like I can do a line count of changes from start to finish, the previous > developer accomplished more in 10 hours, and hes been paid. And we already > hired a new one prior to these emails. It seems like you dont know OpenWRT as > well as you claim. This is all Im going to say publicly about it. This was a > business to business deal and has no recourse being on a public mailing list, > trying to accomplish what? embarrass us? Wount work, If it embarrasses > anyone, it will be you. Also remember, There is an NDA in place you signed, > be very careful. Line counts don’t take into consideration the amount of time to bring up software on a new platform that’s supposed to be portable but in fact isn’t. If you’re going to solicit in a public forum, then it should be known that the terms advertised were not in fact accurate. Yes, there’s an NDA. Nothing strategic or proprietary has been disclosed. And any civil legal proceedings would enter into the public record. And pursing legal action internationally would cost you more than I’ve billed. I think you need to be even more careful. -Philip > >> >> >> >> >>> On Apr 1, 2021, at 5:52 AM, Embedded Devel >>> wrote: >>> >>> need someone to fix an application we have, was fully functional some 10 >>> years ago. >>> >>> can provide a vm, with git repo sources of app and remote access to the ap >>> >>> we believe its a small issue that someone could resolve quickly. >>> >>> possible to turn into larger project for the right person >>> >>> >>> Thanks >>> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mac80211: split ath patch in dedicated subdir
The ath patch number is already large and adding other patch for ath11k
will add more confusion with the patch numbering.
Since the support of ath11k based device is imminent, prepare the mac80211
ath patch dir and split it in the dedicated ath5k, ath9k, ath10k and ath11k
(empty for now).
Signed-off-by: Ansuel Smith
---
package/kernel/mac80211/Makefile | 8
.../{ath => ath10k}/080-ath10k_thermal_config.patch | 0
...0k-add-CCMP-PN-replay-protection-for-fragmented-.patch | 0
...ath10k-drop-fragments-with-multicast-DA-for-PCIe.patch | 0
...ath10k-drop-fragments-with-multicast-DA-for-SDIO.patch | 0
...0k-drop-MPDU-which-has-discard-flag-set-by-firmw.patch | 0
...th10k-Fix-TKIP-Michael-MIC-verification-for-PCIe.patch | 0
...0k-Validate-first-subframe-of-A-MSDU-before-proc.patch | 0
.../921-ath10k_init_devices_synchronously.patch | 0
.../922-ath10k-increase-rx-buffer-size-to-2048.patch | 0
.../{ath => ath10k}/930-ath10k_add_tpt_led_trigger.patch | 0
...nd-GPIO-controlling-support-for-various-chipsets.patch | 0
.../975-ath10k-use-tpt-trigger-by-default.patch | 0
.../980-ath10k-fix-max-antenna-gain-unit.patch| 0
...0k-adjust-tx-power-reduction-for-US-regulatory-d.patch | 0
.../{ath => ath5k}/201-ath5k-WAR-for-AR71xx-PCI-bug.patch | 0
.../{ath => ath5k}/411-ath5k_allow_adhoc_and_ap.patch | 0
.../{ath => ath5k}/420-ath5k_disable_fast_cc.patch| 0
.../patches/{ath => ath5k}/430-add_ath5k_platform.patch | 0
.../patches/{ath => ath5k}/432-ath5k_add_pciids.patch | 0
.../{ath => ath5k}/440-ath5k_channel_bw_debugfs.patch | 0
.../350-ath9k_hw-reset-AHB-WMAC-interface-on-AR91xx.patch | 0
.../351-ath9k_hw-issue-external-reset-for-QCA955x.patch | 0
.../354-ath9k-force-rx_clear-when-disabling-rx.patch | 0
...rt-ath9k-interpret-requested-txpower-in-EIRP-dom.patch | 0
...k-adjust-tx-power-reduction-for-US-regulatory-do.patch | 0
.../patches/{ath => ath9k}/401-ath9k_blink_default.patch | 0
.../{ath => ath9k}/410-ath9k_allow_adhoc_and_ap.patch | 0
...450-ath9k-enabled-MFP-capability-unconditionally.patch | 0
.../patches/{ath => ath9k}/500-ath9k_eeprom_debugfs.patch | 0
.../patches/{ath => ath9k}/501-ath9k_ahb_init.patch | 0
.../{ath => ath9k}/510-ath9k_intr_mitigation_tweak.patch | 0
.../patches/{ath => ath9k}/511-ath9k_reduce_rxbuf.patch | 0
.../{ath => ath9k}/512-ath9k_channelbw_debugfs.patch | 0
.../patches/{ath => ath9k}/513-ath9k_add_pci_ids.patch| 0
.../patches/{ath => ath9k}/530-ath9k_extra_leds.patch | 0
.../{ath => ath9k}/531-ath9k_extra_platform_leds.patch| 0
.../{ath => ath9k}/540-ath9k_reduce_ani_interval.patch| 0
.../patches/{ath => ath9k}/542-ath9k_debugfs_diag.patch | 0
.../{ath => ath9k}/543-ath9k_entropy_from_adc.patch | 0
.../544-ath9k-ar933x-usb-hang-workaround.patch| 0
.../patches/{ath => ath9k}/545-ath9k_ani_ws_detect.patch | 0
.../{ath => ath9k}/547-ath9k_led_defstate_fix.patch | 0
.../{ath => ath9k}/548-ath9k_enable_gpio_chip.patch | 0
.../{ath => ath9k}/549-ath9k_enable_gpio_buttons.patch| 0
.../{ath => ath9k}/550-ath9k-disable-bands-via-dt.patch | 0
.../{ath => ath9k}/551-ath9k_ubnt_uap_plus_hsr.patch | 0
.../552-ahb_of.patch => ath9k/552-ath9k-ahb_of.patch} | 0
.../patches/{ath => ath9k}/553-ath9k_of_gpio_mask.patch | 0
49 files changed, 8 insertions(+)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/080-ath10k_thermal_config.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/300-ath10k-add-CCMP-PN-replay-protection-for-fragmented-.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/301-ath10k-drop-fragments-with-multicast-DA-for-PCIe.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/302-ath10k-drop-fragments-with-multicast-DA-for-SDIO.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/303-ath10k-drop-MPDU-which-has-discard-flag-set-by-firmw.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/304-ath10k-Fix-TKIP-Michael-MIC-verification-for-PCIe.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/305-ath10k-Validate-first-subframe-of-A-MSDU-before-proc.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/921-ath10k_init_devices_synchronously.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/922-ath10k-increase-rx-buffer-size-to-2048.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/930-ath10k_add_tpt_led_trigger.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
(100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/975-ath10k-use-tpt-trigger-by-default.patch (100%)
rename package/kernel/mac80211/patches/{ath =>
ath10k}/980-ath10k-fix-max-antenna-gain-unit.patch (100%)
rename
Re: openwrt developer / paid work
On 6/1/21 10:45 PM, Philip Prindeville wrote: This was advertised as "paid work". I'm still waiting to be paid. On Apr 1, 2021, at 5:52 AM, Embedded Devel wrote: need someone to fix an application we have, was fully functional some 10 years ago. can provide a vm, with git repo sources of app and remote access to the ap we believe its a small issue that someone could resolve quickly. possible to turn into larger project for the right person Thanks Never fall for the dumbed down matrix slaves. They never pay. „Some say they are the devil.“ said the GNU and OX agreed };-) With their revenues they do holidays and do more slavery. In the best/worst case they copy Apple. #SupportMikeRoweSoft „If the order is mediocrity: Hail Chaos which bringeth forth good fruit of repentance!“ said the illuminate of Ismeat (Hack-fleisch of Maat and Isfet) When you understand it, you are illuminated and eligible for initiation for which you need to realize that others fail to which enlightens you more about the hidden reality of mediocrity. https://www.youtube.com/watch?v=ewRjZoRtu0Y -- * _o) Follow the penguin! //\ Vincent Wiemann V_/_+49-511-582974 * ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: sysntpd: add trigger to reload server
Hi,
> > service_triggers() {
> > - local script name use_dhcp
> > + local enable_server interface name script use_dhcp
>
>
> I'd rather leave the existing variables in their original order.
>
>
OpenWrt Submission Guidelines [0] says that entries in lists should be
placed in alphabetical order.
Or should variables be declared in the order in which they are used?
[0] https://openwrt.org/submitting-patches#submission_guidelines
--
Best regards,
Alexey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: openwrt developer / paid work
This was advertised as "paid work". I'm still waiting to be paid. > On Apr 1, 2021, at 5:52 AM, Embedded Devel wrote: > > need someone to fix an application we have, was fully functional some 10 > years ago. > > can provide a vm, with git repo sources of app and remote access to the ap > > we believe its a small issue that someone could resolve quickly. > > possible to turn into larger project for the right person > > > Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: sysntpd: add trigger to reload server
Hi,
>> start_service() {
>> +. /lib/functions/network.sh
>
>
> This doesn't look right. It's usually added at the top of the file, unnested.
Which would be the wrong thing to do here. Since the init script is run
on the host system during build (to enable it), it must not source files
which are only available on target.
Sourcing the library inside the procedure is correct.
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 'config route' extension for more compact notation
Replies... > On May 26, 2021, at 12:12 AM, Vincent Wiemann > wrote: > > On 5/25/21 11:31 PM, Philip Prindeville wrote: >> Hi, >> I'm thinking about something like (taken from my home router): >> config route >> option target '103.136.220.0/22' >> option interface 'wan' >> option type 'blackhole' >> config route >> option target '103.123.116.0/22' >> option interface 'wan' >> option type 'blackhole' >> config route >> option target '130.44.212.0/22' >> option interface 'wan' >> option type 'blackhole' >> etc. Kudos to you if you spotted these as being ByteDance TikTok servers in >> China which US subscribers aren't supposed to have their traffic sent to, >> but (surprise!!!) it still is anyway. >> A nicer (more compact) notation might be: >> config route >> list target '103.123.116.0/22' >> list target '103.136.220.0/22' >> list target '130.44.212.0/22' >> option interface 'wan' >> option type 'blackhole' >> So, how about a change to config/route where, if it doesn't find 'option >> target', then it searches for 'list target' instead, and populates an ipset >> instead, using that for the match criteria? >> We could probably do something similar for config/rule in the firewall, for >> the src_ip, src_port, dst_ip, dst_port, etc. using 'list' instead of >> 'option', and ipsets to compactly match multiple addresses, ports, etc. >> But then, firewall would depend on ipset functionality being baked in. On >> x86_64, this isn't big: >> -rw-r--r-- 1 philipp philipp 823 May 10 22:15 >> bin/targets/x86/64/packages/kmod-ipt-ipset_5.4.110-1_x86_64.ipk >> -rw-r--r-- 1 philipp philipp 2036 Mar 19 16:57 >> bin/packages/x86_64/base/ipset_7.6-1_x86_64.ipk >> What do you all think? >> -Philip > > I like the idea of baking in ipset, but it would be very strange to have > a blackhole route which creates an ipset filter. > > It would avoid user confusion if we stick to the approach here: > https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_config_ipset > > Best, > > Vincent Point taken. Okay, what about adding ipset support to routes then? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: sysntpd: add trigger to reload server
Comments...
> On May 29, 2021, at 5:39 PM, Alexey Dobrovolsky
> wrote:
>
> sysntpd server becomes unavailable if the index of the bound
> interface changes. So let's add an interface trigger to reload sysntpd.
>
> This patch also adds the ability for the sysntpd script to handle
> uci interface name from configuration.
>
> Fixes: 4da60500ebd2 ("busybox: sysntpd: option to bind server to iface")
> Signed-off-by: Alexey Dobrovolsky
> ---
> package/utils/busybox/files/sysntpd | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/package/utils/busybox/files/sysntpd
> b/package/utils/busybox/files/sysntpd
> index c4c311c242..e1c9e0cdca 100755
> --- a/package/utils/busybox/files/sysntpd
> +++ b/package/utils/busybox/files/sysntpd
> @@ -56,7 +56,14 @@ start_ntpd_instance() {
> procd_set_param command "$PROG" -n -N
> if [ "$enable_server" = "1" ]; then
> procd_append_param command -l
> - [ -n "$interface" ] && procd_append_param command -I $interface
> + [ -n "$interface" ] && {
> + local ifname
> +
> + network_get_device ifname "$interface" || \
> + ifname="$interface"
> + procd_append_param command -I "$ifname"
> + procd_append_param netdev "$ifname"
> + }
> fi
> [ -x "$HOTPLUG_SCRIPT" ] && procd_append_param command -S
> "$HOTPLUG_SCRIPT"
> for peer in $server; do
> @@ -79,11 +86,12 @@ start_ntpd_instance() {
> }
>
> start_service() {
> + . /lib/functions/network.sh
This doesn't look right. It's usually added at the top of the file, unnested.
> validate_ntp_section ntp start_ntpd_instance
> }
>
> service_triggers() {
> - local script name use_dhcp
> + local enable_server interface name script use_dhcp
I'd rather leave the existing variables in their original order.
>
> script=$(readlink -f "$initscript")
> name=$(basename ${script:-$initscript})
> @@ -106,5 +114,17 @@ service_triggers() {
> fi
> }
>
> + config_get enable_server ntp enable_server
> + config_get interface ntp interface
> +
> + [ "$enable_server" = "1" ] && [ -n "$interface" ] && {
> + local ifname
> +
> + network_get_device ifname "$interface" || \
> + ifname="$interface"
> + procd_add_interface_trigger "interface.*" "$ifname" \
> + /etc/init.d/"$name" reload
> + }
> +
> procd_add_validation validate_ntp_section
> }
> --
> 2.25.1
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uim: add --uim-get-sim-state
On 24/05/21 11:21 am, Arjun wrote:
Hi,
I believe I've made the required changes. Can this be merged in now?
-
Arjun
On May 8, 2021 12:02:57 AM UTC, Arjun AK wrote:
From: Arjun
This command will show whether a SIM card has been inserted and whether
a pin is required.
Signed-off-by: Arjun
---
commands-uim.c | 26 ++
commands-uim.h | 4 +++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/commands-uim.c b/commands-uim.c
index 859da68..03166a2 100644
--- a/commands-uim.c
+++ b/commands-uim.c
@@ -54,3 +54,29 @@ cmd_uim_verify_pin2_prepare(struct qmi_dev *qmi,
struct qmi_request *req, struct
qmi_set_uim_verify_pin_request(msg, );
return QMI_CMD_REQUEST;
}
+
+
+static void cmd_uim_get_sim_state_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg)
+{
+ struct qmi_uim_get_card_status_response res;
+ qmi_parse_uim_get_card_status_response(msg, );
+
+ void * const array = blobmsg_open_array(, "sim_cards");
+if (res.data.card_status.cards_n > 0){
+ void * const table = blobmsg_open_table(, NULL);
+
+ for (int i = 0; i < res.data.card_status.cards_n;i++){
+ blobmsg_add_u32(, "state",
res.data.card_status.cards[i].card_state);
+ blobmsg_add_u32(, "upin_state",
res.data.card_status.cards[i].upin_state);
+ }
+ blobmsg_close_table(, table);
+ }
+ blobmsg_close_array(, array);
+}
+
+static enum qmi_cmd_result
+cmd_uim_get_sim_state_prepare(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg, char *arg)
+{
+ qmi_set_uim_get_card_status_request(msg);
+ return QMI_CMD_REQUEST;
+}
diff --git a/commands-uim.h b/commands-uim.h
index 86ebae4..02a49b1 100644
--- a/commands-uim.h
+++ b/commands-uim.h
@@ -21,10 +21,12 @@
#define __uqmi_uim_commands
\
__uqmi_command(uim_verify_pin1, uim-verify-pin1, required,
QMI_SERVICE_UIM), \
- __uqmi_command(uim_verify_pin2, uim-verify-pin2, required,
QMI_SERVICE_UIM) \
+ __uqmi_command(uim_verify_pin2, uim-verify-pin2, required,
QMI_SERVICE_UIM), \
+ __uqmi_command(uim_get_sim_state, uim-get-sim-state, no,
QMI_SERVICE_UIM) \
#define uim_helptext \
" --uim-verify-pin1 : Verify PIN1 (new
devices)\n" \
" --uim-verify-pin2 : Verify PIN2 (new
devices)\n" \
+ " --uim-get-sim-state: Get current SIM
state\n" \
Can someone merge this in ?
-
Arjun
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Luci->Network->Interfaces is broken
Am 31.05.2021 um 19:01 schrieb Jo-Philipp Wich: Hi, This is the reason. Long time ago, I did select the option 'Remove ipkg/opkg status data files in final images' to reduce the image size. Since such an option can be selected, LuCI cannot assume, that the file netifd.control exists. fixed. It works now (no error message), but the bad thing is, it isn't visible in LuCI, which wireless adapter's are attached to the bridge and it needs some clicks to see which interfaces (wired ports) are attached to the bridge. I don't like this solution in LuCI. Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Interface names when putting 802.1q VLAN on top of bonding configuration
Hi, > One more question, now I'm trying to put a bridge on top of each of these > vlan* interfaces so that I can map those to a few physical interfaces. I also > need several vlans to map to one of the interfaces (tagged).. not sure how to > do that yet either. Any suggestions with this config? When I apply it, I lose > network access. If you move an interface into a bridge (e.g. vlan10 into bv10) then you need to put the IP addresses (172.20.32.250/255.255.255.0 for vlan10) onto the bridge and remove it from vlan10. There is also no need to retain the `config interface vlan10` section then anymore. Netdevs used as bridge ports cannot be used standalone anymore. Your config should look like that: -- 8< -- config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdb9:bf48:0362::/48' config interface lanxge option proto 'bonding' option auto '1' option bonding_policy '802.3ad' option link_monitoring 'mii' option slaves 'eth4 eth5' option lacp_rate 'fast' option miimon '100' option use_carrier 1 option xmit_hash_policy 'layer3+4' option force_link '1' option ipaddr 127.0.0.2 config device option type 8021q option ifname bonding-lanxge option vid 10 option name vlan10 config device option type 8021q option ifname bonding-lanxge option vid 20 option name vlan20 config device option type 8021q option ifname bonding-lanxge option vid 21 option name vlan21 config device option type 8021q option ifname bonding-lanxge option vid 30 option name vlan30 config interface 'wan' option ifname 'eth0.0' option proto 'dhcp' config interface bv10 option type 'bridge' option ifname vlan10 option proto static option ipaddr 172.20.32.250 option netmask 255.255.255.0 config interface bv20 option type 'bridge' option ifname vlan20 option proto static option ipaddr 172.20.34.2 option netmask 255.255.255.128 config interface bv21 option type 'bridge' option ifname vlan21 option proto static option ipaddr 172.20.35.3 option netmask 255.255.255.240 config interface bv30 option type 'bridge' option ifname vlan30 option proto static option ipaddr 172.20.34.130 option netmask 255.255.255.128 -- >8 -- Since legacy bridge declarations (through option type bridge in config interface) are being phased out, your config ideally should look like that (requires current master or OpenWrt 21.02 branch): -- 8< -- config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdb9:bf48:0362::/48' config interface lanxge option proto 'bonding' option auto '1' option bonding_policy '802.3ad' option link_monitoring 'mii' option slaves 'eth4 eth5' option lacp_rate 'fast' option miimon '100' option use_carrier 1 option xmit_hash_policy 'layer3+4' option force_link '1' option ipaddr 127.0.0.2 config device option type 8021q option ifname bonding-lanxge option vid 10 option name vlan10 config device option type 8021q option ifname bonding-lanxge option vid 20 option name vlan20 config device option type 8021q option ifname bonding-lanxge option vid 21 option name vlan21 config device option type 8021q option ifname bonding-lanxge option vid 30 option name vlan30 config device option type bridge option name bv10 list ports vlan10 config device option type bridge option name bv20 list ports vlan20 config device option type bridge option name bv21 list ports vlan21 config device option type bridge option name bv30 list ports vlan30 config interface 'wan' option ifname 'eth0.0' option proto 'dhcp' config interface bv10 option device bv10 option proto static option ipaddr 172.20.32.250 option netmask 255.255.255.0 config interface bv20 option device bv20 option proto static option ipaddr 172.20.34.2 option netmask 255.255.255.128 config interface bv21 option device bv21 option proto static option ipaddr 172.20.35.3 option netmask 255.255.255.240 config interface bv30 option device bv30 option proto
Re: [PATCH] base-files: simplify setting device MAC
Hi,
> Ideally you should be able to use jsonfilter too but I don't know how to
> deal with "-" in a property name.
Use bracket notation.
> Following doesn't work for me:
>
> ubus call network.device status '{ "name": "br-lan" }' | jsonfilter -e
> "$.bridge-members"
ubus call network.device status '{ "name": "br-lan" }' | jsonfilter -e
> "$['bridge-members']"
~ Jo
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Linksys E8450 - odd networking
On 6/1/21 6:04 PM, Rafał Miłecki wrote: On 01.06.2021 09:21, Embedded Devel wrote: something is odd with Linksys E8450 on master as of last night eth0 has no ip address, wan has a dhcp address as the gateway, no client behind it connected to the lan can ping 8.8.8.8, the router itself can ping 8.8.8.8 , it worked fine before the "double" luci update the configs prompts. i need ideas. could it be just a firewall forwarding rule ? eth0 should NOT have IP address, it's Ethernet interface connected to the swtich (and so - indirectly - all its ports). wan has 192.168.10.123 assigned (using DCHP I believe) - is that really your gateway IP? Isn't your gateway 192.168.10.1 by any chance? What's your "ip route" output? yes it shows default via 192.168.10.1 dev wan proto static src 192.168.10.123 172.25.0.0/16 dev ztppix7qfq proto kernel scope link src 172.25.182.185 192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1 192.168.10.0/24 dev wan proto kernel scope link src 192.168.10.123 still cant pass traffic from the lan side out... and br-lan is connected to lan firewall. Is your "br-lan" assigned to the firewall zone? root@E8-9F-80-62-6F-F0:~# ifconfig br-lan Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::ea9f:80ff:fe62:6ff0/64 Scope:Link inet6 addr: fda6:309:a895::1/60 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13267 errors:0 dropped:0 overruns:0 frame:0 TX packets:88876 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1294113 (1.2 MiB) TX bytes:4856343 (4.6 MiB) eth0 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 inet6 addr: fe80::ea9f:80ff:fe62:6ff0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1504 Metric:1 RX packets:91700 errors:0 dropped:0 overruns:0 frame:0 TX packets:236577 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:26829752 (25.5 MiB) TX bytes:31170503 (29.7 MiB) Interrupt:36 lan1 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lan2 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13274 errors:0 dropped:0 overruns:0 frame:0 TX packets:88872 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1294477 (1.2 MiB) TX bytes:4856151 (4.6 MiB) lan3 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lan4 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:93856 errors:0 dropped:0 overruns:0 frame:0 TX packets:93856 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16987663 (16.2 MiB) TX bytes:16987663 (16.2 MiB) wan Link encap:Ethernet HWaddr E8:9F:80:62:6F:EF inet addr:192.168.10.123 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::ea9f:80ff:fe62:6fef/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:78426 errors:0 dropped:0 overruns:0 frame:0 TX packets:147404 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:23884675 (22.7 MiB) TX bytes:23116828 (22.0 MiB) ztppix7qfq Link encap:Ethernet HWaddr AE:69:2B:78:B5:F6 inet addr:172.25.182.185 Bcast:172.25.255.255 Mask:255.255.0.0 inet6 addr: fcf9:c824:3237:2e64:2b8c::1/40 Scope:Global inet6 addr: fde5:cd7a:9e1c:55e:ac99:9337:2e64:2b8c/88 Scope:Global inet6 addr: fe80::4403:5dff:fe1b:c35e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:2800 Metric:1 RX packets:5994 errors:0 dropped:0 overruns:0 frame:0 TX packets:6350 errors:0
Re: Linksys E8450 - odd networking
On 01.06.2021 09:21, Embedded Devel wrote: something is odd with Linksys E8450 on master as of last night eth0 has no ip address, wan has a dhcp address as the gateway, no client behind it connected to the lan can ping 8.8.8.8, the router itself can ping 8.8.8.8 , it worked fine before the "double" luci update the configs prompts. i need ideas. could it be just a firewall forwarding rule ? eth0 should NOT have IP address, it's Ethernet interface connected to the swtich (and so - indirectly - all its ports). wan has 192.168.10.123 assigned (using DCHP I believe) - is that really your gateway IP? Isn't your gateway 192.168.10.1 by any chance? What's your "ip route" output? Is your "br-lan" assigned to the firewall zone? root@E8-9F-80-62-6F-F0:~# ifconfig br-lan Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::ea9f:80ff:fe62:6ff0/64 Scope:Link inet6 addr: fda6:309:a895::1/60 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13267 errors:0 dropped:0 overruns:0 frame:0 TX packets:88876 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1294113 (1.2 MiB) TX bytes:4856343 (4.6 MiB) eth0 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 inet6 addr: fe80::ea9f:80ff:fe62:6ff0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1504 Metric:1 RX packets:91700 errors:0 dropped:0 overruns:0 frame:0 TX packets:236577 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:26829752 (25.5 MiB) TX bytes:31170503 (29.7 MiB) Interrupt:36 lan1 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lan2 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13274 errors:0 dropped:0 overruns:0 frame:0 TX packets:88872 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1294477 (1.2 MiB) TX bytes:4856151 (4.6 MiB) lan3 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lan4 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:93856 errors:0 dropped:0 overruns:0 frame:0 TX packets:93856 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16987663 (16.2 MiB) TX bytes:16987663 (16.2 MiB) wan Link encap:Ethernet HWaddr E8:9F:80:62:6F:EF inet addr:192.168.10.123 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::ea9f:80ff:fe62:6fef/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:78426 errors:0 dropped:0 overruns:0 frame:0 TX packets:147404 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:23884675 (22.7 MiB) TX bytes:23116828 (22.0 MiB) ztppix7qfq Link encap:Ethernet HWaddr AE:69:2B:78:B5:F6 inet addr:172.25.182.185 Bcast:172.25.255.255 Mask:255.255.0.0 inet6 addr: fcf9:c824:3237:2e64:2b8c::1/40 Scope:Global inet6 addr: fde5:cd7a:9e1c:55e:ac99:9337:2e64:2b8c/88 Scope:Global inet6 addr: fe80::4403:5dff:fe1b:c35e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:2800 Metric:1 RX packets:5994 errors:0 dropped:0 overruns:0 frame:0 TX packets:6350 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:545025 (532.2 KiB) TX bytes:2516950 (2.3 MiB) config interface 'loopback' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' option device 'lo' config globals 'globals' option ula_prefix 'fda6:0309:a895::/48' config interface 'lan' option proto 'static' option ipaddr '192.168.1.1'
Linksys E8450 - odd networking
something is odd with Linksys E8450 on master as of last night eth0 has no ip address, wan has a dhcp address as the gateway, no client behind it connected to the lan can ping 8.8.8.8, the router itself can ping 8.8.8.8 , it worked fine before the "double" luci update the configs prompts. i need ideas. could it be just a firewall forwarding rule ? root@E8-9F-80-62-6F-F0:~# ifconfig br-lan Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::ea9f:80ff:fe62:6ff0/64 Scope:Link inet6 addr: fda6:309:a895::1/60 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13267 errors:0 dropped:0 overruns:0 frame:0 TX packets:88876 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1294113 (1.2 MiB) TX bytes:4856343 (4.6 MiB) eth0 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 inet6 addr: fe80::ea9f:80ff:fe62:6ff0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1504 Metric:1 RX packets:91700 errors:0 dropped:0 overruns:0 frame:0 TX packets:236577 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:26829752 (25.5 MiB) TX bytes:31170503 (29.7 MiB) Interrupt:36 lan1 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lan2 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13274 errors:0 dropped:0 overruns:0 frame:0 TX packets:88872 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1294477 (1.2 MiB) TX bytes:4856151 (4.6 MiB) lan3 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lan4 Link encap:Ethernet HWaddr E8:9F:80:62:6F:F0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:93856 errors:0 dropped:0 overruns:0 frame:0 TX packets:93856 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16987663 (16.2 MiB) TX bytes:16987663 (16.2 MiB) wan Link encap:Ethernet HWaddr E8:9F:80:62:6F:EF inet addr:192.168.10.123 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::ea9f:80ff:fe62:6fef/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:78426 errors:0 dropped:0 overruns:0 frame:0 TX packets:147404 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:23884675 (22.7 MiB) TX bytes:23116828 (22.0 MiB) ztppix7qfq Link encap:Ethernet HWaddr AE:69:2B:78:B5:F6 inet addr:172.25.182.185 Bcast:172.25.255.255 Mask:255.255.0.0 inet6 addr: fcf9:c824:3237:2e64:2b8c::1/40 Scope:Global inet6 addr: fde5:cd7a:9e1c:55e:ac99:9337:2e64:2b8c/88 Scope:Global inet6 addr: fe80::4403:5dff:fe1b:c35e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:2800 Metric:1 RX packets:5994 errors:0 dropped:0 overruns:0 frame:0 TX packets:6350 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:545025 (532.2 KiB) TX bytes:2516950 (2.3 MiB) config interface 'loopback' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' option device 'lo' config globals 'globals' option ula_prefix 'fda6:0309:a895::/48' config interface 'lan' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' option device 'br-lan' config interface 'wan' option proto 'dhcp' option device 'wan' config interface 'wan6' option proto 'dhcpv6' option device 'wan' config device 'device1' option name 'br-lan' list ports 'lan1' list ports 'lan2' list ports 'lan3' list ports 'lan4' option type 'bridge' ___
TP-Link AD7200: WAN port is swapped with last LAN port
Hello again, On OpenWrt 21.02-rc2 (and probably earlier), the WAN port is treated as a LAN port and LAN port 4 is treated as the WAN port on the TP-Link AD7200. (Actually, all the ports show up in LuCI in reverse order from their labels on the case.) How can I fix that? -Alex ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
