Github snapshot test builds (Updated 30-May-2015)

[RMerlin]

Sad but print server doesn't work, again, printer status always reports 'Busy' and the first task from the printing queue goes to printer only after turning printer off/on. Else report 'printer is busy' until next restart.

And there are no entries in the syslog when tasks go to printer, only entry about printer detect on startup.

Do you have the same result with either John's fork, or the stock Asus firmware?

 

[john9527]

Do you have the same result with either John's fork, or the stock Asus firmware?

I'll let him confirm, but I believe he tested the fork and everything worked OK....
http://www.snbforums.com/threads/print-server-issues.24429/#post-182339

 

[RMerlin]

I'll let him confirm, but I believe he tested the fork and everything worked OK....
http://www.snbforums.com/threads/print-server-issues.24429/#post-182339

Which is odd, because we should have the same codebase now, as I reverted the MIPS Kernel patch, and re-applied the userspace patch to lprng.

 

[john9527]

Which is odd, because we should have the same codebase now, as I reverted the MIPS Kernel patch, and re-applied the userspace patch to lprng.

My thoughts exactly when I saw his post. The only thing different I see is that I pulled in the lprng fix and the p910nd in two separate commits, while you pulled them in together. But that shouldn't make a difference.

 

[stevef9432203]

Just tested it / works / Fedora 22
upnpc : miniupnpc library test client. (c) 2005-2013 Thomas Bernard
Go to http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
desc: http://192.168.1.1:37491/rootDesc.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.1.1:37491/
Local LAN ip address : 192.168.1.3
Connection Type : IP_Routed
Status : Connected, uptime=50910s, LastConnectionError : ERROR_NONE
Time started : Mon May 25 23:12:29 2015
MaxBitRateDown : 10000000 bps (10.0 Mbps) MaxBitRateUp 10000000 bps (10.0 Mbps)
ExternalIPAddress = 100.108.201.202
i protocol exPort->inAddr:inPort description remoteHost leaseTime
0 TCP 5102->192.168.1.156:5102 'NAT-PMP 5102 tcp' '' 86399708
GetGenericPortMappingEntry() returned 713 (SpecifiedArrayIndexInvalid)

 

[RMerlin]

My thoughts exactly when I saw his post. The only thing different I see is that I pulled in the lprng fix and the p910nd in two separate commits, while you pulled them in together. But that shouldn't make a difference.

If you also have a checkout of my repo, could you do a diff between our two lprng/p910nd directories to ensure that one of us isn't missing something?

 

[RMerlin]

Just tested it / works / Fedora 22
upnpc : miniupnpc library test client. (c) 2005-2013 Thomas Bernard

It seems Windows doesn't really like miniupnpd's IGDv2 implementation (which is still marked as experimental by its author). Anyway, IGDv2 wasn't intended to be enabled, as I knew beforehand it was encountering compatibility issues with some applications. I kept all the code in place in case it can be re-enabled in the future (the IPv6 pinhole support being the main reason why I wanted it in the first place, and that part was working great). It just got accidentally re-enabled by a namespace collision with an include file.

 

[cosmoxl]

testing out the policy routing now that exceptions can be made in GUI.

for some background, I have internet facing router at 192.168.1.1 and router that runs openvpn client at 192.168.2.1.

With a rule 192.168.2.0/24 to all destinations going through the VPN tunnel, router 192.168.2.1 does not communicate to the internet through the tunnel but through the WAN. Doing traceroutes, etc while VPN is on I'd like the router itself to use the tunnel. Is that possible?

 

[Random Bleep]

Is there anything improved regarding LogJam in this version?
Btw, intercepting traffic from the OpenVPN server doesn't even need the downgrade attack on DH because it uses 512 bit by default!(latest version i checked is 378.52)

 

[Marsi4eg]

Which is odd, because we should have the same codebase now, as I reverted the MIPS Kernel patch, and re-applied the userspace patch to lprng.

Could it be caused by usb driver which (as I remember, maybe I'm wrong) is different in 374.43 and newer builds? Support for usb hubs was implemented etc...

 

[RMerlin]

Is there anything improved regarding LogJam in this version?
Btw, intercepting traffic from the OpenVPN server doesn't even need the downgrade attack on DH because it uses 512 bit by default!(latest version i checked is 378.52)

The default OpenVPN DH is only 512 bits because it would probably take hours for the router to generate a 2048-bit one itself. You are free to generate your own DH and put it instead of the one automatically generated by the router however. Anyone looking into a more secure OpenVPN setup would manually generate all their keys and certificates anyway, and keep the CA key stored outside of the router.

 

[RMerlin]

Also note that Asuswrt-Merlin isn't really affected by Logjam, as I don't support any of the weak EXPORT ciphers.

 

[RMerlin]

The webui itself was already hardened a few release ago. It will only accept the following ciphers (with a few explicit rejections at the end of that list):

"ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-G
CM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-EC
DSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-
SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:
!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"

OpenVPN allowed TLS are currently a bit wider, because of the need to inter operate with a variety of clients (for the server) and providers (for the client). I haven't decided yet on a good way to harden it without sacrificing compatibility. One solution I'm currently leaning toward is to have a specific suite of secure ciphers defined, and these would be allowed by default. There would probably be a webui option to enable support for weaker ciphers (which would be disabled by default).

I'm also tempted to make that a generic "Harden security" setting instead, which once enabled, would limit the available ciphers in addition to enforcing the use of TLS 1.0 or higher (currently it defaults to TLS 1.0 only for compatibility reasons - something that OpenVPN 2.3.7+ will be addressing in the future).

I'm still considering the available options there.

 

[cosmoxl]

testing out the policy routing now that exceptions can be made in GUI.

for some background, I have internet facing router at 192.168.1.1 and router that runs openvpn client at 192.168.2.1.

With a rule 192.168.2.0/24 to all destinations going through the VPN tunnel, router 192.168.2.1 does not communicate to the internet through the tunnel but through the WAN. Doing traceroutes, etc while VPN is on I'd like the router itself to use the tunnel. Is that possible?

OK, I'm guessing it's not possible. Afterall, how could the router allow some clients through WAN if itself was forced through the tunnel, right?

 

[Marsi4eg]

Do you have the same result with either John's fork, or the stock Asus firmware?

John's fork works normally, as a stock Asus 374.43. I haven't tested stock firmwares newer than 374.43

 

[RMerlin]

John's fork works normally, as a stock Asus 374.43. I haven't tested stock firmwares newer than 374.43

Since we both have the same code for the LPR driver now, I can only assume it's something else that was changed by Asus in recent GPLs. You would have to test it with the stock firmware to confirm this, and if it's the case, it's up to Asus to fix it. I have no way of testing it, and quite frankly I care little for this particular feature which does not belong in a router, to be honest. Especially with such a low compatibility rate (Asus's own list of tested printers had like maybe a dozen printers listed last time I saw it).

 

[Marsi4eg]

Ok, I got what you said, thank you for a try. I think it's caused by usb driver, because there is a small difference in syslog entries between 374.43 and 376/378.xx:

When usb device is connected, 374.43 says "usb1-1" or "usb1-2" but on newer builds with usb hubs support it says "usb1.1-1" or "usb1.1-2" or something like that
but ok, as far as this is Asus bug, I hope you could do a small report to make them look into this in the future.

Now I found a solution to use my old N16 in AP mode as a print server, with 374.43 firmware
So there's not a huge problem now

 

[cosmoxl]

Merlin, if block routed clients if tunnel goes down is set to yes, but redirect internet traffic is set to all traffic or no, the block still exists. Is that working or intended or should those ip rules be cleaned up with the switch away from policy routing?

 

[RMerlin]

Merlin, if block routed clients if tunnel goes down is set to yes, but redirect internet traffic is set to all traffic or no, the block still exists. Is that working or intended or should those ip rules be cleaned up with the switch away from policy routing?

Traffic should get routed when you're not in policy routing mode. Can you provide exact steps to reproduce the problem? It was working correctly when I tested it during development.

 

[cosmoxl]

Connected to a VPN provider, in routing policy mode, block routed clients if tunnel goes down set to yes. Everything working properly.

All I have to do is switch to all traffic mode and click apply to reproduce the problem of LAN clients routed through tunnel being blocked even though the tunnel is indeed up.

As the tunnel goes down rules are put in place to prohibit the default route. However when the tunnel comes back up in all traffic mode that rule is not cleaned up because, as the log explicitly says, it's not in routing policy mode anymore.