**** BEGIN LOGGING AT Mon Jun 01 02:59:57 2020 Jun 01 13:13:28 hm, capturing from eth0 on my rt-ac85p shows Ethernet frames which are clearly VLAN. Jun 01 13:13:35 I cannot make tcpdump or wireshark interpret them as such Jun 01 13:13:42 just tells me they're malformed. Jun 01 13:14:10 14:04:08.571473 a8:5e:45:92:c4:cc > 48:2a:e3:14:86:25 Null Information, send seq 4, rcv seq 0, Flags [Command], length 728 Jun 01 13:14:10 0x0000: 482a e314 8625 a85e 4592 c4cc 0001 0000 H*...%.^E....... Jun 01 13:14:10 0x0010: 0800 4510 02d4 cb1f 4000 4006 fdfe 5a9b ..E.....@.@...Z. Jun 01 13:14:12 etc Jun 01 13:18:55 your ethertype is 0x0001, this looks strange Jun 01 13:21:56 that's the vlan id Jun 01 13:22:21 ethertype is 0800 for Legacy IP Jun 01 13:23:58 802.1Q uses 0x8100 as ethertype, then two bytes for the VLAN ID, then the ethertype of the next protocol (0x0800 IPv4 in your case indeed) Jun 01 13:24:53 so your capture does not show standard VLANs, maybe your are seeing something that is normally used internally between the switch and the CPU Jun 01 13:24:53 here's one from the 21st century Jun 01 13:24:55 14:24:36.669098 18:62:2c:5d:94:6a > 64:5d:86:61:ab:02 Null Information, send seq 67, rcv seq 110, Flags [Poll], length 118 Jun 01 13:24:55 0x0000: 645d 8661 ab02 1862 2c5d 946a 0000 0000 d].a...b,].j.... Jun 01 13:24:55 0x0010: 86dd 600a bb5a 004a 1140 2001 08b0 010b ..`..Z.J.@...... Jun 01 13:25:00 hm, maybe Jun 01 13:27:10 I am only really frowning at this device because I suspect it of repeating packets it shouldn't, confusing the switches and causing DHCP replies to go the wrong way, never reaching the device they're really intended for Jun 01 13:27:14 Jun 1 09:20:21 lantiq.infradead.org kernel: [72869.668521] br-lan: received packet on eth0.1 with own address as source address (addr:18:62:2c:5d:94:6a, vlan:0) Jun 01 14:14:25 can someone test this command on their openwrt: time ping -c1 -w2 test.com Jun 01 14:14:46 the deadline option isn't working for me Jun 01 14:15:55 JyZyXEL: exits after 10 seconds on 19.07 and master. Jun 01 14:16:22 for me it exists after 5 seconds.. and it _should_ exist in 2 seconds Jun 01 14:16:26 exit* Jun 01 14:18:44 -W2 does the same, as does -W2 -w2 Jun 01 14:21:39 15:21:00.718476 sendto(0, "\10\0\356\334F\317\0\0\201\23A@\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64, 0, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("69.172.200.235")}, 28) = 64 Jun 01 14:21:39 15:21:00.726843 rt_sigaction(SIGALRM, {sa_handler=0x41ab49, sa_mask=[RT_68 RT_70 RT_71 RT_73 RT_74 RT_75 RT_77 RT_78 RT_80 RT_81 RT_83 RT_84 RT_86 RT_87 RT_88 RT_89 RT_90 RT_91 RT_93 RT_94 RT_95], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0}, {sa_handler=SIG_DFL, sa_mask=[RT_67 RT_68 RT_69 RT_71 RT_74 RT_75 RT_76 RT_77 RT_78 RT_81 RT_87 RT_88 RT_89 RT_90 RT_91 RT_92 RT_93 RT_94 RT_95], sa_flags=0}, 16) = 0 Jun 01 14:21:40 15:21:00.731656 setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=10, tv_usec=0}}, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=0, tv_usec=0}}) = 0 Jun 01 14:21:41 15:21:00.736601 recvfrom(0, 0x4598a0, 192, 0, 0x7fc12cc8, [16]) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) Jun 01 14:21:44 15:21:10.734525 --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- Jun 01 14:22:46 "tv_sec=10" it's setting the wrong timer value Jun 01 14:27:40 it works fine here, it exits after 2 seconds Jun 01 14:27:59 wut. how can we all have a different result Jun 01 14:28:04 ath79 / 19.07.1 / busybox 1.30.1-5 Jun 01 14:28:28 ah, I was using -W, not -w Jun 01 14:29:37 it takes 10 seconds with -w2 Jun 01 14:30:30 from the help -W seems more appropriate (-w is only to limit the total time, and I guess it's checked only after each reply / timeout) Jun 01 14:31:18 so, maybe a bit unexpected, but not really a bug Jun 01 14:31:40 either one always takes 5 seconds for me on OpenWrt 19.07.1, r10911-c155900f66 on xrx200 Jun 01 14:31:49 "ping -c1 -W 2 -w 2 test.com" does take only 2 seconds here Jun 01 14:32:09 real 0m 5.01s Jun 01 14:32:39 oh im also getting ping: bad address 'test.com' Jun 01 14:32:47 so its not even resolving for me Jun 01 14:34:11 ah yeah, 5 seconds is a typical DNS lookup timeout Jun 01 14:34:29 ok, "time ping -c1 -w2 8.8.8.9" takes 10 seconds and "time ping -c1 -W2 8.8.8.9" takes 2 seconds Jun 01 14:34:52 the ping manual doesn't mention that the deadline does not apply to DNS resolving Jun 01 14:35:49 that's another bug on my device where openwrt doesn't resolve addresses after a reboot, until i manually do "/etc/init.d/dnsmasq restart" Jun 01 14:36:29 and i always forget to do it and don't know what would be the best way to automatize it Jun 01 14:36:31 don't rely on the usual ping manual, because openwrt uses busybox's ping, and it can behave a bit differently anyway Jun 01 14:36:58 busyboxes ping only seems to have the --help anyways Jun 01 14:37:32 sounds like a DNSSEC / NTP issue? I remember seeing a fix about this in 19.07.3 Jun 01 14:37:50 see https://openwrt.org/releases/19.07/notes-19.07.3 Jun 01 14:38:15 https://bugs.openwrt.org/index.php?do=details&task_id=2574 Jun 01 14:39:54 nope, i don't use dnssec or have it in my dnsmasq **** ENDING LOGGING AT Tue Jun 02 02:59:57 2020