Hacker News Reader

>> were trying do it in the field, without the proper reference materials, equipment, or parts

there is your problem.

that does not mean that the fix is to have a 'nobody can touch this but the contractors'

The US Military - all branches - have a long and great tradition of making field fixes. This is critical out there.

Waiting 3 days for a 10min fix may be acceptable in a US base, but in a war zone it will get people killed. At the very least, they need to be able to get remote support for on-site personnel to actually implement the fix.

Man, I think you have a wrong impression here, field fixes are usually sacrificial, and are made in haste, and often on "this might work." A great tradition it isn't, coat it in 100 MPH tape and 550 cord, and hope it holds. is generally the the solution to most issues.

Not to say there haven't been great innovation, but realistically most of these repairs are being made by guys that barely got out of high school, and had maybe 20 weeks of training. (I was one of them, its not a dig, its reality)

And as much as it pissed me off when a piece of equipment was no longer available, because it got shipped off, I was also equally pissed off when my unit all got sick and was throwing up because our water purification system broke, and a commander told the cooks to add bleach to the water. That is something a soldier has to do, where as a contractor wouldn't be likely to.

In the military you spend a lot of your time pissed off because someone, somewhere is doing something stupid, and it will probably get you killed.

> In the military you spend a lot of your time pissed off because someone, somewhere is doing something stupid, and it will probably get you killed.

This very succinctly sums up almost every conversation I've had with ex-military.

Bleach is perfectly fine to kill bacteria & some nematodes but, its like 1 cap full per 5gal and should be allowed to outgas after. Don't get me wrong, its not the best method but, it works.

Oh military communications equipment. I can totally see that stuff bugging out if someone looks at it wrong.

I actually worked a bit designing military comms when I was just out of school, but left because the politics was too crazy. Military comms seems to be held back in the 60s where everything had to be built for purpose and it doesn't matter that this radio uses 15 bit bytes and runs on 22 volt power and that radio uses 13 bit bytes and runs on -48 volt power since they were never designed to communicate or exist in the same system. Until a "Grand Program" is started to get them to talk. Then contractors comes out of the woodwork and eventually they come up with a design where the two radios (positioned next to each other) pass "XML" (<bit position:0 value:0\>) over a custom designed third pair of radios and can communicate only a small subset of what either radio was able to express. Of course none of that uses Ethernet or IP or even some standard military connection protocol, because that would make things less efficient and suppliers want the biggest numbers possible so they are competitive.

If we are going to have a technology dependent military and they can't use COTS then they should at least make things modular so learning about one piece of hardware can be applied to other pieces of hardware. And hey, if it's modular then maybe military techs can at least swap modules to fix stuff.

There are a few reasons that military tech turns out this way. The largest I've seen is that the military doesn't actually make any money with it's tech. From a classic business perspective, it's just an end user. There isn't a monetary incentive to remake entire systems to work well together.

Another big reason for the strange and overbearing standards is that there are so many different classified legacy systems that need to function, and no one is really allowed to alter, that newer systems need to be backwards compatible to work with them.

I'm not sure I buy the argument about not making money. Sure there's not a monetary incentive to make the whole system work well together, but that doesn't mean that the military should ignore how failures in their communication infrastructure limit their ability to rapidly respond to threats and coordinate between different forces. Combined arms is a thing a after all, and it sucks when people have to spend time coordinating because targets or enemies show up in some units but not their attached units (or worse show up in different locations on each).

Sure, legacy systems are an issue and compatibility is necessary (especially for systems we need to talk with allies who spends less money upgrading equipment than we do). But that doesn't justify the new things not working together. Is there a reason that we got MADL with the F-35 and IFDL for the F-22 and needed a special program (with unmanned airborne relays) to allow the two to talk? Those are both new systems, there just doesn't seem to be any overall coordination. Heck, to some degree it seems like this inability to interoperate is intentional, as one of the F-35 requirements was that it could receive but not transmit on the existing legacy waveform, Link-16.

I don't mean to be so negative about it. The technology behind modern military radios is incredible and the radios effectively meet the requirements that the military specifies. This allows them to do amazing things. I just think that, particularly for communications, they need to look past the new hotness for something less exciting that both ages better and works well with existing systems.

The military isn't all that concerned about a modular enterchangable system that use similar methods between systems.

We have time and available people who are educated, they can learn the some odd 40 systems in 27 weeks (excluding tacSat.)

So all those conveniences, only serve to make it easier for our enemies to understand. Additionally alot of the military communications equipment make use of proprietary hardware that perform functions standard equipment can't and in environmental conditions that would make it impossible for off the shelf equipment.

As for the network over FM they've had that since the late 90s, at the time because of the security and frequency hoping, and it being all done analog, the network could span roughly 15 miles and had a 64kbps backbone.

Just enough to send text file reports over.

But why worry about enemies understanding the radio? I can practically guarantee that the lower classification maintenance books that get "lost" already make it to enemy hands. Plus if we use COTS then looking at anything but the encryption module would tell them little to nothing and allow them to use whatever existing civilian supply chains are available.

Sure there's a time for LPI/LPJ, but short of a war with China I don't really see the need for most forces. Anywhere else we'd have air superiority and jammers are just loud, bright targets.

If you have a LPI/LPJ module you just put in the radio when you need it then it's much easier to keep out of enemy hands.

Then there is the cost of training for all the different radios. Yes, you could put one man or of a squad in training for 6 months ago he knows the basics about every radio there is. Or you could spend a couple weeks teaching everybody how to work a radio. Or you could have a real in depth training so you have a lot of fully qualified repair technicians.

I'm not exactly sure what your talking about for the radio waveform fielded in the late 90s. That's too late for SINGCARS and too early for JTRS waveforms like SRW and WNW. The capability description seems a bit like SRW (though that is frequency hopped, not FM), which was one of the few limited "successes" that came out of JTRS (the design goals were 100x as many members of the network, 10x the range, 10x the backbone capacity, and the ability for software upgrades to make it compatible with any future radio).

I'm at the end of the day you really need to argue this with the military not me.

as far as COTS parts, I mean if you think you can build a radio of that size with its requirements,life span,etc someone probably would have.

they moved to slightly modded radios similar to law enforcement for squad level communications, but I dont see that happening for larger scale systems in the near future.

But the field operation guide doesn't tell you how to open the radio, that is beyond operator (RTO) and field services.

There were at least 11 builtin counter measures, to prevent someone from exploring the guts of the radio, and sure you could see what is in the radio, but once the eproms fried themselves, you would be hard pressed to figure out what was on them.

The manuals that explain those enter workings aren't issued to field units, hence why they have maint. Centers.

Not sure what you mean by too late for SINCGARS, the originals before the half sizes came out, I just as you could load the crypto and hopset from and ANCD, all you need to do was take a dog bone cable and splice and map the wires to a serial cable, and then configure telnet. Then set the proper broadcast mode on the radio.

you could probably find the specifics in a leaked field manual :)

So the equipment deployed in Afghanistan then needs to do a round-trip in US if it’s critical to the mission? I understand why Capt. insist so much to attempt a local repair. Are there repair posts in deployment?

That is interesting.

Surely there is a middle way? This is a classic throwing the baby out with bathwater.

The middle way is have fixed-cost civilian contractors for 'standard' maintenance, and contractors that bill by the hour for fixing fuck-ups caused by field repairs.

You still have the issue of middle-managers in the armed forces asking enlisted men to do stupid things, that end up wrecking equipment, but the only way to fix that is for better accountability within the command structure. Good luck with that, since the lack of accountability shields the only people who have the power to fix it. [1]

[1] See this outline of the fatal collision of the USS Fitzgerald for an example of how well accountability for stupid orders works in the US Armed Forces - https://features.propublica.org/navy-accidents/uss-fitzgeral... [2]

[2] The long and short of it is that someone above you tells you what to do, and if you can't do it, you get canned. So you do it, but you cut corners. If those cut corners cause a disaster, it'll be your ass on the line.

> The equipment you get there is usually the result of a failed attempts by trained personal to fix things

Are there statistics on how many things were successfully fixed vs how many ended up in the maintenance center? If not, that is a possible survivorship bias, kind of.

I don't understand. With pounding sand, don't contractors get tried with military tribunal if they interfere with field activities of the army? Like, SWAT team in the house, with "give us source code or we're going to the court with charges of treason now"? I'd assume Capt. is correct in attempting to fix immediately, and somebody who'd oppose him should be investigated, right? By CID or FBI? Because contractors can't likely make fixes more ASAP than operators in the field?

Or is it the purchasers who're procuring the equipment which "needs to be shipped and fixed properly"? Are we fighting wars in a manner "wait a minute, dear enemy, I'll just fix this small issue in a gusto, and we'll continue"?

Just curious.

Contractors don't fall in the military hierarchy and the example given isn't interfering with field activities.

Basically, a Capt can say what ever they like but if it's just not possible to be fixed in the field then it's not going to happen.

Also, you don't get thrown into jail everytime you disobey an order. Especially when it comes to technical equipment.

I'm not a lawyer, but I'd assume when a field unit conducts operations, in the field, and some equipment fails, it's the job of the supply chain to do everything possible to help mitigate the issue reasonably fast. Definition of "reasonably fast" would be an expectation, carried from previous history of similar cases, and definition of "similar" is carried from previous history of purchasing equipment for the army. In other words, one can't just say "oh, this is more complex, and suddenly you can't rely on your practices anymore" without first - when the equipment was talked about - making that clear.

And "everything possible" would include tools, electronic or software, and software codes - and yes, possibly engineers who created them on the line, something like what was done when Apollo project had landings on the Moon. Only in this case I'd assume different kind of responsibility than just contractual.

I don't fall in the military hierarchy at the moment, but that doesn't mean I can give aid and comfort to enemy. Again, I'm not a lawyer - that's why it's a tribunal - but for a court to give go-ahead to this (absent more prompt collaboration beforehand) would be something to expect. What would you expect if you'd be in the field in this case?

And that's the point - for such a contractor, the only punishment available is through courts, with more or less a presumption of innocence, and where the officer is in a lot of career jeopardy if the tribunal digs up that they were being unreasonable.

By contrast, a soldier in the chain of command can be punished administratively, and disobeying orders is a crime that in most militaries is only excusable if the order is criminal, not if it's stupid. Rarely brought, but the spectre of it is there

You can always refuse the NJP and demand a court martial. In most cases, it's an extremely bad idea. As you go up the chain, more severe punishment can be applied.

I have seen it work with one pissed off LCpl. The officer decided to back off.

The requirements and financial penalties for failing to perform the duties specified in the contract are spelled out... in the contract. The biggest one is the government could neither give you a pile of money nor give you the opportunity to earn more piles of money in the future.

There is no way you could do your job badly enough for it to be treason nor as far as I know subject one to a military tribunal.

I have wondered what the procedure is when someone gives impossible orders. Like, I know there's a spectrum here, but just to illustrate, what do you do if your superior says "I'm ordering you to jump that gap" but it's thirty feet wide and fifty feet deep with big metal spikes at the bottom? If you ordered me to, I don't know, fix a computer, and I've diagnosed that the computer is busted because the CPU has let the magic smoke out and I don't have any spares or any other less-critical equipment to cannibalize for a replacement CPU, is it just my job to tell my superior that it can't be fixed and if they keep insisting I'm just going to have to wait for my lawyer save me at the court-martial?

Stanley Kubrick's Paths of Glory is a good illustration of how this question plays out.

There's no duty to obey an unlawful order; UCMJ case history indicates that in order to be lawful an order can't infringe on the statutory rights of the person receiving the order. In other words, you don't have to kill yourself attempting a patently impossible feat, and as there can be no possible military objective being pursued by giving the order, the officer should know better than to issue it.

As for your second scenario, yes, that's about it. Although to be honest it's unlikely to ever go to court martial; an officer demanding impossible things happens all the time and is dealt with at the company level.

The parent appears to conflate general orders with technical orders; your interpretation of the second scenario appears to do the same as well.

The word "technical" does not appear anywhere in the UCMJ. Technical orders are Air Force specific. There is no distinction between general orders and other kinds of orders in the military at large.

Nor did I say it did either.

The proper term "Technical Order" is indeed salient to the Air Force, but the notional concept of a "technical order" is precisely what the parent describes and exists in all branches of service, deriving its authority from a long traceability chain that terminates as a general order issued by the Secretary of the respective branch of service, e.g. in the Navy, its functional equivalent is a "Technical Manual".

I beg to differ on distinction. Whereas both uniformed and civilian personnel are required to comply with executing technical orders per the same chain of authority, the latter is almost completely shielded from the punitive hammer of the UCMJ.

In the US, you'd be conflating general orders (punishable by Article 92 of the UCMJ applicable to uniformed personnel) and technical orders (something completely different and more akin to a commercial service manual).

Despite seemingly popular belief, uniformed personnel maintaining military equipment simply aren't at liberty to arbitrarily fix shit that breaks however way they please using whatever support equipment/material is readily available.

Think of it this way: the general order issued would be that all uniformed personnel must comply with the explicit language of technical orders in performing routine/unscheduled/critical maintenance of military equipment---no more, no less. In turn, said technical orders specify the applicable troubleshooting, diagnostic, repair, test, documentation, etc. instructions that maintenance personnel must follow and even describe system theory of operations (albeit fairly high level; nowhere near the level of specificity adequate for an engineer).

Consider this[1] junior Air Force crew chief. He's reviewing the maintenance records (specifically, 781A records which document discrepancies, related maintenance and their associated corrective actions; maintained in parallel with mirror digital database equivalent) of an assigned aircraft because he was trained in tech school on compliance of a certain mandatory technical order[2] to do so. Everything he and all his uniformed colleagues are tasked to perform is quite literally "by the book" (of which there are many) and to be executed without deviation. In theory, nothing is left to guess work and everything is traceable, all the way down to what pieceparts of a weapon system can/can't be serviced at specific levels of maintenance. Technical order doesn't exist? Can't do it. Demonstrated proficiency at a routine task? Doesn't matter; the applicable technical order must always be present, open at task and performed to the letter at all times. In this environment, you're not authorized to wipe the ass end of an aircraft without an explicit technical order enumerating step-by-step instructions. That maintenance officer screaming at this guy's senior enlisted supervisor is in fact a logistician in company-grade uniform. Said officer can steer this airman towards court martial for a serious enough technical order deviation, but really can't do shit if exhaustive technical order compliance doesn't result in a desired outcome.

In your example, the system would be deemed "not mission capable", the required part(s) would be placed on order (whose priority shot call would be determined by the production superintendent) and you'll move on to something else until the part(s) arrive and you're directed to resume maintenance action.

[1] https://www.defense.gov/observe/photo-gallery/igphoto/200245...

[2] https://www.tinker.af.mil/Portals/106/Documents/Technical%20...

Ah, that makes sense - If the universe of orders that can be given w.r.t. technology is closed, then yeah, there's theoretically no ambiguity and there's no way for the superior and the technician to disagree about whether an order can be followed. Thanks for the detailed writeup!

I'm not sure how you are refusing to improperly service something, The contractor is there because a high ranking individual at the DOD put them there, in most cases they are helpful, and willing to help out when they can, but they are there with the orders to make sure the equipment they are tasked is maintained properly.

With that said, if a commander orders someone under his command to smash the piece of equipment with a hammer, the contract won't interfere, but he will report the situation.

The issue is, most of the equipment at this point is well beyond the knowledge a company commander would have, they aren't qualified to know if this is something that can be fixed in the field, and a soldier under his command that is qualified isn't in a position to refuse the capt. order. So they fry the equipment.

The army is pretty big on redundancy, and having contingencies, it would be very rare that an operation couldn't continue without a single piece of equipment. It might be harder, and may be a greater risk, but in a place where lots of things get shot, you make a plan, then you make due.

I'm not saying the scenarios I'm describing fit all situations, but I can say that far less equipment was destroyed after they came on board.

I didn't mean a contractor in the army quarters. Being in the field close to soldiers should help - in case of farmers, it's as if John Deere's certified mechanic (of course with all training, tools and spare parts, including and especially all software-related) was on the farm during harvest period. However, there shouldn't be a situation when the equipment can be fixed - i.e. it's not destroyed enough - and it's not because of software. Software is something which is relatively easy to change - I'm a software guy - and it has this property and advantage over hardware. So if it's software which misbehaves, it should be double duty of such a contractor - this time the whole company, not only the person in the army position - to help with everything, in a timely manner. In farm it's to allow harvesting to go with less problems, in fight it's to avoid losses among soldiers.

I'm mostly talking about the whole company approach to such time-sensitive customers.

You can't field-update software which has to pass a hardware-enforced integrity check. This is by design, and is very much a feature (for further reading, look into anti-tamper).

In general, military (electronic) gear is designed to be difficult to repair because repair and reverse-engineer are pretty similar. One radio being out is a small problem. The radio system's crypto being compromised because it was captured and reversed is a big Problem.

> You can't field-update software which has to pass a hardware-enforced integrity check. This is by design, and is very much a feature (for further reading, look into anti-tamper).

The suggested notion that anti-tamper integration exists on arbitrary whathaveyou weapon systems is, at best, misinformed. Field updating of operational software at the box level over e.g. 1553, or ARINC 429 via 615, or even vanilla RS-485 PHY via bespoke protocol, is very much a thing and almost de facto mandatory capability for most systems. If we broaden the scope of the term "field" to include intermediate-level maintenance in forward-operating labs staffed by uniformed personnel, then even firmware updates of cherry-picked circuit card assemblies can be a thing (although much simpler isolation to a replaceable circuit card or modular assembly is a lot more typical; CCA-level firmware updating is usually reserved for depot or OEM activity).

> In general, military (electronic) gear is designed to be difficult to repair because repair and reverse-engineer are pretty similar.

Bullshit. In fact the exact opposite is almost always boilerplate baked into acquisition performance objectives, sometimes even down to defining explicit MTTR targets. Certain systems even modularize the anti-tamper crypto applique portion to enable repair of everything else that isn't anywhere near as sensitive and much more probable to fail based on analysis.

The real meta is an adversarial one where private defense contractors are intentionally exploiting a complex process with the objective intent of locking in the ever so lucrative OEM sole source sustainment dependency, and the corrupt influence on DFARS statutory language as it relates to technical data rights is a critical part of that game.

> Software is something which is relatively easy to change - I'm a software guy - and it has this property and advantage over hardware.

Ha...you've clearly never been a software engineer in the encumbered world of fielded defense systems.

I would suggest you start by reading the part of the constitution where the crime of treason is defined and then continue on until you get through the bill of rights. Any dysfunction there is is liable to be systematic. You wouldn't need to point a gun at someone to force them to share their source code and if you did YOU would be the one going to prison. If it was required by the fat government contract it would be done.

Sometimes there's nothing you can do to fix something and a piece of equipment has to be shipped off and repaired (in my line of work this has usually required cranes to take communication terminals off ships!). Usually the military will want to have spares though, so there are options if field repair isn't viable.

The manufacturer/contracting company will always have a contract with the customer limiting liability so no, you're not going to be tried for anything but the company might get sued for breech of contract if things go really wrong.

But my experience has been they they are pretty chill as long as you're respectful, make it obvious that you're competent and you know what you're talking about (which requires actually being competent, not something you can fake for long in that kind of situation!), and offer alternatives and solutions to get things going again.