Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621
Hi.
i check the code again. found xmit_more can cause tx timeout. you can
reference this.
https://www.mail-archive.com/netdev@vger.kernel.org/msg123334.html
so the patch should be like this. edit mtk_eth_soc.c
tx_num = fe_cal_txd_req(skb);
if (unlikely(fe_empty_txd(ring) <= tx_num)) {
+if (skb->xmit_more)
+fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
netif_stop_queue(dev);
netif_err(priv, tx_queued, dev,
"Tx Ring full when queue awake!\n");
but i am not sure. maybe the pause frame cause the problem.
2017-08-25 22:25 GMT+08:00 Kristian Evensen :
> Hi all,
>
> On Sun, Aug 20, 2017 at 12:30 AM, John Crispin wrote:
>> correct, in my testing i have been ... with 200 parallel flows ... on
>> MT7623, we'll have to find out what mt7621 can achieve ... this is all using
>> hwnat ...
>> 1) tcp - at 50 byte frames i am able to pass 720 MBit which is > 1M FPS
>> 2) udp - at 128 byte frames i am able to pass ~450k FPS at ~10% packet loss
>> .. at near wirespeed
>
> I have spent the last two days looking into this. My testing was based
> on LEDE master as of yesterday morning and my initial test setup was
> the following:
>
> Server (Intel NUC) <-> Gbit Switch <-> ZBT 2926 <-> Client
>
> The switch was tested and confirmed working at gigabit speeds. I used
> iperf for my tests, with a payload of 100B and configured port
> forwarding of UDP port 1203 from ZBT to client. I then ran the
> following command on the NUC in a loop:
>
> iperf -u -c 10.1.2.63 -t 3600 -d -p 1203 -l 100B -b 1000M
>
> I left the test running over night (around 16 hours of pushing data),
> but no error had been triggered as of this morning. Using bwm-ng, I
> saw that the NUC was able to push around 40 Mbit/s, which, based on
> earlier tests I have done where I have used the NUC as traffic
> generator, seemed a bit low. I don't know if it is relevant, but when
> capturing traffic (on both NUC and client) I saw pause packets quite
> frequently.
>
> Since this tests did not yield any result, and throughput was low, I
> looked at some of the setups where I have seen this error. In all
> setups, there is always something placed in front of the 2926 (a
> router, switch, ...). I therefore modified my test setup to be as
> follows:
>
> Server (Intel NUC) <-> Gbit Switch <-> ZBT 2926 #1 <-> ZBT 2926 #2 <-> Client
>
> I forwarded port 1203 on the new ZBT router and repeated the
> experiment. Using this setup, the NUC pushed about 260Mbit/s and I am
> reliably able to trigger the error within ~1000 seconds. The error is
> always seen on ZBT #1, and sometimes on ZBT #2. If I see the error on
> #2 it is always at a later time than #1, so it seems that the two
> routers somehow affect each other. When looking at the RX bandwidth on
> the client (using bwm-ng), I see that it is very bursty. I receive
> data at about 32Mbit/s, then no data for a while, then back to around
> 32 Mbit/s, and so on, until the error is triggered and switch (TX) on
> the router(s) die. Pause frames are also seen on both server and
> client in this experiment.
>
> After having found a way to reliably trigger the issue, I tested the
> patch provided by Mingyu. With this patch, the error is triggered much
> faster, usually after around 300 seconds.
>
> Mingyu, do you have any other ideas on what could be wrong or how to fix this?
>
> John, would it be possible to get access to your staged commit, so
> that I can repeat the test using your new code?
>
> Thanks for all the help,
> Kristian
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] samba36: Remove syslog and load printers lines.
printer support is removed using 200-remove_printer_support.patch. the syslog parameter requires samba to be compiled with --with-syslog. Currently samba does not log to syslog and probably has not for a long time. Signed-off-by: Rosen Penev --- package/network/services/samba36/files/smb.conf.template | 2 -- 1 file changed, 2 deletions(-) diff --git a/package/network/services/samba36/files/smb.conf.template b/package/network/services/samba36/files/smb.conf.template index 47ec11699d..fc72f9258c 100644 --- a/package/network/services/samba36/files/smb.conf.template +++ b/package/network/services/samba36/files/smb.conf.template @@ -9,7 +9,6 @@ deadtime = 30 enable core files = no invalid users = root - load printers = no local master = no map to guest = Bad User max protocol = SMB2 @@ -18,5 +17,4 @@ passdb backend = smbpasswd security = user smb passwd file = /etc/samba/smbpasswd - syslog = 2 use sendfile = yes -- 2.13.5 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] firewall issue
Citeren e9hack : Hi, my firewall configuration set the default forward policy to reject and wan forward to drop. iptable -L -v Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes targetprot opt inout source destination 330K 276M forwarding_rule all -- any any anywhere anywhere /* !fw3: user chain for forwarding */ 325K 276M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED /* !fw3 */ 3035 200K zone_lan_forwardall -- br-lanany anywhere anywhere /* !fw3 */ 483 21304 zone_wan_forwardall -- pppoe-wan any anywhere anywhere /* !fw3 */ 167 10623 zone_guest1_forward all -- br-guest1 any anywhere anywhere /* !fw3 */ ... 34 2040 reject all -- any any anywhere anywhere /* !fw3 */ Chain zone_wan_forward (1 references) pkts bytes targetprot opt in out source destination 483 21304 forwarding_wan_rule all -- any any anywhere anywhere /* !fw3: user chain for forwarding */ 483 21304 ACCEPT all -- any any anywhere anywhere ctstate DNAT /* !fw3: Accept port forwards */ 0 0 zone_wan_dest_DROP all -- any any anywhere anywhere /* !fw3 */ Chain zone_wan_dest_DROP (9 references) pkts bytes targetprot opt in out source destination 0 0 DROPall -- any pppoe-wan anywhere anywhere /* !fw3 */ I expect, that the last line in zone_wan_forward is a drop rule with 'out' set to 'any' and not 'out' set to 'pppoe-wan'. The same occurs for ipv6. See https://bugs.lede-project.org/index.php?do=details&task_id=920. Apparently this is intentional, but I agree with you this is unexpected. I ended up reverting https://git.lede-project.org/?p=project/firewall3.git;a=commit;h=91953d6a6e90df988f442f53097bd208784, which makes the default policy source bound again (instead of destination bound as it is now). Since the traffic enters the forward chains source bound, this will match all traffic that makes it to the last rule in the forward chains. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] firewall issue
Hi, my firewall configuration set the default forward policy to reject and wan forward to drop. iptable -L -v Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes targetprot opt inout source destination 330K 276M forwarding_rule all -- any any anywhere anywhere /* !fw3: user chain for forwarding */ 325K 276M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED /* !fw3 */ 3035 200K zone_lan_forwardall -- br-lanany anywhere anywhere /* !fw3 */ 483 21304 zone_wan_forwardall -- pppoe-wan any anywhere anywhere /* !fw3 */ 167 10623 zone_guest1_forward all -- br-guest1 any anywhere anywhere /* !fw3 */ ... 34 2040 reject all -- any any anywhere anywhere /* !fw3 */ Chain zone_wan_forward (1 references) pkts bytes targetprot opt in out source destination 483 21304 forwarding_wan_rule all -- any any anywhere anywhere /* !fw3: user chain for forwarding */ 483 21304 ACCEPT all -- any any anywhere anywhere ctstate DNAT /* !fw3: Accept port forwards */ 0 0 zone_wan_dest_DROP all -- any any anywhere anywhere /* !fw3 */ Chain zone_wan_dest_DROP (9 references) pkts bytes targetprot opt in out source destination 0 0 DROPall -- any pppoe-wan anywhere anywhere /* !fw3 */ I expect, that the last line in zone_wan_forward is a drop rule with 'out' set to 'any' and not 'out' set to 'pppoe-wan'. The same occurs for ipv6. Regards, Hartmut ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LF Developer's Work
I am not necessarily looking for work at the moment, but the mt76 is one of my targets for the bufferbloat work and I have some familiarity with it. felix is your man, tho. Alan Gregory writes: > We're an ISP looking for a developer to work on fix/improve wireless support > for devices we are planning to use on our network. > Specificaly https://github.com/openwrt/mt76. Contact if you have interest. > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] IPv6 link locals, vlans and bridging
On 25/08/17 15:35, Matthew McClintock wrote: > On Fri, Aug 25, 2017 at 8:16 AM, Kevin Darbyshire-Bryant > wrote: >> Here's a 'fun' one that I'm trying to work who is doing what incorrectly. > Just a random bit of info, I've had dnsmasq issues with bridges until > I disabled these: > > net.bridge.bridge-nf-call-ip6tables=0 > net.bridge.bridge-nf-call-iptables=0 > net.bridge.bridge-nf-call-arptables=0 That's the default in LEDE it seems. > > Not sure this is your issue, but you should run tcpdump on the > interfaces and see what's going on. I've some other things I want to check, but I agree tcpdump should be most instructive :-) > > -M > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] IPv6 link locals, vlans and bridging
On Fri, Aug 25, 2017 at 8:16 AM, Kevin Darbyshire-Bryant wrote: > Here's a 'fun' one that I'm trying to work who is doing what incorrectly. > > For 'reasons' I have a number of tagged vlan ethernet interfaces. I also > have a similar number of wifi interfaces. These vlan ethernet interfaces > and wifi interfaces are bridged together in pairs. > > The wifi interfaces have non-unique link local addresses that appear auto > assigned: > > wlan0 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:4E > inet6 addr: fe80::62e3:27ff:feaf:9e4e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:43577 errors:0 dropped:0 overruns:0 frame:0 > TX packets:82723 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:15588069 (14.8 MiB) TX bytes:97978594 (93.4 MiB) > > wlan0-1 Link encap:Ethernet HWaddr 62:E3:27:AF:9E:4E > inet6 addr: fe80::60e3:27ff:feaf:9e4e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:15106 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:7953093 (7.5 MiB) > > wlan1 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:4F > inet6 addr: fe80::62e3:27ff:feaf:9e4f/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:90 errors:0 dropped:0 overruns:0 frame:0 > TX packets:16399 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:12498 (12.2 KiB) TX bytes:8373520 (7.9 MiB) > > wlan1-1 Link encap:Ethernet HWaddr 62:E3:27:AF:9E:4F > inet6 addr: fe80::60e3:27ff:feaf:9e4f/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:15748 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:8266015 (7.8 MiB) > > The ethernet vlans mostly do not have link local addresses except eth1.3 > which is the main untagged and hence main interface (this also has a global > address) > > eth1.10 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:39845 errors:0 dropped:0 overruns:0 frame:0 > TX packets:69474 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:5739889 (5.4 MiB) TX bytes:65964032 (62.9 MiB) > > eth1.15 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3 errors:0 dropped:0 overruns:0 frame:0 > TX packets:15786 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:319 (319.0 B) TX bytes:7995298 (7.6 MiB) > > eth1.20 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:29258 errors:0 dropped:0 overruns:0 frame:0 > TX packets:50498 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:2799288 (2.6 MiB) TX bytes:36024938 (34.3 MiB) > > eth1.25 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3 errors:0 dropped:0 overruns:0 frame:0 > TX packets:15782 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:319 (319.0 B) TX bytes:7994866 (7.6 MiB) > > eth1.3Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 > inet addr:192.250.219.1 Bcast:192.168.250.255 Mask:255.255.255.0 > inet6 addr: fe80::62e3:27ff:feaf:9e50/64 Scope:Link > inet6 addr: 2a02:c7f:1250:1250::da2b:da2b/64 Scope:Global > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:8254319 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5455240 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:12101826609 (11.2 GiB) TX bytes:325616404 (310.5 MiB) > > So far, possibly so good. The 'fun' starts with the bridge interfaces: > > br-wifi5_guest Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 > inet addr:192.168.25.1 Bcast:192.168.25.255 Mask:255.255.255.0 > inet6 addr: 2a02:c7f:1234:bf25::da2b:da2b/64 Scope:Global > inet6 addr: fe80::62e3:27ff:feaf:9e50/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3 errors:0 dropped:0 overruns:0 frame:0 > TX packets:15782 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:319 (319.0 B) TX bytes:7994866 (7.6 M
Re: [LEDE-DEV] Transmit timeouts with mtk_eth_soc and MT7621
Hi all, On Sun, Aug 20, 2017 at 12:30 AM, John Crispin wrote: > correct, in my testing i have been ... with 200 parallel flows ... on > MT7623, we'll have to find out what mt7621 can achieve ... this is all using > hwnat ... > 1) tcp - at 50 byte frames i am able to pass 720 MBit which is > 1M FPS > 2) udp - at 128 byte frames i am able to pass ~450k FPS at ~10% packet loss > .. at near wirespeed I have spent the last two days looking into this. My testing was based on LEDE master as of yesterday morning and my initial test setup was the following: Server (Intel NUC) <-> Gbit Switch <-> ZBT 2926 <-> Client The switch was tested and confirmed working at gigabit speeds. I used iperf for my tests, with a payload of 100B and configured port forwarding of UDP port 1203 from ZBT to client. I then ran the following command on the NUC in a loop: iperf -u -c 10.1.2.63 -t 3600 -d -p 1203 -l 100B -b 1000M I left the test running over night (around 16 hours of pushing data), but no error had been triggered as of this morning. Using bwm-ng, I saw that the NUC was able to push around 40 Mbit/s, which, based on earlier tests I have done where I have used the NUC as traffic generator, seemed a bit low. I don't know if it is relevant, but when capturing traffic (on both NUC and client) I saw pause packets quite frequently. Since this tests did not yield any result, and throughput was low, I looked at some of the setups where I have seen this error. In all setups, there is always something placed in front of the 2926 (a router, switch, ...). I therefore modified my test setup to be as follows: Server (Intel NUC) <-> Gbit Switch <-> ZBT 2926 #1 <-> ZBT 2926 #2 <-> Client I forwarded port 1203 on the new ZBT router and repeated the experiment. Using this setup, the NUC pushed about 260Mbit/s and I am reliably able to trigger the error within ~1000 seconds. The error is always seen on ZBT #1, and sometimes on ZBT #2. If I see the error on #2 it is always at a later time than #1, so it seems that the two routers somehow affect each other. When looking at the RX bandwidth on the client (using bwm-ng), I see that it is very bursty. I receive data at about 32Mbit/s, then no data for a while, then back to around 32 Mbit/s, and so on, until the error is triggered and switch (TX) on the router(s) die. Pause frames are also seen on both server and client in this experiment. After having found a way to reliably trigger the issue, I tested the patch provided by Mingyu. With this patch, the error is triggered much faster, usually after around 300 seconds. Mingyu, do you have any other ideas on what could be wrong or how to fix this? John, would it be possible to get access to your staged commit, so that I can repeat the test using your new code? Thanks for all the help, Kristian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] IPv6 link locals, vlans and bridging
On 25-08-17, Kevin Darbyshire-Bryant wrote: > I have dnsmasq listening on the bridge interfaces - it's happy doing so and > says it's listening on the link local address (effectively the same address > many times) all ok. It also listens on the global address. If I configure > dns clients to use the link local address for DNS service I get no > responses. If I configure dns clients to use the global address relevant > for each bridge then dns responses are fine. Are you sure it's related to your complex bridging setup? Maybe dnsmasq just fails to answer on link-local IPv6 addresses in all cases? This was already reported before: https://bugs.lede-project.org/index.php?do=details&task_id=677 Baptiste signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] IPv6 link locals, vlans and bridging
Here's a 'fun' one that I'm trying to work who is doing what incorrectly. For 'reasons' I have a number of tagged vlan ethernet interfaces. I also have a similar number of wifi interfaces. These vlan ethernet interfaces and wifi interfaces are bridged together in pairs. The wifi interfaces have non-unique link local addresses that appear auto assigned: wlan0 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:4E inet6 addr: fe80::62e3:27ff:feaf:9e4e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:43577 errors:0 dropped:0 overruns:0 frame:0 TX packets:82723 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15588069 (14.8 MiB) TX bytes:97978594 (93.4 MiB) wlan0-1 Link encap:Ethernet HWaddr 62:E3:27:AF:9E:4E inet6 addr: fe80::60e3:27ff:feaf:9e4e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:15106 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:7953093 (7.5 MiB) wlan1 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:4F inet6 addr: fe80::62e3:27ff:feaf:9e4f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:90 errors:0 dropped:0 overruns:0 frame:0 TX packets:16399 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12498 (12.2 KiB) TX bytes:8373520 (7.9 MiB) wlan1-1 Link encap:Ethernet HWaddr 62:E3:27:AF:9E:4F inet6 addr: fe80::60e3:27ff:feaf:9e4f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:15748 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:8266015 (7.8 MiB) The ethernet vlans mostly do not have link local addresses except eth1.3 which is the main untagged and hence main interface (this also has a global address) eth1.10 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39845 errors:0 dropped:0 overruns:0 frame:0 TX packets:69474 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5739889 (5.4 MiB) TX bytes:65964032 (62.9 MiB) eth1.15 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:15786 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:319 (319.0 B) TX bytes:7995298 (7.6 MiB) eth1.20 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:29258 errors:0 dropped:0 overruns:0 frame:0 TX packets:50498 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2799288 (2.6 MiB) TX bytes:36024938 (34.3 MiB) eth1.25 Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:15782 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:319 (319.0 B) TX bytes:7994866 (7.6 MiB) eth1.3Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 inet addr:192.250.219.1 Bcast:192.168.250.255 Mask:255.255.255.0 inet6 addr: fe80::62e3:27ff:feaf:9e50/64 Scope:Link inet6 addr: 2a02:c7f:1250:1250::da2b:da2b/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8254319 errors:0 dropped:0 overruns:0 frame:0 TX packets:5455240 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12101826609 (11.2 GiB) TX bytes:325616404 (310.5 MiB) So far, possibly so good. The 'fun' starts with the bridge interfaces: br-wifi5_guest Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 inet addr:192.168.25.1 Bcast:192.168.25.255 Mask:255.255.255.0 inet6 addr: 2a02:c7f:1234:bf25::da2b:da2b/64 Scope:Global inet6 addr: fe80::62e3:27ff:feaf:9e50/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:15782 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:319 (319.0 B) TX bytes:7994866 (7.6 MiB) br-wifi5_priv Link encap:Ethernet HWaddr 60:E3:27:AF:9E:50 inet addr:192.168.20.1 Bcast:192.168.20.255 Mask:255.255.255.0 inet6 addr: 2a02:c7f:1234:bf20::da2b:da2b/64 Scope:Global inet6 addr
Re: [LEDE-DEV] [PATCH] brcm47xx: include wpad-mini only for devices with WiFi supported
On 2017-08-25 13:16, Rafał Miłecki wrote: > From: Rafał Miłecki > > This saves some flash space for the others. > > Signed-off-by: Rafał Miłecki You could just add -wpad-mini to DEVICE_PACKAGES for devices that don't need it. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] brcm47xx: include wpad-mini only for devices with WiFi supported
From: Rafał Miłecki This saves some flash space for the others. Signed-off-by: Rafał Miłecki --- target/linux/brcm47xx/Makefile | 2 +- target/linux/brcm47xx/image/Makefile | 141 ++- 2 files changed, 73 insertions(+), 70 deletions(-) diff --git a/target/linux/brcm47xx/Makefile b/target/linux/brcm47xx/Makefile index 73b7bff4f3..992d2d698b 100644 --- a/target/linux/brcm47xx/Makefile +++ b/target/linux/brcm47xx/Makefile @@ -21,7 +21,7 @@ endef include $(INCLUDE_DIR)/target.mk -DEFAULT_PACKAGES += swconfig wpad-mini nvram otrx \ +DEFAULT_PACKAGES += swconfig nvram otrx \ kmod-leds-gpio kmod-gpio-button-hotplug \ kmod-ledtrig-default-on kmod-ledtrig-timer kmod-ledtrig-netdev diff --git a/target/linux/brcm47xx/image/Makefile b/target/linux/brcm47xx/image/Makefile index 8c681ac345..4501bcaf38 100644 --- a/target/linux/brcm47xx/image/Makefile +++ b/target/linux/brcm47xx/image/Makefile @@ -7,6 +7,9 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk +IEEE8021X := wpad-mini +B43 := $(IEEE8021X) kmod-b43 +B43LEGACY := $(IEEE8021X) kmod-b43legacy USB1_PACKAGES := kmod-usb-ohci USB2_PACKAGES := $(USB1_PACKAGES) kmod-usb2 @@ -191,7 +194,7 @@ ifeq ($(SUBTARGET),generic) # BCM4705 with tg3 define Device/linksys-wrt300n-v1.1 DEVICE_TITLE := Linksys WRT300N v1.1 - DEVICE_PACKAGES := kmod-tg3 kmod-b43 + DEVICE_PACKAGES := kmod-tg3 $(B43) $(Device/linksys) DEVICE_ID := EWC2 VERSION := 1.51.2 @@ -200,7 +203,7 @@ TARGET_DEVICES += linksys-wrt300n-v1.1 define Device/linksys-wrt310n-v1 DEVICE_TITLE := Linksys WRT310N v1 - DEVICE_PACKAGES := kmod-tg3 kmod-b43 + DEVICE_PACKAGES := kmod-tg3 $(B43) $(Device/linksys) DEVICE_ID := 310N VERSION := 1.0.10 @@ -209,7 +212,7 @@ TARGET_DEVICES += linksys-wrt310n-v1 define Device/linksys-wrt350n-v1 DEVICE_TITLE := Linksys WRT350N v1 - DEVICE_PACKAGES := kmod-tg3 kmod-b43 $(USB2_PACKAGES) + DEVICE_PACKAGES := kmod-tg3 $(B43) $(USB2_PACKAGES) $(Device/linksys) DEVICE_ID := EWCG VERSION := 1.04.1 @@ -218,7 +221,7 @@ TARGET_DEVICES += linksys-wrt350n-v1 define Device/linksys-wrt610n-v1 DEVICE_TITLE := Linksys WRT610N v1 - DEVICE_PACKAGES := kmod-tg3 kmod-b43 $(USB2_PACKAGES) + DEVICE_PACKAGES := kmod-tg3 $(B43) $(USB2_PACKAGES) $(Device/linksys) DEVICE_ID := 610N VERSION := 1.0.1 @@ -228,7 +231,7 @@ TARGET_DEVICES += linksys-wrt610n-v1 # BCMA SoC with SSB WiFi define Device/linksys-wrt610n-v2 DEVICE_TITLE := Linksys WRT610N v2 - DEVICE_PACKAGES := kmod-bgmac kmod-b43 $(USB2_PACKAGES) + DEVICE_PACKAGES := kmod-bgmac $(B43) $(USB2_PACKAGES) $(Device/linksys) DEVICE_ID := 610N VERSION := 2.0.0 @@ -237,7 +240,7 @@ TARGET_DEVICES += linksys-wrt610n-v2 define Device/linksys-e3000-v1 DEVICE_TITLE := Linksys E3000 v1 - DEVICE_PACKAGES := kmod-bgmac kmod-b43 $(USB2_PACKAGES) + DEVICE_PACKAGES := kmod-bgmac $(B43) $(USB2_PACKAGES) $(Device/linksys) DEVICE_ID := 61XN VERSION := 1.0.3 @@ -260,7 +263,7 @@ ifeq ($(SUBTARGET),legacy) define Device/asus-wl-300g DEVICE_TITLE := Asus WL-300g - DEVICE_PACKAGES := kmod-b43 kmod-b43legacy + DEVICE_PACKAGES := $(B43) $(B43LEGACY) $(Device/asus) PRODUCTID := "WL300g " endef @@ -268,7 +271,7 @@ TARGET_DEVICES += asus-wl-300g define Device/asus-wl-320gp DEVICE_TITLE := Asus WL-320gP - DEVICE_PACKAGES := kmod-b43 + DEVICE_PACKAGES := $(B43) $(Device/asus) PRODUCTID := "WL320gP " endef @@ -276,7 +279,7 @@ TARGET_DEVICES += asus-wl-320gp define Device/asus-wl-330ge DEVICE_TITLE := Asus WL-330gE - DEVICE_PACKAGES := kmod-b43 + DEVICE_PACKAGES := $(B43) $(Device/asus) PRODUCTID := "WL-330gE" endef @@ -284,7 +287,7 @@ TARGET_DEVICES += asus-wl-330ge define Device/asus-wl-500gp-v1 DEVICE_TITLE := Asus WL-500gP v1 - DEVICE_PACKAGES := kmod-b43 $(USB2_PACKAGES) + DEVICE_PACKAGES := $(B43) $(USB2_PACKAGES) $(Device/asus) PRODUCTID := "WL500gp " endef @@ -292,7 +295,7 @@ TARGET_DEVICES += asus-wl-500gp-v1 define Device/asus-wl-500gp-v2 DEVICE_TITLE := Asus WL-500gP v2 - DEVICE_PACKAGES := kmod-b43 $(USB2_PACKAGES) + DEVICE_PACKAGES := $(B43) $(USB2_PACKAGES) $(Device/asus) PRODUCTID := "WL500gpv2 " endef @@ -300,7 +303,7 @@ TARGET_DEVICES += asus-wl-500gp-v2 define Device/asus-wl-500w DEVICE_TITLE := Asus WL-500W - DEVICE_PACKAGES := kmod-b43 kmod-usb-uhci kmod-usb2-pci + DEVICE_PACKAGES := $(B43) kmod-usb-uhci kmod-usb2-pci $(Device/asus) PRODUCTID := "WL500W " endef @@ -308,7 +311,7 @@ TARGET_DEVICES += asus-wl-500w define Device/asus-wl-520gu DEVICE_TITLE := Asus WL-520gU - DEVICE_PACKAGES := kmod-b43 $(USB2_PACKAGES) + DEVICE_PACKAGES := $(B43) $(USB2_PACKAGES) $(Device/asus) PRODUCTID := "WL520gu " endef @@ -316,7 +319,7 @@ TARGET_DEVICES += asus-wl-520gu define Device/asus-wl-550ge DEVICE_TITLE := Asus WL-550gE - DEVICE_PACKAGES := kmod-b43 + DEVIC
Re: [LEDE-DEV] [PATCH 2/2] samba36: Don't resolve interfaces.
On 25/08/17 00:51, Rosen Penev wrote: It's redundant and also buggy. IPv6 link local addresses and ::1 are not resolved for example. Doesn't matter since lo and br-lan for example, resolve to them. Signed-off-by: Rosen Penev --- Excellent! I've long carried an identical local patch for exactly the same reasons, especially the buggy ipv6 subnet expansion. I tried a couple of times to get mine into LEDE but it got lost in the noise. So I'll add my voice to this in the hope it doesn't meet the same fate :-) LVGTM Acked-by: Kevin Darbyshire-Bryant ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
