What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

3KB/s incoming "phantom" WAN traffic/broadcast (RT-AC66U) ?

sveinan

Occasional Visitor
I like to understand who is doing what through my WAN/internet traffic (equipment in my signature). Was doing a review of connections/traffic in my network. Elimination and so on. But after removing all cables from my RT-AC66U, factory default, and turning off wireless. Only leaving WAN and my PC or laptop physically connected (alternating between them). I still get a constant 3KB/s traffic indicated through Traffic Monitor:
TrafficMonitor.png

At the same point in time, no active connections indicated (have pressed 'Refresh'):
ActiveConnections.png

Was about to give up. Then tried to turn on 'Logged packets type:' to 'Both' (under Firewall / General). That gave me a continuous stream of following entries in System Log:
Code:
Apr  2 12:49:45 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50059 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:46 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50082 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:46 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50091 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:47 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2yy.1.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50163 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:47 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50182 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:48 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50202 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:48 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50210 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:48 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50215 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:48 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50240 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:49 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2yy.1.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50260 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:49 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50282 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:49 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2yy.1.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50289 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:51 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50345 PROTO=UDP <1>SPT=67 DPT=68 LEN=308
Apr  2 12:49:51 kernel: ACCEPT  <4>ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:2f:xx:xx:xx:xx:00 <1>SRC=10.2xx.0.1 DST=255.255.255.255 <1>LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=50356 PROTO=UDP <1>SPT=67 DPT=68 LEN=308

Not an expert on this. But I am guessing this indicates some type of broadcast packets, about 3 per second, from/through my Cabel Modem against my WAN port on RT-AC66U. Looks to match the 3KB/s traffic indicated.

Soo, does this look logical ? Anybody more experienced that could clue me inn to what kind of situation/traffic I am looking at ?
 
Ports 67/68 are DHCP packets. Seems odd that you would get such constant traffic over WAN. You didn't disable your firewall by any chance?

Try powering down your modem for about 10 mins to force the connection with your ISP to fully reset, then turn it back on. See if that helps.
 
Thanks for tips Merlin,

Got the same suggestion about ports 67/68 being DHCP on a private message too. Should have seen that connection from the log.

The firewall is set to 'Enable Firewall: (*) Yes'. Should be ok there. Also tried power-off 10min for both modem and router. No change, still getting the DHCP 'spam'.

Per suggestion, I tried a raw packet capture variant. The ISP I have allow 4 IPv4-internet addresses to be assigned through each modem. Connected my modem, router and laptop to a temporary switch. With laptop getting a IPv4-internet IP, like the router, I did a quick Wireshark capture on the ethernet interface. Sure enough, getting about 3 DHCP offers each second (among a lot of ICMPv6 too):
Code:
No  Time         Source                    Destination        Protocol  Length  Info
61  2.324873000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxy:zzyx  ICMPv6    86      Neighbor Solicitation for fe80::xxxz:ayzx:yzxy:zxyz from 00:19:2f:xx:xx:xx
62  2.362789000  10.2xx.0.1                255.255.255.255    DHCP      342     DHCP Offer - Transaction ID 0xzzyy
63  2.385590000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyz:xyzx  ICMPv6    86      Neighbor Solicitation for fe80::xyxx:yxzy:zyxz:yxyz from 00:19:2f:xx:xx:xx
64  2.404238000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyx:yxyz  ICMPv6    86      Neighbor Solicitation for fe80::xyxy:zxyy:xyzx:zxyz from 00:19:2f:xx:xx:xx
65  2.414575000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffzx:zyxz  ICMPv6    86      Neighbor Solicitation for fe80::yxyx:yzxy:zyxz:yzyx from 00:19:2f:xx:xx:xx
66  2.456337000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxy:yzxy  ICMPv6    86      Neighbor Solicitation for fe80::yxyz:xyyx:yzxz:xyzz from 00:19:2f:xx:xx:xx
67  2.509662000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxz:zxyz  ICMPv6    86      Neighbor Solicitation for fe80::xyzx:xxyx:xxxx:yzxz from 00:19:2f:xx:xx:xx
68  2.526233000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxy:yyxz  ICMPv6    86      Neighbor Solicitation for fe80::yzxz:yxyx:yzxy:zyxz from 00:19:2f:xx:xx:xx
69  2.537293000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyz:zyxy  ICMPv6    86      Neighbor Solicitation for fe80::xyyx:yzxz:xyzz:yzxx from 00:19:2f:xx:xx:xx
70  2.564851000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffzy:xyzx  ICMPv6    86      Neighbor Solicitation for fe80::xyzx:yzyx:zyzy:xyzy from 00:19:2f:xx:xx:xx
71  2.578036000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxy:zyzx  ICMPv6    86      Neighbor Solicitation for fe80::zzxy:zxyy:zxzz:xyzx from 00:19:2f:xx:xx:xx
72  2.584119000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffzy:zyzx  ICMPv6    86      Neighbor Solicitation for fe80::xyzx:yzxy:xyxx:yxzy from 00:19:2f:xx:xx:xx
73  2.638570000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyz:yzxy  ICMPv6    86      Neighbor Solicitation for fe80::zxyz:yxzy:zyxy:zyzx from 00:19:2f:xx:xx:xx
74  2.644412000  fe80::219:2fxx:xxxx:xxxx  ff02::1            ICMPv6    86      Router Advertisement from 00:19:2f:xx:xx:xx
75  2.666176000  10.2xx.0.1                255.255.255.255    DHCP      342     DHCP Offer - Transaction ID 0xyyzz
76  2.687046000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffzz:xyxy  ICMPv6    86      Neighbor Solicitation for fe80::xyxx:yxzy:zyxz:yxyz from 00:19:2f:xx:xx:xx
77  2.703280000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyz:yzyz  ICMPv6    86      Neighbor Solicitation for fe80::xzyx:yxyz:xyzy:yzxz from 00:19:2f:xx:xx:xx
78  2.709855000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyy:yzzx  ICMPv6    86      Neighbor Solicitation for fe80::yxzy:zyxy:zyzx:yzyx from 00:19:2f:xx:xx:xx
79  2.794792000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxy:zyxz  ICMPv6    86      Neighbor Solicitation for fe80::xyzx:yyxy:zxzx:zxyy from 00:19:2f:xx:xx:xx
80  2.850634000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyz:zxyx  ICMPv6    86      Neighbor Solicitation for fe80::yxxy:xzyz:yxzy:yzxy from 00:19:2f:xx:xx:xx
81  2.873960000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffzz:xyzz  ICMPv6    86      Neighbor Solicitation for fe80::yzyx:yzyz:xyzx:yxzy from 00:19:2f:xx:xx:xx
82  2.894368000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxy:zzxy  ICMPv6    86      Neighbor Solicitation for fe80::yzzy:zxxx:zaxz:xyzz from 00:19:2f:xx:xx:xx
83  2.958207000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxx:xyzx  ICMPv6    86      Neighbor Solicitation for fe80::yzyx:yzyz:xyyx:zyzy from 00:19:2f:xx:xx:xx
84  3.050387000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffyy:xyzx  ICMPv6    86      Neighbor Solicitation for fe80::xzzx:yzxx:xyyy:zxzz from 00:19:2f:xx:xx:xx
85  3.150422000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffzx:yzxy  ICMPv6    86      Neighbor Solicitation for fe80::yxxy:xzyz:yxxy:xyxx from 00:19:2f:xx:xx:xx
86  3.202901000  10.2xx.0.1                255.255.255.255    DHCP      342     DHCP Offer - Transaction ID 0xzyyz
87  3.212525000  fe80::219:2fxx:xxxx:xxxx  ff02::1:ffxz:zxyx  ICMPv6    86      Neighbor Solicitation for fe80::zxyz:xyzx:yzzx:yzxy from 00:19:2f:xx:xx:xx

Looking into the DHCP offer packet data, all are from identical DHCP server IP (same one that assigned IP to my laptop). Not really sure if I am going to take it any further. Getting ISP's to change behavior, if this is 'bad' practice, usually not that easy :rolleyes:

The small annoyance left is traffic visualized as inbound. Would have though that DHCP offer traffic on WAN should be blocked and not count. At least when router is in OneIP-NAT-localsubnet mode.

Not a big problem. At least I now what this traffic represents. Thanks for the help (and especially for Asuswrt-Merlin) :)

PS: Still open to suggestions though. If I should try more stuff.
 
Are you with Comcast? If yes, there is a known issue where Comcast floods their customer's routers with neighbour solicitation packets when using IPv6. People reported multiple megabytes per day of such traffic. That traffic should normally be terminated at the modem and never reach the router.

Edit: Nevermind, just saw you were from Norway.
 
Well. I wouldn't put it past our ISP's to do strange stuff™ too :o Have had our fair share of routing problems, inside their control. Might get the energy to try a trouble-ticket to ask about this traffic. See if I get lucky for once :cool:

PS: For reference. My ISP is Get.no / Norway.
 
Same issue here, also using Get.no. I'm currently logging all iptables actions and this just floods my log. It's very annoying!

Did you ever contact get? Which cable modem are you using? I'm using Cisco EPC3010. I've tried to login to the modem and see if there is anything to configure, but I don't have the login to do so. Seems like it's set in the firmware to something else than the default Cisco password by the ISP.
 
@skogsmaskin

Sorry m8. Never got around to contacting Get.no. Not logging like you, so have just accepted the 3KB/s traffic, for now :o

We have the same Cisco EPC3010 cable modem. Have also been on the status/login page of the modem. No luck though.

Guess the easiest way is to find some filter option on your logging, if possible. If you contact Get.no and need 'one more sample/customer', just tell me. Would be happy to help :)
 
Similar threads
Thread starter Title Forum Replies Date
A How to allow incoming WAN connections for WireGuard clients? Asuswrt-Merlin 5

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Back
Top