On 08/21/2016 09:01 PM, sdm wrote:

# ifconfig -a

enp7s0 Link encap:Ethernet HWaddr 8C:89:A5:6F:52:B3 inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::8e89:a5ff:fe6f:52b3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14158669 errors:0 dropped:0 overruns:0 frame:0 TX packets:9738576 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16524867515 (15759.3 Mb) TX bytes:2457738636 (2343.8 Mb)

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 MTU:65536 Metric:1 RX packets:1479602 errors:0 dropped:0 overruns:0 frame:0 TX packets:1479602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:1079782831 (1029.7 Mb) TX bytes:1079782831 (1029.7 Mb)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.8.50 P-t-P:10.8.8.49 Mask:255.255.255.255 inet6 addr: fe80::5363:69c5:d73a:2b47/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3588841 errors:0 dropped:0 overruns:0 frame:0 TX packets:2188042 errors:0 dropped:81 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4406775220 (4202.6 Mb) TX bytes:1915

I may have spoken too soon as I'm not sure if turning IPv6 off in YaST2 Networking solved the problem or not. I think I still saw some IPv4: martian source errors when watching journalctl, but it may have slowed down. I will be keeping an eye on it, but any other suggestions appreciated. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Aug 22, 2016 at 7:32 AM, sdm wrote:

On 08/21/2016 09:01 PM, sdm wrote:

...

# ifconfig -a

enp7s0 Link encap:Ethernet HWaddr 8C:89:A5:6F:52:B3 inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::8e89:a5ff:fe6f:52b3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14158669 errors:0 dropped:0 overruns:0 frame:0 TX packets:9738576 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16524867515 (15759.3 Mb) TX bytes:2457738636 (2343.8 Mb)

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 MTU:65536 Metric:1 RX packets:1479602 errors:0 dropped:0 overruns:0 frame:0 TX packets:1479602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:1079782831 (1029.7 Mb) TX bytes:1079782831 (1029.7 Mb)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.8.50 P-t-P:10.8.8.49 Mask:255.255.255.255 inet6 addr: fe80::5363:69c5:d73a:2b47/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3588841 errors:0 dropped:0 overruns:0 frame:0 TX packets:2188042 errors:0 dropped:81 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4406775220 (4202.6 Mb) TX bytes:1915

I may have spoken too soon as I'm not sure if turning IPv6 off in YaST2 Networking solved the problem or not. I think I still saw some IPv4: martian source errors when watching journalctl, but it may have slowed down. I will be keeping an eye on it, but any other suggestions appreciated.

This packet comes from device with MAC b8:a3:86:57:78:f5; OUI appears to belong to D-Link. are you aware of any device with this MAC and type in your network? You cannot really do anything about this messages from openSUSE site - it is just messenger. Some device sends ARP request over LAN segment your interface is connected to and this device's IP does not belong to your interface's subnet. It may or may not indicate a problem. You need to find out what is this device first and check its configuration (if possible - i.e. if this device is under your control). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/22/2016 02:16 AM, Andrei Borzenkov wrote:

On Mon, Aug 22, 2016 at 7:32 AM, sdm wrote:

...

On 08/21/2016 09:01 PM, sdm wrote:

...

# ifconfig -a

enp7s0 Link encap:Ethernet HWaddr 8C:89:A5:6F:52:B3 inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::8e89:a5ff:fe6f:52b3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14158669 errors:0 dropped:0 overruns:0 frame:0 TX packets:9738576 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16524867515 (15759.3 Mb) TX bytes:2457738636 (2343.8 Mb)

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 MTU:65536 Metric:1 RX packets:1479602 errors:0 dropped:0 overruns:0 frame:0 TX packets:1479602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:1079782831 (1029.7 Mb) TX bytes:1079782831 (1029.7 Mb)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.8.50 P-t-P:10.8.8.49 Mask:255.255.255.255 inet6 addr: fe80::5363:69c5:d73a:2b47/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3588841 errors:0 dropped:0 overruns:0 frame:0 TX packets:2188042 errors:0 dropped:81 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4406775220 (4202.6 Mb) TX bytes:1915

I may have spoken too soon as I'm not sure if turning IPv6 off in YaST2 Networking solved the problem or not. I think I still saw some IPv4: martian source errors when watching journalctl, but it may have slowed down. I will be keeping an eye on it, but any other suggestions appreciated.

This packet comes from device with MAC b8:a3:86:57:78:f5; OUI appears to belong to D-Link. are you aware of any device with this MAC and type in your network?

You cannot really do anything about this messages from openSUSE site - it is just messenger. Some device sends ARP request over LAN segment your interface is connected to and this device's IP does not belong to your interface's subnet. It may or may not indicate a problem. You need to find out what is this device first and check its configuration (if possible - i.e. if this device is under your control).

The D-Link is my client bridge router running DD-WRT. I only get these errors when the VPN connection is active, so the client bridge router could be the culprit. The only way I can think of right now to find out, is to try connecting a TW box to the main router, not to the CBR, run OpenVPN and connect, and see if the martian source errors appear. Then run the same box connected to the CBR and see if they appear in the journal. I have also tried WDS, and get the same errors. Client Bridge mode is sort of a "hack" in how it's implemented from what I know, so for whatever reason the problem only crops up when the VPN is connected. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/24/2016 05:12 AM, Ruediger Meier wrote:

On Wednesday 24 August 2016, sdm wrote:

...

...

On Mon, Aug 22, 2016 at 7:32 AM, sdm wrote:

...

On 08/21/2016 09:01 PM, sdm wrote:

...

# ifconfig -a

enp7s0 Link encap:Ethernet HWaddr 8C:89:A5:6F:52:B3 inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::8e89:a5ff:fe6f:52b3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14158669 errors:0 dropped:0 overruns:0 frame:0 TX packets:9738576 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16524867515 (15759.3 Mb) TX bytes:2457738636 (2343.8 Mb)

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 MTU:65536 Metric:1 RX packets:1479602 errors:0 dropped:0 overruns:0 frame:0 TX packets:1479602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:1079782831 (1029.7 Mb) TX bytes:1079782831 (1029.7 Mb)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.8.50 P-t-P:10.8.8.49 Mask:255.255.255.255 inet6 addr: fe80::5363:69c5:d73a:2b47/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3588841 errors:0 dropped:0 overruns:0 frame:0 TX packets:2188042 errors:0 dropped:81 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4406775220 (4202.6 Mb) TX bytes:1915 I may have spoken too soon as I'm not sure if turning IPv6 off in YaST2 Networking solved the problem or not. I think I still saw some IPv4: martian source errors when watching journalctl, but it may have slowed down. I will be keeping an eye on it, but any other suggestions appreciated. This packet comes from device with MAC b8:a3:86:57:78:f5; OUI appears to belong to D-Link. are you aware of any device with this MAC and type in your network?

You cannot really do anything about this messages from openSUSE site - it is just messenger. Some device sends ARP request over LAN segment your interface is connected to and this device's IP does not belong to your interface's subnet. It may or may not indicate a problem. You need to find out what is this device first and check its configuration (if possible - i.e. if this device is under your control). The D-Link is my client bridge router running DD-WRT. I only get

On 08/22/2016 02:16 AM, Andrei Borzenkov wrote: these errors when the VPN connection is active, so the client bridge router could be the culprit. "martian source" means that an IP packet is comming from an IP address (1.1.1.1) where you don't have a route defined for. So your machine is not able to answer.

If you try "ping 1.1.1.1" then you should get: connect: Network is unreachable

And in your case if somebody would ping you _from_ 1.1.1.1 you would log a martian source.

Maybe enabling the VPN removes the route to 1.1.1.1 (or the default route!*). What routes do you have with and without VPN? $ ip -4 route show

You could also find out what kind of traffic is comming from 1.1.1.1 $ tcpdump host 1.1.1.1

(*) Note, in case you have a default route like "default via 192.168.1.1 dev eth0" you should never get this "martian source" message because your machine would send the answer packets via router. But this doesn't mean that your router is really able to forward the answer back to the right device. So in any case with or without VPN, most probably your D-Link device is misconfigured and should not send packages into your Network using 1.1.1.1.

...

The only way I can think of right now to find out, is to try connecting a TW box to the main router, not to the CBR, run OpenVPN and connect, and see if the martian source errors appear. Then run the same box connected to the CBR and see if they appear in the journal. I have also tried WDS, and get the same errors. Client Bridge mode is sort of a "hack" in how it's implemented from what I know, so for whatever reason the problem only crops up when the VPN is connected.

I ended up resetting and flashing both routers with the latest DD-WRT and that appears to have solved the problem with the martian source error messages. Thanks for everyone's help, I didn't understand those were coming from my router until you guys pointed that out. The routers are configured exactly the same as they were before (the client bridge router and primary AP) so I have no idea why this was happening. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org