> I don't think anything we are talking about here would actually help
> with that.
If the fast connection's DNS server replies after a delay or not at all,
and the slow connection's DNS server replies in a timely manner, using
a smart resolver across all the available DNS servers will improve lat
> I think this is a real edge case. You have two connections, the DNS server on
> one of them is broken, the DNS server on the other is not, but the second
> connection performs so much worse than the first
That's exactly the kind of situation that we'd like Homenet to work well
in. Connection A
> But only the client can make that coupling (from DNS reply to connection
> attempt). So if we're just filtering the result set based on the address
> the client uses (which is how I interpret what you put in the draft),
> we're degrading the experience for any client that doesn't know how to
> re
> Why do you think CDNs exist? What would happen if every home network suddenly
> stopped using the technology that makes CDNs work?
I thought I'd just mention that split-horizon DNS is just one possible
technique. BGP anycast is another one. (AFAIK, Akamai use split-horizon
DNS while Cloudflare
> This is a refrain I've heard from you, Juliusz and Markus, which I actually
> find a bit disturbing: the desire not to really solve the problem because it's
> not trivially easy.
If I were in a bad mood, I'd say that the three of us prefer simple, robust
solutions that solve actual problems to c
>>> DNS resolvers use round-robining. That's how the protocol works.
>> Does that mean that dnsmasq breaks the protocol?
>>
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366
> What dnsmasq seems to be doi
> - round-robin = bad (think why happy eyeballs came up for example of why)
> DNS resolvers use round-robining. That's how the protocol works.
Does that mean that dnsmasq breaks the protocol?
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a
> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
> all queries to router A, using a source address in the same prefix
> as the original request was received from.
> 1b. Router A exports over HNCP that it supports MPvD. Router B uses
> router A's address (which
> Juliusz expressed opposition to adoption, but Ray and Michael said the
> reasoning for objection was flawed (that Juliusz was setting the bar too
> high and the procedural objections were not valid in the context of IETF
> procedures).
I probably expressed myself badly -- my objections were tech
> The bottom line is that a global delegation+ACME PKI is a knob I can turn.
Think of it as a knob with a wasps' nest behind it.
> Fixing browsers is a knob I can't turn, and the browser vendors have spoken
> pretty unequivocally on this topic. If you want to tilt at that windmill, I
> will gladl
> (1) this isn't an issue for HNCP or babel. It's an issue for browsers.
It's an issue *with* browsers.
> (2) the issue with browser warnings isn't that they are annoying. It's that if
> we train users to click through them when managing the homenet, we are also
> training them to click through t
> I wanted to know if the scope of this is reasonable and is what the
> working group wants to take on.
I think the scope of this is too wide. It tries to solve a number of
different problems:
1. naming within the Homenet;
2. publishing names of Homenet nodes outside the Homenet;
3. resolv
> I have some other fairly serious nits about this document, but I believe
> that the argument above is sufficient. I am opposed to adoption at this
> stage, but look forward to reconsidering once dnssd has had a serious look
> at the protocols.
I didn't want the point of the previous mail to be
> It wasn't quite the document I was expecting. But rather seems to
> leverage upon a number of other draft-sctl* documents in progress.
I agree with Michael -- this is not a protocol definition, it is an
informal outline of how a number of other protocols can be made to fit
together. It has nor
>> Yeah, the so-called "TTL hack".
> Care to explain why it would not be useful?
At the time I wrote down Babel, I decided that given that we have link-local
addresses that are securely scoped to a single link, the TTL hack is not
necessary.
A workaround to the issue you describe would be to c
> Yeah, the so-called "TTL hack". I considered that for Babel back when it
> was being designed, then decided that it is useful in an IPv6 world.
This was meant to say "not useful", of course.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.
> A trick used in some places, such as ND, is to require the receiver to check
> that the hop limit is equal to 255. This ensures that the packet has not
> been forwarded by any router (obviously the sender also has to send it with
> a hop limit of 255).
Yeah, the so-called "TTL hack". I consider
> ...one might recommend starting with "an upper-layer security protocol"
> such as CMS, COSE, JOSE or some other layer-3 encapsulation.
We're planning to use DTLS for both HNCP and Babel.
But the authentication mechanism is not our main concern. This being
Homenet, we need to generate keys au
> 1) The first sentence seems to not say what to do if a packet comes
> from a 1918 IPv4 address. Even if that's not supposed to happen, it
> could be attempted. What's an implementation supposed to do then?
Both HNCP and Babel use IPv6 for carrying control data. There's no way an
IPv4 packet can
Dear all,
All security wizards are kindly requested to carefully read and if
necessary criticise the following section:
https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-02#section-4
Nasty comments on list, please, compliments by private mail ;-)
Thanks,
-- Juliusz
__
> I'm going to blame this on jet lag. Sorry, Juliusz. I meant Juliusz, not
> Julian.
That's okay. Julius Caesar violated the Geneva Convention at the siege of
Alesia, while emperor Julian was a humanist, a scholar, and a philosopher.
-- Juliusz
___
ho
« Finally, Martin Kafai Lau asked if work should be done to merge the IPv4
and IPv6 FIB (forwarding information base) trees. The FIB tree is the
data structure that represents routing tables in the Linux
kernel. Miller explained that the two trees are not semantically
equivalent: while IPv6
> In the current implementation, a single daemon per registration zone.
Right. Either it could be elected by HNCP, or the daemons could run an
election among themselves.
> The client will query for a SRV at _nsreg._tcp. to find the
> daemon, which can be anywhere, in principle (the daemon will o
Simple and elegant, solves a real problem without too much ideology.
> This daemon will allow a client to claim a name on a Trust On First Use
> (TOFU) basis
Cool.
> If the name in a claim is not already taken by another nclient, the
> client's claim will be successful and the daemon will cache
>> Could you please clarify what you mean by "negotiate"? Current HNCP
>> implementations are provided with a bunch of External Prefixes, which they
>> then carve into /64, one per prefix. Are you envisioning a scenario where
>> the HNCP implementation actually performs active negotiation on its
> There's already a thing called an HNCP agent. Why couldn't
> it be enhanced to negotiate with an upstream ASA for resources?
Could you please clarify what you mean by "negotiate"? Current HNCP
implementations are provided with a bunch of External Prefixes, which they
then carve into /64, one pe
brian> But if the CE includes a little autonomic service agent (ASA) which
brian> is in the ISP's security domain (not the SOHO domain), it can act for
brian> HNCP to solicit address space from the ISP. That's the southern side
brian> of the CASM model and the northern side of HNCP.
HNCP just does
Dear all,
Draft-ietf-homenet-babel-profile-01 says:
REQ5: a Homenet implementation of Babel MUST implement HMAC-based
authentication, as defined in RFC 7298, MUST implement the two
mandatory-to-implement algorithms defined in RFC 7298, and MUST
enable and require authentication when instr
> So far so good. The problem is a (largely hypothetical at this point)
> stub resolver that wants to do DNSSEC verification of the results the
> router gives it.
Yes, I'm following this discussion with interest. The only bit I object
to is bringing .onion into the discussion -- .homenet is noth
> On the computers I know, the stub resolver is in one shared library and
> the SOCKS proxy is in another. What's the difference?
The SOCKS library uses a completely different data transport (one that is
circuit-switched and layered over TCP), with very different capabilities
from the usual packe
> requires special-case code in every single freaking DNS-speaking
> application. Yeah, I'm still pissed off.)
Since people seem puzzled about my rant, here's the relevant quotation
from RFC 7686:
Applications that do not implement the Tor protocol SHOULD generate an
error upon the use o
> This brings us to one of the knottiest parts of special use names, which
> is that they're all handled differently. For .onion, it's generally
> handled in a SOCKS proxy in the application, for .local it's handled by
> mDNS, and for .localhost it's special cased in the stub client library.
Let'
> I do not like REQ5. As a SHOULD, perhaps, but MUST seems excessive.
> Guest networks without any HNCP / routing traffic are the way to go
> anyway in my opinion. What happens behind closed doors (= non-guest) is
> up to the home, I think.
Right. Plus there's the fact that nobody has stepped up
Hi,
I've just submitted
draft-ietf-homenet-babel-profile-01
It should hit the IETF repository soon, in the meantime, my working copy is on
https://github.com/jech/babel-drafts/tree/master/draft-ietf-homenet-babel-profile
The major change is the addition of Section 3, which describes how H
I think I now see how the pieces fit. Thanks, Markus.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> In dnssd we have the “stitching” topic on our plate, around operation of
> dns-sd
> in unmanaged multi-link networks. So this is timely discussion.
Aha, excellent.
> We’re beginning work on a BCP for the use of the discovery/advertising proxy
> in
> enterprise/campus networks, where there is
>> - who merges data from multiple links? (I'd wish that the hybrid
>> proxies compute a minimal spanning tree and perform peer-to-peer
>> magic, but I suspect you're generating a config file dynamically
>> and restarting dnsmasq whenever the set of hybrid proxies changes.)
> There is no need for
>>> - ohybridproxy (only really scalable and sensible IPv6 rdns source that
>>> I am aware of, given nodes talk mdns)
>> Noted, thanks for the opinion. I still don't understand how it works (who
>> gets port 53? how are data from multiple links merged?), but I intend to
>> do my homework.
> I g
> it doesn’t make sense to me why we should spend our time specifying
> protocols for registering names of services in the global domain name
> system unless we have a realistic usage scenario that shows how they
> will be reachable directly by arbitrary public hosts.
Agreed.
> I just don’t see h
> IoT land [...] there is bit more hope
Joke, right?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
>> (I see that hnet-full in OpenWRT/LEDE installs a thing called
>> "minimalist-pcproxy", but I have no idea what it does and whether it
>> handles multiple edge routers correctly.)
> It does.
Excellent.
> Downside with it is that it is based on essentially non-IETF stuff (my
> expired draft) [.
> I can put that controller into my own home and operate it
Assuming that you can control the stateful firewall that's running on the
edge routers. Recall that the edge router is not necessarily on the local
link, and that there can be multiple edge routers.
(I see that hnet-full in OpenWRT/LEDE
> If there is anything in any of the Homenet working group documents or
> pending drafts that contradicts the recommendations of RFC 6092 that
> amount in practice to a prohibition against passive listeners in the
> home network from being reachable by arbitrary exterior hosts, then I’m
> not seein
>> "The top-level domain name '.homenet.' is to be used for naming within
>> a home network. Names ending with '.homenet.' MUST refer to
>> services that are located within a home network (e.g., a printer, or
>> a toaster)."
> My comment was that I find the term "home network" ambiguous. Given t
> But, do you agree that publishing your home lighting controller to the DNS is
> how you manage to control your lights from your phone when you are out of
> wifi distance,
Yes, I didn't mean we should disallow this. If the user wants to publish
his lightbulbs under .com, it's not our job to tell
> Yes, publishing stuff in the global DNS is out of scope for the simple
> homenet naming architecture document.
I suddenly worry much less.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
I've got three comments about the proposed naming architecture.
First point. I feel I'm not alone in feeling uncomfortable about the
sheer breadth of this document. I'm wondering if the main problem isn't
that it's trying to solve multiple problems, each of which is difficult in
itself:
(1)
> Poor visibility and diagnostics of faults make the cost of supporting
> any service expensive and erode brand value
Point.
> So, would it be reasonable for devices that are not sure of the time, to
> report that fact, and their view of what the time is to the user for
> acceptance?
Well, the o
ddos attack like against Dyn
>> I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet,
>> which propagates by exploiting devices configured with default credentials.
>> This has nothing to do with outdated firmwares.
> The problem is that you cannot realistically update tho
>> ddos attack like against Dyn
I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet,
which propagates by exploiting devices configured with default credentials.
This has nothing to do with outdated firmwares.
-- Juliusz
___
homenet
> But, we talked about how this wasn't a totally catch-22, that we could
> know how it was "at least" some time based upon file timestamp, or
> self-certificate not-before dates, or do DNSSEC without time validation
> first.
> My question is: did this get captured into document somewhere?
In case
> PS I'm still looking for validation of the commands issued by getstats.sh.
All your commands are peeking at the state of the kernel. You've got
other layers in your software stack, and when debugging you often need to
find out each of the different states:
- netifd's state can be obtained by
> Slightly OT: I have posted getstats.sh on the Homenet wiki. This is an
> adaptation of a script that I created as a troubleshooting tool for
> OpenWrt. The script collects a standard set of info and outputs it to
> a single file for easy review.
https://lists.infradead.org/mailman/listinfo/lede-
> Thanks for the suggestion, but no change.
It's difficult to debug remotely, since you're not giving the relevant
information. (Which interfaces are the routers connected over? How are
they configured?)
Did you install the "ip" OpenWRT package? (Check with "opkg status ip".)
We've seen silent
> I would expect to be able to ping the ip address
> (2a02:c7d:1d31:a605::3c/64) on eth2 of (2) from (1).
On each router, run
ip6tables -I INPUT -j ACCEPT
ip6tables -I OUTPUT -j ACCEPT
ip6tables -I FORWARD -j ACCEPT
and try again. (This is not a persistent configuration, it will go
> I suspect it has something to do with the "disabling br-lan" messages,
> but I don't know where that config comes from.
No, that's just that as you change the configuration, the software bridge
is being removed. What you're seeing are STP state transitions.
Can you please paste a full boot log
>> The Commission for Truth in Advertising requires me to mention that the
>> last feature is not quite ready yet -- with current software, when one
>> provider goes down, you might need to manually disable the router that's
>> connected to that provider.
> The Commission for Truth in Advertising
> Also... I'm aware that the Installing Homenet guide elides the reasons for
> using it. Do we have a short paragraph that tells *why* a lay person would
> want to use Homenet?
> - No configuration - Homenet routers figure out how things are connected
> and do the right thing
Agreed, but see
>>> I think you mean E1 - that's what the instructions use for the wide area
>>> interface.
>>
>> It looks like one of us is confused.
> It looks like it was me. :-)
Why not rename the interfaces to "internal" and "external"?
> This is a corollary of your assertion at IETF the other day ("if it
> You guys did your homework, posted your code with (unit) test cases, and so
> all the other tests passed.
Thanks for the kind words. And thanks to you for the speedy pull, guys
can go for holidays with clear confirmation that their internship was
a success.
-- Juliusz
> Thank you... the 4.8.0-rc2 will go out on Monday with it.
Jean-Raphaël is in my office, he's telling me "I thought upstreaming was
supposed to be difficult" ;-)
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinf
> Should the procedure remain silent on the firewall? Or should people
> just put all interfaces into the lan zone? Or something else?
Pleae leave it as it is, it's fine. I'd remove the bits about making E0
internal, it just confuses things -- if the router has a 4-port switch,
it's not likely th
> What I would suggest would be to convert the WAN and WLAN interfaces to
> Homenet, but keep the LAN statically configured.
Er, sorry. I missed the bit where you say that things only go wrong when
you convert the LAN interface to hnet.
I'm afraid you're going to have to log in through the WAN i
> When I convert the lan port to hnet as described in Step 10, everything
> comes to tears. After the reboot, the LAN ports do not give DHCP
> addresses, and I cannot connect to either wireless interface...
I assume you have no serial console on this board?
What I would suggest would be to conver
Hi,
A cleaned-up version of Antonin's and Jean-Raphaël's code for tcpdump is
available in the hncp-20160728 branch of their github repository:
https://github.com/MisterDA/tcpdump/tree/hncp-20160728
git clone -b hncp-20160728 https://github.com/MisterDA/tcpdump
The pull request is here:
h
> Rather than describe the symptoms, I think it might be more efficient
> for someone to read through the steps outlined at
> https://gist.github.com/richb-hanover/ec88b851c4da074e48003e6fe9276901
> and tell me if I've got it right?
Looks good to me. You've correctly removed the software bridge a
> I have no objection to implementing the ND option
I retract that. I realise I don't know how difficult this is to implement
in deployed host implementations, so I shouldn't be expressing an opinion.
-- Juliusz
___
homenet mailing list
homenet@ietf.o
I would like to reiterate my opposition to four requirements of this
draft (as described in my mail of 18 July):
- the requirement for a new ND option;
- the requirement for a RESTful management API;
- the requirement for a local DNS resolver on each link;
- the requirement for a ULA.
Speakin
I have been informed by private mail that xn--home encodes to 㯝㯟.
(Just kidding. Thanks to all for a pleasant IETF.)
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> But I think we all accept that there's going to have to be a special-use
> top-level name allocated. That name is either going to be '.home' or
> '.homenet' as far as I can tell.
Ted,
Is this domain meant to be specific to HNCP, or is it a generic site-local
domain for home networks? If the fo
> Maybe I’m just much less good at getting the configurations right first
> time
In my experience, it's only the first two or three years that are difficult.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/hom
> Having these two protocols knowing nothing about each other and each
> others' state is potential source of problems.
I've thought about it some more (warm showers increase the flow of blood
to my brain), and I've realised that this is an important point, and one
that is close to my research int
> Configuring and smoke testing >1 router, > once starts to look like
> a devops problem.
I think you're overthinking it. Once your routers are up and reachable
from outside, propagating a new version of the config files is easily done
using scp. Matthieu tends to automate that using a throw-awa
> Well, in my testing I got the feeling (hard to tell since it was really
> hard to get a comprehensive picture of what was going on over time), that
> sometimes HNCP lost its connection to other HNCP nodes on the lan, while
> babel was still working, and the other way around, babel went down and
>
> The problem came when “Step 3 - Converting WAN interface to Homenet”
> didn’t work as described. I clicked Delete for the WAN interface.
Don't use the web interface. Ssh into the router, and use vi on
/etc/config/network, it's easier and more reliable.
Here's how we make a Homenet router:
o
Speaking with people at this week's IETF meeting, I've realised that some
are confused about why configuration and routing are implemented by
different protocols in Homenet. Contrary to what might seem, this is not
some sort of weird political compromise, but a conscious technical
decision.
Routi
This message is being sent to the manet mailing list, with homenet in CC.
I took to the microphone during this week's manet meeting to remind people
that Homenet has designed HNCP (RFC 7788), a protocol for autonomous
configuration of multilink home networks, and that it would be a terrible
missed
> This proposal doesn't satisfy the problem statement.
> (which nobody wrote. :)
Perhaps we could start by writing up the usage scenarios we have in mind?
I'll start:
1. I want to point a web browser at the configuration interface of the
router in my attic;
2. I want to point a web browser at
> Current host stacks don't have support for saying "if the suffix is
> ".TBD", go here, otherwise go there.
Right, and I missed this point in my strawman. I guess I've been spoiled
by dnsmasq.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
http
>> We want something short and memorable. ".co.uk" is short and memorable.
>> ".univ-paris-diderot.fr" is not.
> Why? This is, I suspect, part of the issue: it seems that we have
> some assumptions about the use of these names, and I'm not entirely
> sure what they are. It is not obvious to me
Not proposing this seriously, just attempting to explore the design space.
Some of the ideas are due to Toke.
Zones and authoritative nameservers are announced over HNCP together with
their set of addresses, which SHOULD include a LUA and MUST include at
least one IPv6 address. There are two bits
> ps - i've read the draft and think it's ready for adoption.
I most humbly disagree. Let's please leave some time for people to think
it over and possibly come with counter-proposals.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.i
> - why do you need a TLD? Why won't a SLD work?
We want something short and memorable. ".co.uk" is short and memorable.
".univ-paris-diderot.fr" is not.
> - why do you need a word from natural language?
We want something short and memorable. ".home" is short and memorable.
".in-addr.arpa" is
> Existing implementations by participants work and interoperate,
Currently, shncpd doesn't do any naming at all except for pushing the
addresses of upstream DNS resolvers to clients over RA and DHCPv4. You
will find the exact status of shncpd at the bottom of
https://www.irif.univ-paris-dider
Ted,
I've read the draft again, and I think that there's only one place where
you rely on having a ULA. So I'd suggest:
Section 3.3 point 2, replace "the homenet's ULA prefix" with "the
homenet's ULA prefix (if any)".
In Section 5.5, change "Homenets have at least one ULA prefix" with
"
Dear all,
We only confirmed the yo-yo issue on Sunday, which caused me to send the
latest version of my slides at the very latest moment. I therefore cannot
blame the chairs for forcing me to work with an older version of my talk
which didn't contain the explanation -- oh, what the heck, yes, I c
> Why wouldn't you allocate one?
I would. ULAs are a goodness. Probably. I'm planning to add ULA
generation to shncpd at some future date, and perhaps even enable it by
default.
The question is about the level of MUSTiness. I only see two reasonable
possibilities:
1. ULA is SHOULD, and we
>> (4) Is there WG consensus on requiring a ULA?
> I believe that this is.
> a) it's in rfc7084 (so they are there even before homenet existed)
> b) it's in rfc7368 (it's in our architecture)
RFC 7084 Section 4.3 says:
The IPv6 CE router SHOULD be capable of generating a ULA prefix [RFC4193]
> Right now HNCP doesn't actually seem to have a TLV for advertising
> resolvers.
That's exactly what I was trying to get at.
> How does this work now?
Not very well.
HNCP announces *external* resolvers in the DHCPv4- and DHCPv6-DATA
sub-TLVs of the EXTERNAL-CONNECTION TLV. Hnetd uses this dat
> I don't think the document is proscribing speaking HNCP without speaking
> DNS.
Then I've misunderstood something, my bad.
Suppose you have routers A and B on a link, and A implements DNS while
B doesn't. How does B find out that it should advertise A's DNS server in
RA, DHCPv4 and DHCPv6?
--
>> From my perspective, though, there is nothing technically hard about
>> what we're talking about here; the main issue is that it's a
>> substantial amount of work.
You're possibly right, I don't know, but I'm worried about implementability.
I'm very worried that you're apparently proscribing sp
This is to repeat the comment that I made at the mike about
draft-lemon-homenet-naming-architecture-01.
Among other things, this draft suggests:
1. having a new ND option (Section 3.5);
2. defining a RESTful management API (Section 3.6);
3. the use of a local resolver (Section 4.5);
4
Here, at Babel towers, our intern Dorine has almost finished reconfiguring
our permanent mesh network to use HNCP instead of AHCP. It is somewhat
fragmentary right now, and uses the 5GHz band only, we'll see how well
HNCP works when we've deployed more routers and set up a parallel mesh on
2.4GHz.
>> - how does software running on my laptop, which just connected to an
>> unknown network, find out what is the local translation of "home"?
> It doesn't. It uses HNCP.
Please describe exactly how my laptop (which doesn't run HNCP) finds out
the right domain. Please describe how an HNCP router
> Those who come from cultures that speak languages descended from older or
> different roots might challenge the universality of that proposal.
I strongly object to Sumerian cuneiform.
> I don't think there is a correct answer to this. .local has worked, which is
> the best we can hope for with
> Where THING is the local translation of "home".
Let us please not open this particular can of worms:
- how does software running on my laptop, which just connected to an
unknown network, find out what is the local translation of "home"?
- how does a user, even one who knows the local
> The specification (AFAIK) does not really require all implementations to
> agree on the same network-wide default (as it is not omitted from DDZ
> TLVs, the sub-zones are fully qualified), but I do not see any other
> sensible default than the one we use now. So I am not sure what this
> will cha
>> Do you know if anyone is working on HNCP support for tcpdump and
>> wireshark? I'm considering giving it out as a student project this
>> summer, but of course it doesn't make a lot of sense if somebody beats us
>> to it.
>>
>> (I already know about the lua script for Wireshark.)
> Plenty of
Dear Markus, dear all,
Do you know if anyone is working on HNCP support for tcpdump and
wireshark? I'm considering giving it out as a student project this
summer, but of course it doesn't make a lot of sense if somebody beats us
to it.
(I already know about the lua script for Wireshark.)
-- Jul
Suddenly shncpd stopped parsing name server information. I asked Markus,
and he explained that the IANA registry[1] has different values for the
DHCPv4_DATA and DHCPv6_DATA TLVs than RFC 7788. Hnetd was following the
former, while shncpd was following the former.
Grr.
I've just fixed shncpd so
101 - 200 of 652 matches
Mail list logo
