(Solved) pfSense blocks static and DHCP ip requests from unraid when bridging is enabled
-
Using: dmesg | grep 'msk' (LAN)
mskc0: <Marvell Yukon 88E8055 Gigabit Ethernet> port 0xce00-0xceff mem 0xfdbfc000-0xfdbfffff irq 17 at device 0.0 on pci3 msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x02> on mskc0 msk0: Using defaults for TSO: 65518/35/2048 miibus1: <MII bus> on msk0 msk0: link state changed to DOWN msk0: link state changed to UP msk0: link state changed to DOWN msk0: link state changed to UP msk0: link state changed to DOWN msk0: link state changed to UPUsing: dmesg | grep 're0' (WAN)
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xde00-0xdeff mem 0xfdcff000-0xfdcfffff,0xfdcf8000-0xfdcfbfff irq 16 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00200000 miibus0: <MII bus> on re0 re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 80:1f:02:45:29:8f re0: netmap queues/slots: TX 1/256, RX 1/256 firewire0: <IEEE1394(FireWire) bus> on fwohci0 sbp0: <SBP-2/SCSI over FireWire> on firewire0 firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 re0: link state changed to DOWN re0: link state changed to UP -
Ok for the Realteck interface, is has a MAC :
@brandon3055 said in (Solved) pfSense blocks static and DHCP ip requests from unraid when bridging is enabled:re0: Ethernet address: 80:1f:02:45:29:8f
The msk0 interface : no.
I tend to say : check with "Marvell Yukon 88E8055 Gigabit Ethernet" support how you can set it's original MAC back.
-
@gertjan said in (Solved) pfSense blocks static and DHCP ip requests from unraid when bridging is enabled:
I tend to say : check with "Marvell Yukon 88E8055 Gigabit Ethernet" support how you can set it's original MAC back.
honestly i don't really care. Its working now and i have no problem with using a random generated mac for the LAN interface.
If this was caused by an issue with my specific nic then thats fine. The override fixes it so thats all that matters. I just initially assumed this was caused by pfsense. -
In my some 30 years in the biz, I can honestly say I do not recall ever seeing such a thing.. How could the nic not have a mac?
Does it get a mac if you boot some other os, so you use a different driver? Has to be some sort of issue with the driver? Or the thing is faulty out of the gate? I would be more concerned to be honest.. I wouldn't trust using it.. Until you figure out what exacty causes such a problem..
I have setup 10's of thousands of machines over the years - never seen such a thing.
Had you flashed the nics firmware at some point? What was on the machine before you installed pfsense on it?
It was working before with pfsense? What version of pfsense was that - the version of freebsd would of been different, etc.
Doing a google for all zeros mac and marvel does have quite a few hits... Not seeing any sort of rhyme or reason to what finding, most people just seem to get a new nic ;)
The only thing close is flashing a dd-wrt firmware on old router set the mac to same thing as everyone else using the firmware, and this would cause problems if someone else with your ISP had also flashed theirs and they got on first.. That took a bit to track down when saw.. Fix was to get the original mac back..
I wold have to say something wrong with the driver or the nic bad firmware flash or something in the factory... What you did by setting a mac is a work around.. But personally I would just get a different nic if you can not track down a reason to why mac went missing.
-
The nic is the built in nic on an old acer pc that looks like it originally came out of a school. I have been running the system with pfsense for about 3 years now and the nic has never caused any issues other than this one. This is only running my home network so nothing critical. It it does ever cause issues i will just throw in a different nic ore move it to a different system.
