Re: [pfSense] Lightning strike

2016-10-16 Thread 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

Re: [pfSense] Lightning strike

2016-10-14 Thread 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 manu

Re: [pfSense] Lightning strike

2016-10-14 Thread 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

Re: [pfSense] Lightning strike

2016-10-13 Thread 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 M

Re: [pfSense] Lightning strike

2016-10-13 Thread 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/

Re: [pfSense] Lightning strike

2016-10-13 Thread 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 p

Re: [pfSense] Lightning strike

2016-10-13 Thread 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

Re: [pfSense] Lightning strike

2016-10-13 Thread 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

Re: [pfSense] Lightning strike

2016-07-29 Thread 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 wor

Re: [pfSense] Lightning strike

2016-07-27 Thread 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-exis

Re: [pfSense] Lightning strike

2016-07-26 Thread 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 repor

Re: [pfSense] Lightning strike

2016-07-26 Thread 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

Re: [pfSense] Lightning strike

2016-07-26 Thread 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 d

Re: [pfSense] Lightning strike

2016-07-25 Thread 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:

Re: [pfSense] Lightning strike

2016-07-25 Thread 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

Re: [pfSense] Lightning strike

2016-07-25 Thread 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

Re: [pfSense] Lightning strike

2016-07-25 Thread 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

[pfSense] Lightning strike

2016-07-25 Thread 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 pre