On 18.06.2013 01:15, Thomas Bächler wrote:
You're confusing me even more - how does the patch relate to ipv6cp?
In ipv6cp, I am assigned a link-local address by the provider. I may be
wrong, but doesn't my peer expect that I use this link-local address in
its routing table in order to
Am 18.06.2013 10:03, schrieb Steven Barth:
On 18.06.2013 01:15, Thomas Bächler wrote:
You're confusing me even more - how does the patch relate to ipv6cp?
In ipv6cp, I am assigned a link-local address by the provider. I may be
wrong, but doesn't my peer expect that I use this link-local
Hi,
On Tue, Jun 18, 2013 at 11:35:41AM +0200, Thomas Bächler wrote:
Documentation in pppd is incomplete here, at best. While I can define an
interface identifier using the 'ipv6' option, it doesn't say anything
about hand-shaking. My impression (from the wording of the
documentation) is that
Gert Doering g...@greenie.muc.de writes:
On Tue, Jun 18, 2013 at 11:35:41AM +0200, Thomas Bächler wrote:
Documentation in pppd is incomplete here, at best. While I can define an
interface identifier using the 'ipv6' option, it doesn't say anything
about hand-shaking. My impression (from the
Hi,
On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote:
I think this change is useful (without having looked at the actual code),
for exactly these reasons. With the IPv6CP handshake, you'll arrive at
something the provider controls - but then in the /64 that is announced
by RA,
Gert Doering g...@greenie.muc.de writes:
On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote:
I think this change is useful (without having looked at the actual code),
for exactly these reasons. With the IPv6CP handshake, you'll arrive at
something the provider controls - but then
On 18.06.2013 14:32, Gert Doering wrote:
Hi,
On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote:
I think this change is useful (without having looked at the actual code),
for exactly these reasons. With the IPv6CP handshake, you'll arrive at
something the provider controls - but then
Am 18.06.2013 14:57, schrieb Steven Barth:
Allright fine, you guys have convinced me.
I just commited a modified version of that patch to trunk.
Please test it.
I see that your version is slightly more straightforward. For the
moment, I can only say that my original version works fine on AA,
Since the upstep to firewall3 in the attitude adjustment branch I notice
NAT masquerade issues when the masq_dest and/or masq_src parameters are set
to 0.0.0.0/0 in the zone topic.
The running config for the zone lan and wan is as follows :
firewall.@zone[0]=zone
firewall.@zone[0].name=lan
On 18.06.2013 15:49, Hans Dedecker wrote:
Since the upstep to firewall3 in the attitude adjustment branch I notice
NAT masquerade issues when the masq_dest and/or masq_src parameters are
set to 0.0.0.0/0 http://0.0.0.0/0 in the zone topic.
Don't do it then? Setting a value of 0.0.0.0/0 is not
On 18.06.2013 15:49, Hans Dedecker wrote:
* Since the upstep to firewall3 in the attitude adjustment branch I
notice** NAT masquerade issues when the masq_dest and/or masq_src
parameters are** set to 0.0.0.0/0 http://0.0.0.0/0 in the zone topic.*
Don't do it then? Setting a value of 0.0.0.0/0 is
Fixed with https://dev.openwrt.org/changeset/36960,
https://dev.openwrt.org/changeset/36962
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
12 matches
Mail list logo
