-
Determination or insanity?
For the last week I've been tracking down a bug in my current project. I've spent just about every spare minute including the weekend trying to figure out why my code works in a test app, but not the main app. I rewrote a huge piece of some communications code to no avail. I tried threading the communications, putting in proper locks, changed how I processed the bytes, etc. Basically when I was receiving large amounts of data from a Bluetooth device, some data was lost in the transmission and the checksum was incorrect; for small amounts of data, this problem didn't show up. At this moment in time, I believe I'm the only person in the world working with this combination of hardware and software which made using Stackoverflow useless.
A co-worker of mine kept sending me ideas to try as I was completely out of ideas. His latest idea was to put the files from my test app into the main app to make sure the project settings weren't the problem. That didn't solve the problem, so I started ripping out pieces of the code and came across some code we had put in for a demo.
All of the communications code that I was working on was using the External Accessory protocol over Bluetooth. The demo code we had in there was using Multipeer Connectivity which uses WiFi and Bluetooth to discover peers. Once I removed that code, all of my communication issues went away! Now I should file a Radar issue with Apple on issue, but I can't reproduce it outside of the particular hardware I'm using, networking library I've written, and a few other pieces so a bug report would be quite lacking.
I must have spent 40+ hours on this one issue which has caused me to lose sleep and be a bit on edge all week. As failure was not an option and I had no place to turn, I had to solve this. I'm sure that others would have given up as 40+ hours is far too long to spend on a bug. For me, however, I actually spent 4 months full time chasing down a bug in a network router for a cellular base station; like this one, I did eventually discover the fix.
Lesson learned...be careful of using different communication libraries in an app.
-
Troubleshooting OS X Server's Websites
Today I was trying to install a program on my OS X Server and the software complained that something was listening on port 8080. I couldn't figure it out, so after a bit of searching I found a command that could get me closer:
sudo lsof -iTCP -sTCP:LISTEN -P -n | grep 8080The output had in it:
httpd 21950 _www 7u IPv6 0xc086bca85e9b29f7 0t0 TCP *:8080 (LISTEN) httpd 65328 _www 7u IPv6 0xc086bca85e9b29f7 0t0 TCP *:8080 (LISTEN)OK, so now I know that the _www user was running the process. Next up was to do:
ps awuwx | grep _wwwWhich gave me:
_www 23128 0.0 0.0 2518828 1132 ?? S 8:41PM 0:00.00 /usr/sbin/httpd -D FOREGROUND -f /Library/Server/Web/Config/apache2/httpd_server_app.confAh, this tells me that OS X's Server App is running Apache which is fine, but I had Websites turned off in OS X Server!
Hmmm, how do I disable Apache without hacking away on the http files? Well, I noticed on the Websites section I had an entry listening on port 8080. I removed the entry and presto, my server stopped listening on port 8080. Very odd because Websites is off, but OS X Server decided that if Websites is off, it should still listen and serve up a page that says "Websites are turned off."
Besides Apple ending the text with a preposition, this is absolutely the wrong behavior in my opinion. I understand that certain services (CalDAV, WebDAV, etc.) run through Apache and OS X Server has to have it on to work, but Apple needs to have better messaging to indicate that it is listening on various ports and how to turn off the websites.
Maybe I'm not the average OS X Server user in that I run various other services including Jenkins, but OS X Server still is not up to snuff; I'm not sure why I keep running it. OK, I do know why I keep running it; the caching server is excellent, VPN service is good, and file sharing is pretty easy to setup. Good thing I'm not afraid of the command line and can figure this out.
-
Setting up QoS on the Edge Router Lite
When I started using the EdgeRouter Lite, I knew that it was quite powerful and could handle pretty much anything I threw at it. Last week I had to send a very large file to a co-worker, so I put it in Dropbox and soon saw Dropbox use pretty much 100% of my upstream bandwidth; I tried limiting the upstream bandwidth in Dropbox, but the setting failed to do anything. Someone tried to call us on our Ooma and I had trouble with the call, so I stopped the Dropbox upload and turned on the Network Link Conditioner on my Mac to limit the upload.
That evening I started playing with Quality of Service (QoS) on the EdgeRouter Lite to see what I could do to prioritize the voice traffic and limit bandwidth while making calls. After much research over about a week, I finally managed to come up with a configuration that seems to work. There are lots of guides out there, but I didn't quite understand them, so I'll do what I can to explain what I've done here. If there are any errors or tips, feel free to let me know.
First up, I setup a DOWNLOAD traffic-policy to handle downstream bandwidth. I'm not sure that this is truly necessary as I've been unable to continuously max out my downstream connection and when Time Warner Cable upgrade to MAXX this November, it will become less of an issue.
I SSH'd into the box and did the following:
configure -
A simple solution to poorly working remotes
When we remodeled our house, I ran HDMI cable from the TV through the wall to my equipment rack which is on the other side of the wall. At the time, we were using an Apple TV, so we were just using an iPhone over WiFi controlling the Apple TV. This worked well until I added a Roku 3 and a Fire TV to the mix. The Roku 3 uses a WiFi Direct remote and the Fire TV uses a Bluetooth remote.
In theory, the remotes should have no problem reaching about 10 feet through one wall. In practice, the remotes have been flakey. For the longest time, I've been blaming batteries and the remotes. I got so fed up last week that I decided to take another look. My server rack is in the lower level of our house whereas the TV is in the middle level (it's a split level house) and the Roku and Fire TV have both been in the rack; this puts them slightly below the floor level of the middle level. This isn't the best picture, but it will suffice.
I put zip ties around the Fire TV and Roku TV and mounted them on the wall next to the equipment rack; I put them as high as possible given the Ethernet cable I had which situated them about a foot above the rack. Moving the boxes out of the rack and raising them up slightly seems to have done wonders to the remotes. They are now very responsive and I haven't reset the Roku remote in a week and haven't banged them against the couch to get them to work!
While the solution is now obvious, I was so concerned about making my equipment rack nice and neat that I chose to ignore simple troubleshooting steps dealing with RF. Some people may be asking why I don't just stick the boxes next to the TV. For starters, I don't want to see the boxes as they would add clutter to our TV area. Second, I have the wall warts plugged into a power strip that turns off at night to conserve energy (I plug as much as possible into this strip and it automatically shuts down at around 11 pm and turns on around 6 am).
Knock on wood that things keep working; if I have problems again, I'll get some longer Ethernet cables and move the boxes so that they're higher up and on the backside of the TV wall.