search

Chadster766 / McDebian

Linksys WRT3200ACM, WRT1900AC, WRT1900ACS, WRT1200AC and WRT32X Router Debian Implementation
98 stars 14 forks source link

McDebian 4.19.12 Beta #50

Closed Chadster766 closed 5 years ago

Chadster766 commented 5 years ago

McDebian 4.19.12 Beta

Updates:

Notes:

I recommend that only users that have TTL access to their WRT routers do McDebian beta testing.

In the WRT1900AC V1 make sure you have the below u-boot envars set to to accommodate the increased kernel size.

#This is what I have my WRT1900AC V1 u-boot kernel size set for
root@MCDEBIAN:~# fw_printenv pri_kern_size
pri_kern_size=0x500000
root@MCDEBIAN:~# fw_printenv alt_kern_size
alt_kern_size=0x500000

Firmware:

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Stretch-WRT1900AC-V1-FW_VER1_kernel_4.19.12.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Stretch-WRT1900AC-V2-FW_VER1_kernel_4.19.12.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Stretch-WRT1200AC-V1-FW_VER1_kernel_4.19.12.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Stretch-WRT3200ACM-V1-FW_VER1_kernel_4.19.12.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Stretch-WRT32X-V1-FW_VER1_kernel_4.19.12.img

Root File System:

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/rootfs/mcdebian-stretch-router-WRT-1900-1200-3200-32x-Kernel_4_19_12-base.gz

IPv6

To enable IPv6 in this beta release you need to enable radvd:

systemctl enable radvd

Then uncomment the IPv6 config lines in:

vim /etc/default/isc-dhcp-server

After that reboot the router.

ValCher1961 commented 5 years ago

Hi Chadster766! I also collected the 4.19.12 core for testing. The first thing I encountered is the message in the log -

netlink: 'hostapd': attribute type 213 has an invalid length.

At Work Wi-Fi this did not affect, updated HOSAPD to version 2.7 and the message disappeared.

Still noticed, the thermal profile of the Armada has changed, the temperature on the processor has fallen and now in the "normal " mode is not used in the area of 60 C.

Chadster766 commented 5 years ago

Thanks for the info.

If I remember correctly I discovered that in 4.14.x and moved McDebian to hostapd v2.6 at the time to resolve the issue.

ValCher1961 commented 5 years ago

Yes, and now 2.7

Chadster766 commented 5 years ago

I didn't like the fact Hostapd v2.7 didn't work with Debian Stretch out of the box and that many workarounds would have to take place to make it work.

Instead I chose to pull Hostapd v2.6 from Debian Buster development which is designed for the Debian systemd process.

ValCher1961 commented 5 years ago

I also HOSTAPD-2.7 did not get up "out of the box ", had to assemble it from the source and just copy the two files "hostapd" and "hostapd_cli" in /usr/sbin/

popoviciri commented 5 years ago

Resurrected my WRT1900ACSv1 to try this out. Thanks Chad! As is, it works out of the box with these problems:

[ 1.481720] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 1.490384] platform regulatory.0: Falling back to syfs fallback for: regulatory.db

seems to be related with crda: link but doesn't seem to affect the overall function of the wrt box.

[ 0.047747] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 0.047754] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring

Cheers! radu

Chadster766 commented 5 years ago
  • I do not have the line reported by @ValCher1961 in my logs. Only line with word "invalid" are:

[ 0.047747] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 0.047754] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring

This is a only a notification due to the bridges interfaces coming up at different stages of the boot sequence.

Chadster766 commented 5 years ago

[ 1.481720] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 1.490384] platform regulatory.0: Falling back to syfs fallback for: regulatory.db

seems to be related with crda: link but doesn't seem to affect the overall function of the wrt box.

Yeah I don't think it's much of an issue since the wireless operates properly regardless.

Chadster766 commented 5 years ago
  • wifi bad as usual (mwlwifi problem); reason i gave up trying to get this unit work. Though using lower 5G channels seem to work better. Perhaps I should figure out how to properly configure the wifi.

What issue are you having with the wireless? I would like to troubleshoot them if possible.

Chadster766 commented 5 years ago
  • had to disable ipv6 in modprobe.d with "options ipv6 disable_ipv6=1" and "blacklist ipv6" (have my reasons to disable ipv6). I see "radvd" must be enabled to use ipv6 but even without doing so I'm getting ipv6 address despite my linux box does not assign any. I have ipv6.disable=1 in U-boot, but somehow this gets skipped and I'm still assigned ipv6's on all interfaces.

The base configuration for this version of McDebian is to have auto generated IPv6 link-local ( fe80::x) addresses on all interfaces which doesn't effect anything and is spec for networking these days.

The WAN interface is set to receive SLAAC IPv6. The firewall is configured for an IPv6 NAT and to Firewall IPv6.

The LAN br0 interfaces is configured with a ULA IPv6 address (Private IPv6 Address) fc00::1.

If you enable IPv6 as stated in the original post the Internet will only see the WAN SLAAC address and the LAN will be behind NAT on IPv6 private network fc00::\64.

Chadster766 commented 5 years ago
  • AP mode not working without this in /etc/network/interfaces: iface wan inet manual > pre-up ifup br0. I don't understand why, since "wan" is assigned to the bridge. Took many hours to figure this out. But hey, it's holiday! So time for nerding...

Interesting I haven't tested an AP mode with the beta yet. I will get back to you once I give it a try :smile:

popoviciri commented 5 years ago
  • wifi bad as usual (mwlwifi problem); reason i gave up trying to get this unit work. Though using lower 5G channels seem to work better. Perhaps I should figure out how to properly configure the wifi.

What issue are you having with the wireless? I would like to troubleshoot them if possible.

Where do I start? :) For starters, I can only set the 149-155 channels in 5Gz band (besides the 36-42 you have set it with). I did try other combinations, but hostapd fails with "Hardware does not support configured channel". Moving on, say we stay on 149-155, though no android sees it, from my PC (with Intel AC-9260) I'm getting these numbers with iperf3 (WRT right next to my PC):

popoviciri commented 5 years ago

Thanks for the ipv6 course. Didn't know about SLAAC. I though the whole ipv6 idea was that NAT-ing is not necessary. I'll read more into this. Thanks!

ValCher1961 commented 5 years ago

Hi @popoviciri ,

I can only set the 149-155 channels in 5Gz band

Check your region settings and see what this command will produce. iw phy |grep MHz

popoviciri commented 5 years ago

Hi @popoviciri ,

I can only set the 149-155 channels in 5Gz band

Check your region settings and see what this command will produce. iw phy |grep MHz

Right, I get all DFS channels except 36 and 149

             * short GI for 40 MHz
                   short GI (80 MHz)
                   * 5180 MHz [36] (20.0 dBm)
                   * 5200 MHz [40] (20.0 dBm)
                   * 5220 MHz [44] (20.0 dBm)
                   * 5240 MHz [48] (20.0 dBm)
                   * 5260 MHz [52] (20.0 dBm) (radar detection)
                   * 5280 MHz [56] (20.0 dBm) (radar detection)
                   * 5300 MHz [60] (20.0 dBm) (radar detection)
                   * 5320 MHz [64] (20.0 dBm) (radar detection)
                   * 5500 MHz [100] (27.0 dBm) (radar detection)
                   * 5520 MHz [104] (27.0 dBm) (radar detection)
                   * 5540 MHz [108] (27.0 dBm) (radar detection)
                   * 5560 MHz [112] (27.0 dBm) (radar detection)
                   * 5580 MHz [116] (27.0 dBm) (radar detection)
                   * 5600 MHz [120] (27.0 dBm) (radar detection)
                   * 5620 MHz [124] (27.0 dBm) (radar detection)
                   * 5640 MHz [128] (27.0 dBm) (radar detection)
                   * 5660 MHz [132] (27.0 dBm) (radar detection)
                   * 5680 MHz [136] (27.0 dBm) (radar detection)
                   * 5700 MHz [140] (27.0 dBm) (radar detection)
                   * 5720 MHz [144] (disabled)
                   * 5745 MHz [149] (13.0 dBm)
                   * 5765 MHz [153] (13.0 dBm)
                   * 5785 MHz [157] (13.0 dBm)
                   * 5805 MHz [161] (13.0 dBm)
              total <= 16, #channels <= 1, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 160 MHz }

Enabled DFS with (reference):

ieee80211d=1 ieee80211h=1

and managed to connect the PC (Intel AC-9260) to channel 116-122. My android phone also connected to this. Iperf3 results:

Still pitiful...

xiaojx75 commented 5 years ago

Hello Sir, can you add wireguard support in the kernel?

Chadster766 commented 5 years ago

Iperf3 results:

  • PC to linux box (WRT wired to linux router):

0.00-10.16 sec 16.7 MBytes 13.8 Mbits/sec

  • PC to WRT (next to each-other):

0.00-10.17 sec 14.2 MBytes 11.7 Mbits/sec

Still pitiful...

Below are the 5Ghz (McDebian wireless defaults) iperf3 results I get from the WRT1900ACS to a Linux PC:

root@McDebian3:~# iperf3 -c 192.168.1.1 -R
Connecting to host 192.168.1.1, port 5201
Reverse mode, remote host 192.168.1.1 is sending
[  4] local 192.168.1.7 port 46734 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  24.3 MBytes   204 Mbits/sec
[  4]   1.00-2.00   sec  26.3 MBytes   221 Mbits/sec
[  4]   2.00-3.00   sec  32.7 MBytes   274 Mbits/sec
[  4]   3.00-4.00   sec  32.6 MBytes   274 Mbits/sec
[  4]   4.00-5.00   sec  32.6 MBytes   274 Mbits/sec
[  4]   5.00-6.00   sec  32.7 MBytes   274 Mbits/sec
[  4]   6.00-7.00   sec  32.7 MBytes   275 Mbits/sec
[  4]   7.00-8.00   sec  32.3 MBytes   271 Mbits/sec
[  4]   8.00-9.00   sec  31.8 MBytes   266 Mbits/sec
[  4]   9.00-10.00  sec  32.3 MBytes   271 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   314 MBytes   263 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   311 MBytes   261 Mbits/sec                  receiver

iperf Done.
root@McDebian3:~# iwconfig
enxc8d719be5f91  IEEE 802.11AC  ESSID:"McDebian50"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.18 GHz  Access Point: 00:25:9C:13:CE:2D
          Bit Rate:867 Mb/s   Sensitivity:0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=100/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Chadster766 commented 5 years ago

Hello Sir, can you add wireguard support in the kernel?

It looks like all the WireGuard requirements are already enabled in this beta's Linux kernel.

Chadster766 commented 5 years ago
  • AP mode not working without this in /etc/network/interfaces: iface wan inet manual > pre-up ifup br0. I don't understand why, since "wan" is assigned to the bridge. Took many hours to figure this out. But hey, it's holiday! So time for nerding...

I tested a successful WAN AP mode with the below config:

auto wan
#iface wan inet dhcp
iface wan inet manual
        #pre-up iptables-restore < /etc/iptables.up.rules
        pre-up ifup br0

iface wan inet6 auto
        #pre-up ip6tables-restore < /etc/ip6tables.up.rules

iface br0 inet static
        bridge_ports lan1 lan2 lan3 lan4 wan
        address 192.168.200.11
        netmask 255.255.255.0
        network 192.168.200.0
        broadcast 192.168.200.255
        gateway 192.168.200.1
        pre-up /etc/network/mcdebian-model-check

AND

systemctl disable isc-dhcp-server

Keep in mind that for each WRT acting as an AP on the network will have to have unique local mac addresses specified in /etc/network/mcdebian-model-check.

popoviciri commented 5 years ago

That works for me too, though I don't understand why. Having this: pre-up ifup br0 under wan interface setup, while wan is part of the bridge? Anyway, after more testing, I noticed another problem while getting the br0 ip via dhcp. It does work fine, the bridge gets assigned an ip from the router and forwards requests to and from all wired devices. The only problem I have is when I connect wireless to the WRT. For some reason, the DHCP requests are not being forwarded through wlp1s0. This is my config:

auto wan
iface wan inet manual
        pre-up ifup br0
iface br0 inet dhcp
        bridge_ports wan lan1 lan2 lan3 lan4
        pre-up /etc/network/mcdebian-model-check

Likely I'm doing something wrong, because this worked yesterday :D. I'll keep testing and report back here. Meanwhile, I have rsyslog collecting info...

popoviciri commented 5 years ago

I managed to get AP-mode working and all connections (wired or over wifi) are being forwarded correctly. My final /etc/network/interfaces file working in AP-mode (default works great for a router, by the way):

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo eth0 eth1 wan lan1 lan2 lan3 lan4
iface lo inet loopback

iface eth0 inet manual
iface eth1 inet manual
iface lan1 inet manual
iface lan2 inet manual
iface lan3 inet manual
iface lan4 inet manual
iface wlp1s0 inet manual
iface wlp2s0 inet manual

iface wan inet manual
  pre-up ifup br0

iface br0 inet dhcp
  bridge_ports wan lan1 lan2 lan3 lan4
  pre-up /etc/network/mcdebian-model-check

I cannot find a problem with this beta on my WRT1900ACSv1. Been running good in AP mode, with wifi and is stable. I'm thinking to move the filesystem on SSD via the eSATA port as I had it a while ago and put this box to some good use. Thanks @Chadster766, cheers!

popoviciri commented 5 years ago

One more thing: after re-soldering a CAP loose I found inside of the box, here are the iperf results via wifi 5GHz 149-155 channels:

Chadster766 commented 5 years ago

Well done

xiaojx75 commented 5 years ago

Hello Sir, can you add wireguard support in the kernel?

It looks like all the WireGuard requirements are already enabled in this beta's Linux kernel.

Hi I had tried to use dkms to install wireguard module but failed, It seems the wireguard patches still not officially merged into the kernel. I like to use debian on my WRT3200ACM but wireguard is aslo necessary, I am in China, I need to use wireguard pass through The GFW. thanks in advance

ValCher1961 commented 5 years ago

Wireguard support is not yet in the cores 4.19 and 4.20, can later add. https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-Not-In-4.20

Chadster766 commented 5 years ago

Hello Sir, can you add wireguard support in the kernel?

It looks like all the WireGuard requirements are already enabled in this beta's Linux kernel.

Hi I had tried to use dkms to install wireguard module but failed, It seems the wireguard patches still not officially merged into the kernel. I like to use debian on my WRT3200ACM but wireguard is aslo necessary, I am in China, I need to use wireguard pass through The GFW. thanks in advance

I did some testing with this. I would have to built this from source to get it to work.

Couldn't you use OpenVPN instead?

xiaojx75 commented 5 years ago

openvpn protocol was too easier to be blocked by GFW,even changing ports can work only few days. I currently use wireguard in openwrt gorgeous several month which works good with good throughout. thanks in advance if you can compile thus module into the kernel. 发自我的华为手机-------- 原始邮件 --------主题：Re: [Chadster766/McDebian] McDebian 4.19.12 Beta (#50)发件人：Chad McCue 收件人：Chadster766/McDebian 抄送：xiaojx75 ,Comment

Hello Sir, can you add wireguard support in the kernel?

It looks like all the WireGuard requirements are already enabled in this beta's Linux kernel.

Hi I had tried to use dkms to install wireguard module but failed, It seems the wireguard patches still not officially merged into the kernel. I like to use debian on my WRT3200ACM but wireguard is aslo necessary, I am in China, I need to use wireguard pass through The GFW. thanks in advance

I did some testing with this. I would have to built this from source to get it to work. Couldn't you use OpenVPN instead?

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

Chadster766 commented 5 years ago

I've discovered that if the beta doesn't have an Ethernet connection on br0 the wan interface will not come up and networking service will fail. This is important if you configure a WRT in an AP mode with only the wan interface connected to the upstream network.

To resolve this issue add "--ignore-errors" to the wan section of /etc/network/interfaces:

auto wan
iface wan inet dhcp
        pre-up iptables-restore < /etc/iptables.up.rules
        pre-up ifup --ignore-errors br0
Chadster766 commented 5 years ago

I've modified the kernel compilation Makefiles for Wireguard and have successfully built the module for this kernel version.

I doing QA and the Wireguard module to see how it works with the Debian stretch Wireguard package.

Chadster766 commented 5 years ago

Actual I used the Wireguard kernel patch script and it worked fine. So success on Wireguard.

Are there any specific ciphers you need added to the kernel config. I see a half dozed new ones like ChaCha256

xiaojx75 commented 5 years ago

It's great, Thanks a lot. I will test ASAP. no other cipher needed

Chadster766 commented 5 years ago

Sorry I have release the beta that includes the Wireguard VPN. Which my testing shows is as very high performance VPN and easy to config.

Chadster766 commented 5 years ago

I'm adding and doing QA on MESH wireless networking with some Velop nodes before I release this version.

Chadster766 commented 5 years ago

I keep getting a kernel panic whenever I try to enable wireless MESH. I don't really need it and don't have time to troubleshoot I so I'm moving onto releasing the beta with Wireguard support for testing.

Chadster766 commented 5 years ago

I have updated the download for rootfs and firmwares to include Wireguard module as mentioned in the original post.

This will be the production release if user testing goes well.

Chadster766 commented 5 years ago

Beta testing is complete and this version of McDebian published.