Crash Report after runing traceroute
-
@stephenw10
From dmesg.boot below.The 2.5GbE is a Trendnet TEG-25GECTX - the other is the on-board.
pci1: <ACPI PCI bus> on pcib2 re0: <Realtek PCIe 2.5GbE Family Controller> port 0xe000-0xe0ff mem 0xf7d00000-0xf7d0ffff,0xf7d10000-0xf7d13fff at device 0.0 on pci1 re0: Using Memory Mapping! re0: Using 1 MSI-X message re0: ASPM disabled re0: version:1.98.00 re0: Ethernet address: 78:2d:7e:1e:a3:26 This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625. re0: Ethernet address: 78:2d:7e:1e:a3:26 pcib3: <ACPI PCI-PCI bridge> at device 28.3 on pci0 pci2: <ACPI PCI bus> on pcib3 re1: <Realtek PCIe GbE Family Controller> port 0xd000-0xd0ff mem 0xf7c00000-0xf7c00fff,0xf0000000-0xf0003fff at device 0.0 on pci2 re1: Using Memory Mapping! re1: Using 1 MSI-X message re1: ASPM disabled re1: version:1.98.00 re1: Ethernet address: b0:83:fe:ab:1a:90pciconf -lv below:
re0@pci0:2:0:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x10ec subdevice=0x0123 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8125 2.5GbE Controller' class = network subclass = ethernet re1@pci0:3:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x1028 subdevice=0x0612 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet -
@stephenw10
I forgot to mention that the behavior was the same from the GUI. Clicked on traceroute - same thing happened. Tried it from the console - identical behavior.
M -
Looks like it's re1 giving the issue. Is that assigned as WAN?
If you traceroute to something on the LAN using the other NIC does it fail?
If you trceroute using ICMP instead of UDP does it still panic?
I would normally suggest trying the alternative Realtek driver but it looks like you're already doing that to get the 8125 support I assume.
-
@stephenw10
Yes - I updated the driver before any of this happened.
I'll have to test this tomorrow or on the weekend while everything is closed. The system is now in production.
I will report back - as this is a bit odd. We suspected that it might be a loop on the LAN, given that it happened while in a test environment while connected to a couple of switches instead of directly to the WAN link - but that is just conjecture at this point.
I'll definitely post here once I can test. -
@stephenw10 said in Crash Report after runing traceroute:
Looks like it's re1 giving the issue. Is that assigned as WAN?
re1 is currently the LAN link - but it might have been WAN when this happened.
I'll test and report back. -
@stephenw10
WAN - traceroute -i re0 8.8.8.8 - crash on the first hop
LAN - traceroute -i re1 8.8.8.8 - crash on the first hoptraceroute -1 re0 192.168.1.11 - crash on the first hop
traceroute -1 re0 192.168.1.11 - went 6 hops without crashing - but discovered zero routes to a machine sitting on the LAN.traceroute to 192.168.1.11 (192.168.1.11), 64 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * *^Ctraceroute from GUI - crash - presumably on the first hop
The system is now inline and in production with basic WAN/LAN ip assignments.
M -
Hi
what kind of driver are you using?
The site says only about support for Windowshttps://www.trendnet.com/support/TEG-25GECTX
-
@Konstanti
I'm using the updated drivers described here.
The rest of the system seems stable - VLANS working, etc... -
The re driver supports RealTek RTL8139C+, RTL8169, RTL816xS, RTL811xS, RTL8168,RTL810xE and RTL8111 based Fast Ethernet and Gigabit Ethernet adapters
Your adapter is not on this list (I suspect the problem is with the device driver)
device = 'RTL8125 2.5GbE Controller'
-
@Konstanti
The behavior is the same with both NICS - which of course happen to both be Realtek.
Live and learn I guess.
If I end up building another box - I'll keep an eye out for it in the future.
M -
The in kernel re driver doesn't support rtl8125 but the alternative kmod driver does.
@studeoQ said in Crash Report after runing traceroute:
traceroute -1 re0 192.168.1.11 - crash on the first hop
traceroute -1 re0 192.168.1.11 - went 6 hops without crashing - but discovered zero routes to a machine sitting on the LAN.I assume one of those is a typo? And I expect the second test there should show re1 because testing to the LAN from the LAN IP removes re0 from the route. That would confirm it's actually the re0 driver causing a problem. In which case you could try going back to the in-kernel driver but that will stop the 2.5G NIC working.
-
@stephenw10
Yes - a typo - and I couldn't edit - too much time had passed.
Right now - the "fix" is - don't run traceroute...
Everything else is working as expected - so tempted to leave it alone for now. -
@studeoQ said in Crash Report after runing traceroute:
Everything else is working as expected - so tempted to leave it alone for now.
Your initial plan was the best, as 're' will come back to bite you :
@studeoQ said in Crash Report after runing traceroute:
If I end up building another box
No need to rebuild, go visit the BIOS and do what all 're' merits : disable them.
Then slide in a dual (quad ?) intel NIC, and you'll be good. -
Here, perhaps, I agree.
It is unknown from which source code this driver is built and for which version of Freebsd. If there are already problems that lead to a system failure , then it is better to abandon this idea. With Intel network cards, everything has been functioning for years without problems -
@Konstanti
It's a limitation of the box I built - SFF PC with no real ability to add very many options (single PCIe 1X slot) so - finding the right NIC might be the next and only option. If not - then a new box will be in order. I was pretty impatient when it came to building the first one. I'll be more careful in the future. -
Do you see any issues if you run a traceroute from a client behind pfSense through it?
-
@stephenw10
Other than being a little slower than i think is normal - no - there aren't any obvious issues.
It can be run from nodes residing behind it.
I seriously doubt I would be running it on the device for any reason other than testing.
I just thought a system-wide failure was a little odd.If anyone knows of a PCIe X1 dual NIC that might fit the bill - I'm all ears.
Speed tests are normal and I'm getting the expected symmetrical speeds - so it can't be "that broken".
But - I'm not a big fan of loose ends and known broken stuff just lingering around - so - I'd feel better knowing it wasn't an issue. -
@stephenw10
I took another look - and I have an available X16 slot - PCIe 2 - so that opens things up a bit as far as selection. -
So - I added an Intel Pro 1000 - 4 port 1G NIC - and all is well.
Realtek disabled in the bios.
Life is good.
Lesson learned.
All functions normal...Thanks to all who helped.
