DIR-882 (serial only atm) FW (4.9.60-rc1) [temp post]

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Contributions Upload
Author Message
DD-WRT Novice

Joined: 03 Apr 2010
Posts: 28
Location: edmonton

PostPosted: Fri Nov 03, 2017 18:27    Post subject: DIR-882 (serial only atm) FW (4.9.60-rc1) [temp post] Reply with quote

the RALINK forum seems down or something. i don't know why mitt feels the original thread from being viewed would be a good idea, as it just reinforces the theme they claim isn't true (if it wasn't, why not leave the "quack" to muse and share his work?)

they may disable this post too, so get the FW while you can. small things are left (like setting lan_ipaddr variables before calling /sbin/init, as i don't think the
here's a highly experimental dd-wrt image, based on GLIBC, kernel 4.9.60-rc1, and the uclibc provided in the GPL code (for busybox, which is currently required to boot).

latest FW (serial only atm): https://www.sendspace.com/file/u3u2qc last updated 03112017 02:49GMT
directory tree of latest FW: https://pastebin.com/GqgEUefC last updated 01112017 04:12GMT

BULLETIN BOARD [updated on: 03112017 07:08GMT]

  • it seems calling /sbin/init will now generate a minimal config that enables one to login.
  • i believe the network interfaces are now set up correctly, as the ethernet links are reported upon (dis)connecting the an ethernet cable.
  • [update 03112017 07:08GMT] i think i'm comfortable now in saying "all that is left" is fixing the ugliness of the webgui (httpd), and issues surrounding it. i think this is unique to the particular case of the MT7621. for example...
  • What's Left?

    • issue 1: gui crashes on status bandwidth due to a file descriptor issue <- likely caused by some combination of threading/out-of-order-instruction-execution and file stream operations)
    • issue 2: it looks ugly, although most fields and entries seem to be there. where the heck is all of the text?!
    • issue 3: save and apply buttons, where are they? i suspect this has to do with migrating how the nvram commits, although there shouldn't be an issue here (may even be due to using 'expert mode=1' or smething).

    rt2880 + bcmmodern lol... fucking outrageous...

  • What's Different in your version of DD-WRT compared to the rest?

    • first and foremost: gLIBC 2.26. we disclose briefly disclose noteworthy distinctions, so readers can compare and contrast.

      • bash 4.4.12(1) [bash/bashbug] ("12" implying all 12 patches have been applied).
      • util-linux 2.30.510-323e [libmount/libuuid/liblkid/libfdisk]
      • ncurses 6.0 [libncursestw/libsmartcolstw/libpanel/libformtw] (tw suffix meanes "threaded+wide")
      • glib20 2.52.0 (using wide/threaded curses) [gmodule/gthread/gobject/gio/libiconv/gettext]
      • net-tools 1.60 [ifconfig {1.42}+other stuff]
      • libnl 1.1.4 [libnl.so.1.1.4] (for iw)
      • iw 4.9 [iw]
      • iproute2, iproute2-ss170905 [ip utility {for now; have tc as well}]
      • iptables 1.6.1 [iptables, ip6tables]
      • ebtables 2.0.10-4 [ebtables]
      • libpcap 1.8.1 [libpcap.so] (needed by tcpdump; opted to updated & fix filter bug [tcpdump working as of update on 21102017 23:10 GMT])
      • libdnet 1.10/1.11 [libdnet.so.2.43.2 {unofficial}/libdnet.1.0.1{official}] (1.10 used by common linux distros; 1.11 is OG. kept both to cement DD-WRT's OG status)
      • libgudev-232 [libgudev-1.0.so.0.2.0] (gnome and SysV's seemingly-eternal, yet recently-disturbed [thanks MITT (ROMNEY)*] matrimony needed this)
      • procps 3.2.8 [libproc-3.2.8.so/proc/ps/sysctl] again, their inclusion is justified by the added functionality
      • kmod-2.4 [kmod+{modprobe,depmod,insmod,rmmod,lsmod,modinfo} symlinks] (added functionality over busybox justifies inclusion)
      • pci-utils 3.5.5 [libpci.so.3.5.5] (built with kmod for an immersive experienced)
      • e2fsprogs 1.43.4 [libe2p.so/libext2fs.so]
      • together, the three libraries below lay groundwork for SELinux/Linux-PAM (the latter which i'm ready to serve via ipkg...), so i thought they should be included.

        • libcap 2.25 (capabilities library)
        • libattr 1.43.4 (attributes library)
        • libacl 2.2.52 (access control lists library)

      • sysfsutils v2.1.0 [libsysfs.so] (kong inspired this addition. happy i imitated his style [love u kong;)])
      • file 5.32 [libmagic.so,file] (still limited definitions. add some symlinks in /usr/local/share/misc/magic to increase capabilities!)
        and of course...
      • libqm(FUCKING)i 1.18.0 [libqmi-glib.so.5.2.0,qmicli,qmiproxy,qmi-firmware-update] (because it's DD-WRT and LEGIT NETWORKS people get PRIORITY. not noobs)
      • RALINK RT2800_APPS from 2017 SDK (all built on gLIBC; functional unless otherwise stated.):

        • hw_nat
        • qdma
        • acl0,mtr0,ac0,reg (temporarily removed; looking at why the mknod calls aren't sufficient. seems acl0/ac0/mtr0 are deprecated in face of HNAT_V2/GPL_license; still looking into this. reg/ralink_rdm seems to need an update)
        • [26102017 03:05GMT] internet.sh's call to genDevNode is removed since it's wrong, and we already call makedevlinks.
        • nvram utilities [nvram_daemon/ralink_init]

          • to use the nvram restore in rc, please specify the bank number followed by the file. i.e:
            nvram restore {RT2860_NVRAM,RTDEV_NVRAM, WIFI3_NVRAM, CERT_NVRAM*, CONFIG2_NVRAM} <filepath>

            *CERT_NVRAM is empty, so don't freak out seeing nothing returned (it holds certificates, and CONFIG2 is extended on CERT_NVRAM).
            [UPDATE: 23102017 02:40GMT] additional functionality has been added. by default
            nvram show

            will display all nvram banks. i have added the option to show only ONE bank, specified either by the bank name or number (given in square brackets) as follows:
            nvram show {RT2860_NVRAM [0],RTDEV_NVRAM [1], WIFI3_NVRAM [2], CERT_NVRAM [3], CONFIG2_NVRAM [4]}

          • [01112017 23:08GMT] nvram performance significantly improved by removing commit after each variable is set. users must consciously call nvram commit if they want the variable to persist through restart.
          • restore defaults now fully operational, where rc/services/libutils has full access to RT2860_NVRAM and CONFIG2_NVRAM banks.
          • additional information regarding NVRAM usage

            • however, if users want to set variables via nvram_set (ralink utility) into those banks, services will have no problem reading/using them.
            • if there are no manually-set variables (used by services) on RTDEV/WIFI3/CERT_NVRAM, it will not write to them.
            • i am holding off on using RTDEV/WIFI3/CERT for setting variables, just in case we need them for other things.
            • though it works for restore defaults (arguably a good "stress test") libnvram IS NOT PERFECT. in particular i am still making sure cases where RT2860_NVRAM is full, that the nvram kernel driver will automatically use CONFIG2_NVRAM without crying too much.

              • the (re)main(ing) test case is when restore_defaults isn't used, and RT2860_NVRAM gradually fills up, thereby requiring the library to move to CONFIG2_NVRAM for new variables.
              • [02112017 03:52] HOWEVER, what is super cool, is that there are NO duplicates when using startservice defaults, leading me to believe that the nvram logic will now ensure no entry exists (across all blocks) before creating a new one. here is the pastebin from clearing 2860/config2, followed by calling startservice defaults, followed by printing the banks' output:https://pastebin.com/6uWDBMN7

          • switch [removed switch_7530 for now, even though ralink's config-vlan.sh seems to call switch_7530, whose its ioctls are wrong [dir882's switch is a 7530]).
          • flash (lets you read flash memory in linux; saving you from having to hit up uboot)

          iproute2/iptables may need the odd bug fix, but since minor changes were made to the raw source, i expect them to be functional with slightly richer features (but not by much)

    • Why should I use this version of DD-WRT as opposed to others (assuming availability)?

      • simple answer: don't.
      • i'm neither looking to attract casuals, nor infringe upon territories that my contemporaries have managed so well, for so long.

        • it should be clear that my "target audience" deviates significantly from my contemporaries (if posting serial-only fw files [not deliberately, mind you] didn't signify this already).
        • i hope that, in the near future, when i get the hang of the bare minimums required for basic network interface configuration, this will change. but again: not looking to infringe upon my contemporaries' territories, so it's not a priority

    • So you don't care if I use it, but you're posting like you want me to, what the fuck motivated this undertaking?

      • simple answer: a lot of my interest and involvement in dd-wrt is at the operating systems-level, which is the area of expertise of individuals who influenced me ("bill", and sir tim). i felt building the kernel from scratch for an embedded networking device is the "new frontier" since each radio can be looked at as a CPU, as it must shuttle its data separately from our activities.

        • with our data appetite seemingly growing, the CPU "brick wall" (3.2ish GHZ) going unaddressed, i felt the parallelisation/multiprocessing environment in a networks context would bear fruit at the theoretical (Computing Science) level.
        • there are interesting operating systems paradigms that arise, and i felt the current releases for embedded devices didn't share the same perspective (exception of the Beast known as Padavan; i'd have used his ralink_gpio if it worked with the DIR882, but no LEDs -_-)
        • lastly, i've been a DD-WRT "leech" for over 13 years, and looking at my contemporaries' work (eko/slayer/kong), i was both motivated and inspired to not be a moocher. as an example:

          • my source of inspiration for the recent, yet stripped-down, iptables/iproute2 were their 10 year old makefiles. without them, these programs are approximately five-fold larger. as such, i wanted to "step to the plate" and contribute to their great work, as my work is not possible without their decade-plus dedication to this area. they were doing great work while i was picking my ass, content with being mediocre.

        • in other words, my work is more of a "thank you" to the DD-WRT crew for their great work (evidenced by the stripped down makefiles/custom sources-where-necessary to facilitate reduced size) that many of us enjoy for free (for the most part).

    * "IT'S THE GLOBAL ECKANAMY" <cue gesture:>


    older (but important) post that shows the radios are in full 4x4 mode...:
    important things to note in the bootlog that convey significance are the radios now booting up in full 4x4 mode:

    SYNC - BBP R4 to 20MHz.l
    mt7615_apply_dcoc() : reload Central CH [8] BW [0] from cetral freq [2447] offset [2400]
    MtCmdGetRXDCOCCalResult:(ret = 0)
    mt7615_apply_dpd() : reload Central CH [8] BW [0] from cetral freq [2442] i[45] offset [4bf8]
    MtCmdGetTXDPDCalResult:(ret = 0)
    MtCmdChannelSwitch: control_chl = 8,control_ch2=0, central_chl = 8 DBDCIdx= 0, Band= 0
    BW = 0,TXStream = 4, RXStream = 4, scan(1)

    sing it with me:
    A P S (oh) O C
    show you what you mean to me

    A P S (oh) (oh) CEE-uh!!!

    (log of boot up and initialisation of radios after opening eth2--i.e. APSoC): last update 09102017 05:00GMT


    (old, probably september 2017 sometime; preserved to convey it's a SEMI GLIBC, NOT FULL [yet]) edit5: i have managed to call the statically-linked (to glibc) bash inside busybox, and it seems to work. it uses busybox for all the missing programs (like ls, etc) though lol. still encouraging to see! i suspect the bash is limited by the uclibc library as it is called through busybox, but still!!!

    here's the dump:

    edit6: confirmed, glibc is being blocked by the firmware for whatever inexplicable reason. here is the attempt to call rc from the statically-linked bash, which results in the process being killed off and the router rebooting (this is all done using the build provided above, with my [unrelease] ddwrt rootfs):


    * snip dross to improve readers' experience*

    bash-4.4# command rc
    usage: rc [start|stop|restart]
    bash-4.4# command rc start
    bash-4.4# exit
    # reboot: System halted

    i am pretty sure if it was a linking error it would have said "cannot find library libc.so.6". the fact it gave usage output suggests that it did find the libraries and it's something else...


    (moved to section with ldconfig output, originally posted 13102017ish)
    the (semi) GLIBC issue has been isolated to either the bootloader and/or the kernel's boot process.. it has nothing to do with the way i set things up (see below)

    14102017 20:51GMT/15102017 04:45 GMT
    houston, we have a problem. mitt (romney) won't give up control of "his" devices easily, even though we paid for them (typical mitt. thinks everything is his without paying a freakin' dime. freakin' loser).

    it turns out the issue with the broadcom nvram is precisely related to mmap/shm_opening (i.e. memory mapping) a mknod. i am not sure if there's a way around this. i tried creating a file descriptor for a file stream object (fopen + fileno), instead of the typical way (open), but the program then crashes at assigning the descriptor to the stream.

    it seems assigning/handling a file descriptor to a mknod object that will be treated as a shared memory object isn't standardised (even though the build is POSIXLY_CORRECT). this behaviour is in line with the failure to call glibc programs directly after init, and also the issue i experienced with using GNU mount/umount prior to interactive mode.

    here's the snippet of the correctly-generated ld.so.cache for the tree shown in the pastebin, which still results in the same "Attempted to kill init! exitcode=0x00007f00" panic. i only pursued this avenue because i wanted to ensure the ld.so.cache wasn't the issue (and it's not).


    sh-4.4# ldconfig -r /mnt -v
    ldconfig: Warning: ignoring configuration file that cannot be opened: /tools/etc/ld.so.conf: No such file or directory
    ldconfig: Can't stat /tools/lib32: No such file or directory
    ldconfig: Can't stat /tools/lib64: No such file or directory
    libutil.so.1 -> libutil-2.26.so
    libcom_err.so.2 -> libcom_err.so.2.1
    libproc-3.2.8.so -> libproc-3.2.8.so
    libgcc_s.so.1 -> libgcc_s.so.1
    libiw.so -> libiw.so
    libblkid.so.1 -> libblkid.so.1.0
    ld.so.1 -> ld-2.26.so
    libc.so.6 -> libc-2.26.so
    libuuid.so.1 -> libuuid.so.1.2
    libgudev-1.0.so.0 -> libgudev-1.0.so.0.2.0
    libext2fs.so.2 -> libext2fs.so.2.4
    libm.so.6 -> libm-2.26.so
    libpthread.so.0 -> libpthread-2.26.so
    libresolv.so.2 -> libresolv-2.26.so
    libnsl.so.1 -> libnsl-2.26.so
    libopcodes-2.29.1.so -> libopcodes.so
    librt.so.1 -> librt-2.26.so
    libstdc++.so.6 -> libstdc++.so.6.0.24
    libbfd-2.29.1.so -> libbfd.so
    libe2p.so.2 -> libe2p.so.2.3
    libdl.so.2 -> libdl-2.26.so
    libcrypt.so.1 -> libcrypt-2.26.so
    libnvram.so -> libnvram.so
    libss.so.2 -> libss.so.2.0
    ldconfig: Can't create temporary cache file /tools/etc/ld.so.cache~: No such file or directory


    oldish logs providing pictures of "my first gui access" and how mitt's a huge loser
  • FRIENDLY TIP: important nvram settings that are used by rc now persist through restart (in other words, running nvram_daemon in background is now off). in case people have issues, run these commands to get a fresh environment:

    export LD_LIBRARY_PATH=/usr/lib:/lib
    ralink_init clear 2860
    nvram set wl0_mode=apsta
    nvram set wl1_mode=apsta

  • /sbin/init can now make it all the way to the login... but... WE'RE NOT USING BUSYBOX so you're going to see libpam complain. excited to fix this issue so i can work on moving linux login info to nvram.
  • [31102017 21:28GMT] shadow utilities user{add,del,mod},group{s,add,del,mod},login have been added, along with (default) pam config in /etc. did this LOSER mitt (romney) do everything to ensure we can't use our devices.
    i believe i have all the necessary ingredients to create a full root user, so let go of what is ours, you MAGIC UNDERWEAR MANIAC.

[b][27102017 18:54GMT]:getting there...

Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Contributions Upload All times are GMT


Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum