Way, I think it was possible to change the country to wrt3200!

Linux wrt3200acm 4.13.0-rc4 #1 SMP Mon Aug 7 22:53:34 MSK 2017 armv7l GNU/Linux
root@wrt3200acm:~# iw reg get
country RU: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5170 - 5250 @ 80), (N/A, 20), (N/A)
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
        (5650 - 5730 @ 80), (N/A, 30), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)
root@wrt3200acm:~# iw reg set US
root@wrt3200acm:~# iw reg get
country US: DFS-FCC
        (2402 - 2472 @ 40), (N/A, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 23), (N/A)
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS
        (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57240 - 63720 @ 2160), (N/A, 40), (N/A)
root@wrt3200acm:~#

The WRT3200ACm is only available in one version, no v1 or v2 exists.
Every WRT3200ACM has the power and frequency tables locked in firmware and these are not adjustable through firmware.

Well, I'm more interested in having an AC model perform well. How are the wifi drivers for the 3200? After upgrading (or downgrading) to Lede Reboot, my family tells me they can't do facetime or skype on it now. I'm also noticing a lower performance level with it as well.

It sounds like for total control, the 1900ACS just might be the model to stick with. Linksys always seems to end up making changes in this series which ends up crippling the unit (e.g., wrt54x) and things start to go down hill.

(Last edited by langly on 14 Aug 2017, 04:28)

The 3200 has driver issues, and until Marvell fixes the issues, there's little that can be done.  This is quite reminiscent of the driver issues with the 1900 v1, as Linksys jumped the gun, promoting the WRT AC Series as opensource ready when Marvell hadn't signed off.  It took around a year for the 1900 v1 to get a stable driver, so it will likely take just as long with the 3200.

FWIW, I encourage every user with a 3200 to call or email Linksys and complain, as they clearly didn't fully learn from their prior mistake...

(Last edited by JW0914 on 14 Aug 2017, 04:29)

Nor will they ever learn. They're profit driven. I laugh every time I hear people complain about the problems, yet each time they release something new (or give away 50 free units), it's like crack, the consumer knowing the issues goes begging for more and the mfg. keeps making more. So neither side learns.

When it comes to niche products, such as the WRT AC Series, feedback, such as complaints, usually resonate, especially if their executive resolutions department is flooded with complaints.

The driver issue is a Marvell issue, whereas the issue with Linksys is they've pushed products out as opensource when their radio manufacturer, Marvell, hasn't, and hadn't, signed off on their [Marvell's] drivers being opensource.

(Last edited by JW0914 on 14 Aug 2017, 04:45)

This has nothing to do with routers running 3rd party firmware...

It's analogous to saying Ubuntu addressed security vulnerabilities, so people running Arch need to be aware. LEDE is a completely different code base, not to mention far more secure from the get go than OEM firmware from router manufacturers.

Please use proper code tags for URLs

(Last edited by JW0914 on 15 Aug 2017, 23:46)

Sorry about that. I thought it may be useful when folks want to flash stock to update to a newer version of LEDE (this is users who prefer to keep a running stock on one of the partitions). I've deleted my post.

@smmankad That would be information for adding to the wiki under flashing Linksys OEM firmware

@JW0914 Got it. Thank you!

@smmankad I noticed you hadn't added the info to the Wiki, so I updated the Linksys OEM Builds section with updated image links, and added Repository and Release Notes links. 

• I was originally going to place the changes under the Flashing Firmware OpenWrt >> OEM section, however after fully reading the Advisory, it became apparent it belonged under the Firmware Images section.

• I did not link to the advisory because it's not specific, not all WRT builds are affected, and different WRT builds were subjected to different patches, combined with Linksys not elaborating on what needed patching, why it needed patching, or what was patched.
  

  • The advisory points users to the Repository pages for each WRT AC Series router and to the Release Notes for the individual versions.  Since the Advisory is really just an ambiguous Release Notes annotation, it didn't make sense to link to it, combined with the fact that as soon as Linksys releases a firmware update, that advisory becomes moot.

I do know some members choose to leave the OEM firmware on the alt partition, however, in my personal opinion and from a security standpoint, that's unwise to do because the OEM firmware is not, and never will be, a secure router OS.  IIRC, UPnP, possibly WPS and WEP, are enabled by default, with all three being major security risks... convenient, yes, secure, no. 

• Additionally, the OEM firmware cripples the router, with OpenWrt/LEDE/DD-WRT not only able to do more than the OEM firmware can do, LuCI alone is far more intuitive than the ridiculous layout of the OEM firmware's WebUI.
  

  • The only thing a user loses by not using the OEM firmware is the mobile app.
    

    • It's likely it's only a matter of time before someone creates a mobile app for LEDE, especially with the renewed popularity of the OpenWrt code base due to the WRT AC Series.

• I also believe it to be unwise since the alt partition will be auto switched to upon 3 failed boots, defaulting the router to it's factory state.

(Last edited by JW0914 on 16 Aug 2017, 16:39)

@JW0914 Thank you! (Something from work came up, and I couldn't get around to it in time).

I agree with your assessment regarding the stock FW. I have been mulling over getting rid of it on the alt partition altogether and just have LEDE on both (one version will be older, of course, since flashing will always occur on the non-current partition, unless you flash the same version twice to keep both partitions at par)

Now if only we could figure out why the WRT1900ACv1 is not very much liked by the 4.9.x kernel (DDWRT/LEDE). I recently used the 4.11.x kernel on the router via McDebian. Worked flawlessly.

Hey guys, first time poster and WRT3200ACM owner here.

I have not used my USB-TTL Adapter until yesterday and noticed something regarding flashing the stock firmware via serial/tftp:

The stock firmware would not boot completely (hanging on wan, sysevent received: phylink_wan_state) unless I deliberately resetted the device via the reset switch after flashing (pressing it for 10 seconds on reboot after flashing). Simply entering reset in uboot did not do the trick, resetting the uboot environment to default did nothing either.

This led to a few hours of troubleshooting on my part where I flashed back and forth between lede and stock several times (lede always booted instantly, no need to reset there) and redownloading the stock firmware several times, thinking my image was corrupt.

So someone may want to add this information to the wiki, since this happened with all the firmware versions I have tried (thinking it might have been a version-specific bug I tried older revisions as well), helping someone save precious time.

EDIT: I just added it to the wiki myself, I guess thats allowed.

(Last edited by Flynn84 on 22 Aug 2017, 17:58)

@Flynn84 Please post all serial output within code brackets, starting from the first setenv command, as there shouldn't be any need to press the reset button if it's flashed correctly.

• In the future, please wait for someone to confirm/verify whether an issue is an issue, or whether it's user error/environment specific before adding specific troubleshooting information to the wiki. 
  

  • The reasoning isn't to discourage you or anyone from adding to the wiki, as the more people that contribute, the better; however when it comes to troubleshooting information, until someone else can verify/replicate, there's no way to know for sure whether the issue is user error/environment specific.  This leads to unnecessary reversions in the wiki should an issue prove to be user error/environment specific after being added to the wiki.

(Last edited by JW0914 on 22 Aug 2017, 21:45)

Alright, I do understand. Flashing the lede and stock images went without an error and brought me back to the "Marvell>>" prompt after confirming the flash with OK. I unfortunately did not save the console output. I also did not read it very carefully, however, it looked like booting just stopped for no apparent reason (This was after the boot image already loaded up with the Linksys ASCII-logo).

I will redo flashing once I have some time on my hands again and will get back to you. It might have been my error the whole time, but I did everything according to the wiki and the lede-image booted flawlessly.

Cheers

(Last edited by Flynn84 on 23 Aug 2017, 00:21)

Hello

       Is there a way to disable wireless login management and only have the login management on ethernet(lan) ports??

Thank you

You'll need to configure a vSwitch & vLAN if wishing to restrict it to a specific number of LAN ports, else if you simply want it accessible only through ethernet, but don't wish to restrict it to a specific LAN port(s), you'll simply need to create a vLAN without a vSwitch

• If you're using Windows, Windows doesn't natively support virtual interfaces, however the TAP creation script from OpenVPN can be used to create one. 
  

  1. Install the OpenVPN client software,

  2. Execute as Admin: C:\Program Files\TAP-Windows\bin\addtap.bat

  3. Navigate to: Control Panel\Network and Internet\Network Connections,
     right click on the newly created interface, and select Properties >> Configure >> Advanced
     

     • Assign it a 12 digit MAC address (A -F, 0-9)

     • Change Media Status to Always Connected, then select OK

  4. Open up the adapter's properties again.
     

     • Highlight Internet Protocol Version 4 (TCP/IPv4) and select Properties

     • Assign it a static IP and subnet mask that's within the new admin network, which, with the configs below, would be:
       

       • IP: 192.168.2.2

       • Subnet Mask: 255.255.255.248

       • Default Gateway 192.168.2.1

       • Do not set a DNS server address

     • Select OK, then Yes at the Warning dialogue warning of multiple gateways.

w/o vSwitch

/etc/config/network

    # LAN: Management #
#---------------------------------------------------
config interface 'admin'
    option  proto           'static'
    option  ipaddr          192.168.2.1
    option  netmask         255.255.255.248
    option  broadcast       192.168.2.7
    option  delegate        0

/etc/config/dhcp

    # LAN: Management #
#---------------------------------------------------
config dhcp 'admin'
    option  interface       'admin'
    option  leasetime       '24h'
    option  start           2
    option  limit           5
    option  force           1

/etc/config/firewall

    # LAN: Management #
#---------------------------------------------------
config zone
    option  name            'Admin'
    option  network         'admin'
    option  input           'REJECT'
    option  output          'ACCEPT'
    option  forward         'REJECT'

• You could technically set output to reject as well, however this would prevent you from multi-hopping or connecting to any device upstream.

• Also, if you're exposing SSH to WAN, do so via a port redirect by selecting a high port that's listed as unknown from this list (preferable north of 40,000)

SSH Server

• DropBear:: /etc/config/dropbear
  

  • Add:    option  Interface           'admin'

• OpenSSH:  /etc/ssh/sshd_config
  

  • Add: ListenAddress                 = 192.168.2.1

Once all config file edits have been made, issue the following:

/etc/init.d/network reload ; /etc/init.d/odhcpd restart ; /etc/init.d/dnsmasq restart ; /etc/init.d/firewall reload ; /etc/init.d/dropbear restart ; /etc/init.d/sshd restart

• I've included dnsmasq and openssh in the above in case you're using either

(Last edited by JW0914 on 23 Aug 2017, 06:25)

thank you JW0914, much appreciated

@gimbleguy No problem at all.  I'm assuming you want it accessible only over LAN for security concerns, however, provided it's configured with a 2048bit key that's also protected with a secure password, there's zero chance of an unauthorized person gaining access to SSH.

I would recommend switching to OpenSSH over DropBear as OpenSSH provides more functionality and far greater security controls.  If you do choose to switch, here is the config I recommend using:

/etc/ssh/sshd_config

#

     ##::[[---  LEDE OpenSSH Config  ---]]::##

####################################################
           ##----- Global Options -----##
####################################################

    # Connection #
#---------------------------------------------------
AddressFamily                     = inet

Port                              = 64947
ListenAddress                     = 192.168.2.1


    # Encryption #
#---------------------------------------------------
Protocol                          = 2

AuthorizedKeysFile                = /home/%u/.ssh/authorized_keys

HostKey                           = /etc/ssh/ids/ssh_host_rsa_key
HostKey                           = /etc/ssh/ids/ssh_host_ed25519_key

RekeyLimit                        = 100M 30m


    # Authentication #
#---------------------------------------------------
AllowUsers                        = user1

ChallengeResponseAuthentication   = no
KbdInteractiveAuthentication      = no
PasswordAuthentication            = no

PermitEmptyPasswords              = no
PubkeyAuthentication              = yes

StrictModes                       = yes

LoginGraceTime                    = 30

MaxAuthTries                      = 3
MaxSessions                       = 10
MaxStartups                       = 3:30:10

PermitRootLogin                   = no


    # Reliability #
#---------------------------------------------------
ClientAliveCountMax               = 3
ClientAliveInterval               = 600

TCPKeepAlive                      = yes
UseDNS                            = yes


    # Security #
#---------------------------------------------------
AllowAgentForwarding              = yes
AllowTcpForwarding                = yes

GatewayPorts                      = clientspecified
PermitTunnel                      = yes

Subsystem sftp                    = /usr/lib/sftp-server


    # Logging #
#---------------------------------------------------
SyslogFacility                    = AUTH
LogLevel                          = VERBOSE

PidFile                           = /tmp/run/sshd.pid


    # Environment #
#---------------------------------------------------
#PermitUserRC                     = yes


    # Ciphers and ReKeying #
#---------------------------------------------------
FingerprintHash                   = sha256

Ciphers                           = aes256-gcm@openssh.com,rijndael-cbc@lysator.liu.se,aes256-cbc,aes192-cbc,aes128-cbc

HostKeyAlgorithms                 = ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

HostbasedAcceptedKeyTypes         = ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

KexAlgorithms                     = curve25519-sha256@libssh.org,curve25519-sha256,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521

MACs                              = hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512

PubkeyAcceptedKeyTypes            = ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

• This requires adding a user (user1 as an example), as root should not be allowed access to login via ssh, creating a group named sudo, adding the new user to group sudo, then installing the sudo pkg

%UserProfile%\.ssh\config (OpenSSH for Windows)

#

    ##::[[---  Windows OpenSSH Config  ---]]::##

####################################################
               ##----- Custom -----##
####################################################

UserKnownHostsFile                = ~\.ssh\known_hosts


####################################################
               ##----- Hosts -----##
####################################################

  # You'll need to create the directory:
    # ~\.ssh\ids\<remote hostname/IP>\<remote user>\SSH_User_Key_2r
      # "_2r" identifies the key as 2048bit RSA, with "_2e" being ED25519

  # PowerShell recognizes ~ as %UserProfile%

    # PowerShell should be set to replace Command Prompt in Settings
      # Certain cli programs will not launch when issued in PowerShell;
      # simply preface the command with: cmd /c <cli program>

  # Using hosts, one can simply issue the host variable to connect: ssh ACS


    # WRT1900ACS #
#---------------------------------------------------

  # Local:
Host                              ACS
  Hostname                        LEDE.WRT
  Port                            64947
  User                            user1
  IdentityFile                    %d\.ssh\ids\local\%h\%r\WRT1900ACS_2r

  # Remote:
Host                              ACSR
  Hostname                        your.ddns.com
  Port                            64947
  User                            user1
  IdentityFile                    %d\.ssh\ids\remote\%h\%r\WRT1900ACS_2r


####################################################
              ##----- Options -----##
####################################################

    # Connection #
#---------------------------------------------------
AddressFamily                     = inet


    # Encryption #
#---------------------------------------------------
RekeyLimit                        = 500M 30m


    # Authentication #
#---------------------------------------------------
ChallengeResponseAuthentication   = no
KbdInteractiveAuthentication      = no
PasswordAuthentication            = no

PreferredAuthentications          = publickey
PubkeyAuthentication              = yes
AddKeysToAgent                    = ask


    # Reliability #
#---------------------------------------------------
TCPKeepAlive                      = yes


    # Security #
#---------------------------------------------------
ForwardAgent                      = yes
ForwardX11                        = yes

GatewayPorts                      = no

HashKnownHosts                    = yes
StrictHostKeyChecking             = ask


    # Logging #
#---------------------------------------------------
SyslogFacility                    = AUTH
LogLevel                          = VERBOSE


    # Environment #
#---------------------------------------------------

  # Disabled:
    ## PermitUserRC               = yes


    # Ciphers and ReKeying #
#---------------------------------------------------
FingerprintHash                   = sha256

Ciphers                           = rijndael-cbc@lysator.liu.se,aes256-cbc,aes192-cbc,aes128-cbc

HostKeyAlgorithms                 = ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

HostbasedKeyTypes                 = ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

KexAlgorithms                     = curve25519-sha256@libssh.org,curve25519-sha256,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521

MACs                              = hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512

PubkeyAcceptedKeyTypes            = ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

/etc/sudo

#

     ##::[[---  LEDE Sudoers Config  ---]]::##

####################################################
           ##----- Active Options -----##
####################################################

  # This file MUST be edited by root via `visudo`

    # Failure to use `visudo` results in syntax / file
    # permission errors preventing sudo from running

  # Man pages #
    # sudoers: www.sudo.ws/man/1.8.15/sudoers.man.html
    # sudo.conf: www.sudo.ws/man/1.8.15/sudo.conf.man.html


    # Defaults Specification #
#---------------------------------------------------
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/sbin:/usr/bin:/sbin:/bin"
Defaults        targetpw


    # User Privilege Specification #
#---------------------------------------------------

# Users:
root            ALL=(ALL:ALL) ALL

# Groups:
%sudo           ALL=(ALL:ALL) ALL

• Must have permissions set to 440

Once added, run the following script:

#!/bin/sh

    # Sudo #
#---------------------------------------------------

# Sudoers

  # Permissions #
    chmod 440 /etc/sudo


    # OpenSSH #
#---------------------------------------------------

# Keys #

  # Generate 2048 RSA #
    ssh-keygen -b 2048 -t rsa -E sha256 -C "WRT1900ACS OpenSSH Server RSA" -f /etc/ssh/ids/ssh_host_rsa_key

  # Generate 2048 ED25519 #
    ssh-keygen -t ed25519 -E sha256 -C "WRT1900ACS OpenSSH Server ED25519" -f /etc/ssh/ids/ssh_host_ed25519_key

  # Permissions #
    chmod 600 /etc/ssh/ids/*_key


# .ssh #

  # root:
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys
    ln -s /root /home/root

  # user1:
    chown -R user1:user1 /home/user1
    chmod 700 /home/user1/.ssh
    chmod 600 /home/user1/.ssh/authorized_keys


# Restart OpenSSH #
  /etc/init.d/sshd restart


# Moduli #

  # Generate:
    ssh-keygen -G moduli-2048.candidates -b 2048

  # Select Candidates:
    ssh-keygen -T moduli-2048 -f moduli-2048.candidates

  # Backup:
    cp /etc/ssh/moduli /etc/ssh/moduli.orig && rm -f /etc/ssh/moduli

  # Replace:
    cp /etc/ssh/moduli-2048 /etc/ssh/moduli && rm -f /etc/ssh/moduli-2048


# Restart OpenSSH #
  /etc/init.d/sshd restart

(Last edited by JW0914 on 24 Aug 2017, 01:12)

oh I didn't know that, switching to Openssh today hopefully. I will follow your guide. Thank you JW0914

No problem at all.

If you decide to also install OpenSSH on Windows, let me know and I can provide the Windows OpenSSH server config I use, as well as a few additional commands to secure the host keys by using PsExe to run the SSH-Add command as NT Service/System

You'll also need to install

• shadow-useradd in order to add a user specifically for SSH, which will need to have a unique password set in order to properly use sudo.

• OpenSSH-moduli package, as generating a moduli with an ARM processor will take a very long time.  This moduli needs to be at /etc/ssh/moduli before running the script in my prior post.

If you plan on using the Hosts section in the client config I posted in my prior post, you'll need to configure static IPs on the router, then add the local hostnames.domain to the Windows host file in the format of:
<IP>    <HostName>    <HostName.DomainName>

• HostName: what you name the static IP on the router

• Local DomainName: what you set under Local Domain in LuCI or Domain in /etc/config/dhcp

C:\Windows\System32\drivers\etc\hosts

#

     ##::[[---  Windows Host Config  ---]]::##

####################################################
         ##----- Windows OS Entries -----##
####################################################

    # Loopback #
#---------------------------------------------------
127.0.0.1         localhost
::1               localhost


####################################################
                ##----- LAN -----##
####################################################

    # Sophos UTM #
#---------------------------------------------------
192.168.200.100   FreeNAS     FreeNAS.UTM


    # WRT1900ACS #
#---------------------------------------------------

  # Admin:
192.168.20.1      LEDE        LEDE.WRT
192.168.20.3      ESXi0       ESXi0.WRT
192.168.20.4      ESXi1       ESXi1.WRT
192.168.20.5      C27500      C27500.WRT
192.168.20.6      C27501      C27501.WRT
192.168.20.7      2758F       2758F.WRT
192.168.20.10     FreeNAS0    FreeNAS0.WRT


  # Android:
192.168.6.2       NX6         NX6.WRT
192.168.6.3       XT926       XT926.WRT


  # LAN:
192.168.200.1     UTM         UTM.WRT
192.168.200.2     18L         18L.WRT
192.168.200.3     18W         18W.WRT


  # Media:
192.168.255.2     AVR         AVR.WRT
192.168.255.3     HR54        HR54.WRT
192.168.255.4     JSL         JSL.WRT
192.168.255.5     JSW         JSW.WRT
192.168.255.6     PS          PS.WRT
192.168.255.7     PSS         PSS.WRT
192.168.255.8     PSL         PSL.WRT
192.168.255.9     PSW         PSW.WRT
192.168.255.10    XB3         XB3.WRT
192.168.255.11    XBL         XBL.WRT
192.168.255.12    XBW         XBW.WRT
192.168.255.13    Wii         Wii.WRT
192.168.255.14    HE          HE.WRT
192.168.255.15    HH          HH.WRT


  # Printers:
192.168.250.2     MF8380      MF8380.WRT
192.168.250.3     18-MF8380   18-MF8380.WRT

(Last edited by JW0914 on 24 Aug 2017, 01:10)

So I have come around to trying to reproduce the stock image not booting. I have one problem now: I don't seem to be able to set the boot partition in uboot. As far as I understand it, the command should be setenv boot_part x for x=1 or 2. But it seems like the router always boots in my already configured stock image on the second partition (because it initializes the wifi networks with my personal ssids instead of the default ones). Am I missing something here?

Also does there exist any documentation for the uboot commands? As far as I understand the uboot in this router is modified with custom commands so the default uboot documentation is kinda useless.

I can't post my minicom output at the moment because I am not allowed to post links. What qualifies as a link so that I can remove it from the log?

(Last edited by Flynn84 on 24 Aug 2017, 16:50)

@Flynn84 Copy the serial output and paste it within code brackets in your reply.  If you're using PuTTY, you can set the log location under Session > Logging.

As to the boot commands: run_linksysnandboot (primary partition) OR run_linksysaltnandboot (backup partition)

I tried it with the code brackets and it did not work. There is also nothing in that console output which prematurely ends the coding bracket or something like that. I just pastebinned it now (available for 10 mins): pastebin/SQsaJRBY

Anyways this is probably obsolete now anyways, I will try using your commands now. As I am on Linux I use minicom -C /folder/file.txt which does the same.

EDIT: Sorry for the low retention time on that pastebin but it should not be of any use anyways. the commands for my uboot are run nandboot and run altnandboot and not "linksysnandboot".

(Last edited by Flynn84 on 24 Aug 2017, 17:26)

You're not doing something right then... paste the serial output in the reply message box, select all text, then select the <> button in the formatting bar, above the message box.