| 1 |
On 6 November 2015 at 17:28, lee <lee@××××××××.de> wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> finally I got set up pppoe, which turned out to be surprisingly easy. |
| 5 |
> It's working fine, though I'm getting a warning when the pppoe interface |
| 6 |
> is brought up: |
| 7 |
> |
| 8 |
> |
| 9 |
> heimdali init.d # service net.ppp0 start |
| 10 |
> * Bringing up interface ppp0 |
| 11 |
> * Starting pppd in ppp0 ... [ ok ] |
| 12 |
> * Backgrounding ... |
| 13 |
> * WARNING: net.ppp0 has started, but is inactive |
| 14 |
> heimdali init.d # |
| 15 |
> |
| 16 |
> |
| 17 |
> Why is this warning showing, and what can I do about it? |
| 18 |
> |
| 19 |
|
| 20 |
this warning can be safely ignored, all it tells you is that the |
| 21 |
service will be fully up when connection will be established. |
| 22 |
the same state is for ethernet until the ifplugd detects connection to network. |
| 23 |
|
| 24 |
> How does pppoe work together with shorewall and bind? |
| 25 |
> |
| 26 |
> When I stop the net.ppp0 service, shorewall is automatically stopped as |
| 27 |
> well. When I start net.ppp0, shorewall is not started automatically. |
| 28 |
> |
| 29 |
> I would like to automatically have net.ppp0 first started and then |
| 30 |
> shorewall. |
| 31 |
|
| 32 |
usually the firewall service should be started before all interfaces |
| 33 |
(except lo). |
| 34 |
add the following to /etc/conf.d/net.ppp0: |
| 35 |
--- |
| 36 |
rc_net_ppp0_need="firewall net.enp2s0" |
| 37 |
--- |
| 38 |
|
| 39 |
this will make sure that the ppp0 interface is started after both |
| 40 |
firewall and enp2s0. |
| 41 |
|
| 42 |
I also have the following in /etc/rc.conf to avoid stopping services |
| 43 |
while network is down: |
| 44 |
--- |
| 45 |
rc_hotplug="!net.enp2s0 !net.ppp*" |
| 46 |
--- |
| 47 |
|
| 48 |
> When net.ppp0 is stopped and restarted, I also must restart the name |
| 49 |
> server (bind) :( Otherwise it is unable to resolve anything. |
| 50 |
> |
| 51 |
> Can this somehow be avoided? If not, can this be done automatically? |
| 52 |
|
| 53 |
this is strange... why bind must be restarted? |
| 54 |
I use dnsmasq and it survive network down without any issue. |
| 55 |
but if you must, add the following to /etc/conf.d/net.ppp0: |
| 56 |
--- |
| 57 |
postup() { |
| 58 |
# whatever required after interface is up |
| 59 |
return 0 |
| 60 |
} |
| 61 |
--- |
| 62 |
|
| 63 |
> |
| 64 |
> The log files show martian sources from a bridge device which is used |
| 65 |
> for the networking of a container: |
| 66 |
> |
| 67 |
> |
| 68 |
> [1734776.722127] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev enp2s0 |
| 69 |
> [1734776.722132] ll header: 00000000: ff ff ff ff ff ff 00 0b 6b 81 c9 44 08 00 ........k..D.. |
| 70 |
> |
| 71 |
> |
| 72 |
> The enp2s0 interface is used for pppoe, 192.168.1.1 is the IP of the |
| 73 |
> bridge. The bridge does not have a physical network interface assigned |
| 74 |
> to it. |
| 75 |
> |
| 76 |
> The routefilter option is enabled on all interfaces. Why would there be |
| 77 |
> such a broadcast originating from the bridge, and how can I prevent it? |
| 78 |
|
| 79 |
not sure what you describe here, but maybe you would like to disable |
| 80 |
spanning tree, add the following to disable spanning tree to |
| 81 |
/etc/conf.d/br0.conf (provided br0 is the name of the bridge). |
| 82 |
--- |
| 83 |
stp_state_br0=0 |
| 84 |
--- |
| 85 |
|
| 86 |
> |
| 87 |
> -- |
| 88 |
> Again we must be afraid of speaking of daemons for fear that daemons |
| 89 |
> might swallow us. Finally, this fear has become reasonable. |
| 90 |
> |
Archives