Alon Bar-Lev <[email protected]> writes: > On 6 November 2015 at 17:28, lee <[email protected]> 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 <[email protected]> # 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.
