Re: [OpenWrt-Devel] Native IPv6 broken in trunk

[Adam Kuklycz]

Update:

It looks like some new firewall rules that are introduced in newer 
versions of trunk are stopping IPv6 from working.


I turned off Allow-MLD, and 2 blank rules which seem to be there by 
factory default accept forward any esp and any udp port 500.  Also 
disabled SYN flood protection and Drop Invalid Packets...


IPv6 now works.

Very weird indeed.

Now the only extra thing I need to do is after the router has booted, I 
need to restart the firewall via /etc/init.d/firewall restart and IPv6 
works just fine.


Seems the b0rked IPv6 addresses was corrected during the past 1500 
commits somewhere and so that is also now working fine.


Boils down to firewall rules.

Heh.  A few less hairs on my head.



On 10/02/16 16:27, Adam Kuklycz wrote:
Further to this, I have compiled trunk versions 47750 and 47458 which 
both exhibit the same IPv6 non-routing issue, however with 47458 the 
IPv6 address is a bit less b0rked...


inet6 addr: :::::561e:7d31:631e%3/64 Scope:Global

PING ipv6.google.com(sin04s05-in-x0e.1e100.net) 56 data bytes
ping: sendmsg: Network unreachable
ping: sendmsg: Permission denied
ping: sendmsg: Network unreachable
ping: sendmsg: Network unreachable
ping: sendmsg: Network unreachable
ping: sendmsg: Network unreachable
^C
--- ipv6.google.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5022ms

Some commits which caught my eye are the following:

47514 47493 47487 47460/47459 & 47288

Could be totally wrong however and it could be a download during the 
compile process that causes things to break...but so far I've spent 
the whole day compiling and trying to narrow down what is causing IPv6 
to not work.


A build I did on Oct 25, 2015 for revision 47245 works fine with IPv6.

Note that I am using Ubuntu 14.04.3 x64 to compile.

Any help appreciated

TIA

Adam




On 10/02/16 12:05, Adam Kuklycz wrote:

Hi all,

I've noticed with current trunk (Designated Driver) and revisions 
down to 48272 that IPv6 native does not work.


Infact when checking via ifconfig -a, on the pppoe-wan interface, the 
IPv6 address ends up as follows:


inet6 addr: ::::bd9f:ac2e:e659:67ee%2010362168/64 
Scope:Global


I've attached the config file to this email that I used to compile.

The /etc/config/network file is as follows:

root@rear-gw:~# cat /etc/config/network

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 'fd10:bc2e:49e1::/48'

config interface 'lan'
option force_link '1'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '64'
option dns '150.101.158.130'
option ipaddr '172.18.18.1'
option _orig_ifname 'eth0.1 wlan0 wlan0-1 wlan1'
option _orig_bridge 'true'
option ifname 'eth0.1'

config interface 'wan'
option proto 'pppoe'
option username 'akukl...@dynamic.internode.on.net'
option password 'gc7qvhy8v'
option peerdns '0'
option dns '150.101.158.130'
option ifname 'eth0.2'
option ipv6 'auto'

config interface 'wan6'
option proto 'dhcpv6'
option dns '2001:44B8:41DC:FE00::3'
option peerdns '0'
option reqaddress 'try'
option reqprefix '64'
option ifname '@wan'

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

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

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

root@rear-gw:~#


___
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


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

Re: [OpenWrt-Devel] Native IPv6 broken in trunk

[Adam Kuklycz]

Further to this, I have compiled trunk versions 47750 and 47458 which 
both exhibit the same IPv6 non-routing issue, however with 47458 the 
IPv6 address is a bit less b0rked...


inet6 addr: :::::561e:7d31:631e%3/64 Scope:Global

PING ipv6.google.com(sin04s05-in-x0e.1e100.net) 56 data bytes
ping: sendmsg: Network unreachable
ping: sendmsg: Permission denied
ping: sendmsg: Network unreachable
ping: sendmsg: Network unreachable
ping: sendmsg: Network unreachable
ping: sendmsg: Network unreachable
^C
--- ipv6.google.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5022ms

Some commits which caught my eye are the following:

47514 47493 47487 47460/47459 & 47288

Could be totally wrong however and it could be a download during the 
compile process that causes things to break...but so far I've spent the 
whole day compiling and trying to narrow down what is causing IPv6 to 
not work.


A build I did on Oct 25, 2015 for revision 47245 works fine with IPv6.

Note that I am using Ubuntu 14.04.3 x64 to compile.

Any help appreciated

TIA

Adam




On 10/02/16 12:05, Adam Kuklycz wrote:

Hi all,

I've noticed with current trunk (Designated Driver) and revisions down 
to 48272 that IPv6 native does not work.


Infact when checking via ifconfig -a, on the pppoe-wan interface, the 
IPv6 address ends up as follows:


inet6 addr: ::::bd9f:ac2e:e659:67ee%2010362168/64 
Scope:Global


I've attached the config file to this email that I used to compile.

The /etc/config/network file is as follows:

root@rear-gw:~# cat /etc/config/network

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 'fd10:bc2e:49e1::/48'

config interface 'lan'
option force_link '1'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '64'
option dns '150.101.158.130'
option ipaddr '172.18.18.1'
option _orig_ifname 'eth0.1 wlan0 wlan0-1 wlan1'
option _orig_bridge 'true'
option ifname 'eth0.1'

config interface 'wan'
option proto 'pppoe'
option username 'akukl...@dynamic.internode.on.net'
option password 'gc7qvhy8v'
option peerdns '0'
option dns '150.101.158.130'
option ifname 'eth0.2'
option ipv6 'auto'

config interface 'wan6'
option proto 'dhcpv6'
option dns '2001:44B8:41DC:FE00::3'
option peerdns '0'
option reqaddress 'try'
option reqprefix '64'
option ifname '@wan'

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

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

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

root@rear-gw:~#


___
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

Re: [OpenWrt-Devel] Native IPv6 Broken in recent trunk

[Adam Kuklycz]

Wow, you really can't get away with much these days:(

BTW I didn't just change the subject I blanked out the entire message as 
well :P


I'll start a fresh thread once I've compiled and tested the earlier 
trunk commit, which I am about to begin now.




On 10/02/16 00:55, John Crispin wrote:

Hi Adam,

please do not hijack threads. if you want to send us a mail then dont
click Reply on an un-related thread and then change the subject. this
will mess up patchwork, which did notice what you did ;)

--> https://patchwork.ozlabs.org/patch/580275/

John

On 09/02/2016 05:42, Adam Kuklycz wrote:

All,

I've compiled OpenWRT trunk version r48667 successfully and have noticed
that when using PPPoE with native IPv6 that while IPv6 addresses are
correctly assigned and also allocated out to client devices on the LAN,
there is no default route for WAN6, and thus nothing can connect to the
Internet via IPv6, including the router itself.

This means that even when doing a ping6 or traceroute6 from the router,
all external addresses show up as no route.

Have attached the config used which I hope is nothing out of the
ordinary...

The last firmware I compiled and have work fine with IPv6 was r47245.

I have reported this issue once before but that was quite some time
ago...so I am surprised if this is a regression.

Relevant parts of /etc/config/network (which work fine using r47245):

config interface 'lan'
 option force_link '1'
 option type 'bridge'
 option proto 'static'
 option netmask '255.255.255.0'
 option ip6assign '64'
 option dns 'x'
 option ipaddr '172.18.18.1'
 option _orig_ifname 'eth0.1 wlan0 wlan0-1 wlan1'
 option _orig_bridge 'true'
 option ifname 'eth0.1'

config interface 'wan'
 option _orig_ifname 'eth0.2'
 option _orig_bridge 'false'
 option proto 'pppoe'
 option username 'xxx'
 option password 'xx'
 option peerdns '0'
 option dns ''
 option ifname 'eth0.2'
 option ipv6 'auto'

config interface 'wan6'
 option proto 'dhcpv6'
 option dns ''
 option peerdns '0'
 option reqaddress 'try'
 option reqprefix '64'
 option _orig_ifname '@wan'
 option _orig_bridge 'false'
 option ifname 'eth0.2'


___
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

Re: [OpenWrt-Devel] Native IPv6 Broken in recent trunk

[Adam Kuklycz]

Built revision 48634, same deal.  Will try building 48272 in the morning 
and advise.


On 09/02/16 23:48, Adam Kuklycz wrote:

Hi there,

Yes I tried @wan to no avail, reverting back to an earlier build saw 
my IPv6 connectivity restored.


I am trying a commit from Friday just gone, just before some commits 
were put up fixing some issues that corrected routing. Bit of a long 
shot as it's only IPv6 affected but never know.


As I said in my earlier email the last build I did was from 47245 so 
that's a lot of commits to sift through for the solution, hopefully I 
can narrow that a bit for you guys.


Cheers


On 09/02/16 23:39, Jo-Philipp Wich wrote:

Hi.


config interface 'lan'
 option force_link '1'
 option type 'bridge'
 option proto 'static'
 option netmask '255.255.255.0'
 option ip6assign '64'
 option dns 'x'
 option ipaddr '172.18.18.1'
 option _orig_ifname 'eth0.1 wlan0 wlan0-1 wlan1'
 option _orig_bridge 'true'
 option ifname 'eth0.1'

config interface 'wan'
 option _orig_ifname 'eth0.2'
 option _orig_bridge 'false'
 option proto 'pppoe'
 option username 'xxx'
 option password 'xx'
 option peerdns '0'
 option dns ''
 option ifname 'eth0.2'
 option ipv6 'auto'

config interface 'wan6'
 option proto 'dhcpv6'
 option dns ''
 option peerdns '0'
 option reqaddress 'try'
 option reqprefix '64'
 option _orig_ifname '@wan'
 option _orig_bridge 'false'
 option ifname 'eth0.2'

This should most likely be either "pppoe-wan" or "@wan",
___
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

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

Re: [OpenWrt-Devel] Native IPv6 Broken in recent trunk

[Adam Kuklycz]

Hi there,

Yes I tried @wan to no avail, reverting back to an earlier build saw my 
IPv6 connectivity restored.


I am trying a commit from Friday just gone, just before some commits 
were put up fixing some issues that corrected routing.  Bit of a long 
shot as it's only IPv6 affected but never know.


As I said in my earlier email the last build I did was from 47245 so 
that's a lot of commits to sift through for the solution, hopefully I 
can narrow that a bit for you guys.


Cheers


On 09/02/16 23:39, Jo-Philipp Wich wrote:

Hi.


config interface 'lan'
 option force_link '1'
 option type 'bridge'
 option proto 'static'
 option netmask '255.255.255.0'
 option ip6assign '64'
 option dns 'x'
 option ipaddr '172.18.18.1'
 option _orig_ifname 'eth0.1 wlan0 wlan0-1 wlan1'
 option _orig_bridge 'true'
 option ifname 'eth0.1'

config interface 'wan'
 option _orig_ifname 'eth0.2'
 option _orig_bridge 'false'
 option proto 'pppoe'
 option username 'xxx'
 option password 'xx'
 option peerdns '0'
 option dns ''
 option ifname 'eth0.2'
 option ipv6 'auto'

config interface 'wan6'
 option proto 'dhcpv6'
 option dns ''
 option peerdns '0'
 option reqaddress 'try'
 option reqprefix '64'
 option _orig_ifname '@wan'
 option _orig_bridge 'false'
 option ifname 'eth0.2'

This should most likely be either "pppoe-wan" or "@wan",
___
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

Re: [OpenWrt-Devel] [CC 15.05-rc3] mwan3: Update

[Adam Kuklycz]

Hi there,

I didn't see this fix come into the main CC trunk?

The package does generate these annoying messages in the syslog whenever 
a user is on the overview page on the router:


Sat Aug 29 11:45:26 2015 daemon.err uhttpd[2507]: uci: Entry not found
Sat Aug 29 11:45:31 2015 daemon.err uhttpd[2507]: uci: Entry not found



On 10/08/15 18:36, j...@openwrt.org wrote:

The mwan3 package has been rebuilt and was uploaded to the Chaos Calmer
15.05 Release Candicate 3 repository.


VERSION

1.6-1 => 1.6-2


CHANGELOG

[Thu, 23 Jul 2015 13:51:04 +0200 75f9788]

Update to version 1.6-2

Fix malformed uci commands. (issue #1502)


CHANGES

  net/mwan3/Makefile |2 +-
  net/mwan3/files/usr/sbin/mwan3 |8 
  2 files changed, 5 insertions(+), 5 deletions(-)


REFERENCES

  * 
https://github.com/openwrt/packages/commit/75f978879e2b98065d86d4bcb377c0f3e677557d
___
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

Re: [OpenWrt-Devel] [PATCH] toolchain/uClibc: add support of uClibc-ng

[Adam Kuklycz]

CKAGE_rpcd=y
CONFIG_PACKAGE_samba36-server=y
CONFIG_PACKAGE_snmpd=y
CONFIG_PACKAGE_sqm-scripts=y
CONFIG_PACKAGE_tc=y
CONFIG_PACKAGE_tcpdump-mini=y
CONFIG_PACKAGE_terminfo=y
CONFIG_PACKAGE_uhttpd=y
CONFIG_PACKAGE_uhttpd-mod-ubus=y
CONFIG_PACKAGE_umbim=y
CONFIG_PACKAGE_uqmi=y
CONFIG_PACKAGE_usb-modeswitch=y
CONFIG_PACKAGE_usbreset=y
CONFIG_PACKAGE_usbutils=y
CONFIG_PACKAGE_wifitoggle=y
CONFIG_PACKAGE_wireless-tools=y
CONFIG_PACKAGE_wpad=y
# CONFIG_PACKAGE_wpad-mini is not set
CONFIG_PACKAGE_wwan=y
CONFIG_PACKAGE_zabbix-agentd=y
CONFIG_PACKAGE_zabbix-extra-mac80211=y
CONFIG_PACKAGE_zabbix-extra-network=y
CONFIG_PACKAGE_zabbix-extra-wifi=y
CONFIG_PACKAGE_zlib=y
CONFIG_SDK=y
CONFIG_WPA_SUPPLICANT_INTERNAL=y
# CONFIG_UCLIBC_USE_VERSION_0_9_33 is not set
adamk@Precision-M4500:~/ChaosCalmer-r46734$


On 28/08/15 16:27, Felix Fietkau wrote:

On 2015-08-28 01:34, Adam Kuklycz wrote:

Fair enough.

MUSL:
-rw-r--r--  1 adamk adamk  6700676 Aug 27 23:15 root.squashfs

UCLIBC:
-rw-r--r--  1 adamk adamk  6601764 Aug 27 14:19 root.squashfs

So about 100KB difference.

Running Ubuntu 14.04.2 LTS x64 here.

I guess what I am looking at is the final product, which is around 300KB
bigger in size.  Regardless, I'm going to need to reduce features for
routers with 8MB of flash, as kernel bloat also adds around another 300KB.

Can you please post the output of running ./scripts/diffconfig.sh?

Thanks,

- Felix

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

Re: [OpenWrt-Devel] [PATCH] toolchain/uClibc: add support of uClibc-ng

[Adam Kuklycz]

Fair enough.

MUSL:
-rw-r--r--  1 adamk adamk  6700676 Aug 27 23:15 root.squashfs

UCLIBC:
-rw-r--r--  1 adamk adamk  6601764 Aug 27 14:19 root.squashfs

So about 100KB difference.

Running Ubuntu 14.04.2 LTS x64 here.

I guess what I am looking at is the final product, which is around 300KB 
bigger in size.  Regardless, I'm going to need to reduce features for 
routers with 8MB of flash, as kernel bloat also adds around another 300KB.




On 28/08/15 09:11, Felix Fietkau wrote:

On 2015-08-28 01:03, Adam Kuklycz wrote:

Just following up on the suspected memory leak, and image build sizes.

With the memory leak, it's not a memory leak as such rather than
conntrackd filling things up with a log file.

After 22 hours of running:

root@gateway-openwrt:/tmp/log# ls -l
-rw---1 root root  30080612 Aug 28 08:44
conntrackd-stats.log
drwxr-xr-x2 root root60 Aug 27 10:37 ddns
-rw-r--r--1 root root 0 Aug 25 13:06 lastlog
-rw-r--r--1 root root 0 Aug 27 10:36 log.nmbd
-rw-r--r--1 root root 0 Aug 27 10:36 log.smbd
-rw-r--r--1 root root 0 Aug 25 13:06 wtmp

Deleting the log file and then shutting down conntrackd cleared the used
space.  I might look at omitting conntrackd from the builds in future.

Now for the build sizes.

musl does produce a larger image.  Below is the result of a
configuration file I have used for trunk builds with releases 457xx and
have reused for a build on r46734 the only changes being I selected
either uclibc or musl for the toolchain, otherwise the config file used
is identical.

MUSL:

-rw-r--r-- 1 adamk adamk  8126468 Aug 27 23:15
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin

UCLIBC:

-rw-r--r-- 1 adamk adamk  7864324 Aug 27 14:19
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin


Now, for stability sakes I'll want to reduce the image size anyway, with
the bloat from latest kernels blowing things out by a good 300KB as
well, but it looks like using musl adds around 300KB too.

Have the devs determined that perhaps the increased performance of using
musl outweighs the hit on image sizes?

Images are padded, often to 256 KB (which is the size increase of your
image). This means that it might be that musl just slightly increases
the image size enough to push it to the next 256KB boundary.

Comparing the size of
build_dir/target-mips_34kc_musl-1.1.10/linux-ar71xx_generic/root.squashfs-raw
between uclibc and musl should be more accurate.

- Felix

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

Re: [OpenWrt-Devel] [PATCH] toolchain/uClibc: add support of uClibc-ng

[Adam Kuklycz]

Just following up on the suspected memory leak, and image build sizes.

With the memory leak, it's not a memory leak as such rather than 
conntrackd filling things up with a log file.


After 22 hours of running:

root@gateway-openwrt:/tmp/log# ls -l
-rw---1 root root  30080612 Aug 28 08:44 
conntrackd-stats.log

drwxr-xr-x2 root root60 Aug 27 10:37 ddns
-rw-r--r--1 root root 0 Aug 25 13:06 lastlog
-rw-r--r--1 root root 0 Aug 27 10:36 log.nmbd
-rw-r--r--1 root root 0 Aug 27 10:36 log.smbd
-rw-r--r--1 root root 0 Aug 25 13:06 wtmp

Deleting the log file and then shutting down conntrackd cleared the used 
space.  I might look at omitting conntrackd from the builds in future.


Now for the build sizes.

musl does produce a larger image.  Below is the result of a 
configuration file I have used for trunk builds with releases 457xx and 
have reused for a build on r46734 the only changes being I selected 
either uclibc or musl for the toolchain, otherwise the config file used 
is identical.


MUSL:

-rw-r--r-- 1 adamk adamk  8126468 Aug 27 23:15 
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin


UCLIBC:

-rw-r--r-- 1 adamk adamk  7864324 Aug 27 14:19 
openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin



Now, for stability sakes I'll want to reduce the image size anyway, with 
the bloat from latest kernels blowing things out by a good 300KB as 
well, but it looks like using musl adds around 300KB too.


Have the devs determined that perhaps the increased performance of using 
musl outweighs the hit on image sizes?


Cheers
Adam


On 27/08/15 22:17, Adam Kuklycz wrote:

Hi Felix

Thanks for clarifying.  I've also noticed what appears to be a memory 
leak in my latest build as well which I am working on drilling down 
now.  After a couple days of uptime the device is out of memory.  It's 
much more pronounced when doing downloads with many connections 
simultaneously.


So all that said, yes I do agree there is always more bloat with each 
kernel update sadly.  I'm busy now doing builds with both uclibc and 
musl and will be interested to see the size comparisons. Will take 
several hours so will report back in the morning (Australian time)


Cheers


On 27/08/15 19:33, Felix Fietkau wrote:

On 2015-08-27 01:48, Adam Kuklycz wrote:

Hi all,

I was wondering why OpenWRT switched to musl -- is it purely because
uclibc hasn't actually maintained their code properly?

That's only part of the reason. Aside from the maintainenance, the code
quality of uClibc is also poor compared to musl.
musl also has better runtime performance and uses less RAM.


One of the things I have noticed since the CC trunk builds I did with
kernel 3.18.11 + uclibc is that the image sizes have ballooned out by a
fair bit.

For example, a build on trunk r45705 which uses uclibc and kernel
3.18.11 would allow for most features to be included in a build e.g.
openvpn, luci + ssl support, more connecting protocols than just pppoe
and so on with a router sporting 8MB of flash.

Now with recent trunk builds, with musl and kernel 4.1.x, I've had to
cut features considerably just to make it fit.  Just adding openvpn 
with

openssl support means that an image prior that built at 7MB would
balloon out to 8MB which would mean that the image would not be 
produced

as it is too big.

Last time I compared musl vs uClibc images, the size difference was
neglegible. I'd say it's more likely that the switch to Linux 4.1 caused
the size increase (the kernel does get more bloated with each new 
release).


- Felix

___
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

Re: [OpenWrt-Devel] [PATCH] toolchain/uClibc: add support of uClibc-ng

[Adam Kuklycz]

Hi Felix

Thanks for clarifying.  I've also noticed what appears to be a memory 
leak in my latest build as well which I am working on drilling down 
now.  After a couple days of uptime the device is out of memory.  It's 
much more pronounced when doing downloads with many connections 
simultaneously.


So all that said, yes I do agree there is always more bloat with each 
kernel update sadly.  I'm busy now doing builds with both uclibc and 
musl and will be interested to see the size comparisons. Will take 
several hours so will report back in the morning (Australian time)


Cheers


On 27/08/15 19:33, Felix Fietkau wrote:

On 2015-08-27 01:48, Adam Kuklycz wrote:

Hi all,

I was wondering why OpenWRT switched to musl -- is it purely because
uclibc hasn't actually maintained their code properly?

That's only part of the reason. Aside from the maintainenance, the code
quality of uClibc is also poor compared to musl.
musl also has better runtime performance and uses less RAM.


One of the things I have noticed since the CC trunk builds I did with
kernel 3.18.11 + uclibc is that the image sizes have ballooned out by a
fair bit.

For example, a build on trunk r45705 which uses uclibc and kernel
3.18.11 would allow for most features to be included in a build e.g.
openvpn, luci + ssl support, more connecting protocols than just pppoe
and so on with a router sporting 8MB of flash.

Now with recent trunk builds, with musl and kernel 4.1.x, I've had to
cut features considerably just to make it fit.  Just adding openvpn with
openssl support means that an image prior that built at 7MB would
balloon out to 8MB which would mean that the image would not be produced
as it is too big.

Last time I compared musl vs uClibc images, the size difference was
neglegible. I'd say it's more likely that the switch to Linux 4.1 caused
the size increase (the kernel does get more bloated with each new release).

- Felix

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

Re: [OpenWrt-Devel] [PATCH] toolchain/uClibc: add support of uClibc-ng

[Adam Kuklycz]

Hi all,

I was wondering why OpenWRT switched to musl -- is it purely because 
uclibc hasn't actually maintained their code properly?


One of the things I have noticed since the CC trunk builds I did with 
kernel 3.18.11 + uclibc is that the image sizes have ballooned out by a 
fair bit.


For example, a build on trunk r45705 which uses uclibc and kernel 
3.18.11 would allow for most features to be included in a build e.g. 
openvpn, luci + ssl support, more connecting protocols than just pppoe 
and so on with a router sporting 8MB of flash.


Now with recent trunk builds, with musl and kernel 4.1.x, I've had to 
cut features considerably just to make it fit.  Just adding openvpn with 
openssl support means that an image prior that built at 7MB would 
balloon out to 8MB which would mean that the image would not be produced 
as it is too big.


I've yet to do a separate build with latest trunk and uclibc but 
certainly something has caused image build sizes to grow quite a bit 
recently, though in testing I've done at least, it hasn't impacted on 
router performance for now.


Cheers
Adam


On 27/08/15 04:28, Alexey Brodkin wrote:

Hi John,

On Wed, 2015-08-26 at 20:20 +0200, John Crispin wrote:

Hi,

On 26/08/2015 20:11, Alexey Brodkin wrote:

uClibc-ng is a spin-off of original uClibc, see http://www.uclibc-ng.org/

We try to regularly add changes from uClibc to uClibc-ng.
We even sent patches and bug reports to the uClibc mailing list.
The config file is compatible between uClibc-ng 1.0 and uClibc git master.
This might change in the future.

Our main goal is to provide regularly a stable and tested release
to make embedded system developers happy.

The main advantage of uClibc-ng over olde good uClibc is regular releases
so there's no need to keep tons of patches on top of years old
0.9.33.2


why do you not use musl ? it is actively support rather than being
hooked on life support.

The point is I'm about to submit patch with support of new architecture (ARC)
in OpenWRT. And unfortunately the only libc we have now is uClibc.

And since "original" uClibc lack recent releases (where ARC support might exist
as we're in uclibc's master branch for quite some time already) I went forward
with uClibc-ng which sees releases much more often and in released tarballs
we already have support of ARC.

So I understand that other architectures may not benefit a lot from newer
uClibc but for us (ARC) there's no other way.

Hope that makes sense.

-Alexey
___
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

Re: [OpenWrt-Devel] [PATCH] luci-proto-wwan minimal support

[Adam Kuklycz]

Or at least let us know how to apply the patch manually and I will add 
it into my unofficial builds that I make with the ar71xx platform.


I'd love to see proper or even some sort of wwan support in the luci 
side of things.




On 21/05/15 15:41, Cezary Jackiewicz wrote:

Dnia 2015-04-22, o godz. 15:59:37
Aleksandr Kolesnik  napisał(a):


Signed-off-by: Aleksandr Kolesnik 

Hi,
there is chance to to include this into 15.05?


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

Re: [OpenWrt-Devel] Why OpenWrt sucks?

[Adam Kuklycz]

I think what everyone needs to just think and remember for a minute:

*  OpenWRT is built by the community and not by highly paid engineers
*  OpenWRT is often far more feature rich than stock firmwares written for
the devices supported
*  OpenWRT is even used sometimes by hardware vendors as a baseline for
their own firmwares

I think that suggesting OpenWRT is done by guesswork and not done by people
who know their code is just counter productive and if we're to criticize the
hard work of the OpenWRT team then we should at least be upbuilding in what
we say rather than just saying OpenWRT performance sucks balls.

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Zefir Kurtisi
Sent: Wednesday, 11 March 2015 11:13 PM
To: Felix Fietkau; David Lang; José Vázquez
Cc: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] Why OpenWrt sucks?

On 03/10/2015 10:39 PM, Felix Fietkau wrote:
> On 2015-03-10 20:22, Zefir Kurtisi wrote:
> 
>> This gives at least two sources for optimization for the reference 
>> driver: 1) save inter-layer processing overhead (passing commands 
>> from hostapd directly to HW is cheaper than passing it through 4 
>> layers), and 2) vastly reduce locking when you are in full control of
concurrency.
> The overhead of commands issued by hostapd is pretty much irrelevant.
> All that matters for driver performance is the actual data path 
> (network stack, mac80211 tx/rx, driver tx/rx).
> Also, I've not seen any indication in my tests that locking is a 
> measurable cause of performance issues.
> When it comes to performance issues, guesswork is meaningless, 
> measurements (e.g. profiling results) matter!
> 
> - Felix
> 
Hm, maybe my memory is deceiving me, but I'm pretty sure my statement is not
based on guesswork but in fact on measurements.

Like 3 years ago, for a PPC based platform we had to decide whether to go
with the reference driver or with aht9k. For that, thorough performance
measurements were performed and ath9k was somewhere between 10 and 30%
behind throughput wise.
Guessing that synchronization might be one factor, we removed locking in
ath9k and results improved noticeably by up to 5%. At that time and on a PPC
platform it was a factor, it might be irrelevant today. I remember it well
since it indicated that ath9k has some optimization potential left and we
finally decided for it.

Anyway, that was not my point here. What I claim is that a proprietary
driver always opens more optimization potential (cross-layer wise).


Cheers,
Zefir
___
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

[OpenWrt-Devel] sierra-directip howto in OpenWRT

[Adam Kuklycz]

Hi all

I asked in the forums but nobody has replied so asking on here as well.

I'm running a Sierra 320U which supports 3G & LTE/4G.

Have compiled in the directip options as well as QMI etc so I now see 
the wwan0 interface and there are some generic directip scripts in /etc/gcom


What is the known process to get the Sierra USB modems connected via 
directip & wwan0 instead of via the serial link/pppd option?


Note that I have providers that both use CHAP/PAP auth and have a 
username/password as well as others who do not require this, so would 
like to configure scripts up accordingly or have a second script 
modified to suit both options.  I'm aware there is no LuCI support (yet) 
for this configuration.


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

Re: [OpenWrt-Devel] git.infradead.org offline? mirror for mtd-utils-1.4.5?

[Adam Kuklycz]

Thanks Bastian, this has worked for me as well :)

Adam


-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Bastian Bittorf
Sent: Friday, 24 October 2014 7:12 PM
To: Claudio Thomas
Cc: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] git.infradead.org offline? mirror for
mtd-utils-1.4.5?

* Claudio Thomas  [24.10.2014 10:08]:
> ist there somewhere a mirror for mtd-utils-1.4.5? git.infradead.org

copy these to your local dl/ dir:
http://www.intercity-vpn.de/files/openwrt/mtd-utils-1.4.5.tar.gz
http://www.intercity-vpn.de/files/openwrt/mtd-utils-1.5.0.tar.gz

there is already a ticket open for this issue. bye, bastian
___
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

Re: [OpenWrt-Devel] git.infradead.org offline? mirror for mtd-utils-1.4.5?

[Adam Kuklycz]

 

I’m seeing the same thing:

 

Checking out files from the git repository...

Cloning into 'mtd-utils-1.4.5'...

fatal: unable to connect to git.infradead.org:

git.infradead.org: Name or service not known

 

It was also down a few days ago for quite a while; it would be nice if there 
was a backup repository for this, for times when technical issues arise like 
now where the main site is down.

 

Thanks

Adam

 

 

 

From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf 
Of Claudio Thomas
Sent: Friday, 24 October 2014 6:48 PM
To: OpenWrt Development List
Subject: [OpenWrt-Devel] git.infradead.org offline? mirror for mtd-utils-1.4.5?

 

Hi,
ist there somewhere a mirror for mtd-utils-1.4.5? git.infradead.org seems to be 
(temporary) dead:
Cloning into 'mtd-utils-1.4.5'...
fatal: unable to connect to git.infradead.org:
git.infradead.org: Name or service not known

Thanks, 
Claudio
-- 
Working on OpenWrt BB for XM1700E 
 

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

Re: [OpenWrt-Devel] Open source & open process

[Adam Kuklycz]

One thing I have observed is that some developers are on the TRAC system and
actively looking at tickets, while others are purely on the mailing list and
do not regularly (or at all) look at the TRAC system.

This can cause confusion and frustration for some who are wanting to report
a bug, and report it via the TRAC system only to find out a couple of weeks
later that the developer responsible for a certain bug/package only looks at
the mailing list.

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of John Crispin
Sent: Thursday, 2 October 2014 3:31 PM
To: Hanno Schupp
Cc: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] Open source & open process


no its certainly farting. i have you 2 and about 1 other person
complain. the other 95% sent me mails with nice and simple questions and
input and so forth.

i just had a look, yesterday i got related to BB

* 8 "thank you" mails
* 6 mails asking for various support things
* 4 pkg maintainers ask for help/logs
* 2 devs asking for root on the build server
* 2 people reminded me that now BB is out of the way that i promised to
fix NCM, hwdetect, ...
* 2 mails of people voicing wishes for CC
* 2 driver fixes for i2c on mediatek  .
* and etiennes mails and your reply

sorry but looking at those numbers it is farting that you are doing.

John








On 02/10/2014 07:01, Hanno Schupp wrote:
> I think this is his point, mate: You work hard (in isolation), but
> don't communicate.
> If you want to avoid emails that smell like farts to you, why not tell
> people what's going on?
>
> On 2 October 2014 17:51, John Crispin  > wrote:
>
> nice rant, what happened at mignight that you got so angry that you
> feel you needed to vent it out on us ?
>
> i would like to point out that the BB-final binaries have been online
> for over a day. currently the root filesystems only hold a opkg.conf
> with base and luci. last night we regenerated the files so that the
> opkg.conf holds all feeds.
>
> while you were busy farting we were busy working. but thanks for the
> nice mail.
>
>
>
>
>
> On 01/10/2014 23:59, Etienne Champetier wrote:
> > Hi,
> >
> > OpenWRT is a wonderfull piece of open source code, and it would be
> > really great if the project management could be as open as the
> > code. BB should be out now but for an unknow reason, it's not, and
> > it's frustating. If some feature are missing, let people know. If
> > some bugs need to be killed, let the community help. If buildbots
> > are broken, let someone provide new ones. Open a TODO list on an
> > etherpad, involve people. Whatever the reasons are, i'm sure some
> > people can help.
> >
> > When you open the process, you get more work done (see new packages
> > feed).
> >
> > Please communicate!!!
> >
> > Thanks Etienne
> >
> >
> > ___ 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
>
>
___
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

Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.

[Adam Kuklycz]

Hi all,

I've flashed my Netgear WNDR4300 with trunk r41336 and have run a series 
of tests.


Everything looks great!  I can restore backed up settings, I can 
configure it from scratch too should I desire.


Sysupgrade works fine on my WNDR4300 via the web UI.  Paul if you're 
still having issues with this on your WNDR3700v4 it may be specific to 
that model; I do not have one of these to test on unfortunately. But 
sysupgrade on the WNDR4300 works and works well.  All settings are kept 
when sysupgrading too.


If it helps Paul out I can email him my config file, write me directly 
for it; that should eliminate any mistakes that have been overlooked.  
Easy to do.


Will run the router for a few hours on the test bench and do some 
traffic through it, should that play nice then it's problems resolved on 
my end :)


Cheers
Adam


On 25/06/14 13:14, Paul Blazejowski wrote:

Adam,

what do you know? hehehe when one sleeps another fixes things ;-)

so far so good, my router has been up for few hours without problems...
there's still issue with the sysupgrade image that John is already aware
of ... and may have a fix for us to test ... one fix at a time they say.

glad we made much progress today!

thank you all!


On Wed, 2014-06-25 at 00:07 +, Adam Kuklycz wrote:

Geez, it must be true that you should only sleep when you're dead...damn Aussie 
time zones...

I'll test with latest trunk as well & will confirm.  But looks promising!



-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf 
Of Paul Blazejowski
Sent: Wednesday, 25 June 2014 6:27 AM
To: John Crispin
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear 
WNDR3700v4/4300.

sorry i meant https://dev.openwrt.org/ticket/16803 the previous one is closed 
for good ;-)


On Tue, 2014-06-24 at 16:25 -0400, Paul Blazejowski wrote:

Hi again,

thanks for the tftp fix, flushing just became so much faster and easier.

Tested trunk r41336 after your jffs2 fix and the image boots fine,
restored my configuration changes, rebooted the router and all changes
are saved now. I will post the working dmesg to the ticket at
https://dev.openwrt.org/ticket/16840 but it is safe to say that you
can close it ;-) now.

Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is
next on the list...

Thank you,
-paul

On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote:

On 24/06/2014 19:05, Paul Blazejowski wrote:

John,

Yes i use the reset with pin and from there i tftp the original
firmware from netgear after that i go to the gui and upload the
open-wrt image because the router will not accept the wndr3700v4
image (there's a cosmetic fix for that, i created a patch that
someone from the forums has sent months ago to this list but it
was never accepted...) https://dev.openwrt.org/ticket/16840

With that patch tftp'ing the
openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need
to flash the original firmware.

If there's another method that can be used to flash the image(s)
please let me know i would want to try any alternative ways of
flashing and could learn a thing or two in the process as well ;-)

Thank you, -paul


Hi,

i just pushed the V vs v fix and another fix that removes the jffs2
magic. i think this might have been the cause of the problems.
please retry with current trunk and let me know if the problem is
gone or still there

John
___
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

___
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

Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.

[Adam Kuklycz]

Geez, it must be true that you should only sleep when you're dead...damn Aussie 
time zones...

I'll test with latest trunk as well & will confirm.  But looks promising!



-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf 
Of Paul Blazejowski
Sent: Wednesday, 25 June 2014 6:27 AM
To: John Crispin
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear 
WNDR3700v4/4300.

sorry i meant https://dev.openwrt.org/ticket/16803 the previous one is closed 
for good ;-)


On Tue, 2014-06-24 at 16:25 -0400, Paul Blazejowski wrote:
> Hi again,
> 
> thanks for the tftp fix, flushing just became so much faster and easier.
> 
> Tested trunk r41336 after your jffs2 fix and the image boots fine, 
> restored my configuration changes, rebooted the router and all changes 
> are saved now. I will post the working dmesg to the ticket at
> https://dev.openwrt.org/ticket/16840 but it is safe to say that you 
> can close it ;-) now.
> 
> Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is 
> next on the list...
> 
> Thank you,
> -paul
> 
> On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote:
> > 
> > On 24/06/2014 19:05, Paul Blazejowski wrote:
> > > John,
> > > 
> > > Yes i use the reset with pin and from there i tftp the original 
> > > firmware from netgear after that i go to the gui and upload the 
> > > open-wrt image because the router will not accept the wndr3700v4 
> > > image (there's a cosmetic fix for that, i created a patch that 
> > > someone from the forums has sent months ago to this list but it 
> > > was never accepted...) https://dev.openwrt.org/ticket/16840
> > > 
> > > With that patch tftp'ing the
> > > openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need 
> > > to flash the original firmware.
> > > 
> > > If there's another method that can be used to flash the image(s) 
> > > please let me know i would want to try any alternative ways of 
> > > flashing and could learn a thing or two in the process as well ;-)
> > > 
> > > Thank you, -paul
> > 
> > 
> > Hi,
> > 
> > i just pushed the V vs v fix and another fix that removes the jffs2 
> > magic. i think this might have been the cause of the problems. 
> > please retry with current trunk and let me know if the problem is 
> > gone or still there
> > 
> > John
> > ___
> > 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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.

[Adam Kuklycz]

Guys if you need a guinea pig for testing the WNDR4300's I am happy to assist.  
Since introducing the sysupgrade features, upon a router reboot all settings 
are restored to factory defaults.

Also, is this mail list a channel that reaches most or all developers?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel