Dead Gladiator. Both batteries replaced. Still dead.

[dcmdon]

A few years ago when I was not real happy with where I was working (lots of agency politics) a friend know of my automotive experience - and my network experience, including firewalls, routers, servers, fiber optics and more. He suggested I'd fit right in as a Mercedes tech. He figured it would be an almost sideways move in a way.



Security is one reason -
getting to the thing you want to talk to and not have other things respond is another. Maybe Dave can correct me, but I view it a bit like ports on a network. If you want to talk to a VPN server you hit that server's IP address - but that IP address may be shared with other services, so you hit it with these posts and protocols - IPSec — Ports 500 UDP and 4500 UDP, there's layer 2 tunneling protocol (L2TP), lots of fun stuff. A router on the edge is set up to direct any traffic coming in destined for that IP address using those protocols and ports to that server. They go no place else. If you have a Mickysoft network you can watch all of the communication going on with a sniffer and see what responds and what doesn't respond based on the traffic received or seen.

I could see some of this working like a VPN - tunneling through the network and encrypting the traffic being sent, decrypted by the other end because it has the encryption key that was set up establishing the connection.

So to take your analogy one step further, lets say you had a laptop that was continually pinging some resource on the network trying to connect. If it didn't eventually stop it would run its battery down.

It would seem to me that it would be easy to add logic that said if battery voltage is < X, then shut down the head unit and prevent it from trying to connect until battery voltage is > Y.

So again, I'm not saying electronics are fragile.

I'm saying that the way they are implemented in the Jeep (and possibly other modern cars) is fragile.

The double battery situation is another example. When the JL shipped if the aux battery was dead but the primary was fine, the truck wouldn't start. It was immobilized for no other reason than bad software design. Eventually a firmware update fixed that.

Software design has to anticipate component failure and include work arounds in the case of all anticipated failures.

If A fails we run at full capacity but show a "Service vehicle now" indicator.
If B fails we go into limp mode.
If C fails we shut the whole thing down.
If D fails we go into limp but don't allow a restart.

Its not the hardware. It seems to be shitty software that causes this fragility.

I don't claim to even begin to understand the interdependencies between systems on modern cars. But it would seem that with good system design and good software, a modern car could be MORE robust than an older car simply because there are redundant sensors or secondary ways to derive the same values.

Sponsored

 

[ShadowsPapa]

Software design has to anticipate component failure and include work arounds in the case of all anticipated failures.

Not really feasible. The number of ways a thing can fail are unknown. That's why even with tens of thousands of people beta testing software over weeks or months, some things still don't get found.
One example is what Symantec called "the PFG fix" after I found it and duplicated conditions for force a failure and contacted their developers. Apparently no one had ever run across what I found in mixed network environments (Netware and Microsoft mixed networks)
We were using IPX/SPX and TCP/IP on the same networks. I noted failures in certain updates - can't recall the details now but totally confused their platinum support. No one else had ever seen what I was seeing. I setup a duplicate network in the lab using VMs, captured traffic, logs, etc and sent them the files to bring up my servers in their own lab. Their developers found the issue, fixed it and named it after the company I worked for at the time. Later it was found some other big company had see similar goofy stuff and couldn't figure out what was going on and had no idea how to explain it and just worked around it. They were pretty happy when the next bit update came out for the corporate security app from Symantec.
Think of all of the possible combinations of things, timing, events, people, people using things in certain ways.
You can try hard but can't plan for every possible contingency or combination. And with the competition as it is - it's as bad in vehicles now as it once was in computer technology - beat the competition out the door by a few weeks and you win. They try hard but can't resolve all possibilities with software.
In this case all it takes is a battery not up to snuff, or some combination of settings, whatever, and you have trouble. Cold weather - more trouble as batters are far less efficient when below certain temperatures.
Frankly, it shouldn't take a whole lot for these to keep communications open and encryption keys or protocols shared but then if I don't plug my phone in overnight when I get up it's way down - all because it's trying to keep communication open to a tower. It's sleeping, the screen is off, I have no games or other stuff that should be sucking power out.

 

[DAVECS1]

Not really feasible. The number of ways a thing can fail are unknown. That's why even with tens of thousands of people beta testing software over weeks or months, some things still don't get found.
One example is what Symantec called "the PFG fix" after I found it and duplicated conditions for force a failure and contacted their developers. Apparently no one had ever run across what I found in mixed network environments (Netware and Microsoft mixed networks)
We were using IPX/SPX and TCP/IP on the same networks. I noted failures in certain updates - can't recall the details now but totally confused their platinum support. No one else had ever seen what I was seeing. I setup a duplicate network in the lab using VMs, captured traffic, logs, etc and sent them the files to bring up my servers in their own lab. Their developers found the issue, fixed it and named it after the company I worked for at the time. Later it was found some other big company had see similar goofy stuff and couldn't figure out what was going on and had no idea how to explain it and just worked around it. They were pretty happy when the next bit update came out for the corporate security app from Symantec.
Think of all of the possible combinations of things, timing, events, people, people using things in certain ways.
You can try hard but can't plan for every possible contingency or combination. And with the competition as it is - it's as bad in vehicles now as it once was in computer technology - beat the competition out the door by a few weeks and you win. They try hard but can't resolve all possibilities with software.
In this case all it takes is a battery not up to snuff, or some combination of settings, whatever, and you have trouble. Cold weather - more trouble as batters are far less efficient when below certain temperatures.
Frankly, it shouldn't take a whole lot for these to keep communications open and encryption keys or protocols shared but then if I don't plug my phone in overnight when I get up it's way down - all because it's trying to keep communication open to a tower. It's sleeping, the screen is off, I have no games or other stuff that should be sucking power out.

So the reason it does not catch the power being low is because the controller that does that is actually sleeping correctly but then gets polled on due to the fact the radio or whoever wants everyone to confirm who they are, so it goes through its checks and powers off.

You both are right the software can and should be better. If they are following TUV standards each unit of apftware would have no more than 16 units of I/O and that I/O would be checked in a full factorial and then each block would ve checkedin a full factorial against one another. The problem theough is usually architecture atuff is not tested as most engineers check core capability performance and architecture gets implemented moments before production

 

[dcmdon]

So the reason it does not catch the power being low is because the controller that does that is actually sleeping correctly but then gets polled on due to the fact the radio or whoever wants everyone to confirm who they are, so it goes through its checks and powers off.

You both are right the software can and should be better. If they are following TUV standards each unit of apftware would have no more than 16 units of I/O and that I/O would be checked in a full factorial and then each block would ve checkedin a full factorial against one another. The problem theough is usually architecture atuff is not tested as most engineers check core capability performance and architecture gets implemented moments before production

And hence the dual battery reflash. Ha.

Shadow Papa - IPX/SPX?? How long has it been since you had Netware in your network. Ha. To date myself, I was a Netware 3.1 CNE. ha. Circa 1994.

I get that its never possible to anticipate all modes of failure. But I would think that if an item was dragging down bus voltage, you would shut that thing down.

They had that logic in Apollo for gods sake. ha.

 

[ShadowsPapa]

And hence the dual battery reflash. Ha.

Shadow Papa - IPX/SPX?? How long has it been since you had Netware in your network. Ha. To date myself, I was a Netware 3.1 CNE. ha. Circa 1994.

I get that its never possible to anticipate all modes of failure. But I would think that if an item was dragging down bus voltage, you would shut that thing down.

They had that logic in Apollo for gods sake. ha.

I set up Token Ring networks in 89-90 when some of the rogue managers at PFG wanted something better and started setting up servers in their own work areas with Netware.

Then I changed jobs and got into Netware servers in about 90 or 91, I worked for a non-profit health care facility. I set up their network, records scanning, etc. I can't recall the version it was back then but I believe the first server was a 286. Netware could only handle drives of certain sizes at the time. I set up their network on what was a new media, which later became 10BaseT. At the time I set it up I was the first in our area to use it and the equipment was pretty new stuff. It was simply called Ethernet over twisted pair back then until it became a standard.

Then I moved to Compressor Controls Corp (multi-national electronic engineering company) in I believe 92 or 93 and took care of network things there. They were pure Netware until my boss was pushed out and a new guy came in and switched much of the network to Windows. Still they had 4th Shift software that required netware so it was a multi-OS and multi-protocol network. I moved them from old Ethernet to 10BaseT and fiber.

Moved from there to PFG again in 99 where I moved up to the top IT area taking care of server and desktop intrusion prevention and anti-malware. That's where they had the big mix by that time and used mainframe storage as virtual server drives for the netware servers. So it was a real mix.

Then on to the state in 2004 - no more Netware, all Windows, all TCP/IP

 

[flipboltz]

Another update. Tech called and said their “electrical guru” isolated the 2 amp draw to the radio. So, they have ordered new radio that will be here in 5-6 days. We’ll see if that’s the answer.

Hey @Buckshot went to start my jeep just now and the exact same thing happened, stuck in run, wipers running, clicking noise from aux battery. I for sure don't think it is the battery, what was the solution for yours? I never saw an update.

 

[ehs750]

SO first time posting. I bought a used 2021 jeep gladiator willys diesel 6 months ago. Other than dealership holding it for three weeks at beginging because they it said faied wheel sensors(lack of parts ). I have been running great since i have had four wheeling and enjoying. Anyway went on vacation three weeks. when i got back truck would not do anything. completly dead. got a jump from a passing tow truck and was on my way home from LAX. Seen to be charging at 14.1 volt and all was fine. 20 miles down freeway doing 70 all power died no power steeing , brakes. came back on and fine except check engine and anti steering light was on. then next 10 miles power up down no power steering every error you can think of can on screen . towed to dealership and now waiting for update on condition has 34000 mile. so under warrtany

 

[ehs750]

10 days at dealership. being told they check recall first for hpp and found metal in fuel sys. ordered parts for entire fuel sys. waiting for parts and then they will troubleshoot power failure.

Sponsored