ich weiß nicht ob es die richtige section ist. alles funzt wie es sollte, bin jedoch neugierig wieso mir netstats etc. anzeigt das ich beim empfangen packetverlust habe. netapp z.b. meldet das auch im monitoring. nach längerem googlen bin ich nun auf ne mauer gestoßen und komm mit meinem laien-wissen einfach nicht weiter. ich weiß nicht obs am realtek netzwerkchip liegen könnte oder ob was bei mir im netzwerk schabernack treibt. hab das problem auf zwei rechnern und hab bisher noch nicht mich an andere rechner rangesetzt. das komisches es taucht auch auf, wenn kein kabel dran ist und der chip per bios deaktiviert worden ist. deswegen bin ich verwirrt. einmal bei meinem debian nas und einmal auf meinem desktop.
aufn nas läuft nen backports kernel. beide haben nen rtl8125 chip. wäre der korrekte weg nun, im bios die netzwerkkarte zu deaktivieren und eine frische neuinstallation zu machen? bzw. mal mit einem livesystem zu begutachten?
Code: Alles auswählen
uname -a
Linux debian-home 6.10.11+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.11-1~bpo12+1 (2024-10-03) x86_64 GNU/Linux
Code: Alles auswählen
sudo netstat -i
Kernel-Schnittstellentabelle
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
arr-net 1500 5789089 0 0 0 7051794 0 0 0 BMRU
br-0dccc8f8540c 1500 0 0 0 0 0 0 0 0 BMU
br-5bee625f2e76 1500 6038450 0 0 0 6131346 0 0 0 BMRU
docker0 1500 7394 0 0 0 8037 0 0 0 BMRU
enp4s0 1500 18485804 0 247389 0 16177686 0 0 0 BMRU
lo 65536 50365 0 0 0 50365 0 0 0 LRU
Code: Alles auswählen
Linux fedora.fritz.box 6.11.8-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Nov 14 20:37:39 UTC 2024 x86_64 GNU/LinuxCode: Alles auswählen
sudo netstat -i
Kernel Schnittstellentabelle
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0 1500 0 0 0 0 0 0 9 0 BMU
enp6s0 1500 0 0 0 0 0 0 2 0 BMU
enp7s0 1500 2643080 0 7889 0 764668 0 2 0 BMRU
lo 65536 30644 0 0 0 30644 0 0 0 LRU
https://jvns.ca/blog/2017/09/05/finding ... g-dropped/
Code: Alles auswählen
swapper 0 [007] 76893.289576: skb:kfree_skb: skbaddr=0xffff9329531a7000 protocol=35041 location=__netif_receive_skb_core.constprop.0+0x140 reason: UNHANDLED_PROTO
ffffffff93fe894b kfree_skb_reason+0x8b ([kernel.kallsyms])
ffffffff93fe894b kfree_skb_reason+0x8b ([kernel.kallsyms])
ffffffff94008770 __netif_receive_skb_core.constprop.0+0x140 ([kernel.kallsyms])
ffffffff940096ca __netif_receive_skb_list_core+0x13a ([kernel.kallsyms])
ffffffff94009e6f netif_receive_skb_list_internal+0x20f ([kernel.kallsyms])
ffffffff9400a672 napi_complete_done+0x72 ([kernel.kallsyms])
ffffffffc057f752 rtl8169_poll+0x4a2 ([kernel.kallsyms])
ffffffff9400a7d8 __napi_poll+0x28 ([kernel.kallsyms])
ffffffff9400aefa net_rx_action+0x2ca ([kernel.kallsyms])
ffffffff936c8e80 handle_softirqs+0xd0 ([kernel.kallsyms])
ffffffff936c9111 __irq_exit_rcu+0x91 ([kernel.kallsyms])
ffffffff94267fd1 sysvec_apic_timer_interrupt+0x71 ([kernel.kallsyms])
ffffffff9440160a asm_sysvec_apic_timer_interrupt+0x1a ([kernel.kallsyms])
ffffffff94269c4c cpuidle_enter_state+0xcc ([kernel.kallsyms])
ffffffff93fadf6d cpuidle_enter+0x2d ([kernel.kallsyms])
ffffffff9372d307 do_idle+0x1e7 ([kernel.kallsyms])
ffffffff9372d569 cpu_startup_entry+0x29 ([kernel.kallsyms])
ffffffff93680b7c start_secondary+0x11c ([kernel.kallsyms])
ffffffff93639f8d common_startup_64+0x13e ([kernel.kallsyms])
kworker/u32:0-e 796455 [000] 76893.289661: skb:kfree_skb: skbaddr=0xffff9329531a1d00 protocol=35041 location=__netif_receive_skb_core.constprop.0+0x140 reason: UNHANDLED_PROTO
ffffffff93fe894b kfree_skb_reason+0x8b ([kernel.kallsyms])
ffffffff93fe894b kfree_skb_reason+0x8b ([kernel.kallsyms])
ffffffff94008770 __netif_receive_skb_core.constprop.0+0x140 ([kernel.kallsyms])
ffffffff9400989c __netif_receive_skb_one_core+0x3c ([kernel.kallsyms])
ffffffff94009ba7 process_backlog+0x87 ([kernel.kallsyms])
ffffffff9400a7d8 __napi_poll+0x28 ([kernel.kallsyms])
ffffffff9400aefa net_rx_action+0x2ca ([kernel.kallsyms])
ffffffff936c8e80 handle_softirqs+0xd0 ([kernel.kallsyms])
ffffffff936c8b9b do_softirq.part.0+0x3b ([kernel.kallsyms])
ffffffff936c91a4 __local_bh_enable_ip+0x64 ([kernel.kallsyms])
ffffffff9400358e netif_rx+0xde ([kernel.kallsyms])
ffffffffc1be28ed macvlan_broadcast+0xed ([kernel.kallsyms])
ffffffffc1be2aed macvlan_process_broadcast+0xed ([kernel.kallsyms])
ffffffff936e9459 process_one_work+0x179 ([kernel.kallsyms])
ffffffff936e9fe5 worker_thread+0x265 ([kernel.kallsyms])
ffffffff936f2eaf kthread+0xcf ([kernel.kallsyms])
ffffffff9364cb81 ret_from_fork+0x31 ([kernel.kallsyms])
ffffffff93604a6a ret_from_fork_asm+0x1a ([kernel.kallsyms])
zumindest hab ich es so verstanden und deswegen werden bestimmte packete verworfen. hab bald den drang die fehler zu beseiten. aber man kennt ja das sprichwort, die fehler lässt man drinne, weil der rest ja bisher funktioniert.mit tcpdump/wireshark weiter zu forschen ist ja sinnfrei(?) die packete werden ja vorher verworfen. oder gibts da ein switch um die daten roh, vor dem kernel zu bekomm?