A cross platform golang command line tool interact with AT&T Fiber gateways.
- Pull metrics from a gateway and send them to statsd(Datadog)
- Pull data like network connections, uptime, firmware version, model, and serial number from a gateway
- Pull metrics from a gateway and display them as text
- Do various resets including restarting a gateway
- Custom Datadog dashboards per gateway model
- Can be run as a daemon in kubernetes via helm, docker, or systemd
In most cases Datadog can be
used for
The dashboards can be viewed both in browsers, and in Datadog mobile apps from the Apple App Store and Google Play Store.
- BGW320-505 gateway
- BGW320-500 gateway, it has been reported to work
- BGW210-700 gateway, will likely work, but untested
I currently have version 6.30.5 on my
BGW320-505 gateway.
I have tested with previous versions back to 4.27.7, and expect them to work.
Here is the documentation.
See THANKS.md
The BGW320-505 gateway's hardware is from Nokia, but at least the base of the software is from Arris. Here is an example of a manual for the software. Note this isn't the manual for any of the common AT&T Fiber residential gateway models.
I just had AT&T Fiber installed. As part of the installation process I received a AT&T (Nokia) BGW320-505 gateway. I immediately found and set up the passthrough mode. I already had my own iptables based router running Fedora Linux. I wanted to continue to use it. I wasn't interested in disabling my existing DHCP servers and DNS servers. I also wasn't interested in changing the ip addresses of my whole network.
In my research one downside I found of passthrough mode is that the BGW320-505 gateway continues to do some connection tracking. It has a max of 8192 connections. This can be tracked on the Diagnostics|NAT Table page. It is said that the most common way this becomes a problem is via bittorrent clients opening enough connections to go over the limit.
The problem with the Diagnostics|NAT Table page is it is behind a login page. I wanted to write a script to scrape the page. I then dug into the HTML form and javascript. What I found is the authors don't trust the network given you can access it via HTTP or HTTPS](https://en.wikipedia.org/wiki/HTTPS) with an invalid certificate. So they made the login process complicate.
There seems to a bug in the page design where the first time you go it will claim your browser doesn't accept cookies, but it works on reload. My guess is that this happens because it is trying to read the cookie that it hasn't given you yet.
The login process goes something like this.
- Load a page, get redirected to the login page, and get told your browser doesn't accept cookies.
- Reload the page.
- Receive the nonce hidden value in the page, and hashing functions written in javascript that use md5. md5(password+ nonce).
- Posting to the login page these variables.
- nonce, an all lower
case 64 character hex-decimal value. Looks like a
sha256sum, like
87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7. - password, not the actual password, but instead the same number of
characters as the password replaced with
*characters - hashpassword, the results of the hashpwd function
- Continue, the submit button that calls the hashing function and triggers the post.
Once you are logged in your session is only tracked by your session cookie. It is possible to generate too many sessions. I accomplished this during the writing of this code, because at first it was generating a new session per run.
I originally prototyped this written in javascript. Since I was trying to reuse the javascript from the login page. I started with PhantomJS. It worked, and was using Firefox. This meant Firefox needed to be installed, and it needed to be able to run in the background. I switched to Puppeteer once I realized PhantomJS was not being maintained. Puppeteer worked better, but suffered the same problems as PhantomJS.
I then realized I could just rewrite the javascript code in golang. This works well. It greatly simplifies the dependecies, CPU resources, memory resources, testing, and more.
There are two flaws in the login process.
- The security of the whole process is tied to the security of the session cookie. Given that it goes across HTTP(no encryption) or HTTPS with an invalid certificate(easy to man in the middle), this is not good.
- The hashing method is just a fig leaf, because of flaw one. In addition it uses md5, which is known to be insecure. Modern solutions would be things like sha256 or bcrypt.
As far as I can tell there is no way to replace the gateway's SSL certificate.
I first ran across the first flaw over 15 years ago. I had gone to a Defcon talk about it, and then discovered the same flaw in the real world.