OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

@chris88

Looks like your bootloader is corrupt.

nitroshift

@JW0914 (and anyone else) - I cracked the plastic housings off the connectors, and I'm 100% sure there's contact (and no shorting). I've ensured I have the most recent driver available for my USB - UART USB dongle. It's definitely on COM3. I've used the PuTTY configuration file provided on the WRT1X00AC wiki. I've tried on a second computer (Mac). Nothing is showing up in the terminal. However...

I started trying to connect to random pin combinations and discovered that without the GND pin connected, the router actually booted. When I reconnected it, or removed all connectors it was back to not booting. So I left the GND pin off, reflashed, and now it's working like normal again.

I'm happy, but a little perplexed. Also a little put off I couldn't get a console going.

(Last edited by chris88 on 3 Nov 2016, 03:23)

chris88 wrote:

@JW0914 (and anyone else) - I cracked the plastic housings off the connectors, and I'm 100% sure there's contact (and no shorting). I've ensured I have the most recent driver available for my USB - UART USB dongle. It's definitely on COM3. I've used the PuTTY configuration file provided on the WRT1X00AC wiki. I've tried on a second computer (Mac). Nothing is showing up in the terminal. However...

I started trying to connect to random pin combinations and discovered that without the GND pin connected, the router actually booted. When I reconnected it, or removed all connectors it was back to not booting. So I left the GND pin off, reflashed, and now it's working like normal again.

I'm happy, but a little perplexed. Also a little put off I couldn't get a console going.

Something isn't right with your pin out, as it wouldn't be possible to communicate with the router without ground being connected.  DC requires a return path for electrons (voltage flows positive to negative for >0v, negative to positive <0v [actual electron flow is opposite]), with TX & RX carrying voltages from >0v - 3.3v, of which requires ground [0v] to complete the circuit.

Did you by chance review the serial portion of the wiki? I mentioned it before for a reason, as it gives the pin out.... nevermind... SSL cert has expired, wiki site isn't available until it's renewed

  • Pin #: 1 [Gnd], 2 [Rx], 4 [Tx]

    • While every router except the 1900ac v1 has the header flipped horizontally, the pins are the same.  Part of your problem is my fault, as I should have added a picture of the header on Armada 385's and will do so once the new server cert has been uploaded.


These are two webpages I bookmarked and found helpful a few years back which visualize what occurs with TTL [transistor-transitor logic] signals:

(Last edited by JW0914 on 3 Nov 2016, 05:00)

JW0914 wrote:
Chadster766 wrote:

What I do in iptables is allow only specific Public IP Addresses to remote manage my routers or run a opensouce package called fail2ban.

Do you connect with SSH from a smartphone that's using a non-wifi connection by chance?

For that scenario I would use fail2ban instead of restricting access via iptables source IP.

Chadster766 wrote:
JW0914 wrote:
Chadster766 wrote:

What I do in iptables is allow only specific Public IP Addresses to remote manage my routers or run a opensouce package called fail2ban.

Do you connect with SSH from a smartphone that's using a non-wifi connection by chance?

For that scenario I would use fail2ban instead of restricting access via iptables source IP.

I meant have you found a way to pin an IP/MAC Address to a smartphone while on a cellular, non-wifi connection?  I was interested in finding a way to do so a while back, as I prefer VPN and SSH to be allowed to only certain MACs with a specific IP, however I kept running into the problem that cellular networks do not adhere to RFC standards for data usage.

JW0914 wrote:

I meant have you found a way to pin an IP/MAC Address to a smartphone while on a cellular, non-wifi connection?  I was interested in finding a way to do so a while back, as I prefer VPN and SSH to be allowed to only certain MACs with a specific IP, however I kept running into the problem that cellular networks do not adhere to RFC standards for data usage.

Only commercial accounts with Telcos allow you to have a Public Static IP Address assigned to your SIM card. Without that I don't see how this could be done.

Lot's of discussion on Firewall rules these past couple days.

So, in fear of being ridiculed, I will ask anyways.

Is LEDE/OpenWRT coming with a standard set of firewall rules that would be considered "safe" for the general public? Or is it a "must" that you need to create your own set of firewall rules as soon as you install...

cybrnook2002 wrote:

Lot's of discussion on Firewall rules these past couple days.

So, in fear of being ridiculed, I will ask anyways.

Is LEDE/OpenWRT coming with a standard set of firewall rules that would be considered "safe" for the general public? Or is it a "must" that you need to create your own set of firewall rules as soon as you install...

Yes... in fact, it's the most secure default firewall I've come across since switching from DD-WRT about 18 months ago.  You can view the default rules via:

fw3 print

The only thing I would recommend is disabling the default rules that are populated under Network >> Firewall >> Rules in LuCI or /etc/config/firewall via cli.  While some users may need those specific default rules, they're also a minor security concern (inbound icmp echo-request from WAN for instance).  I prefer a less is more approach and only opening up inbound WAN access protocols and ports when one actually needs it.

(Last edited by JW0914 on 3 Nov 2016, 19:03)

I, for example, am running Kaloz's build from Oct 13.

Since they were once one in the same, I assume LEDE is using the same rules as OpenWRT. Or have LEDE now customized itself even down to the firewall rules level?

Again, I apologize if this rudimentary for some here :-). I am good with "technology" ;-) ;-) I promise. It's just blanket firewall rule sets, out side of the basic point to point rules are something that are still a bit of a mystery to me. So, I will raise my hand :-)

JW0914 wrote:

The only thing I would recommend is disabling the default rules that are populated under Network >> Firewall >> Rules in LuCI or /etc/config/firewall via cli.  While some users may need those specific default rules, they're also a minor security concern (inbound icmp echo-request from WAN for instance)

Would something like this affect things like upnp, or other "out of the box" features some may expect?

I assume this is the equivalent of disabling a ping from WAN, which of course I do not need (or want).

(Last edited by cybrnook2002 on 3 Nov 2016, 19:05)

@cybrnook2002  LEDE is a forked OpenWrt distro, and, AFAIK, utilizes the same default iptables/fw3 rules implementation.  There's no need to replace them until they switch to netfilter, which is more efficient (multiple iptables rules can be combined into a single netfilter rule)

Thanks JW0914 for taking the time for me (and everyone else in the thread, and the wiki :-) ). I am good, will read up on netfilter now.

cybrnook2002 wrote:

Would something like this affect things like upnp, or other "out of the box" features some may expect?

I assume this is the equivalent of disabling a ping from WAN, which of course I do not need (or want).

UPnP should not be utilized, period, as it's an enormous security risk.  It does take a bit of extra time to configure individual port redirects, but it's the correct way of configuring port forwarding.

  • UPnP, like WPS, was created for user convenience, but at the cost of security

    • IoT devices, for example, are in the exact same boat


--- content removed due to mix up ---

(Last edited by JW0914 on 3 Nov 2016, 21:05)

Yes, I recall seeing the same post you are trying to reference, it's cropped up in here a few times :-)

and reading up on it now, upnp was not something I have explicitly enabled in luci, and from what I am reading, it's not enabled out of the box. So in this case, I should not be using upnp and have not had any negative side affects, nice...

Thanks Again!

(Last edited by cybrnook2002 on 3 Nov 2016, 20:10)

Mixing up terms wink

Nftables replaces iptables, ip6tables, arptables and ebtables.

@sera that I was =]  Thanks!

This is interesting....  a count of the number of IPTables drops for Just destination port 23 (Telnet) to my outside interface, in the past 10 days. The requests are coming various parts, but mainly Russia, France, China etc.

root@lede:/mnt/usb# cat firewallLog.log |grep DPT=23 |wc -l
674

Bad guys are looking for devices that respond on 23. Once found, they try to identify the device and then use known default user/passwords to break in. I'm also seeing other ports as well that are being checked over and over again.

This isn't a ddos attempt, but an attempt to break in to known weak devices, to which once controlled, will become a part of a bot farm.

I have a script that scrubs the logs every night.  Since Sep 1 (top dest ports dropped by firewall, only those with count over 500):

Count by DST port:
  62318 DPT=23
   2752 DPT=2323
   2499 DPT=22
   1550 DPT=3389
   1175 DPT=80
    715 DPT=443
    662 DPT=8080
    631 DPT=53413
    526 DPT=3306

The 53413 was originally a "huh?" moment, but google it -- there's a well-known vulnerability in netis routers.  But yes, in the last few months the telnet traffic has gone through the roof.

Most users never realize just how many exploitive attempts are being seen by their routers every day unless they've specifically enacted logging of all dropped/rejected traffic, or on certain ports. One will also likely see far higher exploitive attempts being made against against a business IP [SOHO/SMB] than a consumer one.

After I first switched to Sophos for my WAN facing router, I configured it to log all blocked traffic and was astonished at the tens of thousands of blocked exploitive attempts that were being made. After analyzing traffic for a few days, it was apparent they were coming mostly out of specific countries and continents, and once I configured country blocking and removed logging for country blocked IPs, the amount dropped down into the thousands.

(Last edited by JW0914 on 4 Nov 2016, 04:05)

Makes me wonder what foolish and irresponsible IOT device manufacturer enabled telnet recently to spawn all the new attempts.

IoT device manufacturers, or car manufacturers for that matter, seem to believe they don't need to properly secure their products,

  • Chrysler was made aware of remote exploits allowing full control of a vehicle, including transmission, and refused to patch their software for 9 months, so the gentleman who did the exploits released it publicly and it was patched within a week

However it's not likely the traffic is due to IoT devices, as this type of penetration testing for exploitative ports has been going on for years... Most simply aren't aware of it because router firewalls normally don't log dropped/rejected traffic, unless one manually configures them to do so.

Too often, public infrastructure servers aren't securely configured for WAN access, and while normal everyday users will be exploited on the happen chance they've misconfigured WAN accessible devices, the main targets are corporations, government, and public infrastructure servers/devices.

(Last edited by JW0914 on 4 Nov 2016, 13:14)

JW0914 wrote:

However it's not likely the traffic is due to IoT devices, as this type of penetration testing for exploitative ports has been going on for years... Most simply aren't aware of it because router firewalls normally don't log dropped/rejected traffic, unless one manually configures them to do so.

I get what you're saying and I didn't mean to imply the traffic is caused by the the IOT devices themselves but more the recent increase in penetration tests/scans for port 23 suggests, at least to me, new devices are being deployed with that port listening.

wink

(Last edited by kirkgbr on 4 Nov 2016, 13:45)

That's unfortunate, both for the obvious reason and because most consumers won't base who they choose to buy IoT devices from on whether or not the manufacturer takes a few minutes to secure the device's networking functions.

There was an article on a tech site posted yesterday about how smart light bulbs can be used, for all intents and purposes, to take down the internet, similar to massive attack back in 2013 that crippled the internet worldwide

(Last edited by JW0914 on 4 Nov 2016, 13:53)

@sera,

Is it possible to use your patch sets with LEDE?  If so, are there any modifications that need to be done?  Sorry if this has been covered before.

Thanks,

Mike

mmcneil wrote:

@sera,

Is it possible to use your patch sets with LEDE?  If so, are there any modifications that need to be done?  Sorry if this has been covered before.

Thanks,

Mike

With some work yes, but as the series is lot about ripping out custom solutions for the sake of custom solutions you will end up pretty much in the same place anyway.  wink

More seriously, doable but not trivial, give it a try and even should you fail you certainly will have learned a few things.

Tryed to upgrade lede

image date:  05-Nov-2016 18:23

root@AC1900M:~# cd /tmp
root@AC1900M:/tmp# sysupgrade -c lede-mvebu-linksys-wrt1900ac-squashfs-sysupgrad
e.bin
Saving config files...
killall: watchdog: no process killed
Sending TERM to remaining processes ... logd rpcd netifd odhcpd crond dnscrypt-proxy uhttpd smbd nmbd collectd dnsmasq ntpd fan_monitor vnstatd sleep ubusd askfirst
Sending KILL to remaining processes ... askfirst
Switching to ramdisk...
Performing system upgrade...
cannot find target partition
@AC1900M:/tmp#

Anyone else see this error?

(Last edited by gufus on 5 Nov 2016, 22:15)