Re: [pfSense] Lightning strike

[Volker Kuhlmann]

On Fri 14 Oct 2016 16:41:22 NZDT +1300, Jim Thompson wrote:

> > Does a disappearing reX driver interface renumber the ueX interfaces?
> 
> On FreeBSD?  no.  On a linux system?  LIkely.

I am unsure whether that is still so for Linux, there seem to have been
changes there but I haven't looked at it as it's been inconsequential to
me. But pfsense runs on freebsd so linux behaviour has no relevance
here.

> Let's say you had one re(4) and two em(4) devices.   Let's assume for now
> you have:
> 
> em0: WAN
> em1: LAN
> re0:  OPT1
> 
> Case 0:
> em0 gets fried in such a way that it doesn't enumerate on the bus.  We are
> left with:
> em1: LAN
> re0: OPT1
> What should pfSense do in this instance?

Run! No change of interface assignments to ports. Ignore missing
interfaces. The way you are presenting this anyway.

> Case 1:
> em1 gets fried in such a way that it doesn't enumerate on the bus.  We are
> left with:
> em0: WAN
> re0: OPT1
> What should pfSense do in this instance?

Run with re0:OPT1 only. Ignore missing interfaces.

> Case 2:
> re0 gets fried in such a way that it doesn't enumerate on the bus.  We are
> left with:
> em0: WAN
> em1: LAN
> What should pfSense do in this instance?

Run. No change of interface assignments to ports. Ignore missing
interfaces.

> Case 3:
> pfSense is operating in a dual-WAN mode
> em0: WAN0
> em1: WAN1
> re0:  LAN
> 
> em0 gets fried in such a way that it doesn't enumerate on the bus.  We are
> left with:
> em1: WAN1
> re0:  LAN
> What should pfSense do in this instance?

Run with re0:LAN only. Ignore missing interfaces.

> Case 4:
> pfSense is operating in a dual-WAN mode
> em0: WAN0
> em1: WAN1
> re0:  LAN
> 
> em1 gets fried in such a way that it doesn't enumerate on the bus.  We are
> left with:
> em0: WAN0
> re0:  LAN
> What should pfSense do in this instance?

Run with re0:LAN only. Ignore missing interfaces.

> Case 5:
> pfSense is operating in a dual-WAN mode
> em0: WAN0
> em1: WAN1
> re0:  LAN
> 
> re0 gets fried in such a way that it doesn't enumerate on the bus.  We are
> left with:
> em0: WAN0
> em1: WAN1

Run with em0: WAN0, em1: WAN1 only. Ignore missing interfaces.

> Now let's say you have a 2440, with 4 igb(4) interfaces
> 
> igb0: WAN0
> igb1: WAN1
> igb2: LAN
> igb3: OPT1

All interfaces are igbX. No interfaces left that don't get shuffled
around. Stop.

All your remaining cases are the same.

> Now, having described the desired behavior for pfSense in each case,
> generalize an algorithm for up to 8 interfaces of
> the same device type, 8 different device types, or a mix of device types, that
> behaves correctly in each case.
> 
> Pseudo-code will do for now.

I had already given it in my previous email. It doesn't give improvement
in all cases, but in those which are safe. You'll need to store
user-chosen mappings of interfaces to ports. That's already done.

The current situation sucks. A user of a router appliance is not
primarily interested in as to why it sucks.

But Espen Johansen gave the solution: Don't touch primary OS-port names
or their braindead implementation. Create aliases based on MAC address.
Access port exclusively through alias name. Fix pfsense(!!) to keep
rules assigned to no interface accessible from the BUI, so the user can
manually re-assign them in bulk, instead of enforcing a click-me-stupid
orgy or XML file hacking. Aliases to emX, reX, igbX etc names are a
matter of today's intelligence in OS implementation. No more excuses for
decades old decisions. :-)

Volker

-- 
Volker Kuhlmann is list0570 with the domain in header.
http://volker.top.geek.nz/  Please do not CC list postings to me.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Espen Johansen]

Map interfaces based on mac and give them a name. Then adress the
interfaces based on that name. When it comes to reorganization of
interfaces the answer is; don't do it. Let the user remap interfaces
manually only. If the user wants to drop their DMZ to get wan back online
then it should be a manual process.
In order to accomplish this you need a interface database and a simple
interface setup process with a foreach loop. This code was done in 2007 but
it was never comitted.

Ifconfig allows naming of interfaces. So once they are named and mac->name
binding is done, then the binding is remebered "forever" in a config file.
If a new interface is added and not found in the mac->name "DB" it is just
placed in a unassigned state untill the user assigns it manually.

-lsf

On Fri, Oct 14, 2016, 18:00 Vick Khera  wrote:

> On Thu, Oct 13, 2016 at 6:25 PM, Walter Parker  wrote:
> > Problem is that all of the current OS do this sort of renumbering (I'd
> have
> > to check, but I think it could be a hardware/driver issue). IIRC Linux
> > systems have had this sort of problem in even greater measure than the
> > BSDs. The plug and play nature of USB has caused issues for most systems
>
> Current versions of CentOS/RedHat hard-wire ethernet names. You have
> to go dig in and find some file that has the mappings and delete them
> if you do something like replace a motherboard with embedded NICs,
> otherwise it makes all new ethernet device names for you. The mapping
> is base on MAC address.
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Vick Khera]

On Thu, Oct 13, 2016 at 6:25 PM, Walter Parker  wrote:
> Problem is that all of the current OS do this sort of renumbering (I'd have
> to check, but I think it could be a hardware/driver issue). IIRC Linux
> systems have had this sort of problem in even greater measure than the
> BSDs. The plug and play nature of USB has caused issues for most systems

Current versions of CentOS/RedHat hard-wire ethernet names. You have
to go dig in and find some file that has the mappings and delete them
if you do something like replace a motherboard with embedded NICs,
otherwise it makes all new ethernet device names for you. The mapping
is base on MAC address.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Dave Warren]

On Thu, Oct 13, 2016, at 20:41, Jim Thompson wrote:

> What should pfSense do in this instance?

Point taken about all the possible things that can go wrong and various
permutations from pfSense's perspective.

As a starting point for a generalized solution, isn't it possible to
read the hardware MAC address from an ethernet device? If so, couldn't
the hardware MAC be used to uniquely identify interfaces even if the
disappearance of one or more interfaces causes interfaces to be
renumbered?


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Jim Thompson]

You are making a very poor assumption about which parts of the "Ethernet"
interface are missing after a high voltage event.

You may still have (enough of) the MAC to be enumerated on the
(PCI/PCIe/...) bus.   If this occurs, then no renumbering will take place,
since, as far as BIOS/boot firmware/OS can 'tell', the device still exists
(can be enumerated), even if the PHY(s) are non-responsive.

This is different than removing a PCI/PCIe card from a system.  In this
case, the device is no longer on the bus, and will not be enumerated
for the OS to probe/attach/open/...

> Does a disappearing reX driver interface renumber the ueX interfaces?

On FreeBSD?  no.  On a linux system?  LIkely.

Let's say you had one re(4) and two em(4) devices.   Let's assume for now
you have:

em0: WAN
em1: LAN
re0:  OPT1

Case 0:

em0 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
em1: LAN
re0: OPT1

What should pfSense do in this instance?

Case 1:
em1 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
em0: WAN
re0: OPT1

What should pfSense do in this instance?

Case 2:
re0 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
em0: WAN
em1: LAN

What should pfSense do in this instance?

Case 3:
pfSense is operating in a dual-WAN mode
em0: WAN0
em1: WAN1
re0:  LAN

em0 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
em1: WAN1
re0:  LAN

What should pfSense do in this instance?


Case 4:
pfSense is operating in a dual-WAN mode
em0: WAN0
em1: WAN1
re0:  LAN

em1 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
em0: WAN0
re0:  LAN

What should pfSense do in this instance?

Case 5:
pfSense is operating in a dual-WAN mode
em0: WAN0
em1: WAN1
re0:  LAN

re0 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
em0: WAN0
em1: WAN1


Now let's say you have a 2440, with 4 igb(4) interfaces

igb0: WAN0
igb1: WAN1
igb2: LAN
igb3: OPT1

Case 6:

igb0 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
igb1: WAN1
igb2: LAN
igb3: OPT1

What should pfSense do in this instance?

Case 7:
igb1 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
igb0: WAN0
igb2: LAN
igb3: OPT1

What should pfSense do in this instance?

Case 8:
igb2 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
igb0: WAN0
igb1: WAN1
igb3: OPT1

Case 9:
igb3 gets fried in such a way that it doesn't enumerate on the bus.  We are
left with:
igb0: WAN0
igb1: WAN1
igb2: LAN

What should pfSense do in this instance?

Case 10:
igb0 and igb1 get knocked off the bus
What should pfSense do in this instance?

Case 11:
igb1 and igb2 get knocked off the bus
What should pfSense do in this instance?

Case 12:
igb2 and igb3 get knocked off the bus
What should pfSense do in this instance?

Case 13:
igb3 and igb0 get knocked off the bus
What should pfSense do in this instance?

Case 14:
igb0 and igb2 get knocked off the bus
What should pfSense do in this instance?

Case 15:
igb1 and igb3 get knocked off the bus
What should pfSense do in this instance?

Case 16:
igb0, igb1 and igb2 get knocked off the bus
What should pfSense do in this instance?

Case 17:
igb0, igb1 and igb3 get knocked off the bus
What should pfSense do in this instance?

Case 18:
igb1, igb2 and igb3 get knocked off the bus
What should pfSense do in this instance?

Now, having described the desired behavior for pfSense in each case,
generalize an algorithm for up to 8 interfaces of
the same device type, 8 different device types, or a mix of device types, that
behaves correctly in each case.

Pseudo-code will do for now.

I look forward to your response.

JIm


On Thu, Oct 13, 2016 at 8:41 PM, Volker Kuhlmann 
wrote:

> On Fri 14 Oct 2016 11:25:12 NZDT +1300, Walter Parker wrote:
>
> > Problem is that all of the current OS do this sort of renumbering (I'd
> have
> > to check, but I think it could be a hardware/driver issue). IIRC Linux
> > systems have had this sort of problem in even greater measure than the
> > BSDs. The plug and play nature of USB has caused issues for most systems
> > (drive letter changes on Windows, device name changes on Linux, even BSD
> > has started doing this). The brain dead here is problem that extends to
> the
> > PC industry as a whole.
>
> Totally with you there on PC industry intelligence!
>
> > PFSense is subject bad decisions that were made
> > decades ago by other companies without enough vision. The automapping
> ideas
> > in hardware were not properly thought out and software didn't think it
> > though either.
>
> Sure, pfsense can do little about dumb OS things, and swapping
> interfaces randomly is a major security problem. But pfsense could still
> do much better. Does a disappearing USB interface renumber Ethernet
> interfaces? Does a disappearing reX driver interface renumber the ueX
> interfaces? I didn't th

Re: [pfSense] Lightning strike

[Volker Kuhlmann]

On Fri 14 Oct 2016 11:25:12 NZDT +1300, Walter Parker wrote:

> Problem is that all of the current OS do this sort of renumbering (I'd have
> to check, but I think it could be a hardware/driver issue). IIRC Linux
> systems have had this sort of problem in even greater measure than the
> BSDs. The plug and play nature of USB has caused issues for most systems
> (drive letter changes on Windows, device name changes on Linux, even BSD
> has started doing this). The brain dead here is problem that extends to the
> PC industry as a whole.

Totally with you there on PC industry intelligence!

> PFSense is subject bad decisions that were made
> decades ago by other companies without enough vision. The automapping ideas
> in hardware were not properly thought out and software didn't think it
> though either.

Sure, pfsense can do little about dumb OS things, and swapping
interfaces randomly is a major security problem. But pfsense could still
do much better. Does a disappearing USB interface renumber Ethernet
interfaces? Does a disappearing reX driver interface renumber the ueX
interfaces? I didn't think so, so it should be possible to remove those
that will/could be renumbered and run with the rest, without getting
surprises other than missing interfaces or failing to boot.

Volker

-- 
Volker Kuhlmann is list0570 with the domain in header.
http://volker.top.geek.nz/  Please do not CC list postings to me.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Walter Parker]

On Thu, Oct 13, 2016 at 2:40 PM, Volker Kuhlmann 
wrote:

> On Wed 27 Jul 2016 13:40:16 NZST +1200, Chris Buechler wrote:
>
> > > I find this really really annoying of pfsense! Especially for headless
> > > systems. Hey, why run with only one interface and some functionality
> > > missing when one can run with functionality of zero point zero instead?
> >
> > Because any fall back there is potentially unsafe. Say you have
> > igb0-igb5, and igb2 dies. Now your igb3 is igb2, igb4 is igb3, etc.
> > Any assumptions you make about what's correct are potentially
> > dangerous, and likely to be wrong. We've had discussions around that
> > in greater depth multiple times over the years. Any way you do it has
> > edge case bugs, is dangerous and/or wouldn't be right anyway.
>
> So the root cause of the problem is not to be able to bind pfsense
> interfaces to ports (whether this is the OS's fault or not is not
> something a user cares about).
>
> In my case the USB interface runs the wifi. I can do without that
> easily. But not getting access to pfsense on the LAN port on a headless
> APU-4 because the USB dongle is unplugged, dead, or whatever and
> therefore my wifi may be offline sure does look braindead to me. Sorry.
>
> Volker
>
> --
> Volker Kuhlmann is list0570 with the domain in header.
> http://volker.top.geek.nz/  Please do not CC list postings to me.
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>

Problem is that all of the current OS do this sort of renumbering (I'd have
to check, but I think it could be a hardware/driver issue). IIRC Linux
systems have had this sort of problem in even greater measure than the
BSDs. The plug and play nature of USB has caused issues for most systems
(drive letter changes on Windows, device name changes on Linux, even BSD
has started doing this). The brain dead here is problem that extends to the
PC industry as a whole. PFSense is subject bad decisions that were made
decades ago by other companies without enough vision. The automapping ideas
in hardware were not properly thought out and software didn't think it
though either.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Volker Kuhlmann]

On Wed 27 Jul 2016 13:40:16 NZST +1200, Chris Buechler wrote:

> > I find this really really annoying of pfsense! Especially for headless
> > systems. Hey, why run with only one interface and some functionality
> > missing when one can run with functionality of zero point zero instead?
> 
> Because any fall back there is potentially unsafe. Say you have
> igb0-igb5, and igb2 dies. Now your igb3 is igb2, igb4 is igb3, etc.
> Any assumptions you make about what's correct are potentially
> dangerous, and likely to be wrong. We've had discussions around that
> in greater depth multiple times over the years. Any way you do it has
> edge case bugs, is dangerous and/or wouldn't be right anyway.

So the root cause of the problem is not to be able to bind pfsense
interfaces to ports (whether this is the OS's fault or not is not
something a user cares about).

In my case the USB interface runs the wifi. I can do without that
easily. But not getting access to pfsense on the LAN port on a headless
APU-4 because the USB dongle is unplugged, dead, or whatever and
therefore my wifi may be offline sure does look braindead to me. Sorry.

Volker

-- 
Volker Kuhlmann is list0570 with the domain in header.
http://volker.top.geek.nz/  Please do not CC list postings to me.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Karl Fife]

On 7/26/2016 8:40 PM, Chris Buechler wrote:

On Tue, Jul 26, 2016 at 7:43 PM, Volker Kuhlmann  wrote:

On Tue 26 Jul 2016 09:41:37 NZST +1200, Karl Fife wrote:


Interesting how it failed: The fried port 'simply' broke
connectivity for the interface's LAN segment.  Everything else
continued to work.  I kinda didn't believe the report that Internet
was out for the one LAN, since the other was not.

I don't think this is that unusual or surprising. You get the same
effect if you plug in a real POTS line into an Ethernet port...


  After some
testing, I found the system would not come up after reboot because
it had gone into port reassignment mode since the config made
reference to a non-existent interface.

I find this really really annoying of pfsense! Especially for headless
systems. Hey, why run with only one interface and some functionality
missing when one can run with functionality of zero point zero instead?


Because any fall back there is potentially unsafe. Say you have
igb0-igb5, and igb2 dies. Now your igb3 is igb2, igb4 is igb3, etc.
Any assumptions you make about what's correct are potentially
dangerous, and likely to be wrong. We've had discussions around that
in greater depth multiple times over the years. Any way you do it has
edge case bugs, is dangerous and/or wouldn't be right anyway.



Amen to that.   Please don't change port behavior "automagically". This 
appears to be a phenomenon now.  I'm often seeing examples of ridiculous 
"fail safe" hardware features (e.g. binding IPMI to eth0 on IPMI link 
failure, or bridging interfaces on OS failure). Chok-full-o externalized 
security risks.   Certain "visionaries" needs to be taken out and beaten.


Thanks to Moshe, Jim and others for the links and musings!!   I now 
suspect that the isolation amplifier likely induced current on the 
Ethernet controller side of the circuit, meaning that the board may need 
a dual-chipectomy.


Either way, my thinking is that the low cost of fiber fiber and 
transceivers may be cheap insurance in the fugure if for example there's 
potential for different safety-ground reference points in the AC 
wiring.  In my case, I was on different panels within the same 
structure.  Technically they have the same safety-ground reference, but 
in the event of an AC power anomaly/event, anything can happen (e.g. as 
a the safety ground path begins to carry current).


I do think that if switching gear on BOTH ends of my Ethernet run *had 
been* bonded to a common "Earth-ground" reference (vs the electrical 
safety ground, as recommended by manufacturers), I suspect it may have 
significantly reduced the probability of damage as the anomaly would 
have been partly sunk through the earth-ground lug on the back of the 
equipemnt, reducing the potential for errant current being induced 
through the isolation transformer.  As it was only one side was bonded 
to a dedicated earth-ground, possibly increasing the chance of trouble 
versus the chances if neither side had been earth-grounded at all.



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Jim Thompson]

On Tue, Jul 26, 2016 at 7:43 PM, Volker Kuhlmann 
wrote:

> On Tue 26 Jul 2016 09:41:37 NZST +1200, Karl Fife wrote:
>
> >  After some
> > testing, I found the system would not come up after reboot because
> > it had gone into port reassignment mode since the config made
> > reference to a non-existent interface.
>
> I find this really really annoying of pfsense! Especially for headless
> systems. Hey, why run with only one interface and some functionality
> missing when one can run with functionality of zero point zero instead?
>
>
Certainly, let's just go ahead and run if you inserted or deleted a NIC.
Won't change anything, let's just
run with the new enumeration.

Afterall, what could happen?   rules for some internal NIC get dropped on
WAN?  Sure thing.

(NOT!)

Sometimes security != convenience.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Chris Buechler]

On Tue, Jul 26, 2016 at 7:43 PM, Volker Kuhlmann  wrote:
> On Tue 26 Jul 2016 09:41:37 NZST +1200, Karl Fife wrote:
>
>> Interesting how it failed: The fried port 'simply' broke
>> connectivity for the interface's LAN segment.  Everything else
>> continued to work.  I kinda didn't believe the report that Internet
>> was out for the one LAN, since the other was not.
>
> I don't think this is that unusual or surprising. You get the same
> effect if you plug in a real POTS line into an Ethernet port...
>
>>  After some
>> testing, I found the system would not come up after reboot because
>> it had gone into port reassignment mode since the config made
>> reference to a non-existent interface.
>
> I find this really really annoying of pfsense! Especially for headless
> systems. Hey, why run with only one interface and some functionality
> missing when one can run with functionality of zero point zero instead?
>

Because any fall back there is potentially unsafe. Say you have
igb0-igb5, and igb2 dies. Now your igb3 is igb2, igb4 is igb3, etc.
Any assumptions you make about what's correct are potentially
dangerous, and likely to be wrong. We've had discussions around that
in greater depth multiple times over the years. Any way you do it has
edge case bugs, is dangerous and/or wouldn't be right anyway.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Volker Kuhlmann]

On Tue 26 Jul 2016 09:41:37 NZST +1200, Karl Fife wrote:

> Interesting how it failed: The fried port 'simply' broke
> connectivity for the interface's LAN segment.  Everything else
> continued to work.  I kinda didn't believe the report that Internet
> was out for the one LAN, since the other was not.

I don't think this is that unusual or surprising. You get the same
effect if you plug in a real POTS line into an Ethernet port...

>  After some
> testing, I found the system would not come up after reboot because
> it had gone into port reassignment mode since the config made
> reference to a non-existent interface.

I find this really really annoying of pfsense! Especially for headless
systems. Hey, why run with only one interface and some functionality
missing when one can run with functionality of zero point zero instead?

> Can anyone tell me what's component is typically fried in this
> scenario?  Is it the NIC controller chip itself? I'm guessing it's
> not, rather I'm guessing it's just the big, blocky Ethernet
> Isolation transformer/amplifier that's been fried.

It is a safe bet that the Ethernet transformer (the "magnetics" part) is
fried. A fried transformer does not mean the Ethernet chip is OK; it is
possible to get the chip's I/O lines act as fuses (now blown) without
affecting adjacent I/O lines for other ports. It all depends on the
how much energy went in. Obviously it wasn't as much as to blow the
chip's top off, as in one of the slide photos!

It is actually hard to desolder multi-pin throughole components. You can
attempt to cut surface mount pins one by one with a scalpel etc. Ensure
not to put mechanical strain on any other component!! Ideally, not on
the dead component either to reduce the risk of damaging PCB tracks.
Once the dead bit falls off, unsolder the pin remainders one by one.
Then solder a new component on with a steady hand. Remove any solder
bridges you manage to create before powering up... Spare transformers
are probably cheap, but you have to get an equivalent (functionality,
pin location) one.

After that, assuming you made no mistake, you may still have to replace
the Ethernet chip too. Dunno re ease of purchase and price.

The jack itself has no components that can blow, except for the LEDs.
They're not essential for functionality, worst case you disconnect them
if they have shorted.

You attempt all of this only after you have declared the unit a write
off, especially if you haven't done it before. You then have a unique
learning opportunity.

At all times you must ensure an electrostatic free environment and
observe all ESD protection rules, or you risk (invisibly!) destroying
other chips, or worse, damaging them so they go out of spec but at first
sight still "work".

Outsourcing is a possibility, but it may only be enconomic if the
Ethernet chip is OK.

HTH,

Volker

-- 
Volker Kuhlmann is list0570 with the domain in header.
http://volker.top.geek.nz/  Please do not CC list postings to me.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[WebDawg]

On Mon, Jul 25, 2016 at 9:10 PM, Moshe Katz  wrote:

> From the picture, those are definitely surface-mount. I don't think I'd
> recommend trying it yourself unless you have experience and comfort working
> with SMD components.
>
> That said, if you do have the experience, it looks like the parts don't
> cost more than a few dollars.
>
> Moshe
>
>
You could outsource the repair.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Moshe Katz]

>From the picture, those are definitely surface-mount. I don't think I'd
recommend trying it yourself unless you have experience and comfort working
with SMD components.

That said, if you do have the experience, it looks like the parts don't
cost more than a few dollars.

Moshe

On Jul 25, 2016 7:06 PM, "Jim Thompson"  wrote:

> Pic of 7541, see for yourself.
>
> http://imgur.com/5RiHxOz
>
> On Mon, Jul 25, 2016 at 5:57 PM, Moshe Katz  wrote:
>
> > Since you described that the board has isolation transformers, I would
> > assume that they followed the spec and put in network jacks with
> magnetics
> > <
> >
> http://electronics.stackexchange.com/questions/27756/why-are-ethernet-rj45-sockets-magnetically-coupled
> > >
> > instead of direct connections.
> > As I understand it, there are two types of magnetics - those built into
> the
> > jack (as seen in this Raspberry Pi blog post
> >  with X-Ray
> > images), and those which use a separate chip or transformer.
> >
> > I believe you are correct that the only way to get it working would be to
> > desolder the fried transformer and replace it with a new one.
> >
> > Depending on your soldering skills and comfort level, you could likely
> > replace the fried part with a new one.
> >
> > Unfortunately, the only people I know who have done this successfully
> have
> > been working with the type that has integrated isolation components (like
> > the RasPi), not the type that has separate ones. Assuming the chips are
> > through-hole (like most jacks are), it should be exactly the same
> > difficulty as replacing the jack itself. Otherwise, you might have a hard
> > time. It's hard to know for sure without looking at the board directly.
> >
> > Moshe
> >
> > --
> > Moshe Katz
> > -- mo...@ymkatz.net
> > -- +1(301)867-3732
> >
> > On Mon, Jul 25, 2016 at 5:41 PM, Karl Fife  wrote:
> >
> > > The 6th Ethernet port (em5) on my Lanner fw-7541D died Saturday night
> > > during the electrical storm.  Just the one port.
> > >
> > > Apparently fried, apparently by an electrical anomaly.
> > >
> > > Now, the link light is always on (dimly lit), whether populated or not,
> > > and neither the POST, nor the OS detects the presence of the fifth
> port.
> > >
> > > Interesting how it failed: The fried port 'simply' broke connectivity
> for
> > > the interface's LAN segment.  Everything else continued to work.  I
> kinda
> > > didn't believe the report that Internet was out for the one LAN, since
> > the
> > > other was not.  After some testing, I found the system would not come
> up
> > > after reboot because it had gone into port reassignment mode since the
> > > config made reference to a non-existent interface.
> > >
> > > I edited the config in VI to de-reference the interface, and All's
> well.
> > >
> > > I really like this Lanner hardware, and would like to keep it in
> service.
> > > Ideally I'd like to fix the (now dead) spare port so that I still have
> a
> > > spare.
> > >
> > > Can anyone tell me what's component is typically fried in this
> scenario?
> > > Is it the NIC controller chip itself? I'm guessing it's not, rather I'm
> > > guessing it's just the big, blocky Ethernet Isolation
> > transformer/amplifier
> > > that's been fried.  I'm also guessing that the reason the system is
> still
> > > functional (at all) is because the little dude did its job.  I know
> it's
> > a
> > > long shot, but I'd like to hear if anyone has ever repaired a fried
> > > Ethernet port on a motherboard.
> > >
> > > Also ironic, everything's very well grounded with a dedicated
> > earth-ground
> > > via #6 AWG except the one (damned) switch that services that one
> (damned)
> > > LAN. I imagine if I'd gone to the trouble of running a dedicated ground
> > to
> > > that switch, it may not have sunk the spike.  Any experience or war
> > stories
> > > in this arena appreciated as well.  Memo to myself: Run fiber to
> switches
> > > on different power/earth.
> > >
> > > -Karl
> > > ___
> > > pfSense mailing list
> > > https://lists.pfsense.org/mailman/listinfo/list
> > > Support the project with Gold! https://pfsense.org/gold
> > >
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> > Support the project with Gold! https://pfsense.org/gold
> >
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Jim Thompson]

Pic of 7541, see for yourself.

http://imgur.com/5RiHxOz

On Mon, Jul 25, 2016 at 5:57 PM, Moshe Katz  wrote:

> Since you described that the board has isolation transformers, I would
> assume that they followed the spec and put in network jacks with magnetics
> <
> http://electronics.stackexchange.com/questions/27756/why-are-ethernet-rj45-sockets-magnetically-coupled
> >
> instead of direct connections.
> As I understand it, there are two types of magnetics - those built into the
> jack (as seen in this Raspberry Pi blog post
>  with X-Ray
> images), and those which use a separate chip or transformer.
>
> I believe you are correct that the only way to get it working would be to
> desolder the fried transformer and replace it with a new one.
>
> Depending on your soldering skills and comfort level, you could likely
> replace the fried part with a new one.
>
> Unfortunately, the only people I know who have done this successfully have
> been working with the type that has integrated isolation components (like
> the RasPi), not the type that has separate ones. Assuming the chips are
> through-hole (like most jacks are), it should be exactly the same
> difficulty as replacing the jack itself. Otherwise, you might have a hard
> time. It's hard to know for sure without looking at the board directly.
>
> Moshe
>
> --
> Moshe Katz
> -- mo...@ymkatz.net
> -- +1(301)867-3732
>
> On Mon, Jul 25, 2016 at 5:41 PM, Karl Fife  wrote:
>
> > The 6th Ethernet port (em5) on my Lanner fw-7541D died Saturday night
> > during the electrical storm.  Just the one port.
> >
> > Apparently fried, apparently by an electrical anomaly.
> >
> > Now, the link light is always on (dimly lit), whether populated or not,
> > and neither the POST, nor the OS detects the presence of the fifth port.
> >
> > Interesting how it failed: The fried port 'simply' broke connectivity for
> > the interface's LAN segment.  Everything else continued to work.  I kinda
> > didn't believe the report that Internet was out for the one LAN, since
> the
> > other was not.  After some testing, I found the system would not come up
> > after reboot because it had gone into port reassignment mode since the
> > config made reference to a non-existent interface.
> >
> > I edited the config in VI to de-reference the interface, and All's well.
> >
> > I really like this Lanner hardware, and would like to keep it in service.
> > Ideally I'd like to fix the (now dead) spare port so that I still have a
> > spare.
> >
> > Can anyone tell me what's component is typically fried in this scenario?
> > Is it the NIC controller chip itself? I'm guessing it's not, rather I'm
> > guessing it's just the big, blocky Ethernet Isolation
> transformer/amplifier
> > that's been fried.  I'm also guessing that the reason the system is still
> > functional (at all) is because the little dude did its job.  I know it's
> a
> > long shot, but I'd like to hear if anyone has ever repaired a fried
> > Ethernet port on a motherboard.
> >
> > Also ironic, everything's very well grounded with a dedicated
> earth-ground
> > via #6 AWG except the one (damned) switch that services that one (damned)
> > LAN. I imagine if I'd gone to the trouble of running a dedicated ground
> to
> > that switch, it may not have sunk the spike.  Any experience or war
> stories
> > in this arena appreciated as well.  Memo to myself: Run fiber to switches
> > on different power/earth.
> >
> > -Karl
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> > Support the project with Gold! https://pfsense.org/gold
> >
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Jim Thompson]

"Lightning surge damage to Ethernet and POTS ports connected to
inside wiring"
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D6842005

A summary of the paper:
http://incompliancemag.com/article/lightning-surge-damage-to-ethernet-and-pots-ports-connected-to-inside-wiring/

a slide deck on the same subject, by the same author:
http://www.atis.org/peg/docs/2015/LightningSurgeDamage_JRandolph.pdf

In which:

> Interestingly, some generic replacement power supplies purchased on the
Internet showed breakdown levels as low as 3 kV. Internal inspection
revealed that the isolation barriers in these supplies were not compliant
with [10]. These non-compliant supplies had no safety markings from
independent labs, although they did have the CE marking for manufacturer’s
self-declaration in Europe.

Which is to say cheap far-eastern wall warts are not compliant, though
claiming to be.

> At present there is no evidence of non-compliant power supplies being
used by name brand manufacturers of routers and cordless phones.

"Well, obviously it's not meant to be taken literally; it refers to
any manufacturers
of dairy products." [1]

But here's the important bottom line:

> The key point here is that a high current, fast rise time surge on the AC
mains can interact with the inductance of the ground wire to create a high
voltage common mode surge on every cable that is connected to the surge
protector. In some sense, the surge protector takes a surge on the AC mains
and “broadcasts” it onto every cable that is connected to the surge
protector. This happens despite the fact the surge protector has been
installed correctly and the ground wire of the AC mains outlet is connected
properly.

In other words, your ground wire won't help you.   Check the slide deck
(and paper), it can be that the ground potential has risen.

I'll add that inductive coupling is a function of the rate of change rather
than the peak current.  So when di/dt is a small fraction of infinity, it
doesn't really matter much that your inductor coil is a stretch of wire
five meters away ... it's going to get a big spike of current and the teeny
tiny little transistors in your equipment are going to arc over.  A small
puff of smoke will appear.  If you're unlucky, a fire will shortly (narf)
follow.

Surge protectors have several practical failures:

1 - they are rated for a certain amount of energy, and a big strike
overwhelms that, so you're done.

2 - they are rated for that amount of energy over their service lifetime,
which means that come the big storm your five-year-old surge protector has
actually sacrificed itself to a thousand little surges that you never
noticed over the time it's been in service.

3 - they have a response curve that makes them more suitable for lower
di/dt or dv/dt spikes ... this makes them a good protection for spikes that
originate far away and get their sharp edges worn off as they travel across
the network, not so much for close hits.

For extra credit:

Who did some of the important early research on lightning effects?  Why, Mr
Steinmetz, of course.
https://en.wikipedia.org/wiki/Charles_Proteus_Steinmetz


tl;dr: your multiport surge protectors are a prime suspect.

Jim

[1] https://en.wikiquote.org/wiki/Monty_Python%27s_Life_of_Brian


On Mon, Jul 25, 2016 at 4:41 PM, Karl Fife  wrote:

> The 6th Ethernet port (em5) on my Lanner fw-7541D died Saturday night
> during the electrical storm.  Just the one port.
>
> Apparently fried, apparently by an electrical anomaly.
>
> Now, the link light is always on (dimly lit), whether populated or not,
> and neither the POST, nor the OS detects the presence of the fifth port.
>
> Interesting how it failed: The fried port 'simply' broke connectivity for
> the interface's LAN segment.  Everything else continued to work.  I kinda
> didn't believe the report that Internet was out for the one LAN, since the
> other was not.  After some testing, I found the system would not come up
> after reboot because it had gone into port reassignment mode since the
> config made reference to a non-existent interface.
>
> I edited the config in VI to de-reference the interface, and All's well.
>
> I really like this Lanner hardware, and would like to keep it in service.
> Ideally I'd like to fix the (now dead) spare port so that I still have a
> spare.
>
> Can anyone tell me what's component is typically fried in this scenario?
> Is it the NIC controller chip itself? I'm guessing it's not, rather I'm
> guessing it's just the big, blocky Ethernet Isolation transformer/amplifier
> that's been fried.  I'm also guessing that the reason the system is still
> functional (at all) is because the little dude did its job.  I know it's a
> long shot, but I'd like to hear if anyone has ever repaired a fried
> Ethernet port on a motherboard.
>
> Also ironic, everything's very well grounded with a dedicated earth-ground
> via #6 AWG except the one (damned) switch that services that one (damned)
> LAN. I imag

Re: [pfSense] Lightning strike

[Moshe Katz]

Since you described that the board has isolation transformers, I would
assume that they followed the spec and put in network jacks with magnetics

instead of direct connections.
As I understand it, there are two types of magnetics - those built into the
jack (as seen in this Raspberry Pi blog post
 with X-Ray
images), and those which use a separate chip or transformer.

I believe you are correct that the only way to get it working would be to
desolder the fried transformer and replace it with a new one.

Depending on your soldering skills and comfort level, you could likely
replace the fried part with a new one.

Unfortunately, the only people I know who have done this successfully have
been working with the type that has integrated isolation components (like
the RasPi), not the type that has separate ones. Assuming the chips are
through-hole (like most jacks are), it should be exactly the same
difficulty as replacing the jack itself. Otherwise, you might have a hard
time. It's hard to know for sure without looking at the board directly.

Moshe

--
Moshe Katz
-- mo...@ymkatz.net
-- +1(301)867-3732

On Mon, Jul 25, 2016 at 5:41 PM, Karl Fife  wrote:

> The 6th Ethernet port (em5) on my Lanner fw-7541D died Saturday night
> during the electrical storm.  Just the one port.
>
> Apparently fried, apparently by an electrical anomaly.
>
> Now, the link light is always on (dimly lit), whether populated or not,
> and neither the POST, nor the OS detects the presence of the fifth port.
>
> Interesting how it failed: The fried port 'simply' broke connectivity for
> the interface's LAN segment.  Everything else continued to work.  I kinda
> didn't believe the report that Internet was out for the one LAN, since the
> other was not.  After some testing, I found the system would not come up
> after reboot because it had gone into port reassignment mode since the
> config made reference to a non-existent interface.
>
> I edited the config in VI to de-reference the interface, and All's well.
>
> I really like this Lanner hardware, and would like to keep it in service.
> Ideally I'd like to fix the (now dead) spare port so that I still have a
> spare.
>
> Can anyone tell me what's component is typically fried in this scenario?
> Is it the NIC controller chip itself? I'm guessing it's not, rather I'm
> guessing it's just the big, blocky Ethernet Isolation transformer/amplifier
> that's been fried.  I'm also guessing that the reason the system is still
> functional (at all) is because the little dude did its job.  I know it's a
> long shot, but I'd like to hear if anyone has ever repaired a fried
> Ethernet port on a motherboard.
>
> Also ironic, everything's very well grounded with a dedicated earth-ground
> via #6 AWG except the one (damned) switch that services that one (damned)
> LAN. I imagine if I'd gone to the trouble of running a dedicated ground to
> that switch, it may not have sunk the spike.  Any experience or war stories
> in this arena appreciated as well.  Memo to myself: Run fiber to switches
> on different power/earth.
>
> -Karl
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Lightning strike

[Karl Fife]

The 6th Ethernet port (em5) on my Lanner fw-7541D died Saturday night 
during the electrical storm.  Just the one port.


Apparently fried, apparently by an electrical anomaly.

Now, the link light is always on (dimly lit), whether populated or not, 
and neither the POST, nor the OS detects the presence of the fifth port.


Interesting how it failed: The fried port 'simply' broke connectivity 
for the interface's LAN segment.  Everything else continued to work.  I 
kinda didn't believe the report that Internet was out for the one LAN, 
since the other was not.  After some testing, I found the system would 
not come up after reboot because it had gone into port reassignment mode 
since the config made reference to a non-existent interface.


I edited the config in VI to de-reference the interface, and All's well.

I really like this Lanner hardware, and would like to keep it in 
service.  Ideally I'd like to fix the (now dead) spare port so that I 
still have a spare.


Can anyone tell me what's component is typically fried in this scenario? 
 Is it the NIC controller chip itself? I'm guessing it's not, rather 
I'm guessing it's just the big, blocky Ethernet Isolation 
transformer/amplifier that's been fried.  I'm also guessing that the 
reason the system is still functional (at all) is because the little 
dude did its job.  I know it's a long shot, but I'd like to hear if 
anyone has ever repaired a fried Ethernet port on a motherboard.


Also ironic, everything's very well grounded with a dedicated 
earth-ground via #6 AWG except the one (damned) switch that services 
that one (damned) LAN. I imagine if I'd gone to the trouble of running a 
dedicated ground to that switch, it may not have sunk the spike.  Any 
experience or war stories in this arena appreciated as well.  Memo to 
myself: Run fiber to switches on different power/earth.


-Karl
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold