So Karl over at TRC got one of thes in for us to look at using with customised OpenWRT/LEDE firmware for a large project rolloput. On paper they are perfect and have all we need. Ok we cant use the DECT radio but hey.

SO a quick look over at https://openwrt.org/toh/avm/fritz.box.wlan.3370 and this should be easy. Got the UART header soldered in, I have the bnoot process stopped and ready to go….

Crap!

As is usually the case with OSS the documentation is a little poor. Starting with the fact that the supplied Image on the page is one file, and then the instructions go on about needing to upload two.

More searching just initally found more complaints of the same 🙁

I did eventually find Micheal Kuron’s blog at https://blog.michael.kuron-germany.de/2018/12/openwrt-on-avm-fritzbox-3370/ which then gave a better link for formwares. the are snapshots so up to date too. The link for these is http://downloads.openwrt.org/snapshots/targets/lantiq/xrx200/

Make sure you get the right one. As detailed on the OpenWRT and Micheal’s page the manufacturer of the flash chip matters.

Now, off we go a’flashin….

Well broadly speaking, it all works, but there is a big gotchya here that I don’t see mentioned anywhere. Don’t use the Windows FTP client. There is no way to put this into passive mode. It’ll simply tell you the cammand isnt known (PASV or Passive) and then *if* you press on anyway you’ll soft brick the router. You won’t be abl;e to do anything until you can get a firmware uploaded. I simply moved the files onto a USB stick and booted a Mint Live distribution which worked just fine.

R

So you want to know more…

The module is not just a switch, if you have it in bits you’ll have noticed there is a little more going on and there is that odd disk too…

What seems to be going on here is that there is a little bit more than just mdulating the power to the fan. Rover wanted to avoid sontaneous combustion of the blower motors too. So there are two more parts to this story.

First up is that disk again…

This is a device called a PTC. This is used by the HEVAC ECU to know how hot that heatsink is. Excessive heat can signify a serious failure, a stuck fan or an overload condition. At this point the ECU can kill the drive to the fan. This simply wired between one of the multi plug pins and ground. However it isnt soldered and relys on contact with the heatsink and that spring contact on the board. A bad contact *could* lead the ECU to summise that there is something amiss and shut the fan down. Its certainly worth giving it a clean if you are doing the transistors.

Above is a circuit diagram of the module. Values and compnent names aren’t correct as I just wanted a schematic. I beleive this is correct, although I wouldnt reccomend trying to reproduce it (yet, more later)

The PTC is R1 and as you can see, it simply feeds back to the connector.

The drive transistors are Q1 and Q2. These are in the negative supply to the motor, you’ll also see there is a relay, K1 accross these transistors . You can also see these transistors are in parralel to each other and the failure of one will take out the other.

The drive signal goes right to the transistors but it also goes to the circuitry on the right. When the drive signal reaches a specific value this circuit powers the relay up running the blower at full speed. The reason for this is that there will be a voltage drop over the transistors, even when driven fully on. The relay activates and connects the blower direct to the power supply thus taking this drop out of the circuit. This is the reason that with many of these that fail they will work on full power. Converseley a failure in this circuit or dirty relay contacts could cause loss of full power.

The transistors would normally fail open circuit, in the event they failed short you could end up with a fan jammed on full, however an overload failure would typically annihalate them so it’s unlikeley. The P38’s electrical system does constantly monitor the state of sub compnements so it’s also mot impossible that in the event the blower malfunctions the BECM can kill the aproproate relay (RL6 or RL7)

So what could be done to improve this?

Semiconductor technology has come on a fair way since these were designed. The first job would be to change the transistors to a new type known as a MOSFET. These devices have a much lower voltage drop accross them meaning they generate much, much less heat and place less demands on the driving electronics. It may negate the need for the relay making the whole thing much simpler.  Simpler and cooler means a longer life and potentially better system performance. With the lower heat load it’s also possible this could be remade as an external module to save dismantling a faulty blower provided the motor is fine. It may be possible to change the transistors in the module to MOSFETs as it is with minimal changes.

So we now turn our attention to the module.

So time for a little warning here. If you want to follow along or are planning on repairing your module be warned, some of what you are going to have to do cannot be reversed. The module is riveted together and you’ll need a good soldering iron. If you make any mistakes here you could kill the module. Its not a complex bit of kit but you could damage the HEVAC panel.

This is the switching module we mentioned in part 1 and takes the place of the resistor pack used in manual systems. The two large metal cans are the transistors used to do the switching and they do fail. Rover used two to split the load over both but one can fail and result in the second failing instantly from overload.

To get in and replace these you’ll need to drill the rivets out from the top (side with the cans). Carfull punch the remains of the rivets out as they hold the PCB on too. You will need to replace these later with bolts.

Flip the board over and desolder the two legs for each transistor. Use a good iron and a solder sucker. Once you get the pins clean the transistors will drop from the heatsink.

Replacements *can* be found, they are Motorola T1829-1 which are PNP Power Darlington devices. However you’ll be looking at used parts or new old stock, they aren’t easy to find. A drop in replacement is the MJ11015 which is easy enough to find online and from most electronics suppliers. To replace these you’ll need the transistors, heatsink compund and a solvent cleaner. Remove all of the old heatsink compound and gently prize the board off of the heatsink. You should have the following…

There is a small disk set in between the transistors that *may* drop out if you arent careful. clean everything off especially the contact for the small disk..

Isopropyl alcohol will shift most of the grot.  Treat all the terminals on the board for the connections to the loom and fan to a good clean up with fine emery paper. Make sure that the bottom of the mounting holes for the transistors AND the matching board holes are clean and shiney as these carry the current for the fan motor.
Clip the board back to the heatsink, then apply heatsink paste to the transistors sparingly and a small amount to the mounting area on the heatsink. They will only line up one way and you can guide the pins back through the board. Secure each transistor and the circuit board with M3.5 or M4 bolts and nuts. use shakeproof washers and nylocks to be sure. Using good quality solder, preferably NOT lead free, solder the four pins tow the board and then reassemble the whole module and re-install. With any luck you’ll have a working blower module.

Now, for the curious of you….Lets go down that rabbit holes a little deeper…

Anyone who knows these cars and is trying to keep one on the road will sooner or later run into HEVAC problems. These seem to stem from the blend motors or the blower modules as a rule. As I have a spare one and a dead one on the car I decided to take the spare and totally overhaul it and try and see what actually fails on these as well as document how they work.

As with a number of modern cars these modules aren’t simply motors but contain some electronics too. Having dug deep in these Rover did some good work but were possibly constrained by what they had to work with, this seems to be the source of the issues.

Simpler cars simply use a multi position switch to feed a series of power resistors, these give you your different fan speeds. These resisters can and do fail, as do the switches and this can cause loss of speed settings, the whole fan and in some cases (Looking at you here Vauxhall) spontaneous combustion of the air box.

When you are looking at a climate control system you need to control the speed of the fan via a computer of some sort, switching relays and transistors can be done to use the resistor system but its simpler and more precise to use something called PWM. Here instead of a simple on/off signal we use a transistor as a switch to control the power to the motor. If we then switch the transistor quickly you can control the speed of the motor by how long the signal stays on. At a basic level you now have 255 speed settings vs 4 or 5 and the computer in the HEVAC can manage it electronically.

Most systems them mount the switching transistors on the motor assembly. Modern cars use the same system for engine fans and all sorts of other systems. You supply the fan with power and a switching signal and everything is normally cooled by the fan too. All the big heater resistors are redundant and controlling two fans for dual zone climate control as the P38 uses is much easier. It means there’s no heavy duty switching going on in the ECU (HEVAC Panel) so that can be smaller and integrated with the controls.

Now, The P38 system was advanced at the time but they did make some curious design decisions and were limited by the parts they had to use. A lot of P38 electrical gremlins come from the same source, bleeding edge design that was close to what was practical at the time.

So, lets tear into it…

Either blower comes out easy enough. The procedure is covered elsewhere and I won’t go into it. It does work a little easier on the V8 if you drop the Cruise relay and the ECU that’s with it off the bracket. You get more space.

Once its out, pull the red and black motor connections from the electronics module. Looking at the side you’ll find three rectangular holes spaced equidistantly round the side. Push a flat screwdriver into each hole and gently pull the motor and fan assembly up out of the plastic. You’ll have to work around all three a few times but it will eventually prize out and you can guide the grommet and wiring through the plastic. Put the motor aside as we will look at this first, make sure the little rubber mounts do go astray. 3 screws hold the electronics to the plastic and the aluminum module can be withdrawn. You should have something like this now…

There are a few known issues. The most common is a simply dead unit, in which case you *could* likely swap just the electronics from a known good unit and snap it all back together. However I feel there may be other things at play here.

Another known issue is for the blower motors to torch the fuse box. The most commonly posited reason for this is blocked pollen filters, however with no air to circulate the load on the fan should be less, not more, so this explanation makes little sense. However stripping my unit I spotted something else, the motor was not free to move, well not as free as it should be. Powering the fan up from a bench power supply put the supply into protection at a current way above what I expected, Ah-Ha! So first job was to degunk, clean and lubricate the bearings. The top one is easy enough to do, the bottom one, less so. The motor cannot be stripped any further so its a case of the best you can do. Light machine oil was used on the bearings and some graphite grease to lube the brushes. The motor now not only span easier but drew significantly less current and was quieter. I would pin the fuse box burn outs on stiff motors before filters. As the whole lot comes apart easy enough this is a simple job to do “just in case”

On to the electronics….

Well not a real update as such, but an interesting milestone.

Using the MightyCore package I’ve managed to get the Arduino bootloader up on one of these boards.  Using a USB ASP the bootloader flashed ok. There is something screwy with the serial port bits as the baud rate and speeds are way out of whack. I suspect its an oscillator setup issue as the timing loops are running way too fast, Aprox 7 times too fast and given we have a 7 Mhz Oscilator and arduino thinks we are running at 1Mhz its a safe bet. I’ll have a pop at changing the 7MHz osc for an 8Mhz and see what can be done to get this happy.

Still it means that in theory all the pins are available to me. I have the top drivers traced out. I’ll work out how to make the resultant drawing legible at some point.

It also turns out that the serial number is in the ATmega’s EEPROM. This would imply that the modem is a complete stand alone unit that’s simply sending and receiving data, kinda leaves the path open to making these talk to each other.

Part 2 of this article.

So popping the back of the case, just four screws, reveals this…

There really isnt much to the unit. On the pic of the front you can see a debug header at the bottom. this is duplicated twoce more on the reverse with a finer pitched connector AND a pin header. Quite why 3 copies were needed I don’t know but they are the exact same pinout. The front connection is a perfectly sensible size and pitch. This contains power, the uC’s serial and ICSP lines.

The uC is a well known and standard part that most will be familiar with from the Arduino range. That’s right, you *could* put the Arduino bootloader on here and if I can work out how to talk to the display it would effectiveley be possible to roll your own display controller.  As we have no specs on the LCD itself this is non trivial. Immediateley above it and hooked to the SPI bus is 1Mbit of NOR flash. The crystal is 7.3728Mhz which may have been chosen to make things a bit easier on the UART, although there is no real need to do this.

Below this is a Nordic Semi nRF9E5 RF SOC based on an 8051 core. Nordic Semi push this as a device for operation in the 433/868/915Mhz ISM bands. Given that only 433 is allowed in the UK (and europe I beleive) and looking at the antenna provided that’s where this will live. I can check this quickly enough with my SDR if I get time. however I’m not THAT interested in the radio at this time. These do answer back as the controller will complain if it sees no reply so these are full blown tranceivers and it may be possible to utilise them. The circuitry is quite well separated from the rest of the design suggestion it may have originated as a development board. RX, TX and CTS are labelled on the board, as are three other signals, BE, ARE and RWU. Quite what these are I don’t know however I would suspect there is at least one enable signal there.

This seems to be power supply territory. A bog standard LP324 op amp lives in the middle and then there are a good spattering of caps and an inductor here and what looks like a controller. This needs metering out when the display is doing something. The ribbon on this side seems mostly dedicaed to power with many pins linked. There is an IC buried in the flat flex here too so it’s not quite that simple. I would imagine this is power supplies and row select with the upper ribbons handling the columns.

A close up of the display labels. The model number throws up a pdf : datasheet

This gives us something to go on, we have pin names and potentially the driver chips. We also have the display voltages, 3-5V for Logic and 15-20V for the display! Hence the power supplies.

The drivers seem to be referred to as ‘TAB’s and a quick look for the controllers listed not only gives the chip, but the flat flex layout in the datasheet. So for the top two tabs:
477731_1

And the side one:
393920_1

The top two cover 160 columns each and the side, 240 giving is a resolution of 320*240 which nmatches the image size the software asks for and the model of the display. Hopefully this provides what we need to drive the LCD itself, with out the need for constant refresh there is probobly less speed contraint on the scan time and indeed the scan does seem very slow when its refreshed. A quick check with a meter implies that the pinouts of the displays matches that of the tab. It also suggests that the NT7701s are cascaded as per the datasheet.

This gives us an 8 bit wide interface with 4 control lines and a clock. All of a sudden the idea of driving the display direct seems a little less daunting. With the large SPI EEPROM on board it should be possible to implement a char gen, although the limited RAM may be an issue. If we assume we use one byte per block of 8 pixels thats 320*240/8 = 9600 bytes or 10K of your 16K of RAM on the 16L8. If we are running as a display controller and nothing else this should be plenty. As we are only updating the display when it needs to change there is no need for double buffering etc.

A little update here: Part 2 1/2 – Life!

I have seen this all over the web and no one had the answer that worked for me untill I found a clue hidden in an update.

The Symptoms are (in my case)
Outlook 2016 Suddenly (after an update) Starts asking for a password, although it seems to take the password and username eventually on some machines, more often than not it’ll keep asking.
In this case we are using Exchange 2010. There are a mixed bag of machines on the network and its only the 2016 machines that are doing this. Most of the time cancelling the dialog would make Outlook behave for a while but one or two machines were behaving oddly.

Reset everything in credential manager, forced the autodection via registry, rebuilt the profiles (More on that in a sec), reset passwords, reinstalled Office, tried a fresh install in fact NOTHING worked.

When we created new profiles we could not get them to work, they would not log in no matter what we tried, however OWA was fine with the same details.

At this point we are three months in…

So a few days ago with the intention of doing something else entireley I looked a bit deeper. Rand the connection diagnostics and noticed that was coming back clear. Isolated the machine from the net and BOOM! Prompt gone, Outlook goes back to normal. Allow access to the net again and the prompt is back. So some sniffing at the firewall and Outlook is talking to something at Microsoft prior to even looking at the AD/Exchange servers. A red flag is coming up at this point.

Office 16.0.6741.2017 Added support for something called Direct Connect to Office 365. A few people flagged up that during migrations this ‘Feature’ can screw up where Outlook goes to get mail and cause all manner of stuff ups. The reccomendation is that during a migration you set a registry key:

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\outlook\autodiscover
DWORD: ExcludeExplicitO365Endpoint
Value = 1

So I set this key and bam! Again, Outlook is behaving. Then it dawned on me. When 365 launched it was being given away like candy by a number of businesses including BT. Both sites where I’ve seen this they are/were BT customers and both had been given free 365 accounts. These accounts were long defunct but aparently still there. As we migrated them to AD and Exchange the email addresses would be the same, of course we changed the passwords for most, but not all. Where the passwords were not changed the login would work, Outlook would behave normally but things like checking for email automatically or calendar events were not quite right. Changing the password on one of these accounts broke it like the others. Disabling the “feature” put everything back to normal.

So the new profile I created for myself didn’t work because I had never had an account on 365, Outlook was trying to log into the now no good account for the customers’ domain with details that never existed and failing then not even trying AD. When the registry change was installed I could setup a new account.

Long story short, it seems that MS didnt think that people would ever move away from 365, and by assuming that O365 is ALWAYS authoritative over internal AD and DNS it means that anywhere 0365 has been in place in the past on a domain, you are going to get this error. Of course if the domain has never had an account O365 just denies all knowledge and we fall back to AD without ever knowing.

I’m not sure when overriding settings put in place by an admin became a good idea, but its just another part of the huge train wreck that Microsoft QA has become.

We were recently approached by a customer (They will remain nameless but are a charity) with a batch of Cisco SPA504G IP phones. These had been purchased in good faith and duly delivered. Only they had vendor lock in. The customer tried a few avenues and if you’ve done a lot of searching you’ll know that there are a dozen ways to unlock. Most of them rely on assumptions that the vendor has not done something. The method below worked in this case and goes a little further than other suggestions, however if there has been a certificate set you are out of luck. I know there are people looking at hardware unlocking but at this point I would suggest you gave up.

Firsty, an honourable mention to the provider, Gamma Telecom. An inital call to their support guy was very promising. He didnt see an issue, took some details and we looked at the wireshark dumps (with plain text SIP credentials) and worked out who they belonged to and that they were indeed retired phones and there wasnt an issue with us having them. He took my number and wandered off. Shortly he called back and said I needed to speak to someone else and told me the process to get through the labyrinthine voicemail system. Hopeful I did as instructed.

“No, absoluteley not, we cant give you that information” Thats as far as I got. Despite owning the phones legally the rather rude woman wouldnt even listen to anything we asked. Explaining they were for a charity got no leeway at all. I even suggested the reprovision them and push a reset out that way. The phone went down.

SO here’s what was needed.

The phone gets plugged into my lab setup, its behind its own firewall there and I can control and manipulate everything. It turns out some simple DNS hacks were all that were needed. So watching the phone with wireshark, it asks for an IP, great, it’ll take the TFTP server and try that, no, no dice. It then asks right away for a SRV record from the provider. Ah-HA! I cant change the SRV record at this point, but a quick dig shows that it will ALWAYS return the same hosts, node7 and node4.sip.unlimitedhorizon.co.uk. Host overrides entered in PFSense and the phones start trying to register to my Freepbx lab server. They get denied, but it means I have some control over the damn things.

At this stage I’ve been puzzling over this for a while and then I spot something. When the phones dont get a response or are told to go swing by those servers they sit there in a loop retrying. HOWEVER a login failure rather than a refusal triggers something else. Hot on the tails of both servers failing the login it then tries to connect to an HTTP server, xsp.unlimitedhorizon.co.uk and it asks for /dms/Cisco_504d/<mac>-Recovery.xml A manual browse over there gets nothing, however tweeking the mac address results in firmware images being served. There’s some big security issues here, least being that I suspect its possible to take over another phone by flashing that image to another unit. For us this means that we have an in.

This Site suggests that you can serve an xml file to it. You can then force the phone to pull the file. However if the web UI is locked that wont work and if it’s also not looking for TFTP servers it wont work either. So, I added another DNS override to point that host to one of my servers, uploaded that file, renamed it to match what the phone was asking for and rebooted.

File gets requested and sent, all looks good, phone then ignores the file and switches to trying to use TLS for an update. Uh oh I’m stuffed here. I cant spoof the cert. I can see it failign as it doent like my server cert’s CA. What now.

I have an SPA504G on my desk, I know you can dump the XML so off I go and do just that. A quick look at the XML shows that the MAC is included, so thats edited to match the locked phone and the admin password line from the above xml is added. We reboot again…

Asks for the file…
Grabs the whole damn thing…
Reboots. On reboot i’m greeted with a clone of my phone. A quick venture into the menus shows that the admin password has gone too. A quick factory reset which I can now do and its all up and running as it should. One clean, factory reset phone.

Now this presents a number of conclusions. Cisco are good at this, we’ve seen that if this DID resort to TLS and there is an option to do this, you would be screwed. That they didnt do this seems odd, its one setting, but in doing so they left it wide open. Everything else was set to make it as hard as possible to unlock the phone so why leave this back door wide open?

How much of a risk is that web server. I have five phones here with distict MAC ranges. I can take a good guess that phones would have arrived in batched and a search in a range and a quick text shows I can pull about 5 xml files that dont relate to me.

Its possible they have realised there could be an issue here as the XML files point to a .bin file, the file freely downloads which raises the question of what it is, and can I flash it to anything? I knwo I can force the phones as they stand into arbitary configurations, can these files then be written to a phone to hijack that ‘line’? I’m not willing to risk the customers phones but it does raise the question of security of the system as a whole.

UPDATE

The XML I used from my own phone is here, you use these files at your own risk!

Cisco_504d XML Files

The next thing to look at is how the display deals with the above three modes. Although we wont be using these modes they do show how we may be able to get a few extra bits that we can use.

Radio mode is actually REALLY simple. For some reason though my head unit wont stay in AM mode so I wont cver it but it should be pretty similar. I susect there is a variation on the tuning mode that will display the right steps. I also dont have the telltale codes as I cant actually see them on my display 🙁

We are interested in the code 0x09A,  0x02, 0xaa, 0xbb. This seems to put the display in frequency mode and then displays the frequency in steps of .1MHz from 87.5 so for example 0x01 would be 87.6Mhz. 0xbb is always set as zero but it may be this is used for AM mode.

0x9A, 0x13 is issued just before, I dont think this is mode switching but likeley refers to setting of the telltales. It does seem this is used with every LCD mode change however I have noticed the micro does update the screen whenever it can rather than when needed.

Now the fun (and useful) one. RDS mode. This seems just as simple as above. On switching from frequency mode to RDS mode we see the following commands…

0x9A, 0x02, 0xaa, 0x00 – Freq display refresh, not sure why this is sent
0x9A, 0x23, 0x00, 0x00, 0x00 – Clear display
0x9A, 0x48,0xnn……

Why we are updating the frequency then clearing the display I really dont know. But once the display is clear the head unit sends the station ID as text. The bytes 0x9A and 0x48 are followed by 8 characters as their ASCII codes. If the ID is less then it is padded with 0x20 (space). Exactly what characters are valid is unknown. It should be possible to implement scrolling though as the display updates very fast. It may be possible to skip the clear to make it smoother.

Next: Tape Mode

So we have out unit unlocked. We have the keypad protocol now time to see how the diaplay works. The keypad never changes its behaviour so the previous section applies and I wont show the keyboard data.

It seems that there are at least 4 modes :

“SAFE” this simply displays the word SAFE and nothing else.

“TAPE” Likewise although there are two direction indicators that show

Text mode. This allows freeform text. There are a number of legends too that sadly cant be seen on my display.

Radio Mode. This displays a frequency. It seems to take an 8 bit step number which the display translates.

All commands to the display start with 0x94, there then follows a command byte and the various commands seem to have different lengths. As with the keyboard there is no CRC generation.

“Safe” mode: Assuming you’ve powered up your radio from cold and its been out of the car a while AND its not had the code disabled (some seem to) you’ll be presented with a screen that says SAFE. This is the code entry screen and it seems to be one of a number of stored screen modes.  We see the following commands at boot into safe mode:

0x25, 0x25 : Init from keypad

0x09, 0x61,  0x0B sent along with 0x13, 0x40, 0x00, 0x00 right after. 0x13 is LED and LCD teltale command and this sets a single bit so its possibl this is what actually sets the SAFE display, HOWEVER 0x09 controls the tape direction telltales so this could also be involved here. Until I’m able to extract the codes for the Teltales which will mean being able to see them, I cant be sure what the LED command is doing here. I do plan on sending some of these commands to the display to see what happens so that may help here too. Pressing and holding RDS and TP will send keycode 0x1E and the micro issues a new sequence of commands:

0x9A, 0xE1, 0xFB – No idea what this does.
0x9A, 0x61, 0x0B – This apears to activate the SAFE display.

Once this sequence is done, the second sequence is resent  every 2S. Pressing and holding RDS+TP to go into code entry gets the following:

0x9A, 0x13, 0x40, 0x00, 0x00 – 0x13 IS led control. Byte 3 is LCD telltales as far as I can see.
0x9A, 0x23, 0x00 ,0x00 ,0x00 – LCD Clear
0x9A, 0x92, 0x10 ,0x00 – This is code entry mode. the last 4 nibbles are the currently displayed code. so in this case 1000.

Hitting 1,2,3 or 4 to change the code now will resend the above command with the nibbles altered. eg, if you hit 2 twice you’ll get

0x9A, 0x92, 0x12 ,0x00

Pressing and holding TP+RDS will either start a normal boot (next page) or restart the whole process.

On to RDS and Radio modes