# How kernel detect & names Ethernet interfaces.



## bsaidus (Dec 23, 2016)

Hello !
Suppose that I have a Box with 4 Ethernet interfaces from Intel (for example).
In normal case when FreeBSD boots, the kernel will detect and names interfaces like :
em0, em1, em2, em3.
Now suppose that I have problems with the 3rd one's ( em2 do not work for any raison).
How the kernel detection will be, and how it names them ??
How FreeBSD applies ( consist ) with a defected hardware ?? do he detect it or not ?

Thanks


----------



## SirDice (Dec 23, 2016)

If you would remove em2, em3 will become em2. Interfaces are named in the order they are detected.

How it'll handle defective hardware will depend on the type of defect. If the card isn't detected then it obviously won't be added. But if the PCI bridge part of the card still works but the electronics on the "cable-end" is defective it will detect the card but you'll get errors (or no errors but no connection either) if you try to use it.


----------



## bsaidus (Dec 23, 2016)

SirDice said:


> If you would remove em2, em3 will become em2. Interfaces are named in the order they are detected.
> 
> How it'll handle defective hardware will depend on the type of defect. If the card isn't detected then it obviously won't be added. But if the PCI bridge part of the card still works but the electronics on the "cable-end" is defective it will detect the card but you'll get errors (or no errors but no connection either) if you try to use it.


Thanks SirDice, I'm waiting answers from your parts .


----------



## Phishfry (Dec 23, 2016)

If this is a commodity firewall like a Sophos or Astaro than what you may be dealing with is ethernet bypass.. If so I would look at the bios real hard as there are sometimes bypass settings in there. Some machines use a jumper to disable bypass and some have the spot for a jumper but only traces on the motherboard but you can short them.


----------



## bsaidus (Dec 23, 2016)

Phishfry said:


> If this is a commodity firewall like a Sophos or Astaro than what you may be dealing with is ethernet bypass.. If so I would look at the bios real hard as there are sometimes bypass settings in there. Some machines use a jumper to disable bypass and some have the spot for a jumper but only traces on the motherboard but you can short them.



Actually, I'm trying to build a FreeBSD customized System for Firewalling & saving all configs in an XML database, so I'm asking some question to know how to deal if problems occures.
Thank you for all your help.


----------



## Phishfry (Dec 23, 2016)

Sorry I may have read your question wrongly. You are building a custom software firewall distro and you want to handle bad ethernet ports gracefully. Is that right?


----------



## bsaidus (Dec 24, 2016)

Phishfry said:


> Sorry I may have read your question wrongly. You are building a custom software firewall distro and you want to handle bad ethernet ports gracefully. Is that right?


Yes!
 Think, in my point of view that if for each booting, I should do some controls, if I find something wrong then I halt the process of booting and force the Admin of Firewall to reconfigure correctelly interfaces.


----------



## Phishfry (Dec 24, 2016)

I think looking at pfSense/OPN/monowall is a good idea. They use a setup where you have to declare your interfaces as WAN, LAN and OPT ect...So interface setup would use more than simple hardware recognition. There is also a smallish router distro which is worth looking at for clues.
https://bsdrp.net/

I don't think there any software procedures for handling bad ethernet ports short of a redundant interface/lagg arrangement.


----------



## Phishfry (Dec 24, 2016)

This looks like a simple script driven method
http://serverfault.com/questions/747281/freebsd-interface-up-down-monitoring

Some more usable info
https://sto.blog.remote-admins.com/...execute-script-on-carp-interface-link-change/


----------



## Phishfry (Dec 24, 2016)

That method would only work where the link layer is present. Where you have activity lights on the port but no communications.

For a truly dead port I dunno what you would do. Maybe a lookup table of know ports with MAC's and if on-boot is absent send up error.


----------



## gkontos (Dec 24, 2016)

bsaidus said:


> Yes!
> Think, in my point of view that if for each booting, I should do some controls, if I find something wrong then I halt the process of booting and force the Admin of Firewall to reconfigure correctelly interfaces.


A firewall usually should not need a reboot unless there is a critical update that affects the KERNEL. That said, you could use some sort of XML backup/restore options that could also contain the MAC address of each NIC. So, when the system boots, it should expect to find the correct MAC, otherwise it could worn the admin.


----------

