OpenWrt Forum Archive

Topic: Build for WNDR3700/WNDR3800

The content of this topic has been archived between 9 Jul 2013 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

I have to say, this 32016 build is really smooth and responsive. Web page delays are WAY down using it, compared to Backfire. As ever, I love the nice clean minimal configuration hnyman has put together too - probably a big part of this result. Thanks again to you and of course the Openwrt devs!

Dickie wrote:

mmmm thanks.  I tried that yesterday, and the router started into a reboot loop, so I'll try again  with the latest build. Thanks!

I tried forcing the installation of the pptp modules rom snapshot repository, and although the installation seemed to go ok, also my router went to a reboot loop after I created a pptp tunnel. So, apparently the snapshot version does not work with my build.

I tried to compile the needed modules by myself, and with them the router stays up quite ok.
However, there seems to be some trouble with the pptp authentication in general, so the tunnel does not get properly initiated.
See https://dev.openwrt.org/ticket/11570 and https://dev.openwrt.org/ticket/11545

(Last edited by hnyman on 2 Jun 2012, 14:25)

hnyman wrote:

I tried to compile the needed modules by myself, and with them the router stays up quite ok.
However, there seems to be some trouble with the pptp authentication in general

Thankyou very much hnyman for going to the trouble of checking it out!  I'm already tracking those same tickets on the MSCHAPV2 issue as well, so we'll see how it plays out.  I have a noob-dev question that I'll PM you instead of clogging up the boards.  Thanks again.

I have a problem with your trunk builds,
I can't configure igmp proxy in it,
but have no problems in your Backfire builds,
so do I something wrong or is there a bug in the trunk builds ?
it can also be a bug in the igmp proxy, for I can see it has a different version no.

(Last edited by Jas_4 on 3 Jun 2012, 13:48)

Jas_4 wrote:

I have a problem with your trunk builds,
I can't configure igmp proxy in it,
but have no problems in your Backfire builds,
so do I something wrong or is there a bug in the trunk builds ?
it can also be a bug in the igmp proxy, for I can see it has a different version no.

No idea. I have never used that module.

Actually Backfire and trunk seem to use the same version 0.1, I think. It might be possible that the recent change to netifd scripts might have caused something.

Yes, the trunk version oof igmp proxy uses /etc/config/igmpproxy instead of a plain config file.

@Dickie:
I built the pptp support to my new 32035 build, and initially it seemed able to connect to a pptp tunnel (a demo account from usaip), but then it broke down and did not get up again. The pptp seems to get stuck to a loop of neverending tries, until it gets stopped by bringing the interface down from Luci.

There was also this possible error in the log: Script /lib/netifd/ppp-up finished (pid 2940), status = 0x1
So, I guess the situation has improved, but I am not sure how much. :-(

I am not sure if I had the firewall config correctly in place when doing that, so that might be part of the reason. It looks like the interface does not get added to the firewall when the interface gets up. I have not done pptp config earlier, so I am not quite sure how it is supposed to work.

root@OpenWrt:/tmp/log# head -n 240 pptp-server.log
using channel 1
Using interface pptp-test
Connect: pptp-test <--> /dev/pts/1
Got signal, pid=2853
Script /usr/sbin/pptp vpn16.usaip.eu --loglevel 0 --nolaunchpppd  finished (pid 2849), status = 0x0
Modem hangup
Connection terminated.
using channel 2
Using interface pptp-test
Connect: pptp-test <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xfd68f34b>]
rcvd [LCP ConfReq id=0x1 <auth chap MS-v2> <mru 1460> <magic 0x7c10a720>]
sent [LCP ConfAck id=0x1 <auth chap MS-v2> <mru 1460> <magic 0x7c10a720>]
rcvd [LCP ConfRej id=0x1 <asyncmap 0x0>]
sent [LCP ConfReq id=0x2 <magic 0xfd68f34b>]
rcvd [LCP ConfAck id=0x2 <magic 0xfd68f34b>]
sent [LCP EchoReq id=0x0 magic=0xfd68f34b]
rcvd [LCP ConfReq id=0x2 <auth chap MS-v2> <mru 1460> <magic 0x7c10a720>]
sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0xcb5f1517>]
sent [LCP ConfAck id=0x2 <auth chap MS-v2> <mru 1460> <magic 0x7c10a720>]
rcvd [LCP ConfRej id=0x3 <asyncmap 0x0>]
sent [LCP ConfReq id=0x4 <magic 0xcb5f1517>]
rcvd [LCP ConfAck id=0x4 <magic 0xcb5f1517>]
sent [LCP EchoReq id=0x0 magic=0xcb5f1517]
rcvd [CHAP Challenge id=0x1 <e0d734a5410cd783c68a9affeecd8d53>, name = "MikroTik"]
sent [CHAP Response id=0x1 <5e288edf7dbc240a5664a6c8eb51328100000000000000004b2cd3a8d5d78e820d3eb33cb8184c454ecad834eecabfee00>, name = "demo"]
rcvd [LCP EchoRep id=0x0 magic=0x7c10a720]
rcvd [CHAP Success id=0x1 "S=E4CF6ABA6415E81C372700A4CF482149E3A2CF5E"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x1 <addr 172.31.255.254>]
sent [IPCP TermAck id=0x1]
rcvd [proto=0x8281] 01 01 00 04
Unsupported protocol 0x8281 received
sent [LCP ProtRej id=0x5 82 81 01 01 00 04]
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
sent [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 172.31.156.35> <ms-dns1 172.31.255.254> <ms-dns2 8.8.8.8>]
sent [IPCP ConfReq id=0x3 <addr 172.31.156.35> <ms-dns1 172.31.255.254> <ms-dns2 8.8.8.8>]
rcvd [IPCP ConfAck id=0x3 <addr 172.31.156.35> <ms-dns1 172.31.255.254> <ms-dns2 8.8.8.8>]
sent [LCP EchoReq id=0x1 magic=0xcb5f1517]
rcvd [LCP EchoRep id=0x1 magic=0x7c10a720]
rcvd [IPCP ConfReq id=0x2 <addr 172.31.255.254>]
sent [IPCP ConfAck id=0x2 <addr 172.31.255.254>]
local  IP address 172.31.156.35
remote IP address 172.31.255.254
primary   DNS address 172.31.255.254
secondary DNS address 8.8.8.8
Script /lib/netifd/ppp-up started (pid 2876)
Script /lib/netifd/ppp-up finished (pid 2876), status = 0x1
No response to 5 echo-requests
Serial link appears to be disconnected.
Connect time 0.1 minutes.
Sent 3912807 bytes, received 0 bytes.
Script /lib/netifd/ppp-down started (pid 3014)
MPPE disabled
sent [LCP TermReq id=0x6 "MPPE disabled"]
sent [LCP TermReq id=0x7 "MPPE disabled"]
Script /usr/sbin/pptp vpn16.usaip.eu --loglevel 0 --nolaunchpppd  finished (pid 2856), status = 0x0
Modem hangup
Connection terminated.
using channel 3
Using interface pptp-test
Connect: pptp-test <--> /dev/pts/1
anon warn[pptp_gre_bind:pptp_gre.c:95]: connect: Network is unreachable
anon fatal[main:pptp.c:287]: Cannot bind GRE socket, aborting.
Script /usr/sbin/pptp vpn16.usaip.eu --loglevel 0 --nolaunchpppd  finished (pid 3016), status = 0x1
Modem hangup
Connection terminated.
using channel 4
anon warn[pptp_gre_bind:pptp_gre.c:95]: connect: Network is unreachable
anon fatal[main:pptp.c:287]: Cannot bind GRE socket, aborting.
Failed to set PPP kernel option flags: Inappropriate ioctl for device
Using interface pptp-test
Connect: pptp-test <--> /dev/pts/1
Script /usr/sbin/pptp vpn16.usaip.eu --loglevel 0 --nolaunchpppd  finished (pid 3018), status = 0x1
Modem hangup
Connection terminated.
using channel 5
Using interface pptp-test
Connect: pptp-test <--> /dev/pts/1
anon warn[pptp_gre_bind:pptp_gre.c:95]: connect: Network is unreachable
anon fatal[main:pptp.c:287]: Cannot bind GRE socket, aborting.
Script /usr/sbin/pptp vpn16.usaip.eu --loglevel 0 --nolaunchpppd  finished (pid 3023), status = 0x1
Modem hangup
Connection terminated.
using channel 6
Using interface pptp-test
Connect: pptp-test <--> /dev/pts/1
anon warn[pptp_gre_bind:pptp_gre.c:95]: connect: Network is unreachable
anon fatal[main:pptp.c:287]: Cannot bind GRE socket, aborting.
Modem hangup
Connection terminated.
using channel 7
Using interface pptp-test
Connect: pptp-test <--> /dev/pts/1
Script /usr/sbin/pptp vpn16.usaip.eu --loglevel 0 --nolaunchpppd  finished (pid 3026), status = 0x1
anon warn[pptp_gre_bind:pptp_gre.c:95]: connect: Network is unreachable
anon fatal[main:pptp.c:287]: Cannot bind GRE socket, aborting.
Modem hangup
Connection terminated.
using channel 8

@hnyman - I just recompiled using the latest packages / trunk (says 32035) and everything seems to be working  (falls to kness, shaking fists).  It seems to fail the first few times for no apparent reason, and then connects and stays up?   It does add the int. to the firewall zone I specified when I created the interface - do you have one specified?


Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: pppd 2.4.5 started by root, uid 0
Jun  3 12:18:18 DataHub daemon.info pppd[2484]: Using interface pptp-UKVPN
Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: Connect: pptp-UKVPN <--> /dev/pts/1
Jun  3 12:18:18 DataHub daemon.notice pptp[2488]: anon log[main:pptp.c:279]: The synchronous pptp option is NOT activated
Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: Modem hangup
Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: Connection terminated.
Jun  3 12:18:18 DataHub daemon.notice pptp[2491]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Jun  3 12:18:18 DataHub daemon.notice pptp[2493]: anon log[main:pptp.c:279]: The synchronous pptp option is NOT activated
Jun  3 12:18:18 DataHub daemon.info pppd[2484]: Using interface pptp-UKVPN
Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: Connect: pptp-UKVPN <--> /dev/pts/1
Jun  3 12:18:18 DataHub daemon.notice pptp[2491]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Jun  3 12:18:18 DataHub daemon.notice pptp[2491]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Jun  3 12:18:18 DataHub daemon.notice pptp[2496]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: Modem hangup
Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: Connection terminated.
Jun  3 12:18:18 DataHub daemon.info pppd[2484]: Using interface pptp-UKVPN
Jun  3 12:18:18 DataHub daemon.notice pppd[2484]: Connect: pptp-UKVPN <--> /dev/pts/1
Jun  3 12:18:18 DataHub daemon.notice pptp[2498]: anon log[main:pptp.c:279]: The synchronous pptp option is NOT activated
Jun  3 12:18:19 DataHub daemon.notice pptp[2496]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Jun  3 12:18:19 DataHub daemon.notice pptp[2496]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Jun  3 12:18:19 DataHub daemon.notice pppd[2484]: Modem hangup
Jun  3 12:18:19 DataHub daemon.notice pppd[2484]: Connection terminated.
Jun  3 12:18:19 DataHub daemon.notice pptp[2502]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Jun  3 12:18:19 DataHub daemon.info pppd[2484]: Using interface pptp-UKVPN
Jun  3 12:18:19 DataHub daemon.notice pppd[2484]: Connect: pptp-UKVPN <--> /dev/pts/1
Jun  3 12:18:19 DataHub daemon.notice pptp[2504]: anon log[main:pptp.c:279]: The synchronous pptp option is NOT activated
Jun  3 12:18:19 DataHub daemon.notice pptp[2502]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Jun  3 12:18:19 DataHub daemon.notice pptp[2502]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Jun  3 12:18:19 DataHub daemon.notice pppd[2484]: Modem hangup
Jun  3 12:18:19 DataHub daemon.notice pppd[2484]: Connection terminated.
Jun  3 12:18:19 DataHub daemon.info pppd[2484]: Using interface pptp-UKVPN
Jun  3 12:18:19 DataHub daemon.notice pppd[2484]: Connect: pptp-UKVPN <--> /dev/pts/1
Jun  3 12:18:19 DataHub daemon.notice pptp[2508]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Jun  3 12:18:19 DataHub daemon.notice pptp[2510]: anon log[main:pptp.c:279]: The synchronous pptp option is NOT activated
Jun  3 12:18:19 DataHub daemon.notice pptp[2491]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Jun  3 12:18:19 DataHub daemon.notice pptp[2491]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
Jun  3 12:18:19 DataHub daemon.notice pptp[2491]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 17792).
Jun  3 12:18:19 DataHub daemon.notice pptp[2508]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Jun  3 12:18:19 DataHub daemon.notice pptp[2508]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Jun  3 12:18:19 DataHub daemon.notice pppd[2484]: CHAP authentication succeeded
Jun  3 12:18:20 DataHub daemon.notice pppd[2484]: MPPE 128-bit stateless compression enabled
Jun  3 12:18:20 DataHub daemon.notice pppd[2484]: local  IP address 10.7.1.156
Jun  3 12:18:20 DataHub daemon.notice pppd[2484]: remote IP address 10.0.0.1
Jun  3 12:18:20 DataHub daemon.notice netifd: Interface 'UKVPN' is now up
Jun  3 12:18:21 DataHub user.notice ifup: Enabling Router Solicitations on UKVPN (pptp-UKVPN)
Jun  3 12:18:21 DataHub user.info firewall: adding UKVPN (pptp-UKVPN) to zone wan
Jun  3 12:18:30 DataHub daemon.info dnsmasq[2057]: reading /tmp/resolv.conf.auto
Jun  3 12:18:30 DataHub daemon.info dnsmasq[2057]: using nameserver 75.75.75.75#53
Jun  3 12:18:30 DataHub daemon.info dnsmasq[2057]: using nameserver 75.75.76.76#53
Jun  3 12:18:30 DataHub daemon.info dnsmasq[2057]: using local addresses only for domain lan
Jun  3 12:19:19 DataHub daemon.notice pptp[2496]: anon log[logecho:pptp_ctrl.c:676]: Echo Request received.
Jun  3 12:19:19 DataHub daemon.notice pptp[2496]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Jun  3 12:19:19 DataHub daemon.notice pptp[2502]: anon log[logecho:pptp_ctrl.c:676]: Echo Request received.

(Last edited by Dickie on 3 Jun 2012, 20:29)

jow wrote:

Yes, the trunk version oof igmp proxy uses /etc/config/igmpproxy instead of a plain config file.

Ok.
But how can I then change the config file?
because I usually use: nano /etc/igmpproxy.conf

Jas_4 wrote:
jow wrote:

Yes, the trunk version oof igmp proxy uses /etc/config/igmpproxy instead of a plain config file.

Ok.
But how can I then change the config file?
because I usually use: nano /etc/igmpproxy.conf

nano /etc/config/igmpproxy  ?????

hnyman wrote:
Jas_4 wrote:
jow wrote:

Yes, the trunk version oof igmp proxy uses /etc/config/igmpproxy instead of a plain config file.

Ok.
But how can I then change the config file?
because I usually use: nano /etc/igmpproxy.conf

nano /etc/config/igmpproxy  ?????

thanks for everything
I got it working now.

Am I the only one that thinks the latest build run slow?
slow trunk-r32165-2012-06-10
fast trunk-r32125-2012-06-07

I noticed there are huge commits recently, so maybe things will smooth out in a few days.

@hynman FYI on our PPTP conversation - the latest trunk / packages (32197 onwards) drop support for the user-mode PPTP and re-instate it as a kernel mode PPP extension.  I think you'll need to revisit the changes you made to your config if you want to still include it (I'm trying a build now with 32233 so I'll PM you if anything weird happens)

johnthomas00 wrote:

Am I the only one that thinks the latest build run slow?
slow trunk-r32165-2012-06-10
fast trunk-r32125-2012-06-07

I noticed there are huge commits recently, so maybe things will smooth out in a few days.

Both of those have run normally for me.

Dickie wrote:

@hynman FYI on our PPTP conversation - the latest trunk / packages (32197 onwards) drop support for the user-mode PPTP and re-instate it as a kernel mode PPP extension.  I think you'll need to revisit the changes you made to your config if you want to still include it (I'm trying a build now with 32233 so I'll PM you if anything weird happens)

I didn't publish my yesterday's build, as Luci still had dependency on the old user-mode pptp. Jow seems to have corrected that last night (http://luci.subsignal.org/trac/changeset/8703), so probably I will build today if everything else is smooth.

The added dependency checks for the build process are causing some modules to break at compilation. Collectd/luci statistics already got fixed yesterday and it looks like tons of other modules have their dependencies corrected.

Ok - 32233 all up and running.  Using your base config everything looks ok with the exception of resolveip (I'm guessing a missing dependency from the switch over).  Either install it manually afterwards or explicitly select in the menuconfig and works perfectly so far.

Dickie wrote:

Ok - 32233 all up and running.  Using your base config everything looks ok with the exception of resolveip (I'm guessing a missing dependency from the switch over).  Either install it manually afterwards or explicitly select in the menuconfig and works perfectly so far.

That is interesting, as I thought that jow removed that module by purpose. Do you think that 'resolveip' is needed in the new config?

I actually already built a new version, using the following .config template, but I have not yet uploaded it for general usage.

# Use "make defconfig" to expand this to a full .config
CONFIG_TARGET_ar71xx=y
CONFIG_TARGET_ar71xx_generic_WNDR3700=y
CONFIG_PACKAGE_kmod-leds-wndr3700-usb=y
CONFIG_BUSYBOX_CONFIG_DIFF=y
CONFIG_BUSYBOX_CONFIG_FEATURE_LESS_FLAGS=y
CONFIG_BUSYBOX_CONFIG_FEATURE_LESS_REGEXP=y
CONFIG_BUSYBOX_CONFIG_FEATURE_LESS_WINCH=y
CONFIG_PACKAGE_uhttpd-mod-tls_openssl=y
CONFIG_PACKAGE_htop=y
CONFIG_PACKAGE_nano=y
CONFIG_PACKAGE_ccrypt=y
CONFIG_PACKAGE_haveged=y
CONFIG_PACKAGE_curl=y
CONFIG_PACKAGE_vsftpd=y

# USB device mount
CONFIG_PACKAGE_block-mount=y
CONFIG_PACKAGE_kmod-fs-ext2=y
CONFIG_PACKAGE_kmod-fs-ext3=y
CONFIG_PACKAGE_kmod-fs-ext4=y
CONFIG_PACKAGE_kmod-fs-msdos=y
CONFIG_PACKAGE_kmod-fs-ntfs=y
CONFIG_PACKAGE_kmod-fs-vfat=y
CONFIG_PACKAGE_kmod-nls-cp1250=y
CONFIG_PACKAGE_kmod-nls-cp437=y
CONFIG_PACKAGE_kmod-nls-cp850=y
CONFIG_PACKAGE_kmod-nls-iso8859-1=y
CONFIG_PACKAGE_kmod-nls-iso8859-15=y
CONFIG_PACKAGE_kmod-nls-utf8=y
CONFIG_PACKAGE_kmod-usb-storage=y
CONFIG_PACKAGE_mount-utils=y

# IPv6 support
CONFIG_BUSYBOX_CONFIG_TRACEROUTE6=y
CONFIG_PACKAGE_aiccu=y
CONFIG_PACKAGE_ip6tables=y
CONFIG_PACKAGE_luci-proto-6x4=y

# WLAN/WPS support
CONFIG_PACKAGE_hostapd-utils=y
CONFIG_WPA_SUPPLICANT_INTERNAL=y
CONFIG_WPA_MSG_MIN_PRIORITY=4
CONFIG_PACKAGE_wpad=y
# CONFIG_PACKAGE_wpad-mini is not set
CONFIG_ATH_USER_REGD=y

# Luci
CONFIG_PACKAGE_luci-ssl=y
CONFIG_PACKAGE_luci-mod-admin-full=y
CONFIG_PACKAGE_luci-app-ddns=y
CONFIG_PACKAGE_luci-app-diag-devinfo=y
CONFIG_PACKAGE_luci-app-qos=y
CONFIG_PACKAGE_luci-app-radvd=y
CONFIG_PACKAGE_luci-app-upnp=y
CONFIG_PACKAGE_luci-app-wol=y

# Luci statistics
CONFIG_PACKAGE_luci-app-statistics=y
CONFIG_PACKAGE_collectd-mod-conntrack=y
CONFIG_PACKAGE_collectd-mod-cpu=y
CONFIG_PACKAGE_collectd-mod-dns=y
CONFIG_PACKAGE_collectd-mod-memory=y
CONFIG_PACKAGE_collectd-mod-network=y
CONFIG_PACKAGE_collectd-mod-ping=y

# 3G USB dongle
CONFIG_PACKAGE_luci-proto-3g=y
CONFIG_PACKAGE_kmod-usb-serial-option=y
CONFIG_PACKAGE_kmod-usb-sierrawireless-directip=y

# PPTP support
CONFIG_PACKAGE_luci-proto-ppp=y
CONFIG_PACKAGE_ppp-mod-pptp=y

EDIT: now that you said it, it looks like there is a missing dependency.
The new scripts still use the resolveip command, but the package is not automatically built along pptp.
I am going to write a ticket for that. ... wrote already: https://dev.openwrt.org/ticket/11668

EDIT2: ...and jow fixed the thing while I was writing the ticket: https://dev.openwrt.org/changeset/32269  ;-)

(Last edited by hnyman on 12 Jun 2012, 22:13)

hnyman wrote:

EDIT2: ...and jow fixed the thing while I was writing the ticket: https://dev.openwrt.org/changeset/32269  ;-)

Wow - things happen fast around here.

hnyman wrote:

In the trunk version, the new QoS logic, CoDel, seems to work quite nicely. It replaced the old logic two weeks ago.

I'm experimenting with QoS and wondering if there is a way to define a bidirectional rule. From looking at the UCI code and the wiki, it appears to me that the rules are unidirectional - specifying only a source or dest address and/or port. Is there a better way than the following if I want to prioritize flows to and from a given host range?

config classify
        option target 'Express'
        option ports '443'
        option proto 'tcp'
        option dsthost 'XX.YY.0.0/16'

config classify
        option proto 'tcp'
        option ports '443'
        option target 'Express'
        option srchost 'XX.YY.0.0/16'

To be honest, I am not quite sure how much the new codel logic takes the different queues into account.

Do I still need to enable RADVD with these recent IPv6 builds? The network->Interface->LAN settings now have checkboxes for "Accept router advertisements" and "Send router solicitations". How do those interact with radvd?

I am not sure, but I think that radvd is still needed. (If radvd is stopped, my PC doesn't get a proper IPv6 address.)

Those options got introduced over a year ago with https://dev.openwrt.org/changeset/25454 to trunk/package/base-files/files/etc/hotplug.d/iface/10-routes , but that file has since then disappeared and has been replaced with https://dev.openwrt.org/browser/trunk/package/netifd/files/etc/hotplug.d/iface/10-sysctl . The options seems to actually map into Linux kernel sysctl options net.ipv6.conf.$DEVICE."accept_ra" and ."forwarding". Those are explained here: http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

(Last edited by hnyman on 16 Jun 2012, 08:53)

Ok, I'll experiment further. So far things seem to work with or without radvd from various systems on my network.

On the radvd configuration page, which services do you enable? I assume the Interfaces->LAN checkbox is advisable, but what about Prefixes, Routes, RDNSS and DNSSL? All optional depending on client population?

hnyman wrote:

EDIT2: ...and jow fixed the thing while I was writing the ticket: https://dev.openwrt.org/changeset/32269  ;-)

Do you know if theres an easy way to change the interface order on startup?  The new kernel mode PPTP is great , but it tries to bring it up on boot before the external interface is up (so obviously it fails), so am trying to think how to delay the interface so that it starts on boot, but not until Eth1 is up.

Do you use a symbolic server name? If yes, please temporarely try with IP and see if it works then.

jow wrote:

Do you use a symbolic server name? If yes, please temporarely try with IP and see if it works then.

I'll try that when I get back later - but if the ETH1 is still down, won't it just fail anyway?
Does the kernel PPTP mode retry for a number of attempts 'under the hood'? If so I guess we can just increase the retry count to cover until boot time.