What's new

kernel: br0: received packet on eth1 with own address as source address

  • 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!

The iptables commands shown above just give me an error message.
I get the same error you do.....move the ! before -i....

@coldwizard - the N66 uses a different release of iptables....I think that putting the 'not' qualifier is supposed to be before the interface tag, but the older MIPS iptables version may accept it the other way.

But, I'll be surprised if this stops the logging....I think this was targeted more towards the specific case on the AC87. I think in your case the source address is not the router address. But I've been proven mistaken before :)
 
Last edited:
I just did a copy /paste of the iptables command from your post to my command line, and it worked just fine. Thinking ....
Moving the "!" to in front of the "-i" eliminates the error message. Not that I have any idea what this command actually does. :confused:
Code:
iptables -I INPUT 3 ! -i lo -s `nvram get lan_ipaddr` -j DROP
 
Popping in here from the John fork thread.

The iptables commands shown above just give me an error message.

Code:
# iptables -I INPUT 3 -i ! lo -s `nvram get lan_ipaddr` -j DROP
Bad argument `lo'
Try `iptables -h' or 'iptables --help' for more information.
I'm a complete ignoramus when it comes to the iptables command, but it looks like maybe the "!" is in the wrong place?

I get the same error you do.....move the ! before -i....

@coldwizard - the N66 uses a different release of iptables....I think that putting the 'not' qualifier is supposed to be before the interface tag, but the older MIPS iptables version may accept it.

But, I'll be surprised if this stops the logging....I think this was targeted more towards the specific case on the AC87. I think in your case the source address is not the router address. But I've been proven mistaken before :)

Thank you John!
My iptables accepts the ! in either place

So this script should be

Code:
#!/bin/sh
set -v
# set -x
# kill packets from my own addresses
iptables -I INPUT 3 ! -i lo -s `nvram get lan_ipaddr` -j DROP
iptables -I INPUT 3 ! -i lo -s `nvram get wan_ipaddr` -j DROP
#
 
Last edited:
Moving the "!" to in front of the "-i" eliminates the error message. Not that I have any idea what this command actually does. :confused:
Code:
iptables -I INPUT 3 ! -i lo -s `nvram get lan_ipaddr` -j DROP

OK, now for a quick lesson on iptables (taking this command apart).

The "INPUT" means to process packets coming to the router ( not FORWARD thru the router, or OUTPUT from the router)

The split -I xx 3 means to Insert this as rule #3.

The ! -i lo means to not include traffic from loopback interface (the one where the router talks to itself)

The -s `nvram get lan_ipaddr` says to execute the nvram command to get the lan ip address and check the packets for that source address.

The -j DROP says to drop (or ignore) this packet and not allow it into the router.

So the command says "If any packet comes in on any interface except "lo" with me as the source, drop it as I am not interested in processing it"
 
Last edited:
Thanks for the explanation. How do you determine that the rule number should be 3?
 
Another question, if you don't mind. When I do iptables -S, the 2 new rules display as

-A INPUT -s 76.126.27.xxx/32 ! -i lo -j DROP
-A INPUT -s 192.168.1.1/32 ! -i lo -j DROP


I am wondering about the /32. My LAN is the default 192.168.1.xxx. Isn't that a /24?

Finally, the rules seem to have reduced, but not eliminated, the "own address" warning. Do I need to add something for IPv6?
 
Another question, if you don't mind. When I do iptables -S, the 2 new rules display as

-A INPUT -s 76.126.27.xxx/32 ! -i lo -j DROP
-A INPUT -s 192.168.1.1/32 ! -i lo -j DROP


I am wondering about the /32. My LAN is the default 192.168.1.xxx. Isn't that a /24?

Finally, the rules seem to have reduced, but not eliminated, the "own address" warning. Do I need to add something for IPv6?
That's why I guessed that it wouldn't address your problem....your basically dropping packets going to the router that originate from the router....a case specific to the 87U. I think your 'reduction' is luck of the draw. If you expand the netmask, you'll lock yourself out of the router.

If you want a quiet syslog, you may be able to use an option in the next V15 release that gives you control over the syslog logging level (but it may also quiet other syslog entries in addition to this one).
 
Another question, if you don't mind. When I do iptables -S, the 2 new rules display as

-A INPUT -s 76.126.27.xxx/32 ! -i lo -j DROP
-A INPUT -s 192.168.1.1/32 ! -i lo -j DROP


I am wondering about the /32. My LAN is the default 192.168.1.xxx. Isn't that a /24?

Finally, the rules seem to have reduced, but not eliminated, the "own address" warning. Do I need to add something for IPv6?

having had the new rules inplace for a day now, can you give me first few lines the output of the command
iptables -nvL INPUT --lin

Also the output of command
ifconfig

Change the public IP to xxx where ever it shows.

I am little busy today, will answer your questions when I can.

edit: Also for any Ipv6 addresses make the last 1 to 7 fields be xxx just need the first one as they are mostly public.
 
Last edited:
Another question, if you don't mind. When I do iptables -S, the 2 new rules display as

-A INPUT -s 76.126.27.xxx/32 ! -i lo -j DROP
-A INPUT -s 192.168.1.1/32 ! -i lo -j DROP


I am wondering about the /32. My LAN is the default 192.168.1.xxx. Isn't that a /24?

Finally, the rules seem to have reduced, but not eliminated, the "own address" warning. Do I need to add something for IPv6?
First a little story...
A child learns to pick up all his toys off the floor and put then away neatly.

One day he is playing on the table, and his mother asks him to put his toys away. He pauses, then knocks all the toys off the table, and
before mother can say anything starts to pick them up ...

Was he being bad? No he had just converted the problem of cleaning up the toys from the table to one he knew how to do!

So when we asked iptables to do a rule with just one ip address, it did not know how to do that directly and converted the request to one it knew how to solve. It already knows how to handle a network by matching just the first few bits of the address. For you, the /24 says the first 24 bits are all that must be equal for it to be on your network. Now there are 32 bits in an Ipv4 address, so if you make the network be /32 it will check all 32 bits and get just one IP address. Maybe a little convoluted, but it works. For Ipv6 there are 128 bits in the address, so it would have used /128 to select only one Ipv6 address. Now if you were to change it to a /24 that would be all the addresses in your network, and you would lock yourself out until a reboot (see below)

I don't like "seem to have reduced", I want to know exactly which is why to output of the iptables command. The -nvL part says to List the rules in verbose mode (with usage stats) and numerical address (don't pretty up to output, I prefer exact numbers). The --lin is short for option to get the line numbers of the rules and yes it takes two dashes.

I usually do that type of listing, because the shortest way to delete a rule uses the line/rule number. For example "iptables -D INPUT 3" would delete rule number 3, but be careful as the rules renumber after each command so in this example rule #4 would become rule #3 right after the deletion.

I asked for the ifconfig output because I wanted to check that we had all the Ipv4 addresses covered before tackling the Ipv6 question.

As to John's concern about locking yourself out of the router, that is why we are doing this in firewall-start.sh (note the .sh ending) so that should we make a mistake, a reboot of the router will not execute the .sh file, and we are back up.
 
Last edited:
having had the new rules inplace for a day now, can you give me first few lines the output of the command
iptables -nvL INPUT --lin

Also the output of command
ifconfig
Here you go. I'm still getting the syslog warnings. I think at some point this becomes more trouble than it's worth (for you, I mean)...
Code:
# iptables -nvL INPUT --lin
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target  prot opt in  out  source  destination
1  7  3828 DROP  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp dpt:9999
2  3997  240K DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state INVALID
3  0  0 DROP  all  --  !lo  *  76.126.27.xxx 0.0.0.0/0
4  509 66718 DROP  all  --  !lo  *  192.168.1.1  0.0.0.0/0
5  551K  71M ACCEPT  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
6  60 20326 ACCEPT  all  --  lo  *  0.0.0.0/0  0.0.0.0/0  state NEW
7  628K  84M ACCEPT  all  --  br0  *  0.0.0.0/0  0.0.0.0/0  state NEW
8  38827  13M ACCEPT  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp spt:67 dpt:68
9  5776  410K DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0

# ifconfig
br0  Link encap:Ethernet  HWaddr 08:62:66:97:82:00
  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: 2601:blah:blah:blah/64 Scope:Global
  inet6 addr: fe80::blah:blah:blah/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2849917 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1816543 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:307240011 (293.0 MiB)  TX bytes:522897527 (498.6 MiB)

eth0  Link encap:Ethernet  HWaddr 08:62:66:97:82:00
  inet addr:76.126.27.xxx Bcast:76.126.31.255  Mask:255.255.240.0
  inet6 addr: 2001:blah:blah:blah/128 Scope:Global
  inet6 addr: fe80::blah:blah:blah/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:27982532 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14891119 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:294084027 (280.4 MiB)  TX bytes:400415795 (381.8 MiB)
  Interrupt:179 Base address:0x4000

eth1  Link encap:Ethernet  HWaddr 08:62:66:97:82:00
  inet6 addr: fe80::blah:blah:blah/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2894285 errors:0 dropped:0 overruns:0 frame:1537686
  TX packets:6645458 errors:16680 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:349562001 (333.3 MiB)  TX bytes:2287751353 (2.1 GiB)
  Interrupt:163

eth2  Link encap:Ethernet  HWaddr 08:62:66:97:82:04
  inet6 addr: fe80::blah:blah:blah/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:134390 errors:0 dropped:0 overruns:0 frame:1239
  TX packets:1429546 errors:931 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:14144233 (13.4 MiB)  TX bytes:256529401 (244.6 MiB)
  Interrupt:169

lo  Link encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
  RX packets:126987 errors:0 dropped:0 overruns:0 frame:0
  TX packets:126987 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:25461548 (24.2 MiB)  TX bytes:25461548 (24.2 MiB)

vlan1  Link encap:Ethernet  HWaddr 08:62:66:97:82:00
  inet6 addr: fe80::blah:blah:blah/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2797649 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1901540 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:402009656 (383.3 MiB)  TX bytes:509102090 (485.5 MiB)

wl0.1  Link encap:Ethernet  HWaddr 08:62:66:97:82:01
  inet6 addr: fe80::blah:blah:blah/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:1537686
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
That's why I guessed that it wouldn't address your problem....your basically dropping packets going to the router that originate from the router....a case specific to the 87U. I think your 'reduction' is luck of the draw. If you expand the netmask, you'll lock yourself out of the router.
I understand. It was worth a try.
If you want a quiet syslog, you may be able to use an option in the next V15 release that gives you control over the syslog logging level (but it may also quiet other syslog entries in addition to this one).
Log level control sounds like a good idea, as long as messages are given consistent and correct levels. Or I could stop looking at syslog so often.
 
HaHa, to be honest I was surprised the iptables rule would work for the lan side since the packets are assembled in the lan bridge br0 before entering the iptables configured netfilter rules. Personally I haven't seen any messages for a while on my N66 (used to!), possibly a windows 8/10 laptop not currently here. I always used to get the messages referring to eth1, one of the wireless interfaces, suspect something due to roaming with another access point in the house I believe.
 
I used to get this crap all the time on my RT-AC66U, usually accompanied by horrendous network slowdown only resolved by restart_wireless or a reboot, before I replaced the power supply. It stopped completely after that.
 
Here you go. I'm still getting the syslog warnings. I think at some point this becomes more trouble than it's worth (for you, I mean)...

Until we conclude not possible, I think we should pursue this research.
If it works, I think John will realize the consequences implied.

Anyway, from the output it looks like we suppressed 509 messages with rule #4.

Could you manually edit the following script to put your real Ipv6 addresses shown by the ifconfig command, and try it. Be careful to put in the duplicate Ipv6 fe80 addresses only once.

If it works I will build a script to do it automatically so not specific to your Ipv6 addresses.

Code:
#!/bin/sh
set -v
# first scope:global addresses
ip6tables -I INPUT 1 ! -i lo -s 2601:abcd::1 -j DROP
ip6tables -I INPUT 1 ! -i lo -s 2601:abcd::2 -j DROP
#
# now the scope:link addresses (unique  ones)
ip6tables -I INPUT 1 ! -i lo -s fe80:abcd::1 -j DROP
ip6tables -I INPUT 1 ! -i lo -s fe80:abcd::2 -j DROP
ip6tables -I INPUT 1 ! -i lo -s fe80:abcd::3 -j DROP
#
 
Thanks for the explanation. How do you determine that the rule number should be 3?

Normally in a Ipv4 chain the first two rules are:
one ending with "state INVALID" which drops packets that are just plain wrong for some reason, could be bad length, bad header, or unexpected sequence.

The other ending with "state RELATED,ESTABLISHED" to accept packets continuing an existing connection. It is there for performance reasons to stop processing the rest of the rules.

The exception to this is when you want to break an existing connection like for parental controls in the FORWARD chain.

I see you have a rule #1 for udp port 9999 (security problem a while back). That rule could be moved to #3 so it is later than the rule processing an existing connection.

You will notice that for Ipv6 script I put the rules at #1 since I don't know what to expect there. I would expect a similar "state RELATED,ESTABLISHED" rule, but another other may be a "rt type:0" to avoid source routed packets, which are used for debugging routers and should not be coming over the Internet.

After some time, please do a
ip6tables -nvL INPUT --lin
to get the stats and see the first few rules after what we added.
 
Could you manually edit the following script to put your real Ipv6 addresses shown by the ifconfig command, and try it.
Done. Now we wait.
 
I see you have a rule #1 for udp port 9999 (security problem a while back). That rule could be moved to #3 so it is later than the rule processing an existing connection.
Yeah, now that I'm poking around firewall-start, I'm wondering whether I still need that or whether that hole has been closed elsewhere. I also have this old thing I wonder whether is still needed:
Code:
# Closes off the guest network from the private LAN
ebtables -t broute -A BROUTING -p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
After some time, please do a
ip6tables -nvL INPUT --lin
to get the stats and see the first few rules after what we added.
Getting some results already from one rule.
Code:
# ip6tables -nvL INPUT --lin
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target  prot opt in  out  source  destination
1  0  0 DROP  all  !lo  *  fe80::blah:blah:blah/128  ::/0
2  0  0 DROP  all  !lo  *  fe80::blah:blah:blah/128  ::/0
3  124 14880 DROP  all  !lo  *  fe80::blah:blah:blah/128  ::/0
4  0  0 DROP  all  !lo  *  2001:blah:blah:blah/128  ::/0
5  0  0 DROP  all  !lo  *  2601:blah:blah:blah/128  ::/0
 
In case anyone's interested, you can view the code that generates this message here: https://github.com/RMerl/asuswrt-me...x.4708/linux/linux-2.6.36/net/bridge/br_fdb.c

Personally I don't regard this as a problem that needs fixing*. IMHO it's just an information message from the kernel telling us the bridge database is being updated. I'd be inclined to just let the kernel do its job and age-out the stale entry rather come up with some sort of convoluted iptables/ebtables fudge just for cosmetic reasons. But that's just me, I don't get OCD about the syslog. :)

2 cents

* I'm referring to @RocketJSquirrel message not the OP's VLAN error.
 
Yeah, now that I'm poking around firewall-start, I'm wondering whether I still need that or whether that hole has been closed elsewhere. I also have this old thing I wonder whether is still needed:
Code:
# Closes off the guest network from the private LAN
ebtables -t broute -A BROUTING -p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

If they are not bothering you, and you do not miss the feature on port 9999, I would leave them in just relocated.

Getting some results already from one rule.
Code:
# ip6tables -nvL INPUT --lin
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target  prot opt in  out  source  destination
1  0  0 DROP  all  !lo  *  fe80::blah:blah:blah/128  ::/0
2  0  0 DROP  all  !lo  *  fe80::blah:blah:blah/128  ::/0
3  124 14880 DROP  all  !lo  *  fe80::blah:blah:blah/128  ::/0
4  0  0 DROP  all  !lo  *  2001:blah:blah:blah/128  ::/0
5  0  0 DROP  all  !lo  *  2601:blah:blah:blah/128  ::/0

I expect the fe80 on rule 3 is from the br0 interface.

Also are you getting the messages any more?
If not, I will generate a script to make the rules.
Need to see next 3/4 rules to decide if insert point should be at 2,3 or 4 rule.
 

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!
Top