Public Service Announcement: Do not use ReShip

eBay’s global shipping program is a disaster. Folks outside the US that buy things from eBay have learned to use US-based reshipping services to receive their stuff in a timely and cost-effective manner.

I’d been using Shipito for well over a decade. Over the past few months, though, I’ve been having problems with packages missing small items. Steve over at Big Mess O’ Wires recommends ReShip, so I decided to try them out.

They seemed okay. Their shipping fees were about 5% cheaper than Shipito, packages were reshipped within 24 hours, and packages were opened and photographed as soon as they were received (which was a major contributing factor to Shipito’s issues).

However, packages that were marked as “delivered” in USPS and UPS tracking systems didn’t show up in my account for several days. That was a bit concerning, but I reckoned that they were just overwhelmed with the amount of inbound packages.

Unfortunately, that turned out to not be the case. Two weeks ago, ReShip received three packages for me on the same day. None were placed in my account. I contacted their online support system, and this is how it went:

The order is not showing in our system as being delivered. USPS scans orders as delivered before they get to the warehouse. They do this due to the volume of packages so they are scanned and bundled up for bulk. USPS currently has over 100 orders backlogged to be delivered to us. We are trying to have this resolved. We are very sorry.

We really apologize for this. USPS holds packages at their facility for longer than they should. We have video evidence we have submitted to USPS as proof they don’t scan packages as delivered so we have actually no idea when they deliver packages. You can also monitor your account or Kindly contact USPS regarding your package.

This didn’t smell right. I asked the (outsourced) customer service representative to please escalate this to ReShip for investigation.

The next day, “Diane M” sent this email:

We have been experiencing issues with USPS not delivering to the correct address and then the driver telling us they have back logged packages at the warehouse (this is frequent and we have had to send staff to collect the backlogged packages). We are trying to work with USPS in hopes they will cooperate.

We were delivered a bunch of packages by our neighbors from USPS so hopefully these packages are in there and will be received soon.

… okay, that’s really not good. I said:

The situation seems to be very alarming. What you’re saying is that ReShip cannot reliably receive packages, and there is no recourse available to the customer as USPS says that it has been delivered but ReShip denies that has taken place.

That’s not good. I moved from Shipito to Reship awhile back because Shipito was having theft issues; if ReShip has a bad relationship with USPS, then it’s hard to trust ReShip to safely forward packages.

Is this problem documented by ReShip anywhere, so that customers are aware that ReShip often does not receive packages sent via USPS?

Specific to my situation: two of the three packages have now been marked as “received” and are in my mailbox. How long should I wait for the other package to appear?

Diane replied the following day with this:

We have had issues in the past with USPS and included this in our FAQ section. We have also raised these issues with USPS directly and issued federal complaints. We don’t determine what is and isn’t delivered unfortunately, although having that ability would resolve these issues. If the package was delivered, it may still be in the process of being received.

Okay. I burn about an hour scouring their website looking for a bit saying “USPS doesn’t like us, but we’re working on it”. Can’t find it anywhere. So I say:

I don’t see any reference to problems with USPS anywhere on your website. Could you please send a link?

What are the options regarding the missing package (USPS #9400111699000025640151)? USPS says that it was delivered on 18 June, but you folks say that you don’t have it.

What is ReShip’s liability and responsibility for packages that the carrier delivered but ReShip cannot locate?

What is the best way to resolve this issue, both now and going forward?

Should I escalate to the USPS postal inspection division for investigation?

Diane then ignores my questions:

When USPS delivers packages, they don’t bring a scanner with them at all. They 0deliver packages then drive away. Any packages that are marked as delivered are not done when the packages are delivered at our warehouse (we have evidence of this by video surveillance which we have provided to USPS on multiple occasions). If a package is not delivered to us, there is nothing we can do. That would be between yourself, the vendor, and the carrier. We can certainly write you letter letting you know we did not receive this package so you can submit that to the carrier for a claim.

Right. That’s really not okay with me. The missing package contains an obsolete and somewhat-hard-to-find Apple ][ video card, and I’m not going to tell the guy I bought it from that I didn’t receive it so he needs to refund my money because it isn’t even remotely his fault.

I filed an investigation claim with USPS (I was actually trying to get the postal inspectors directly involved, but it looks like I can’t skip directly to that part).

I looked ReShip up on the Better Business Bureau website (link goes directly to ReShip’s profile) … and, um, wow. They have an “F” rating. The reviews are brutal. They don’t even have a state business license. I sure wish I had checked these reviews before I trusted them with my packages.

I opened a case with the BBB requesting that ReShip reimburse me for the package that they can’t find.

I then told ReShip what I’m doing:

Thank you for your reply.

I’m sorry, but this situation is unacceptable.

Here is what is going to happen:

I have asked USPS to open an investigation into package XXXXX (service request #YYYY). ReShip will be contacted by a postal inspector in the near future. With a bit of luck, that will help to solve your issues with USPS.

I have opened a case with the Portland BBB, case number ZZZZ. I have provided them with this entire email thread. I have asked them to seek USD$85.00 from ReShip as repayment for the package that ReShip has lost.

I will be writing an article about this fiasco on my blog today. With an additional bit of luck, making this situation public can prevent others from using ReShip in the future.

I don’t believe ReShip’s explanation of the situation, but that doesn’t matter — at the end of the day, no matter what the actual reason is, I still won’t have that old 80-column card.

So there it is. Maybe somebody someday will be googling around for reshipping services, see this blog entry, and decide against using ReShip. If this blog entry can prevent just one person from having issues with ReShip, then this fiasco will have at least a minimally positive outcome.

Leave a comment

Franklin ACE 1000 keyboard EPROM dump

A fellow on the Vintage Computer Federation forum needed the EPROM image for a Franklin ACE 1000 keyboard.

It doesn’t look like anyone has dumped it before, so I desoldered the EPROM from the keyboard and dumped the image. It’s an Intel 2758, but it is pin-compatible with the 2716 as what would be A10 on a 2716 is grounded on the keyboard PCB.

The EPROM image is here.

Posted in Franklin | Leave a comment

Franklin ACE 1000 emulation added to MAME

Over the past few months, I’ve been refurbishing a pair of Franklin ACE 1000s. I plan to write a series of articles documenting the things I’ve learned along the way; despite the popularity of these Apple ][+ clones in the 80’s, very little hardware documentation appears to have survived.

One of the things I did to help the repair process was to add Franklin ACE 1000 emulation to MAME. The pull request was merged this morning (https://github.com/mamedev/mame/commit/c471404e026bfa42c016cbcc52b66b77c5b14e39), so it will be in the next release of MAME.

The ROM set is available at https://www.disavowed.jp/hardware/ace1000/ace1000.zip. This set contains the real Franklin character ROM, which doesn’t appear to be available anywhere else.

Enjoy 🙂

Posted in Franklin | Leave a comment

Notice: LineageOS build repository discontinued.

Awhile back, I mentioned that my bandwidth was being consumed by a few bad actors out there who are scraping the entire LineageOS build repository.

This is still happening. It’s been especially bad over the past week.

I’ve been null-routing entire networks in an attempt to keep the service running while preventing jerks from hoovering the entire repo. It’s turned into a game of whack-a-mole, and honestly, providing this service isn’t worth the cycles I’m burning keeping things running for an indifferent “community”.

As of today, the LineageOS build service has been discontinued.

My build script is at https://www.disavowed.jp/lineageos/build-lineage.sh for those who need security updates for their devices.

I’m very sorry to have to do this. I’m especially sorry towards the eight people who have donated over the past few years to support this service. This is why humans can’t have nice things.

Posted in LineageOS | 11 Comments

LineageOS sustaining build repository moved to lineageos.rezrov.net

Multiple people have pinged me regarding lineageos.disavowed.jp having issues.

lineageos.disavowed.jp was deprecated several months ago in favor of lineageos.rezrov.net and the SSL certificate for the old domain finally expired.

I’ve therefore removed the HTTPS redirect to lineageos.rezrov.net with a simple HTTP redirect (because, natch, there won’t be a valid SSL cert for the redirect anymore).

Again: lineageos.disavowed.jp is dead. Use lineageos.rezrov.net.

Thank you.

Posted in LineageOS | Leave a comment

A sane Octoprint (octopi) USB camera daemon

Octoprint is neat. However, the USB/webcamera support is a bit obtuse — especially when you throw haproxy into the mix.

The Octoprint documentation recommends using mjpg-streamer as a standalone daemon to convert a v4l video stream into a HTTP stream … and use haproxy to selectively redirect traffic to that stream when an arbitrary value prepends the HTTP URI.

There are a few issues:

  • The recommended haproxy.cfg isn’t compatible with current versions of haproxy,
  • Octoprint appends a seemingly-random session ID to the camera URI, which confuses the hell out of mjpg-streamer,
  • mjpg-streamer doesn’t appear to handle multiple simultaneous streams, resulting in the infuriating “403: Forbidden! frame already sent” error,
  • mjpg-streamer itself is complete overkill here.

Wanting this to work, I looked around for a simpler scheme. I came across Igor Maculan’s “Simple Python Motion Jpeg” daemon (https://gist.github.com/n3wtron/4624820), which looked promising.

I spent a few hours this morning porting it to python 3.x, fixing a few bugs, and adding command-line tunables. It works, and it works well. It is available on GitHub at https://github.com/christopherkobayashi/octoprint-stuff/blob/main/webcam.py

Below is a working haproxy.cfg that handles SSL:

global
	maxconn		20000
	log		127.0.0.1 local0
	user		haproxy
	chroot		/usr/share/haproxy
	pidfile		/run/haproxy.pid
	daemon

defaults 
	timeout		connect 5s
	timeout		client 1m
	timeout		server 1m

frontend public_ssl
	bind		:::443 v4v6 ssl crt /etc/letsencrypt/live/both.pem
	use_backend	webcam if { path_beg /webcam/ }
	default_backend	octoprint

backend octoprint
	mode		http
	http-request	replace-uri '^([^\ :]*)\ /(.*)' '\1 /\2'
	option		forwardfor
	server		octoprint1 127.0.0.1:5000

backend webcam
	mode		http
	http-request	replace-uri '^([^\ :]*)\/webcam/(.*)$' '\1/\2'
        server webcam	127.0.0.1:8080

The Octoprint web camera URL should be “https://${SERVER_NAME}/webcam/${SOMETHING}.mjpg”. ${SOMETHING}.mjpg can be anything, actually … webcam.py will respond to any request with a MJPEG stream.

I hope this saves time for others banging their heads against Octoprint’s … interesting camera support scheme.

Leave a comment

LineageOS builds for Asus Zenfone 2 (1080p) (Z00A) … and site updates

While cleaning up my work room a few months ago, I found an old Asus Zenfone 2 tucked away in a desk drawer.

The Zenfone 2 is a neat idea executed poorly. It’s dual-SIM (which is why I bought it — it was my China phone, with a China Mobile and a Hong Kong SIM), solidly constructed, with a really good screen. However, one of the SIM slots is 2G-only, it’s using an Intel Atom (x86) processor, and the battery is infamous for randomly dying.

I hooked it up to a USB charger, figuring I’d give the battery a good solid regenerating charge to see if it was worth keeping, and promptly forgot about it. I discovered it again a few days ago (still charging) and tried it out.

Much to my surprise, it booted.

It was supported by LineageOS 14.1. I did a quick build, flashed it onto the device … and it still worked. I’ve added it to the weekly build rooster.

Stock TWRP 3.3.1 (as sourced from twrp.me) works fine. The MM bootloader is probably required; I’ve put a copy of the upgrader in the z00a directory.

Magisk will not work. There’s something odd going on with the bootloader’s kernel image integrity check — after Magisk injects itself into the image, the bootloader will refuse to load it, choosing instead to enter recovery. The fix there is to use LineageOS’ addonsu package. The binary on the official LineageOS site will not work, as one of the ABIs apparently changed in the past few years. I’m now generating the addonsu (and addonsu-remove) package along with the regular build for each platform.

On a different note: I’ve moved the repository from lineageos.disavowed.jp to lineageos.rezrov.net. These builds are apparently a bit popular; I’m seeing people grab these from all over the place (referred from YouTube tutorials, Russian and Japanese forums, in addition to the usual XDA traffic). That makes me happy, but …

… unfortunately, only six people have donated to the webhosting fund. I’ve had to bring the repository in-house to cut costs. I’m really disappointed in the gimme-gimme-gimme mindset displayed by the vast majority of LineageOS users.

I’ll keep the builds available as long as I can, but do not be surprised if the site is one day replaced with a static “so long and thanks for all the fish” page to keep my ISP from throttling my bandwidth. At that point I’ll post my build script and redirect software-lineageos@disavowed.jp to /dev/null.

Anyway … enjoy the Z00A builds.

Posted in LineageOS | 4 Comments

netatalk-classic-20200921 released

I’ve been repairing old 68030- and 68040-class Macintoshes for the past few years. It’s a fun hobby, and allows me to reconnect to an Apple era that was long-gone by the time I joined Apple.

At this point, we have a SE/30, a Classic II, a IIsi, an LC III, a Centris 650, a Quadra 700, and a Quadra 950. All are networked, either through Asanté PhoneNet-to-Ethernet bridges or direct Ethernet.

For the last quarter-century, Netatalk has been the go-to solution for file/printer sharing between UNIX and AppleTalk. Version 2.2.6 was the last release that supported classic DDP AppleTalk (as opposed to AppleTalk-over-TCP/IP, aka “DSI”). Unfortunately, the codebase rotted a bit and needed cleanup to run on current Linux and NetBSD releases.

Now that I’m retired, I have time to work on fun projects like this. I’ve spent the past few months refactoring the 2.2.6 codebase; it’s now at the point where I consider it good enough for public consumption.

I’m calling it “netatalk-classic”. It works out-of-the-box with NetBSD, and seemed okay on Linux once they fixed the Huawei commit that broke AppleTalk (as discussed at https://www.downtowndougbrown.com/2020/08/hacking-up-a-fix-for-the-broken-appletalk-kernel-module-in-linux-5-1-and-newer/ — full disclosure, I’m the guy that tried and failed to get the maintainer to fix the broken code that he himself had approved, so I’m a bit bitter).

Release tarball is at https://github.com/christopherkobayashi/netatalk-classic/archive/20200921.tar.gz and the GitHub source is at https://github.com/christopherkobayashi/netatalk-classic

Share and enjoy. Please drop me a line if you find this useful or need functionality that was removed.

Posted in Apple, Macintosh (m68k) | 2 Comments

LineageOS 15.1 builds for Sony Xperia Tablet Z LTE (pollux)

The LineageOS team is shutting down builds for 15.1.

Ari Opari has asked for Sony Xperia Tablet Z LTE (pollux) builds. They’ve been added to the rooster and are at https://lineageos.disavowed.jp/pollux

Posted in LineageOS | Leave a comment

LineageOS 15.1 builds for Huawei Honor 5X (kiwi)

At the request of Sachin Saini, I’ve added the Huawei Honor 5X (kiwi) to the weekly 15.1 build rooster. Share and enjoy.

Posted in LineageOS | 2 Comments