Simon, Unfortunately the "unit N" option is not always respected by pppd, if for some reason pppN is busy/not available then pppd will try the first available ppp* name starting from ppp0 (it does not even start from N+1).
I guess the best way forward is writing a custom script to set a ADSL_IFACE variable on the params file and then replace ppp0 with $ADSL_IFACE on the providers file. If anyone have a better idea I would appreciate your suggestions. > ---------- Forwarded message ---------- >> > From: Simon Hobson <[email protected]> > To: Shorewall Users <[email protected]> > Cc: > Date: Wed, 21 Oct 2015 18:56:01 +0100 > Subject: Re: [Shorewall-users] Providers: ppp0/1/2 interface detected from > IP address > Marcelo Bello <[email protected]> wrote: > > > On my box sometimes the adsl connection is falling on ppp1/ppp2 and not > always on ppp0. > > > > I could investigate hacks to ensure it always goes to ppp0 but I just > read on the pppd mailing list that they consider best practice to never > assume on which ppp+ interface the connection will be brought up. > > I just added "unit nn" to "/etc/ppp/peers/<provider config file>" to > ensure a consistent number. I vaguely recall (it's a looong time since I > last fiddled with it) that there wasn't an option in the version I had at > the time to do : > > > The solution they give is to use the "linkname adsl" option to pppd and > then ... > > > > > > > ---------- Forwarded message ---------- > From: Norman Henderson <[email protected]> > To: Shorewall Users <[email protected]> > Cc: > Date: Wed, 21 Oct 2015 19:35:28 +0100 > Subject: Re: [Shorewall-users] Packets replied to on wrong vlan > Simon - thank you very much for pointing out the obvious... which I > couldn't see... There had been a bunch of routing set up brute-force using > ip rule and ip route from vtund.conf and network/interfaces. When I removed > the vtun tunnel of course I didn't replicate those rules... which as you > pointed out, caused "everything" from 10.0.69.0/26 to be routed via vlan3. > > I still don't understand why the "local" table didn't handle the routing > for a locally connected network. > > However: I took a couple hours to do what I should have done long ago, get > rid of all of the scripted ip rule and ip route commands, and implemented > properly using shorewall providers and route_rules. > > Everything works again now! > > On Wed, Oct 21, 2015 at 3:02 PM, Lennart Sorensen < > [email protected]> wrote: > >> On Wed, Oct 21, 2015 at 06:13:03PM +1000, Brian Burch wrote: >> > I won't confuse anyone with details (in case they are off-topic), but I >> > thought it would be helpful to let you know I've been doing problem >> > determination on what appears to be a similar issue, but with a >> > different configuration. >> > >> > Naturally, I get shorewall log events for traffic between subnets that >> > should NOT be allowed, but nothing is logged for those connections that >> > are allowed. I believe it is not a shorewall problem, but something is >> > going wrong quite low in the stack. >> > >> > The details seem to be frustratingly variable, but I often see redirect >> > log messages to/from the host sending pings. I have many wireshark >> > traces from a mirror port on my switch, but haven't yet spotted the root >> > cause. >> > >> > In my research I found a reference to Linux being built on a "weak end >> > system model" as defined in RFC1122, which apparently "leads to arp >> > problems with multi-homed hosts". I haven't fully understood the >> > theoretical issues yet, so I apologise if my comments are not relevant >> > to your situation. However, in case it is relevant I thought it best to >> > mention quickly. >> >> Do you mean the arp behaviour where it will answer an arp request for >> an address it owns on another interface? For that we use these settings >> to get sane behaviour on a router: >> >> # Do not answer ARP requests from other interfaces >> net.ipv4.conf.all.arp_ignore=1 >> net.ipv4.conf.all.arp_announce=2 >> >> -- >> Len Sorensen >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Shorewall-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >
------------------------------------------------------------------------------
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
