Re: [gentoo-user] pppoe questions

[lee]

Alon Bar-Lev <alonbl@g.o> writes:

> On 6 November 2015 at 17:28, lee <lee@××××××××.de> wrote:
>> Hi,
>>
>> finally I got set up pppoe, which turned out to be surprisingly easy.
>> It's working fine, though I'm getting a warning when the pppoe interface
>> is brought up:
>>
>>
>> heimdali init.d # service net.ppp0 start
>>  * Bringing up interface ppp0
>>  *   Starting pppd in ppp0 ...                               [ ok ]
>>  *   Backgrounding ...
>>  * WARNING: net.ppp0 has started, but is inactive
>> heimdali init.d #
>>
>>
>> Why is this warning showing, and what can I do about it?
>>
>
> this warning can be safely ignored, all it tells you is that the
> service will be fully up when connection will be established.
> the same state is for ethernet until the ifplugd detects connection to network.
>
>> How does pppoe work together with shorewall and bind?
>>
>> When I stop the net.ppp0 service, shorewall is automatically stopped as
>> well.  When I start net.ppp0, shorewall is not started automatically.
>>
>> I would like to automatically have net.ppp0 first started and then
>> shorewall.
>
> usually the firewall service should be started before all interfaces
> (except lo).
> add the following to /etc/conf.d/net.ppp0:
> ---
> rc_net_ppp0_need="firewall net.enp2s0"
> ---

Thanks!  I copied net.lo to net.ppp0 and put it at the top so it now
goes:


#!/sbin/runscript
# Copyright (c) 2007-2009 Roy Marples <roy@×××××××.name>
# Released under the 2-clause BSD license.

MODULESDIR="/lib/netifrc/net"
MODULESLIST="${RC_SVCDIR}/nettree"
_config_vars="config routes"

rc_net_ppp0_need="firewall net.enp2s0"


I'm not sure if that's right --- I guess I shouldn't make a copy?

> this will make sure that the ppp0 interface is started after both
> firewall and enp2s0.
>
> I also have the following in /etc/rc.conf to avoid stopping services
> while network is down:
> ---
> rc_hotplug="!net.enp2s0 !net.ppp*"
> ---

The comment in /etc/rc.conf says no hotplugging is done by default.
IIUC, you are hotplugging 'net.enp2s0' and 'net.ppp*'?  So allowing to
hotplug them would kinda make them independent of other services, or
other services independent from them?

>> When net.ppp0 is stopped and restarted, I also must restart the name
>> server (bind) :(  Otherwise it is unable to resolve anything.
>>
>> Can this somehow be avoided?  If not, can this be done automatically?
>
> this is strange... why bind must be restarted?
> I use dnsmasq and it survive network down without any issue.
> but if you must, add the following to /etc/conf.d/net.ppp0:
> ---
> postup() {
>         # whatever required after interface is up
>         return 0
> }
> ---

Ah, yes, good idea :)

Fortunately, everything survives when the link goes down and comes back
up, so this would only be an issue when I manually stop/start the
net.ppp0 service.  I can live with that.


>> The log files show martian sources from a bridge device which is used
>> for the networking of a container:
>>
>>
>> [1734776.722127] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
>> [1734776.722132] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
>>
>>
>> The enp2s0 interface is used for pppoe, 192.168.1.1 is the IP of the
>> bridge.  The bridge does not have a physical network interface assigned
>> to it.
>>
>> The routefilter option is enabled on all interfaces.  Why would there be
>> such a broadcast originating from the bridge, and how can I prevent it?
>
> not sure what you describe here, but maybe you would like to disable
> spanning tree, add the following to disable spanning tree to
> /etc/conf.d/br0.conf (provided br0 is the name of the bridge).
> ---
> stp_state_br0=0
> ---

STP is disabled when the bridge is brought up with


config_br_dmz="192.168.1.1 netmask 255.255.255.0 brd 192.168.1.255"
brctl_br_dmz="setfd 0 sethello 10 stp off"


... in /etc/conf.d/net.


heimdali init.d # brctl show
bridge name     bridge id               STP enabled     interfaces
br_dmz          8000.fe150e283be5       no              vethJRMBC7
heimdali init.d # 


[1829515.036283] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829515.036296] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829575.021793] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829575.021806] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829634.958151] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829634.958164] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829694.919256] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829694.919269] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829754.880046] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829754.880059] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829814.849173] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829814.849186] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829874.802373] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829874.802386] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829934.762920] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829934.762933] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1829994.724216] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1829994.724230] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..
[1830054.689127] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0
[1830054.689132] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00        ........k..D..


It looks as if there is a broadcast on the bridge interface every 60
seconds.  This could come from the bridge itself, or from something
running inside the container.  Once I have more containers, there might
be more broadcasts and thus more martian sources.

Can I run some network spying tool inside the container to find out
where the broadcasts are coming from?

With 'tcpdump -e -i eth0 ether broadcast and ether multicast', I'm not
getting anything so far, neither on the bridge interface itself from the
host, nor on the virtual eth0 from within the container.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.