October 8, 2025Oct 8 Community Expert I was puzzled a bit when seeing this:root@F:~# ifconfigbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.4 netmask 255.255.254.0 broadcast 0.0.0.0 inet6 2001:470:70af:1::4 prefixlen 64 scopeid 0x0<global> inet6 fe80::202:c9ff:fea5:a990 prefixlen 64 scopeid 0x20<link> ether 00:02:c9:a5:a9:90 txqueuelen 1000 (Ethernet) RX packets 179807 bytes 231307231 (220.5 MiB) RX errors 0 dropped 3528 overruns 0 frame 0 TX packets 76844 bytes 17873070 (17.0 MiB) TX errors 0 dropped 2 overruns 0 carrier 0 collisions 0br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.4.4 netmask 255.255.255.0 broadcast 0.0.0.0 ether 50:eb:f6:55:9e:de txqueuelen 1000 (Ethernet) RX packets 33480 bytes 7981790 (7.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 206 bytes 42479 (41.4 KiB) TX errors 0 dropped 2 overruns 0 carrier 0 collisions 0docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 inet6 fe80::42:5fff:fee6:e4f0 prefixlen 64 scopeid 0x20<link> inet6 fd17::1 prefixlen 64 scopeid 0x0<global> ether 02:42:5f:e6:e4:f0 txqueuelen 0 (Ethernet)For br0 and br1 the broadcast address is shown as 0.0.0.0 whereas for the docker part, there is a correct broadcast of 172.17.255.255.Is this wrong, or why is this so???
October 8, 2025Oct 8 Community Expert Are you referring to how the docker bridge network is created. As that broadcast IP is for the docker default bridge network.https://docs.docker.com/engine/network/drivers/bridge/my understanding is that this broadcast is in the docker daemon config:https://docs.docker.com/engine/daemon/ Edited October 8, 2025Oct 8 by bmartino1
October 10, 2025Oct 10 Author Community Expert On 10/9/2025 at 12:26 AM, bmartino1 said:Are you referring to how the docker bridge network is created. As that broadcast IP is for the docker default bridge network.No, I dont care about the docker address, I am puzzled because the "normal" bridges show 0.0.0.0 as a broadcast address.This cannot be true or work.(But the box works, so I think this is just a display error???)
October 10, 2025Oct 10 Community Expert I still think your coaught up on linux bridgesDocker’s bridge interface (docker0) is created differently versus Unraid’s system bridges (br0, br1), because they’re managed very differently..Why Docker uses a 172.x.x.x address and broadcast .255.255Docker, by default, creates an internal bridge network (docker0) using the subnet 172.17.0.0/16again this comes from the docker daemon.This comes straight from the Docker daemon’s built-in defaults (unless you override it in /etc/docker/daemon.json) [at least this is where it is in debain...unraids moves this. the nvdia plugin edits the daemon to add the nvdia run time. I don't remember where on unraid the json file is locatd now..That means:Gateway / bridge IP: 172.17.0.1Subnet mask: 255.255.0.0Broadcast: 172.17.255.255The broadcast is calculated automatically:Network address: 172.17.0.0Netmask: 255.255.0.0Broadcast: 172.17.255.255Docker explicitly sets that because it’s running a userland bridge network using iptables and veth pairs... it needs that broadcast address for container-to-container communication and proper ARP behavior inside the virtual subnet.ok so now lets look at the unraid linux bridge networks.Why Unraid’s bridges show broadcast 0.0.0.0br0: broadcast 0.0.0.0br1: broadcast 0.0.0.0that’s not actually wrong... it’s just how Unraid’s ifconfig reports when the bridge’s member interfaces or the underlying configuration (via ip addr or brctl) doesn’t explicitly define a broadcast value. Most modern Linux networking tools (like iproute2) don’t require or even use the broadcast field for L2-bridged interfaces anymore, because the bridge itself operates at Layer 2 and passes broadcast frames transparently...so its not displaying incorectly.. You can confirm that the kernel actually has a correct broadcast in use by running../ip addr show br0inet 192.168.0.4/23 brd 192.168.1.255 scope global br0If its a display error it jsut showing that its open to all address.That’s the real broadcast, even though ifconfig reports 0.0.0.0.In other words, ifconfig is just misleading — it’s deprecated and doesn’t always display bridge attributes correctly.Now Why Docker’s shows correctly while Unraid’s doesn’tDocker configures its bridge with ip commands when it creates docker0, explicitly including the broadcast:example:ip addr add 172.17.0.1/16 brd 172.17.255.255 dev docker0Unraid (via brctl and network scripts) instead attaches the host NIC into the bridge and lets the kernel infer broadcast behavior, so it never writes an explicit brd field — hence the 0.0.0.0 you see in the legacy ifconfig output.If you want to see all network details correctly (not the legacy output), use:ip -br addrorip addr show dev br0exampleroot@The-Borg:~# ip -br addrlo UNKNOWN 127.0.0.1/8 ::1/128tunl0@NONE DOWNeth0 UP fe80::1270:fdff:fecd:86e/64br0 UP 192.168.201.100/24 metric 1 fe80::1270:fdff:fecd:86e/64docker0 UP 172.17.0.1/16 fe80::42:3bff:fe88:732f/64shim-br0@br0 UP 192.168.201.101/24virbr0 DOWN 192.168.122.1/24vnet0 UNKNOWN fe80::fc54:ff:fe55:3fe4/64tailscale1 ...Tailscale data...br-1565206c2c60 DOWN 172.18.0.1/16 fe80::42:21ff:fea8:d4b3/64veth71e0b19@if79 UP fe80::54ff:b2ff:fe1d:b2b/64root@The-Borg:~# ip addr show dev br04: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000link/ether 10:70:fd:cd:08:6e brd ff:ff:ff:ff:ff:ffinet 192.168.201.100/24 metric 1 scope global br0valid_lft forever preferred_lft foreverinet6 fe80::1270:fdff:fecd:86e/64 scope link proto kernel_llvalid_lft forever preferred_lft foreverroot@The-Borg:~# ip addr show dev docker07: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group defaultlink/ether 02:42:3b:88:73:2f brd ff:ff:ff:ff:ff:ffinet 172.17.0.1/16 brd 172.17.255.255 scope global docker0valid_lft forever preferred_lft foreverinet6 fe80::42:3bff:fe88:732f/64 scope link proto kernel_llvalid_lft forever preferred_lft foreverroot@The-Borg:~# ip routedefault via 192.168.201.1 dev br0 metric 1005172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1172.18.0.0/16 dev br-1565206c2c60 proto kernel scope link src 172.18.0.1 linkdown192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown192.168.201.0/24 dev shim-br0 proto kernel scope link src 192.168.201.101192.168.201.0/24 dev br0 proto kernel scope link src 192.168.201.100 metric 1root@The-Borg:~#That’s the modern way to verify the actual broadcast and subnet values in Linux — and you’ll see that everything is configured correctly under the hood.So to me your mis understand the docker0 network. Edited October 11, 2025Oct 11 by bmartino1 removed tailscale data
October 12, 2025Oct 12 Author Community Expert tnx for the explanation, but sadly, it does not work.root@F:~# ip addr show br07: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:02:c9:a5:a9:90 brd ff:ff:ff:ff:ff:ff inet 192.168.0.4/23 metric 1 scope global br0 valid_lft forever preferred_lft forever inet6 2001:470:70af:1::4/64 metric 1 scope global valid_lft forever preferred_lft forever inet6 fe80::202:c9ff:fea5:a990/64 scope link proto kernel_ll valid_lft forever preferred_lft foreverThere is no broadcast addr shown in this command, unless you count in "brd ff:ff:ff:ff:ff:ff" which is V6 and therefor cannot exist.It says "BROADCAST" but does not list it.Of course, the netmask /23 is shown but nothing elseI think it got lost with 7.2(and yeah, it DOES work, so it must be somewhere in the background, deeply hidden)I am just curious WHY it vanished.
October 12, 2025Oct 12 Community Expert If I were to guess as I will go back and double check this. This was a change when they updated the webui for the network settings.I know iproute2 was also updated...I didn't want to reparse the inet.rc script unraid uses as its a giant mess...I agree with you I just double checked my own output and also noticed 0.0.0.0 and the ff:ff:ff:ff etc...ATM My understanding is, to Why Unraid bridges (br0, br1, shim-br0) don’t show a broadcast anymore:Unraid’s bridges are managed by rc.inet1 (Slackware’s legacy init script) and now rely on iproute2 semantics rather than legacy ifconfig semantics.In this newer mode:The broadcast is derived implicitly from the CIDR prefix (e.g. /23 → .1.255).The brd field is omitted unless explicitly configured.ifconfiga legacy wrapper around obsolete ioctl calls displays 0.0.0.0 when the kernel doesn’t store an explicit broadcast value.So nothing’s brokenifconfig just doesn’t know what to show. the application doesn't call nor use it as the device nic auto calculates it off the netmask and ip gateway sub set.as I'm curious I'll share some other kernel linux check commands:You can confirm the kernel is computing the right broadcast internally with:cat /proc/net/fib_trie | grep 192.168.0Exampleroot@The-Borg:~# cat /proc/net/fib_trie | grep 192.168.0+-- 192.168.0.0/20 3 0 5+-- 192.168.0.0/16 2 0 2+-- 192.168.0.0/16 2 0 2root@The-Borg:~#and/or with iprout2 application is defaulting to a calculation with the route rulesto get the actual broadcast its using:ip route get 192.168.1.255Example as i'm using 192.168.201.x/24root@The-Borg:~# ip route get 192.168.201.255broadcast 192.168.201.255 dev br0 table local src 192.168.201.100 uid 0cache <local,brd>root@The-Borg:~#so using the Linux kernel commands checks? so now the questions is Why the line brd ff:ff:ff:ff:ff:ff appears?I assume That’s the Ethernet-layer broadcast MAC address, not IPv6 / ipv4.All bridges and NICs naturally carry a link-layer broadcast entry (ff:ff:ff:ff:ff:ff).IPv4 broadcast (192.168.1.255) and Ethernet broadcast (ff:ff:ff:ff:ff:ff) are distinct but related: the IP broadcast frame is sent using the Ethernet broadcast destination.So, the “broadcast is there” ... just at L2, which is enough for ARP and DHCP to work.I have to go find the relase notes.Form memory, This was Starting around kernel 6.6 and net-tools 2.10, Slackware/Unraid switched to iproute2 as the authoritative tool...ifconfig is still present for compatibility, but it now reads data through the rtnetlink interface, which omits default broadcast fields.. Edited October 12, 2025Oct 12 by bmartino1 spelling.
October 12, 2025Oct 12 Author Community Expert 37 minutes ago, bmartino1 said:to get the actual broadcast its using:ip route get 192.168.1.255LOOOL :-)so you have to know it before to be able to see it? :-)very funny (and not really sane).Anyway, I knew already that it will be calculated on fly and that it obviously works (correctly).My "problem" or "question" just is, "why isn't it show by standard tools anymore?"
October 13, 2025Oct 13 Community Expert You have me invested now in this quirk... so here are some musing and quick thouhts...Yeah. Redundant if you need to know and a end users doesn't know how to calculate and the linux commands that are suposed to share are not working as they should... and the true broadcast is buried and there in the ip route and how the kernel/network interpert... Its a mess...Throwing here to the wall as i would assume simalr to how docker 0 was cretaed i should be able to run a ip coamnd to set the curent IP and boradcast...The Best I can recommend is running a script via user script plugin to predo some of this calculations, get confirm and run the ip command similar to what docker does to inform and tell the kernel this is the broadcast... so later runs of the command ipconfig will show... I guess this could be an annoyance bug report.As after some testing...Made a script to do the broadcast caulations. And the iproute get check the broadcast...The script hat shold fix...#!/usr/bin/env bash # show_broadcasts_noninteractive.sh # Non-interactive: find (and optionally apply) IPv4 broadcast addresses for all interfaces. # Designed to run from Unraid User Scripts plugin (runs as root). # CONFIGURE only the variables in the top section. set -euo pipefail ########################## # CONFIG (edit these) # ########################## # If true, the script will attempt to set the discovered broadcast on each iface. # WARNING: changing interface addressing can disrupt networking. Default: false. APPLY=false #will run a ip comand simlar to how docker is made to then use ifconfig to see braodcast... #Dry run with apply false first to see log of interfaces the script will touch and estimated brodcast via math and what the sytem is shoing via broadcast #Apply will run the IP command to infomr the kerneal and write the brooadcast so later runs of ipconfig and other will show the broadcast... # If true and APPLY=true, the script will not actually run 'ip addr change' but will # print the exact ip command it would run (safe for scheduled jobs). PRINT_ONLY=true # Optional: comma-separated list of interfaces to process (e.g. "br0,eth0"). # Empty -> process all IPv4 interfaces. # Use this to limit scope when running automatically. INTERFACES_INCLUDE="" #It is best to set this eth0, br0 etc... # Optional: comma-separated list of interfaces to skip (e.g. "lo,docker0,virbr0,tailscale1,tunl0") #Don't mess with localhost the loobback interface, nor Docker0 as it is already corect script should skip anyway..., Don't mess with VM netowrk the libvirt Hyper V Swtich, and don't mess with tailscale don't mess with tunel and talscale interfaces. #Unless you know what your doing! INTERFACES_EXCLUDE="lo,docker0,virbr0,tailscale1,tunl0" # Optional: path to a logfile (script will append). Empty -> only stdout. LOGFILE="" #user scirpt plugin has a log... ########################## # end CONFIG # ########################## # helper: logging _log() { local msg="$*" if [[ -n "$LOGFILE" ]]; then printf '%s %s\n' "$(date -Iseconds)" "$msg" | tee -a "$LOGFILE" else printf '%s %s\n' "$(date -Iseconds)" "$msg" fi } # Convert dotted IPv4 to int ip2int() { local IFS=. read -r a b c d <<< "$1" echo $(( (a<<24) | (b<<16) | (c<<8) | d )) } # Convert int to dotted IPv4 int2ip() { local n=$1 n=$(( n & 0xFFFFFFFF )) local a=$(( (n >> 24) & 0xFF )) local b=$(( (n >> 16) & 0xFF )) local c=$(( (n >> 8 ) & 0xFF )) local d=$(( n & 0xFF )) printf "%d.%d.%d.%d\n" "$a" "$b" "$c" "$d" } # CIDR -> mask as 32-bit integer cidr_to_mask() { local cidr=$1 if (( cidr <= 0 )); then echo 0 return fi if (( cidr >= 32 )); then echo 4294967295 return fi local top=$(( (1 << cidr) - 1 )) echo $(( (top << (32 - cidr)) & 0xFFFFFFFF )) } # Query kernel's view of broadcast for a destination query_kernel_broadcast() { local dst=$1 local out br # ip route get may write to stderr on some platforms; capture both out=$(ip route get "$dst" 2>&1 || true) br=$(awk '{ for(i=1;i<=NF;i++){ if($i=="broadcast"){ print $(i+1); exit } } }' <<< "$out") printf "%s" "$br" } # helpers to manage include/exclude lists in_list() { local item="$1" local list="$2" # comma-separated list [[ -z "$list" ]] && return 1 IFS=, read -ra arr <<< "$list" for x in "${arr[@]}"; do [[ "$x" == "$item" ]] && return 0 done return 1 } _log "Starting show_broadcasts_noninteractive. APPLY=${APPLY} PRINT_ONLY=${PRINT_ONLY} INCLUDE='${INTERFACES_INCLUDE}' EXCLUDE='${INTERFACES_EXCLUDE}'" # Iterate IPv4 addresses while IFS= read -r line; do # sample 'ip -o -4 addr show' line: # 7: br0 inet 192.168.0.4/23 brd 192.168.1.255 scope global br0 iface=$(awk '{print $2}' <<< "$line") iface=${iface%:} # enforce include/exclude if in_list "$iface" "$INTERFACES_EXCLUDE"; then _log "Skipping $iface (in EXCLUDE list)." continue fi if [[ -n "$INTERFACES_INCLUDE" ]] && ! in_list "$iface" "$INTERFACES_INCLUDE"; then _log "Skipping $iface (not in INCLUDE list)." continue fi inet_part=$(awk '{for(i=1;i<=NF;i++) if($i=="inet"){print $(i+1); exit}}' <<< "$line") reported_brd=$(awk '{for(i=1;i<=NF;i++) if($i=="brd"){print $(i+1); exit}}' <<< "$line" || true) if [[ -z "$inet_part" ]]; then _log " - $iface: no IPv4 address found, skipping." continue fi ipaddr=${inet_part%%/*} cidr=${inet_part##*/} if [[ -z "$ipaddr" || -z "$cidr" ]]; then _log " - $iface: couldn't parse IP/CIDR from '$inet_part'" continue fi _log "Interface: $iface" _log " Address/CIDR: $ipaddr/$cidr" if [[ -n "$reported_brd" ]]; then _log " Reported brd: $reported_brd" else _log " Reported brd: (none)" fi invalid_reported=false if [[ -z "$reported_brd" || "$reported_brd" == "0.0.0.0" ]]; then invalid_reported=true fi ip_int=$(ip2int "$ipaddr") mask_int=$(cidr_to_mask "$cidr") inv_mask=$(( (~mask_int) & 0xFFFFFFFF )) computed_brd_int=$(( (ip_int & mask_int) | inv_mask )) computed_brd=$(int2ip "$computed_brd_int") _log " Computed brd: $computed_brd (from math)" kern_brd=$(query_kernel_broadcast "$computed_brd") if [[ -n "$kern_brd" ]]; then _log " Kernel says broadcast: $kern_brd" else _log " Kernel broadcast: (none returned)" fi # choose best chosen_brd="" if [[ -n "$kern_brd" && "$kern_brd" != "0.0.0.0" ]]; then chosen_brd="$kern_brd" elif [[ "$invalid_reported" = false && -n "$reported_brd" && "$reported_brd" != "0.0.0.0" ]]; then chosen_brd="$reported_brd" else chosen_brd="$computed_brd" fi _log " -> Selected broadcast: $chosen_brd" if [[ "${APPLY}" == "true" ]]; then # Build the command we would run ip_cmd="ip addr change dev ${iface} local ${ipaddr} broadcast ${chosen_brd} || ip addr add ${ipaddr}/${cidr} dev ${iface} broadcast ${chosen_brd}" if [[ "${PRINT_ONLY}" == "true" ]]; then _log " [PRINT_ONLY] Would run: ${ip_cmd}" else _log " Applying: ${ip_cmd}" # run the change command; swallow failure but log it if bash -c "${ip_cmd}"; then _log " Applied successfully to ${iface}." else _log " Failed to apply to ${iface}. (This may be normal for container-managed or bridge interfaces.)" fi fi fi done < <(ip -o -4 addr show) _log "Finished." # If not applying, advise what to change (final message) if [[ "${APPLY}" != "true" ]]; then _log "APPLY is false. No interfaces were modified. To enable non-interactive applying, set APPLY=true in the script header." _log "If you want to see the ip commands without applying, set PRINT_ONLY=true (and APPLY=true)." fi *Note the Config at the Top... First run test see log... apply is false and print true... more to double check what interfaces will be touched...as this is the comand to run to fix the display issue:2025-10-13T12:32:24-05:00 [PRINT_ONLY] Would run: ip addr change dev br-1565206c2c60 local 172.18.0.1 broadcast 172.18.255.255 || ip addr add 172.18.0.1/16 dev br-1565206c2c60 broadcast 172.18.255.2552025-10-13T12:32:24-05:00 Finished.Script Finished Oct 13, 2025 12:32.24I will now change to apply to true and print to false... let the ip command run to set the brodcast via the ip command... since its confirmed via math and crosed with what the kerneal already shows... this was the ifconig tool see what the kerenal sees as it was written after the run... note br0 and shim-br0 brodacast didn't change even though a bradcast ip was sent and coreclty set I have no network loss or net isseus after this script run..so even with a work around script the ifconfig didn't affect the ifconfig output..Let me try directly by including br0 in include and then use other comadns to see if the brctl and ip adr show comadns see the bridge now...sad panda... ip addr change dev br0 local 192.168.201.100 broadcast 192.168.201.255 || ip addr add 192.168.201.100/24 dev br0 broadcast 192.168.201.255However, I can see the docker veth and other br interfaces got a ip as they should so I have to assume a higer level overwrite via the inet rc script.root@The-Borg:~# cd /etc/rc.d/root@The-Borg:/etc/rc.d# lsrc.0@ rc.atd* rc.dnsmasq rc.ipmidetectd rc.local_shutdown* rc.openldap rc.smartdrc.4* rc.avahidaemon* rc.docker* rc.ipmiseld* rc.loop* rc.php-fpm* rc.sshd*rc.4.local* rc.avahidnsconfd* rc.elogind* rc.ipmitail* rc.mcelog* rc.ptpd* rc.swapfile@rc.6* rc.bind rc.font rc.kadmind rc.messagebus* rc.rpc* rc.sysstatrc.K* rc.bmc-watchdog rc.inet1* rc.keymap* rc.modules* rc.rsyslogd* rc.sysvinit*rc.M* rc.cgconfig rc.inet1.conf rc.kpropd rc.modules.local* rc.runlog rc.tailscale@rc.S* rc.cgred rc.inet2* rc.krb5kdc rc.mysqld rc.samba* rc.udev*rc.S.cont* rc.cgroup2unraid* rc.inetd* rc.library.source rc.nfsd* rc.saslauthd rc.wireguard*rc.acpid* rc.cpufreq* rc.ip_forward* rc.libvirt* rc.nginx* rc.serial* rc.wireless*rc.apcupsd* rc.crond* rc.ipmicfg* rc.local* rc.ntpd* rc.setterm* rc.wsdd2*root@The-Borg:/etc/rc.d# nano rc.inet* which I parsed back in the 7.0 beta...I do see that I have 3 inet stuff so a new inet scirpt may be implemented...the inet1.conf the inet1* and inet2*as teh rc.inetd is the daemon script... so unradi slackware ha defienlty cahged and messed with its networksSomething that wasn't there before the webui network layout change...My unraid system the Borg setting > network on v 7.1.4root@The-Borg:/etc/rc.d# ip addr show br04: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 10:70:fd:cd:08:6e brd ff:ff:ff:ff:ff:ff inet 192.168.201.100/24 metric 1 scope global br0 valid_lft forever preferred_lft forever inet 192.168.201.100/32 brd 192.168.201.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::1270:fdff:fecd:86e/64 scope link proto kernel_ll valid_lft forever preferred_lft foreverroot@The-Borg:/etc/rc.d# so its still getting something via dhcp. but the ip command did run and work...but now there are 2 of the same ip with 1 ip on the wrong cird subnet...hmm... I may need to reach out on the bug reports and higher up in unraid dev team on this one...As I can confirm in older unraid version like version 6 there their weren't mutiple inet rc scripts... which may have cheaged in recent releases...so I have to assume L2 transport broadcast by default thus even a written broadcast command ran is un needed as we are using L2/L3 and the Ethernet device broadcast and kernel with iproute to determine where the ip address needs to go and talk to...still ip a, ipconfig and ip addre show should notate that better... But I'm not 100% sure this is a display bug or comand issues... I still have to assume some werid overwrite happening from the inet script.
October 13, 2025Oct 13 Community Expert Similar to how i'm setting the docker macvlan shib bridge, I may need to flush the dev ip configuration after colecttng tis data and re add it via the ip command to remove duplicates...just though I'd share some seek and find thoughts and data.her is a updates working work around script that restores the broadcast.root@The-Borg:~# ifconfigbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.201.100 netmask 255.255.255.0 broadcast 192.168.201.255 inet6 fe80::1270:fdff:fecd:86e prefixlen 64 scopeid 0x20<link> ether 10:70:fd:cd:08:6e txqueuelen 1000 (Ethernet) RX packets 64097 bytes 14870297 (14.1 MiB) RX errors 0 dropped 14 overruns 0 frame 0 TX packets 36048 bytes 5928118 (5.6 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 02025-10-13T16:33:46-05:00 Start. APPLY=true PRINT_ONLY=false DO_FLUSH=true INCLUDE='br0' EXCLUDE='lo,docker0,virbr0,tailscale1,tunl0,veth*,br-*'2025-10-13T16:33:46-05:002025-10-13T16:33:46-05:00 Interface: br02025-10-13T16:33:46-05:00 Pre-state:4: br0 inet 192.168.201.100/24 metric 1 scope global br0\ valid_lft forever preferred_lft forever2025-10-13T16:33:46-05:00 Detected default GW on br0: 192.168.201.12025-10-13T16:33:46-05:00 Primary: 192.168.201.100/242025-10-13T16:33:46-05:00 Reported brd: (none)2025-10-13T16:33:46-05:00 Computed brd: 192.168.201.2552025-10-13T16:33:46-05:00 Kernel says brd: 192.168.201.2552025-10-13T16:33:46-05:00 -> Selected broadcast: 192.168.201.2552025-10-13T16:33:46-05:00 Applying (down -> flush -> add IP+brd -> up -> restore default route)...2025-10-13T16:33:46-05:00 Applied successfully to br0.2025-10-13T16:33:46-05:00 Post-state:4: br0 inet 192.168.201.100/24 brd 192.168.201.255 scope global br0\ valid_lft forever preferred_lft forever2025-10-13T16:33:46-05:002025-10-13T16:33:46-05:00 Finished.Script Finished Oct 13, 2025 16:33.46Full logs for this script are available at /tmp/user.scripts/tmpScripts/show_broadcasts/log.txtroot@The-Borg:~# ip addr show br04: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 10:70:fd:cd:08:6e brd ff:ff:ff:ff:ff:ff inet 192.168.201.100/24 brd 192.168.201.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::1270:fdff:fecd:86e/64 scope link valid_lft forever preferred_lft forever################Work around script: #!/bin/bash # show_broadcasts_noninteractive.sh # Non-interactive: compute/set IPv4 broadcast on the PRIMARY (/0..30) addr per iface. # When DO_FLUSH=true: link down -> flush -> add IP+brd -> link up -> restore default route (if it was on this iface). # Wildcard include/exclude supported (br*, veth*, br-*). Pure bash + ip + awk. set -euo pipefail ########################## # CONFIG (edit these) ########################## APPLY=true # actually make changes PRINT_ONLY=false # when true (and APPLY=true), print the ip commands instead of running them INTERFACES_INCLUDE="br0" # CSV; supports globs: "br0", "eth0", "br*", "veth*", "br-*"; empty = all (minus EXCLUDE) INTERFACES_EXCLUDE="lo,docker0,virbr0,tailscale1,tunl0,veth*,br-*" # CSV; globs supported; exclude wins DO_FLUSH=true # safe flush sequence (down->flush->add brd->up->restore default route) SLEEP_BEFORE=0 # optional delay to avoid racing rc scripts if you autostart (not recommended) LOGFILE="" # optional extra logfile; empty -> stdout only (User Scripts captures stdout) ########################## # end CONFIG ########################## _log() { local m="$*" if [[ -n "$LOGFILE" ]]; then printf '%s %s\n' "$(date -Iseconds)" "$m" | tee -a "$LOGFILE" else printf '%s %s\n' "$(date -Iseconds)" "$m" fi } matches_globs_csv() { # $1=name, $2=csv_globs local name="$1" local csv="$2" if [[ -z "$csv" ]]; then return 1 fi local IFS=, local pat read -r -a arr <<< "$csv" for pat in "${arr[@]}"; do pat="${pat#"${pat%%[![:space:]]*}"}" pat="${pat%"${pat##*[![:space:]]}"}" [[ -z "$pat" ]] && continue case "$name" in $pat) return 0 ;; esac done return 1 } should_process_iface() { local ifc="$1" if matches_globs_csv "$ifc" "$INTERFACES_EXCLUDE"; then return 1 fi if [[ -z "$INTERFACES_INCLUDE" ]]; then return 0 fi matches_globs_csv "$ifc" "$INTERFACES_INCLUDE" } ip2int() { local IFS=. local a b c d read -r a b c d <<< "$1" echo $(( (a<<24) | (b<<16) | (c<<8) | d )) } int2ip() { local n=$1 n=$(( n & 0xFFFFFFFF )) printf "%d.%d.%d.%d\n" $(( (n>>24)&255 )) $(( (n>>16)&255 )) $(( (n>>8)&255 )) $(( n&255 )) } cidr_to_mask() { local c=$1 if (( c <= 0 )); then echo 0 return fi if (( c >= 32 )); then echo 4294967295 return fi local top=$(( (1<<c) - 1 )) echo $(( (top << (32-c)) & 0xFFFFFFFF )) } query_kernel_broadcast() { local dst=$1 local out br out=$(ip route get "$dst" 2>&1 || true) br=$(awk '{for(i=1;i<=NF;i++) if($i=="broadcast"){print $(i+1); exit}}' <<< "$out") printf "%s" "$br" } pick_primary_line_for_iface() { # arg1=iface local ifc="$1" # returns one best "ip -4 -o addr show dev IF" line (widest network; skip /31,/32) ip -4 -o addr show dev "$ifc" 2>/dev/null | awk ' { for(i=1;i<=NF;i++) if($i=="inet"){ inet=$(i+1) } if(inet=="") next split(inet,a,"/") ip=a[1]; cidr=a[2]+0 if(cidr>=31) next if(mincidr==0 || cidr<mincidr){ mincidr=cidr; best=$0 } inet="" } END{ if(best!="") print best } ' } # --- main --- if (( SLEEP_BEFORE > 0 )); then _log "Sleeping ${SLEEP_BEFORE}s..." sleep "$SLEEP_BEFORE" fi _log "Start. APPLY=${APPLY} PRINT_ONLY=${PRINT_ONLY} DO_FLUSH=${DO_FLUSH} INCLUDE='${INTERFACES_INCLUDE}' EXCLUDE='${INTERFACES_EXCLUDE}'" # enumerate all ifaces that currently have any IPv4; then filter by include/exclude # (we intentionally avoid associative arrays, and process each iface independently) while IFS= read -r IF; do IF="${IF%:}" should_process_iface "$IF" || continue _log "" _log "Interface: $IF" _log " Pre-state:" ip -4 -o addr show dev "$IF" | sed 's/^/ /' || true # pick primary line PL="$(pick_primary_line_for_iface "$IF" || true)" if [[ -z "$PL" ]]; then _log " No broadcast-capable primary (/0..30); skipping." continue fi inet="$(awk '{for(i=1;i<=NF;i++) if($i=="inet"){print $(i+1); exit}}' <<< "$PL")" rep_brd="$(awk '{for(i=1;i<=NF;i++) if($i=="brd"){print $(i+1); exit}}' <<< "$PL" 2>/dev/null || true)" IP="${inet%%/*}" CIDR="${inet##*/}" # capture default gateway if bound to this iface GW="$(ip route show default 2>/dev/null | awk -v IF="$IF" '$1=="default" && $0 ~ (" dev "IF"($| )"){for(i=1;i<=NF;i++) if($i=="via"){print $(i+1)}}' | head -n1)" if [[ -n "$GW" ]]; then _log " Detected default GW on ${IF}: ${GW}" fi _log " Primary: ${IP}/${CIDR}" if [[ -n "$rep_brd" ]]; then _log " Reported brd: ${rep_brd}" else _log " Reported brd: (none)" fi ip_int="$(ip2int "$IP")" m_int="$(cidr_to_mask "$CIDR")" inv=$(( (~m_int) & 0xFFFFFFFF )) comp_brd="$(int2ip $(( (ip_int & m_int) | inv )))" _log " Computed brd: $comp_brd" kern_brd="$(query_kernel_broadcast "$comp_brd")" if [[ -n "$kern_brd" ]]; then _log " Kernel says brd: $kern_brd" else _log " Kernel brd: (none)" fi CHOSEN="$comp_brd" if [[ -n "$kern_brd" && "$kern_brd" != "0.0.0.0" ]]; then CHOSEN="$kern_brd" elif [[ -n "$rep_brd" && "$rep_brd" != "0.0.0.0" ]]; then CHOSEN="$rep_brd" fi _log " -> Selected broadcast: $CHOSEN" if [[ "$APPLY" != "true" || "$PRINT_ONLY" == "true" ]]; then if [[ "$DO_FLUSH" == "true" ]]; then _log " Would run (in order):" _log " ip link set ${IF} down" _log " ip -4 addr flush dev ${IF}" _log " ip addr add ${IP}/${CIDR} brd ${CHOSEN} dev ${IF}" _log " ip link set ${IF} up" if [[ -n "$GW" ]]; then _log " ip route replace default via ${GW} dev ${IF}" fi else _log " Would run: ip addr replace ${IP}/${CIDR} brd ${CHOSEN} dev ${IF}" fi else if [[ "$DO_FLUSH" == "true" ]]; then _log " Applying (down -> flush -> add IP+brd -> up -> restore default route)..." ip link set "${IF}" down ip -4 addr flush dev "${IF}" ip addr add "${IP}/${CIDR}" brd "${CHOSEN}" dev "${IF}" ip link set "${IF}" up if [[ -n "$GW" ]]; then ip route replace default via "${GW}" dev "${IF}" fi # sanity if ! ip -4 -o addr show dev "$IF" | grep -q "${IP}/${CIDR}"; then _log " ERROR: ${IP}/${CIDR} not present on ${IF} after flush/add." exit 1 fi _log " Applied successfully to ${IF}." else _log " Applying: ip addr replace ${IP}/${CIDR} brd ${CHOSEN} dev ${IF}" ip addr replace "${IP}/${CIDR}" brd "${CHOSEN}" dev "${IF}" _log " Applied successfully to ${IF}." fi fi _log " Post-state:" ip -4 -o addr show dev "$IF" | sed 's/^/ /' || true done < <(ip -4 -o addr show | awk '{print $2}' | sed 's/:$//' | sort -u) _log "" _log "Finished." # NOTE: # - Do NOT autostart this by default. A reboot without this script will restore Unraid's implicit-broadcast state. # - If you choose to autostart anyway, consider SLEEP_BEFORE=5..10 to avoid racing rc.inet* and docker. Edited October 13, 2025Oct 13 by bmartino1 workaround script to fix...
October 13, 2025Oct 13 Author Community Expert LOOOL! you are taking this stuff too serious! CALM DOWN !(and dont type too fast, you are mixing up many letters :-) )We all know, its just a display problem, so its the lowest of all low level of bug.So maybe its just something to live with it.(and one more reason for me to stay away from Linux as far as I can. Linux Networking is a mess, and a bigger mess because thousands of people fiddle around with in uncoordinated and break things without any reason or progress. Changing from API1 to API2 is always a bad idea.)
October 13, 2025Oct 13 Community Expert 3 hours ago, MAM59 said:LOOOL! you are taking this stuff too serious! CALM DOWN !(and dont type too fast, you are mixing up many letters :-) )We all know, its just a display problem, so its the lowest of all low level of bug.So maybe its just something to live with it.(and one more reason for me to stay away from Linux as far as I can. Linux Networking is a mess, and a bigger mess because thousands of people fiddle around with in uncoordinated and break things without any reason or progress. Changing from API1 to API2 is always a bad idea.)Yeah, I'm probably taking it a bit too serious. However, I did find a workaround fix. Something I may further report upstream to the ifconfig team for slack ware for bug tracking and fixing...I made a bug report as well.https://forums.unraid.net/bug-reports/stable-releases/714-ifconfig-brodcast-display-error-minor-netowrking-anoyance-work-aroud-fix-script-r4105/
October 14, 2025Oct 14 Author Community Expert Hey, if you are digging so deep, I have one more "strange" networking stuff to report for 7.2Since the update logs of other machines fill up will messages like:l3router.meiszl.de kernel log messages: +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0Some dozens per day. The number is counted up every 20 packets or so. Looks like somebody/something is probing the LAN (but with nobody listening, its a strange probe I think).My suspect of the source is currently UNRAID.Any Idea what this might be? Edited October 14, 2025Oct 14 by MAM59
October 14, 2025Oct 14 Community Expert 1 hour ago, MAM59 said:Hey, if you are digging so deep, I have one more "strange" networking stuff to report for 7.2Since the update logs of other machines fill up will messages like:l3router.meiszl.de kernel log messages: +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0 +IPFW2: IPV6 - Unknown Extension Header(135), ext_hd=0Some dozens per day.The number is counted up every 20 packets or so. Looks like somebody/something is probing the LAN (but with nobody listening, its a strange probe I think).My suspect of the source is currently UNRAID.Any Idea what this might be?Sure I like puzzles, I'll see what I can find out. I'm not very well versed in all of ipv6 stuff. I'm going to Use AI here a bit.My first gut assumption is kinda leaning more on unraid verbose dmesg kernel log setup.. as unraid ships with very high verbose log enabled all over. There is quite a bit of log spamming on unraid...So First, as I've not seen that in a log ever yet... Using google AI to help me dig a bit deeper into this abit more...Here is a breakdown of the kernel message log:IPFW: The message comes from the Internet Protocol FireWall, a native firewall in FreeBSD.IPV6: The log refers to an Internet Protocol Version 6 packet.Unknown Extension Header(135): The firewall encountered an IPv6 extension header with the assigned number 135 and did not have a rule or capability to handle it. A protocol number of 135 is designated for the Mobility Header, which is used in Mobile IPv6 for mobility support.ext_hd=0: This part indicates the position of the extension header. An ext_hd value of 0 means the mobility header was the first extension header in the IPv6 packet, immediately following the base IPv6 header. Why this happensThis log message is often a low-priority informational or warning message, but it could also indicate a misconfiguration or network issue:Mobile IPv6 traffic: If your network or one of its clients is using Mobile IPv6, the packets will include a Mobility Extension Header. IPFW, if not configured to specifically recognize this header, will log the event and drop the packet.Firewall rule deficiency: The firewall's ruleset may not have a specific rule to permit or process the packet containing the mobility header. In the absence of a matching rule, IPFW's default behavior is to deny and log the traffic.Network scanning or a bug: Less commonly, the log could result from network scanning or a bug in a network stack that sends malformed or unusual packets. Some potental things that could casue this on uraid logs:As I'm not blaming the router or a misconfiguration, I'm wonder if this is a forbidden router VM setup running on unraid... as This is the first I've seen that error...as unraid does have weird ipv6 implementation setups. My assumption would be that I don't think unraid knows how to handle a type 135 ipv6 packet natively...https://datatracker.ietf.org/doc/html/rfc6275So Let’s unpack what’s actually happening and how it intersects with Unraid’s Linux base (Slackware) and your ?FreeBSD-based firewall/router? (which is what/where the log appears to be coming from)as the loggin is a bit weird and This doesn't appear to be urnaids logging? it’s the router seeing packets from (or passing by) Unraid. Is that correct? or is this a router VM running on unraid?As I think It’s your router saying “I see weird IPv6 packets with header 135, I don’t know what to do with them.” or Those packets could indeed be originating from Unraid (or a Docker container / VM inside it)...so in the router i would first asume verbose login inthe system ctl.######### Free BSD Router Stuff...FreeBSD’s IPFW has:net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=0 by default when you enable logging.That means every dropped unknown header logs a line — hence the dozens per day.so onthe router I would probably set a limit.On the router (FreeBSD / OPNsense / pfSense / IPFW)You can safely tell IPFW to drop-silently rather than log these:sysctl net.inet.ip.fw.verbose=0 sysctl net.inet.ip.fw.verbose_limit=5 or add a discard rule:ipfw add 100 deny log ip6 from any to any proto 135 (change log to nolog if you just want it quiet).#################Unraid with the 3rd party application.so I would extra install tcpdump on unraid... and esentail do a wireshark capture.https://slackware.pkgs.org/15.0/slackware-x86_64/tcpdump-4.99.1-x86_64-1.txz.htmlbinary application: https://slackware.uk/slackware/slackware64-15.0/slackware64/n/tcpdump-4.99.1-x86_64-1.txzwith unraid tcpdump extra install we can run this on Unraid and try to capture the packets and track the source and sender...Run these on Unraid to see who’s sending Mobility Header packets:# Show live capture of IPv6 packets with Next Header 135 tcpdump -n -i br0 ip6[6] == 135 # or on docker bridge tcpdump -n -i docker0 ip6[6] == 135 If you see output of someting like:IP6 (flowlabel 0x..., nh 135, ...) note the source address that’s your culprit/talker.If it’s a container IP (172.x inside docker0) or VM (192.168.x or fd00:...), you’ll know the culprit...I would also asume some ipv6 unraid issues with RA and bridge packet forwarding.We can limit noise:sysctl -w net.ipv6.conf.all.accept_ra=0 sysctl -w net.ipv6.conf.default.accept_ra=0 to prevent weird RA echoes.stuff for Home assistant on the forum and fixes with other uses with ipv6 for matter... theses were needed to complete additional ipv6 packet on unraid.So I would recoemdn a user scirpt test run and system ctl user script update ipv6 setting on unraid:*I've added it for both your br0 and br1 bridges. #!/bin/bash # Delay before starting sleep 10 # Apply sysctl settings apply_sysctl_settings() { echo "Applying sysctl settings..." sysctl -w net.ipv6.conf.all.forwarding=1 sysctl -w net.ipv6.conf.br0.accept_ra=2 sysctl -w net.ipv6.conf.br0.accept_ra_rt_info_max_plen=64 sysctl -w net.ipv6.conf.br1.accept_ra=2 sysctl -w net.ipv6.conf.br1.accept_ra_rt_info_max_plen=64 echo "Verifying sysctl settings..." sysctl net.ipv6.conf.all.forwarding sysctl net.ipv6.conf.br0.accept_ra sysctl net.ipv6.conf.br0.accept_ra_rt_info_max_plen sysctl net.ipv6.conf.br1.accept_ra sysctl net.ipv6.conf.br1.accept_ra_rt_info_max_plen } #run loop apply_sysctl_settings*Reboot to undo on unraid...script log example (something I've been runing since 7.0 beta to 7.1.4:Applying sysctl settings...net.ipv6.conf.all.forwarding = 1net.ipv6.conf.br0.accept_ra = 2net.ipv6.conf.br0.accept_ra_rt_info_max_plen = 64Verifying sysctl settings...net.ipv6.conf.all.forwarding = 1net.ipv6.conf.br0.accept_ra = 2net.ipv6.conf.br0.accept_ra_rt_info_max_plen = 64
October 14, 2025Oct 14 Author Community Expert your AI is hallucinating quite alot :-) The messages are logged in FreeBSD not UNRAID.And again, "accept_ra_rt_info_max_plen = 64" is seriously debatable and highly dangerous. The assumption that a subnetmask is always "less or equal than 64 bits" is simply wrong.One could divide the given /64 prefix internally into many many subnets, making the mask grow to /72, /80 or even deeper. UNRAID would refuse to carry packets to these boxes then.Anyway, my Wireshark is on the line and I hope to caputure some of these packets soon to see, where they are coming from and what they want...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.