if I am needed

[Dave Taht]

On Sun, Mar 25, 2012 at 2:39 PM, Francis Dupont <fdupont at isc.org> wrote:

> > yea! I can go back to sleep.
>
> => not a bad idea, I finish this and go to sleep too.
>
> > >  - I tried to debug the dhclient6 init script:
> > >  * dhclient -6 requires '-D LL' to build a repeatable and
> > >   easy to predict DUID in the LL format (vs LLT format, which
> > >   is the MAC address + time stamp)
> > >
> > > As if you know the time before you have a  ntp lock, which you can't
> get
> > before you get on the internet.
>
> => this issue is well known: on devices with reliable storage you
> create once a LLT DUID, on others (like CPEs) you create each time
> the same LL DUID. So the -D LL is needed and without the strange
> MAC address is enough.
>

Good to know.

>
> > >  * for an unknown reason the MAC address is one less than written
> > >   on the box and returned by 'ip addr' ? Can't say why...
> > >   (the answer is in the code in dhclient which computes the DUID LL)
> > >
> > >
> > Sorry about that.
> >
> > There are only 3 mac addresses on the box that are real. The rest are
> > generated via various algorithms. You probably hit the flip the 'local'
> bit
> > one?
>
> => no, it is the last byte (1b -> 1a for instance). wireshark shows it
> so I fixed the DHCPv6 config and went to other problems. But I noted
> to warn you so we should win some time the next demo.
>
>
Hmm. That sounds like a bug.


> >  * uci fails to get the wan interface (BTW with B4 there are two
> > >   wan interfaces, one (tun0) for IPv4, one (ge00) for IPv6
> > >
> > >
> > not clear to me this issue, something like uci get network.ge00.addr
> > (syntax maybe off) would work.
>
> => it asks the name so I replace the uci call by ge00.
>
> > >  - the iptables is a mess, I had to flush it (-F -X) and to
> > >   put the default policy for FORWARD
>
> => in fact I don't know if the tables were bad but it was impossible
> to debug them. And as you say a lot of rules make the box slow
> (the linked list of rules is scanned for packets not cached by conntrack,
> sorry but this is a pretty bad design :-)
>
> iptables seemed like a good idea in 1998.


> > did you also have to nuke the ip6tables ?
>
> => no
>
>
I note that I had to explicitly allow ipv6 proto 4 in /etc/firewall.user

I'm concerned about seeing some errors with frags in the log. (logread)


> >  - default dnsmasq arguments didn't work, I relaunched without any
> > >   argument to fix it
> >
> > hmm. What I had was working for me.
>
> => I tried once (by dig @127.0.0.1), restart the init script, not
> work too, stop + dnsmasq &, works, go on the client to try other things.
>
> Note on the laptop I only install the dnsmasq package and removed
> the bind9 init script for run level 2, and it works when I rebooted
> to apply the new configs (addresses & co).
>
>
Hmm. I was interacting with bind9 on io.lab.bufferbloat.net not dnsmasq


> > > I fixed the DHCPv6 server entries (required the LL prefix (03:01?)
> > > and -1 on the last byte. (PS: on the SD-AFTR).
> > >
> > > I had figured you'd just ifconfig ge00 and go from there.
>
> => ip addr but as far as I know both ip and ifconfig use the same ioctls?
>
>
Puzzling. I'll look at it when I get to the lab.


> > > In particular the SD-AFTR failover works great.
> > >
> > cool.
>
> => yes, I copied the config files, put them in place, compiled aftr,
> rebooted, suspend the other box, launch aftr, rush on the client,
> and one second after it was as I did nothing. So it was really
> stateless deterministic (and you can some other synonyms :-)!
>
> did ssh outgoing survive?


> > If you can slam a copy of the entire working /etc directory somewhere I
> > will diff it against what is in the current images and fix it for the
> next
> > demos april 4.
>
> => I'll try to manage one hour or two to save the changes and try
> a more dynamic config (i.e., we can backtrack from the current working
> but a bit too manual and static setup to a full plug and play one,
> we only need an Ethernet plug outside the terminal room).
>
>
I'm in no hurry today! ;)

> Regards
>
> Francis Dupont <fdupont at isc.org>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/sdcpe-devel/attachments/20120325/5f9f7193/attachment-0001.html>