sci.electronics.repair@googlegroups.com

Google Groups

N_Cook <diverse@tcp.co.uk>: Oct 19 10:25AM +0100 Camera kept dry but the outer case got wet and transferred damp air into the camera it seems. Looks as though the T (telephoto) switch of the zoom failed , pressing W (Wide) just showed x1 in hte display, no changes up to x6 for zoom. A blast of low heat hot air for 10 seconds , followed by leaving over a warm power supply for a few hours, seems to have cure it, after a bit of faultering recogniton and creeping up from x1 to x6, now back to normal function, but for how long?. Other than getting inside and probably breaking a foil ribbon or something, any advice , other than keeping it out of damp in the futrere?

N_Cook <diverse@tcp.co.uk>: Oct 19 03:56PM +0100 On 19/10/2017 10:25, N_Cook wrote: > function, but for how long?. > Other than getting inside and probably breaking a foil ribbon or > something, any advice , other than keeping it out of damp in the futrere?   I was advised placing in bag of dry ice, where do you get that? theatrical suppliers or cocktail bars? I'll try placing in a bag of freshly oven activated silica gel perhaps, unless anyone has serious concerns about that.

Mike Coon <gravity@mjcoon.plus.com>: Oct 19 04:06PM +0100 In article <osaee6$4t4$1@dont-email.me>, diverse@tcp.co.uk says... > theatrical suppliers or cocktail bars? > I'll try placing in a bag of freshly oven activated silica gel perhaps, > unless anyone has serious concerns about that.   I don't see what benefit dry ice could possibly have for you. It isn't a dessicant, despite the name. (It just doesn't melt to water!)   There are storage bags meant to be squashed around the contents by applying a vacuum cleaner. That might help with the dessication...   Mike.

Barbara Snook <caedfaa9ed1216d60ef78a6f660f5f85_11930@example.com>: Oct 19 12:14PM replying to William Miller, Barbara Snook wrote: ThermadorModel: 16-11-157 Type: S333 I recently had my Thermador microwave break down. It is about 15 years old and is apart of a built in Thermador Microwave/Oven/Warming tray set. A repair man said apparently the magnatron is broken. However, nobody can seem to find the repair parts. I found this particular model in California but they won't sell it to me $750 because it is out of their zip code area!!!   Here is the info I found:  Model: 16-11-157 ( off of my microwave) ProbablyType: S333  By removing the magnatron, it appears that it is made by Panasonic. Model 2m261-m32    Amazingly Thermador themselves cannot tell me where to go for replacement parts! Help!        I removed the magantron and it appears that it is made by Panasonic. Model 2m261-m32       -- for full context, visit https://www.homeownershub.com/maintenance/some-litton-microwave-parts-still-available-291582-.htm

oldschool@tubes.com: Oct 18 02:32PM -0500 On Wed, 18 Oct 2017 04:40:07 -0700 (PDT), "pfjw@aol.com" <pfjw@aol.com> wrote:   >a) Modern caps do not have 'wires inside'. The do have connection(s) between > the foil and the connecting wires that can go flaky - but those are all-or-nothin >g situations.   That tells me how the caps are connected internally, and although it's "all or nothing", I do wonder if jiggling it (tapping it) can make that connection make or break contact? This inverter is very simple, and I'm pretty confident I can fix it. I'll start by replacing that cap. If that dont do it, I may resolder every connection at least on that end of the board.   This simple inverter does not completely shut down when the battery voltage gets low. Instead it keeps shutting offn and on, till the battery gets so low that it shuts off completely. It did leave me stranded once, when it started to go off and on, in my car, when my battery was weak to start with. The car would not start. Fortunately a friend lived 2 blocks away, so I walked to his house and had him come and jump my car.   >b) The buzzer comes on when the input voltage approaches, then drops below > the trigger voltage for the inverter. So, if your battery voltage drops below wh >atever that is - first inverter will buzz, then AC-out will stop. \   The battery used to test that other inverter was purchased 2 months ago, and was just charged, reading 14+ volts on my digital multimeter.   Although I could not find a schematic, I did find an owners manual for that one. The red LED on that one does different things. Low battery makes the red LED light up solid and the buzzer makes a steady sound.   What I am getting is flashing red, and beeping on-off alarm sound. The manual says that means the LOAD is too large. The load I was using was 80W (AC). Far from too large. It was working until I shut off this switch on the load. (ODD). Then that inverter went into that error mode and has remained that way ever since, even with no load. According to web articles, this is a common problem with this model. The circuit in this thing is very complex, and without a schematic, near impossible to trace. So, I think it belongs in my scrap box.

dansabrservices@yahoo.com: Oct 18 12:35PM -0700 Rather than the cap leads being broken internally, I would suspect that they are broken in the holes of the PC board. Try a quick re-solder first. If it behaves the same, just replace them. Dan

"pfjw@aol.com" <pfjw@aol.com>: Oct 18 01:29PM -0700 On Wednesday, October 18, 2017 at 3:33:01 PM UTC-4, olds...@tubes.com wrote:   Note the interpolations. Again, your conception of things is massively flawed.   > pretty confident I can fix it. I'll start by replacing that cap. If that > dont do it, I may resolder every connection at least on that end of the > board.   Yes. A start.   > battery was weak to start with. The car would not start. Fortunately a > friend lived 2 blocks away, so I walked to his house and had him come > and jump my car.   The one is not directly related to the other.   > >atever that is - first inverter will buzz, then AC-out will stop. \   > The battery used to test that other inverter was purchased 2 months ago, > and was just charged, reading 14+ volts on my digital multimeter.   14V measures the availability of a chemical reaction. If all six cells have unconsumed electrolyte, you will get 14V (13.6). But that voltage will sag to as low as 8V (from six cells) under load. This is where the flaw in your understanding lies.     > What I am getting is flashing red, and beeping on-off alarm sound. The > manual says that means the LOAD is too large. The load I was using was > 80W (AC).   No. The load *size* is a function of the input voltage *UNDER LOAD*. If you can do (for round figures) 120 watts (10 A @ 12 V) of AC load at full battery charge, your maximum load at say.... 8V will be about 75 watts. And that is assuming that the battery has a steady-state capacity of 10A @ 8V. It will not. So, your alarms will trigger. Further, if your load is a motor - the starting surge will be up to 3X the steady state load.   Far from too large. It was working until I shut off this > web articles, this is a common problem with this model. > The circuit in this thing is very complex, and without a schematic, near > impossible to trace. So, I think it belongs in my scrap box.   Most inverters, even cheap ones, will re-set if fed from a properly charged battery at full voltage and THIS DOES NOT MEAN from a battery feeding from the alternator at full voltage. The wave-form from an automotive alternator is chopped DC - there are no "smoothing caps". Inverters do not respond well to chopped DC. Nor do most alternators have the capacity to both run a car, run an inverter, and also charge a battery. Those would be highly specialized devices - our VW camper had such an alternator-and-inverter system, as well as a 200 AH deep-cycle marine battery as a second back-up to the regular battery in the engine compartment.   https://www.topmaq.co.nz/wp-content/uploads/2017/02/AVBA1580_a.jpg   One of these will tell you about your battery. A standard VOM will not. Not even my Fluke.   Again, you need to understand the entirety of your *SYSTEM* and what each piece of information means. So far, you have proven that you do not understand even the most basic concepts.   Peter Wieck Melrose Park, PA

"pfjw@aol.com" <pfjw@aol.com>: Oct 18 01:34PM -0700 One more thing to add - even a "new" battery can be irreparably damaged by even a few excessive discharge cycles. Two cycles to below 40% on a standard car battery - and it is toast. I am sure you did not purchase the $200 option (the correct battery for our VW was over $300. And worth every penny.   Peter Wieck Melrose Park, PA

Foxs Mercantile <jdangus@att.net>: Oct 18 05:14PM -0500 > Again, you need to understand the entirety of your*SYSTEM* > and what each piece of information means. So far, you have > proven that you do not understand even the most basic concepts.   Pearls, swine.     -- Jeff-1.0 wa6fwi http://www.foxsmercantile.com

whit3rd <whit3rd@gmail.com>: Oct 18 03:58PM -0700 > case open on it, and when it fails to work, all I have to do is hit the > large electrolytic cap, with the handle of a screwdriver, and it usually > works again.   Internals of an aluminum electrolytic capacitor are foil, and thin foil can sometimes break. The rapping on the can, however, puts stress mainly on a printed wiring board, NOT on internal foils. Look carefully, for cracks or bad solder joints, at or near the pressure-sensitive fault you've located.   Sometimes, fluxing and reheating all the solder joints is easier than getting a good (lens or microscope is helpful) look at them, but also look for cracks in the circuit board material, or nearby components.   Tapping with an insulated probe (chopsticks work fine) will sometimes locate an invisible fault. It could be almost any component, of course.

rickman <gnuarm@gmail.com>: Oct 18 07:30PM -0400 > One more thing to add - even a "new" battery can be irreparably damaged by even a few excessive discharge cycles. Two cycles to below 40% on a standard car battery - and it is toast. I am sure you did not purchase the $200 option (the correct battery for our VW was over $300. And worth every penny.   40% of what exactly?   --   Rick C   Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998

oldschool@tubes.com: Oct 19 02:43AM -0500 On Wed, 18 Oct 2017 12:35:42 -0700 (PDT), dansabrservices@yahoo.com wrote:   > are broken in the holes of the PC board. Try a quick re-solder first. If it be >haves the same, just replace them. >Dan   I did resolder them. I carefully looked over the solder joints on the whole board. All looked ok, but a few were skimpy on the solder, so I resoldered them. I touched the cap leads just for the heck of it, even though they looked good. But it's quit working since then again. I should get my caps in the mail by the end of the week and will replace this one.

"pfjw@aol.com" <pfjw@aol.com>: Oct 19 03:45AM -0700 On Wednesday, October 18, 2017 at 7:30:32 PM UTC-4, rickman wrote:     > 40% of what exactly?   Below 40% of rated capacity on a conventional lead-acid battery starts the sulphation process. Each repeat, and the plates are further damaged, and the overall capacity further compromised.   Peter Wieck Melrose Park, PA

John-Del <ohger1s@gmail.com>: Oct 19 04:39AM -0700 On Wednesday, October 18, 2017 at 6:14:37 PM UTC-4, Foxs Mercantile wrote:   > Pearls, swine.   LOL!   John Wolcott, CT

William Unruh <unruh@invalid.ca>: Oct 18 06:25PM > I'm not sure what you mean, but I guess what you're saying is that firmware > is only available for the newest routers, which I would agree with. Is that > what you're saying?   No. Many closed source vendors do not bother trying to fix things unless their feet are really roasted. In the case of routers, since the primary attack vector is to clients, and since routers rarely act as clients (most are not in bridge mode) they do not bother. And other closed source vendors do not bother since fixing it only affects the bottom line negatively.   > 3. Open-source vendors fix & release code & anyone can do a "diff"   > The problem is that the bad guys can do the diff and then get a jump in the > wild on building an attack vector.   The problem is less than you would expect since it requires that the bad guys actually do the diff. I doubt that there are many who take each update or kernel/programs, diff them and try to figure out whether it was a security update they could use, or some other update that which is of no use to them. Ie, Unless the code or the press point direct fingers at it, they have no particular reason to zero in on the changes.       > I don't know *how* to solve this, and I don't understand what the Krack > Attack researcher proposed for what Theordore should have done.   Their position now seems to be that Theodore should have waited until Oct 16 when they announced it, and immediately rolled out the fixes on that date (as for example Debian did).     > what the changes were and had to "sit on it" (and not tell anyone). (Yes, > I'm well aware of what a "diff" is in the Bash world anyway, which is just > a command revealing what's different.)   Make the fix, but do not release it until the embargo is over.       > I'm confused about one of two events, as to what the researcher wanted: > 1. Did he want Theordore to just *sit* on the fix & wait?   He wanted him to sit on the fix until the bug was announced and everyone could release the fix at the same time.   Note that Theo asked him for permission to release the fix arguing that it was important for his users not to open to attack. But he asked permssion. That permission was given, but regretted.         > 2. Or did he propose not giving Theordore enough info to fix it next time?   No, "all" vendors were notified of the problem in August. So everyone had the opportunity to fix it. The request was to hold off on the implimentation until a certain date so everyone could fix it at the same time without warning the bad guys beforehand.     > 1. Did he propose that they not release the code until it's public? > 2. Or did he propose not *telling* the open-source community early?   > I'm confused what the suggested "solution" by the researcher was. See above.

William Unruh <unruh@invalid.ca>: Oct 18 06:41PM On 2017-10-18, Doomsdrzej <> wrote: >>right.   > I have to disagree with the first statement. The open-source community > does fix bugs which are very well-known and widespread. That is why   Note that the fix for Krack was not a fix in the distributions, but a fix to wpa_supplicant, an external program. So the key person who should be notified was the developer of wpa_supplicant. Note that the "zero password" problem, probably the worst of the lot, could have been fixed privately as if it were a minor improvement (eg instead of zeroing the password, it could have been filled with random chaacters and released without inciting much suspicion. Of course making sure that users actually upgraded would have been a challenge without the urgency of it being a major flaw that could be attacked.     > glitches that only affect about 25% of their users which they might > not actually fix. They only prioritize whatever they know they can't > get away without fixing.   Who are you talking about here? There is a big difference between a bug which only annoys and a bug which is a security issue.

Roger Blake <rogblake@iname.invalid>: Oct 18 08:14PM > (most are not in bridge mode) they do not bother. And other closed > source vendors do not bother since fixing it only affects the bottom > line negatively.   In some cases it may be possible to run alternative firmware, such as dd-wrt or tomato, once the appropriate versions for your router have been patched.   -- ----------------------------------------------------------------------------- Roger Blake (Posts from Google Groups killfiled due to excess spam.)   NSA sedition and treason -- http://www.DeathToNSAthugs.com Don't talk to cops! -- http://www.DontTalkToCops.com Badges don't grant extra rights -- http://www.CopBlock.org -----------------------------------------------------------------------------

harry newton <harry@is.invalid>: Oct 18 09:10PM He who is William Unruh said on Wed, 18 Oct 2017 18:25:42 -0000 (UTC):   > was a security update they could use, or some other update that which is > of no use to them. Ie, Unless the code or the press point direct fingers > at it, they have no particular reason to zero in on the changes.   Thanks William (and Marek), for explaining what the problem is, but what did the researcher propose as the *solution* for open-source code?   Did he propose that OpenBSD *wait* until the announcement 50 days later? How is the researcher going to *enforce* that 50-day waiting period?     > Their position now seems to be that Theodore should have waited until > Oct 16 when they announced it, and immediately rolled out the fixes on > that date (as for example Debian did).   I see you answered my fundamental confusion (see below).   1. Researcher finds bug on day 0 & plans to announce it 50 days later. 2. OpenSource community has to *wait* until the announcement to ship fixes. 3. Closed-source community can ship when? (any time or wait the 50 days?)   If that's the rules, it seems like it's going to be difficult to *enforce*.   >> He used the words "sit on a diff", > Make the fix, but do not release it until the embargo is over.   Thank you for confirming he wanted OpenBSD to sit and wait before releasing the code. I was worried that some *other* researcher ran a diff and had to "sit on his discovery of that diff" which would have revealed to the seconde researcher what the flaw in wpa_supplicant was.   What you're telling me is that nobody did that manual third-party "diff" of the source code so it wasn't revealed in the wild to a third party to our knowledge before the 50-day waiting period was up.   (Note Marek said 60 days but I think the researchers mentioned only 50 days but let's not quibble if either one of us is wrong as it's close enough.)   >> 1. Did he want Theordore to just *sit* on the fix & wait?   > He wanted him to sit on the fix until the bug was announced and everyone > could release the fix at the same time.   That would mean *every* open-source vendor would have to "sit on the fix" until the announcement. That's fine if the researcher can enforce that.   I guess that is what the standard *should* be but who decides such things?   > Note that Theo asked him for permission to release the fix arguing that > it was important for his users not to open to attack. But he asked > permssion. That permission was given, but regretted.   Ah. THANK YOU FOR EXPLAINING. I *knew* there was regret, but to me, a "diff" is something a third party does of the open-source code to figure out what's different. The guy who wrote the code doesn't have to run a "diff" because he *knows* what he wrote.   So I thought a third party who accidentally found out about the bug by doing a "diff" on the open-source code had to "sit" on it. But that didn't make sense given the rest of the conversation.   So THANK YOU for explaining that: A. Researcher finds bug on day 0 & gives all vendors 50 days to fix. B. OpenBSD fixes it early and asks for permission to ship the code. C. Researcher provides permission but then regrets that decision.   In the future, I guess, researcher wishes to deny *permission* of open-source code to ship the fix early, which is a moral conundrum indeed.   And how does the researcher *enforce* this denial of permission to ship open-source code?   > had the opportunity to fix it. The request was to hold off on the > implimentation until a certain date so everyone could fix it at the same > time without warning the bad guys beforehand.   I see the moral conundrum which pits the visibility of open-source code against the obfuscation of proprietary code for the case of a knowledgeable bad guy...   I. In open-source code, a bad guy can do a *diff* to see what changed. II. If something interesting changed, a bad guy can take advantage of it. III. In effect, they get to have their own personal 0-day vulnerability.   For the price of a "diff", the bad guy gets his own 0-day vulnerability. It's a moral conundrum I had never even thought about until today.

harry newton <harry@is.invalid>: Oct 18 09:24PM He who is William Unruh said on Wed, 18 Oct 2017 18:41:25 -0000 (UTC):   > Note that the fix for Krack was not a fix in the distributions, but a > fix to wpa_supplicant, an external program. So the key person who > should be notified was the developer of wpa_supplicant.   Thanks William (although I know you're responding to someone else) for bringing up a second moral conundrum, which is how many people to tell.   Since we all know that a secret is no longer a secret if everyone knows about it, do they normally enforce secrecy rules among *all* developers of code?   I can imagine, for example, that the Chinese government has at least one programmer in their employ at *every* software company in the USA (as just one example), where that programmer is a sleeper (which is trivial for them to do so I can't believe they don't do it so I assume that they do).   The moral question that arises is: Do you tell that sleeper if he is NOT the developer of "wpa_supplicant"?   > chaacters and released without inciting much suspicion. Of course making > sure that users actually upgraded would have been a challenge without > the urgency of it being a major flaw that could be attacked.   If we couple the fact that the bad guys (e.g., the Russian mafia, the Communist sleepers, the NSA/CIA/FBI/GCHQ, etc.,) have an immense bankroll with the fact that a 'diff' is so obvious to run on open-source code, I don't know what the *standard* solution is when it gets down to details.   William and Marek already said that the researcher wanted OpenBSD to sit on the release of the fix until the vulnerability was announced, which opens up "fork" issues (which may be minor though).   Worse - it opens up the "sleeper" issue depending on what the "need to know" classified level of who gets to know about the bug before it's released.   Does everyone sign an NDA before they're told about the bug? Who enforces when/if that NDA is broken?

Richard Kettlewell <invalid@invalid.invalid>: Oct 18 11:14PM +0100 > 2. OpenSource community has to *wait* until the announcement to ship fixes. > 3. Closed-source community can ship when? (any time or wait the 50 days?)   > If that's the rules, it seems like it's going to be difficult to *enforce*.   Policies like this can be maintained by requiring recipients of vulnerability predisclosures to agree to maintain confidentiality prior to embargo dates. An organization could choose to break that agreement, but they shouldn't expect to be trusted with predisclosures in the future if they do so.     > I. In open-source code, a bad guy can do a *diff* to see what changed. > II. If something interesting changed, a bad guy can take advantage of it. > III. In effect, they get to have their own personal 0-day vulnerability.   You can inspect object code to discover what the bugs were, too. A high-profile example was the 2015 analysis of the Juniper RNG vulnerability, where no source code was required.   -- https://www.greenend.org.uk/rjk/

William Unruh <unruh@invalid.ca>: Oct 19 01:09AM > did the researcher propose as the *solution* for open-source code?   > Did he propose that OpenBSD *wait* until the announcement 50 days later? > How is the researcher going to *enforce* that 50-day waiting period?   Yes, wait. Enforcement is a non-issue. He cannot force compliance. He can however let it be known what they did which will then cause others not to tell OpenBSD anything when the next problem arises. The people doing open source distros are responsible people and their intention is not to make it easy for the bad guys to do nasty things.     >>> He used the words "sit on a diff", >> Make the fix, but do not release it until the embargo is over.   > Thank you for confirming he wanted OpenBSD to sit and wait before releasing   And that made Theo uncomfortable, so he asked permission to ship early. He did not simply go ahead and do it.     > What you're telling me is that nobody did that manual third-party "diff" of > the source code so it wasn't revealed in the wild to a third party to our > knowledge before the 50-day waiting period was up.   WE will never know for sure of course. But there was apparently no evidence that this crack was actuallyused in the wild. Of course NSA may have discovered it 5 years ago, or perhaps ISIS did.   >> could release the fix at the same time.   > That would mean *every* open-source vendor would have to "sit on the fix" > until the announcement. That's fine if the researcher can enforce that.   What is your hang up about "enforce"?       > I guess that is what the standard *should* be but who decides such things?   AGain you are hung up on a "enforce"/central authority thing. People can behave well all on their own, without legal sanctions or centralized laws.   > "diff" is something a third party does of the open-source code to figure > out what's different. The guy who wrote the code doesn't have to run a > "diff" because he *knows* what he wrote.   The permission was to release a patch for the problem. The bad guys could than run a diff on the released new code to see what was changed. That is where the diff comes in.       > So I thought a third party who accidentally found out about the bug by > doing a "diff" on the open-source code had to "sit" on it. But that didn't > make sense given the rest of the conversation.   The worry was that by releasing a patched system, it made it easier for some bad guy to discover there was a problem and what it was.     > open-source code to ship the fix early, which is a moral conundrum indeed.   > And how does the researcher *enforce* this denial of permission to ship > open-source code?   And again. Note that thousands of security holes have been found and annnouncent embargoed in the past. So there is a history of the open source community acting responsibly.   > III. In effect, they get to have their own personal 0-day vulnerability.   > For the price of a "diff", the bad guy gets his own 0-day vulnerability. > It's a moral conundrum I had never even thought about until today.   Yes, but many many others have thought about it.

Snit <usenet@gallopinginsanity.com>: Oct 18 08:08PM -0700 On 10/18/17, 9:38 AM, in article bp0fucp267mmuhhk8r890o5dpecqn8jf8v@4ax.com, > glitches that only affect about 25% of their users which they might > not actually fix. They only prioritize whatever they know they can't > get away without fixing.   They are slow to fix usability issues, but faster to fix security issues.   -- Personal attacks from those who troll show their own insecurity. They cannot use reason to show the message to be wrong so they try to feel somehow superior by attacking the messenger.   They cling to their attacks and ignore the message time and time again.   <https://youtu.be/H4NW-Cqh308>

harry newton <harry@is.invalid>: Oct 19 06:20AM He who is William Unruh said on Thu, 19 Oct 2017 01:09:07 -0000 (UTC):   >> For the price of a "diff", the bad guy gets his own 0-day vulnerability. >> It's a moral conundrum I had never even thought about until today.   > Yes, but many many others have thought about it.   Thanks for explaining the situation, and the process.

"fynnashba@yahoo.com" <fynnashba@yahoo.com>: Oct 18 06:03PM -0700 Hello L have an HP Notebook 200 which has a white screen when it is switched on. in fact no key seem to work apart from the CAP lock key. I ve changed the memory but the problem remains the same. l noticed that when l fixed back the hard disk Ctrl+ Alt+ Del works. Please l need help Thanks

bitrex <bitrex@de.lete.earthlink.net>: Oct 18 07:47PM -0400 >> "using an iron transformer to produce 120V AC output."   > What other kind is there ? /something like stacked Dickson converters ? Or have they found a way to go SMPS with it ?   Imagine like a Class D audio power amp type topology that can put out a 120VAC 60Hz sine wave.

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to sci.electronics.repair+unsubscribe@googlegroups.com.