> bufio.Writer is about 200 lines, and you probably don't even need all
> of them. Just copy it and modify it for your purposes.
Ok, thanks.
-- Juliusz
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
Hi,
I've got a bufio.Writer which is wrapping a net.TCPConn. Once in
a while, Flush() will trigger a write timeout (set with SetWriteDeadline
on the underlying connection), in which case I'd like to reschedule some
requests on a different connection, and then restart the Flush() with
a more
>> 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 latenc
> Yes, but if your fast connection is lossy, it's not fast. Lossy
> 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
> 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
>
> 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
>>> 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
> - 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?
> 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
Hi folks,
As some of you may be aware, FRR master branch speaks Babel.
https://github.com/FRRouting/frr
The Babel support is based on Matthieu's old Quagga code.
After some bug fixing by Donald Sharp (thanks!), it's reached the level of
maturity where it can run as an edge router for both
> suggests you should move the wg.Add(1) out of the Goroutine from here:
[...]
> to there
Thanks, that's an actual bug.
> * Do you happen to know about the context package? It seems like a lot of
> the closedown can happen if you recast part of the system as contexts and
> cancel those
> 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
> 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.
> 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
> How did your students adjust to working with the GOPATH?
No issue at all. I told them to create a directory under ~/go/src, and
that was it.
> It seems to cause some people trouble.
In my experience, undergraduate students accept pretty much anything if
the instructions you give them are
> I glanced at babelweb2 (https://github.com/Vivena/babelweb2/). A code
> review would be useful. For example, from parser/parser.go:
Thanks for the review. As I've mentioned, neither the students nor me
had any significant experience with Go, so we were learning as we went
along.
If you
> 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
Dear all,
I've just finished supervising three fourth year students doing
a month-long summer project in Go. I thought some of you might be
interested in my conclusions.
The students were decent C programmers but had more experience with Java
(and I am not an experienced Go programmer myself).
> Could it run on openwrt and mips?
No, GC built binaries for MIPS32 currently require an FPU. I've put
a small ARM board behind my router for that very reason.
The Go team are aware of the issue, and I'm optimistic that this will be
fixed ina future version. You'll still have to live with the
> Cool, but how do I build this thing?
> % go get -v github.com/Vivena/babelweb2
> github.com/Vivena/babelweb2 (download)
> package babelweb2/parser: unrecognized import path "babelweb2/parser"
Thanks for the report, I've forwarded it to the authors.
In the meantime, you can do:
cd ~/go/src
> Nice. But the demo needs more routers :P
Too tired right now, sorry. I need to set up FRR or BIRD to speak RIPng
to our Cisco, so the Babel network gets a default IPv6 route, and to set
up a few wireless routers in random places.
> Is it documented somewhere what information the interface
> 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
> ...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
> 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
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
___
Dear all,
I've been tasked with organising a meeting about unicast Hellos in Babel.
I've consulted the people I could reach, and Wednesday morning appears to
suit at least a few of them.
So let's meet on
Wednesday 19 July at 10am
I'll see tomorrow morning if I can get a room at the Hilton.
Dear all,
The Babel working group meeting at IETF 99 will be on
17th July 2017 at 17:40 CEST in room Athens/Barcelona
If you're attending IETF 99, please come. If you're not attending, please
do try to participate over this new-fangled Interenet thing:
>> Do I have a guarantee that the final \n will be passed to my custom
>> scan function and the result passed to the Scan function even if the
>> connection hangs just after the \n?
> Yes (assuming the underlying Reader returns the final \n).
>> Do similar properties hold for bufio.Reader (i.e.,
Hi,
I cannot find anything in the documentation about how bufio.Scanner
behaves when the underlying io.Reader does partial reads.
I'm using a Scanner to parse a stream of tokens that arrives over a TCP
socket. The stream is a sequence of lines terminated by \n. Do I have
a guarantee that the
>> 1. ad-hoc mode doesn't work as well as infrastructure mode;
> Has anyone tries using 802.11s configured interface?
Interesting idea. I'd be surprised if it worked much better than plain
ad-hoc mode, but I'd love to be proved wrong.
>> If you're using diversity routing (Babel-Z), be
>>
Hi Valent,
> my name is Valent and I'm founder of www.otvorenamreza.org which is a
> partner project with Wlan Slovenia (we are neighbours) and also
> www.meshpoint.me
We know. You're famous :-)
> We currently have mostly single radio nodes (tplink wr841nd and
> ubiquiti nanostation Loco m2)
> I'm wondering... what if, in the hypothetical routing protocol "Babble",
> one got rid of multicast hellos and ETX entirely, and routed using RTT
> measured by unicast hellos.
Interesting idea.
I think that's a perfectly legitimate implementation of Babel with Unicast
Hellos: we're leaving the
>> 2. 802.11 uses adaptative rate control on unicast frames, but not on
>> multicast frames.
> This is not entirely true, since hostapd is able to send multicast as
> unicast-frames.
And this will cause Babel's link-quality estimation to yield incorrect values.
Dynamically computed metrics are
> Can you provide text?
Yes, I will do. Please focus on specifying the on-the-wire bits, I'll
take care of the appendix.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
>> BTW, are third-party next hops allowed in Babel? I checked RFC 6126
>> but found nothing.
They're not forbidden, but I don't think they are useful. There's no
reason I can see why they wouldn't work, but I haven't actually tested.
> Not sure how babeld will react to non-LL next hop
> Does this mean whatever we decide for wildcard requests applies to
> wildcard updates as well?
Yes, er, no, er, I have no idea.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
I've put some CDF graphs of the results here:
https://www.irif.fr/~jch/software/babel/battlemeshv10.html
I've omitted the BATMAN5 data, since it was adding a lot of noise to the
graphs.
It looks like Babel did very well in the 8-17 test, and resonably well in
the others but with a fair number
confusing -- the message should say that the configured proxy is not
reachable.
Thanks,
-- Juliusz Chroboczek
> Hi, I was wondering what is the best way to enable the RTT metric with
> sensible defaults. It looks like max-rtt-penalty is the option that turns it
> on. What is a good value to set this at starting out?
Yeah, the RTT metric is fiddly. For very good reasons -- it's an
intrinsically unstable
For anyone interested, the Z3 algorithm is named in honour of Benjamin,
the author of the mail I'm replying to.
> Beware also that babel does not support all "recent" channel configurations:
> https://wiki.freifunk.net/ideas
That's not quite true.
> In the absence of explicit diversity routing
> R1(AP mode) ---> R2( Station mode)
All of your routes are single-hop, so there's no diversity information
being propagated. You'll need some longer routes in order to see anything..
> The channel information remains as 11 and 36 for station mode but ap
> mode it is 255. Whether it is
> I have implemented support for subtlvs and the mandatory bit in
> Bird[1][2] and confirmed that it correctly discards source-specific
> updates from Matthieu's branch.
Thanks, Toke!
I should be a little more free starting this week-end, I'll try to get
mandatory bits in all remaining
Matthieu, could you please write up a new version of the I-D with your
encoding? You might want to speak to Gwendoline, since she needs to write
up her TOS-specific encoding.
> If we keep this behaviour and mix tos-specific routes, we will have
> to send 4 wildcard requests to have all routes.
> Unable to find the channel information.
Send the SIGUSR1 signal to babeld (killall -USR1 babeld), then check the
log (using logread if a recent version of LEDE/OpenWRT, in /var/log/babeld.log
if using an older version).
-- Juliusz
___
Babel-users
> Can anyone help me regarding sample config's for diversity routing babel
> configuration.
Just say
diversity true
in /etc/babeld.conf.
You can check that it's working by running babeld with the "-d1" flag, and
checking that the routes carry reasonable channel information.
-- Juliusz
> Any plans to make EIGRP a part of Quagga?
I believe it's part of FRR:
https://github.com/FRRouting/frr/tree/master/eigrpd
Don't know the status, though.
-- Juliusz
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
> I'll look more into that part this week. I've always assumed connman
> would be installed.
I find it causes more trouble than it's worth -- I much prefer to
configure my devices statically.
Thanks,
-- Juliusz
--
For more options, visit http://beagleboard.org/discuss
---
You received this
Dear Robert,
bb-wl18xx-wlan0.service causes issues if connman is not installed. There
are two issues:
1. On line 183 of /usr/bin/bb-wl18xx-wlan0, it says
connmanctl_bin=$(which connmanctl)
This should say
connmanctl_bin=$(which connmanctl || true)
2. The .service file says
While the protocol is defined to work over either IPv6 or IPv4, all
implementations known to me use IPv6 for control traffic. If you need to
run Babel over a network that cannot carry even link-local IPv6, you'll
need to modify the implementation.
The alternative is to set up an overlay network.
--- Begin Message ---
There is now a mailing list for the design team specifying the
integration of HNCP and Babel security.
The list address is homenet-babel-...@ietf.org
We have added those people that had initial discussions around this
during IETF 97.
Ray and Mark
> I've just done a first draft of mandatory bits in babeld. The code is in
> branch "mandatory" of the github repository. It doesn't look *that* bad.
Matthieu and Gwendoline have fixed some bugs, so if you're tracking that
branch, please pull.
-- Juliusz
« 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
Hi,
I've just done a first draft of mandatory bits in babeld. The code is in
branch "mandatory" of the github repository. It doesn't look *that* bad.
If nobody objects too loudly, I'm going to write the protocol up in the
rfc6126bis draft, then merge the mandatory branch into master. Please
> I'm working on securing routing metrics from forgery rather than
> actual encryption/security for the data in transit. I doubt what I
> come up with will end up meeting anyone else's requirements nor be
> upstreamable due to just how much I'll probably end up touching on.
You might be
Folks,
If you have an opinion on the subject, please chime in on ba...@ietf.org.
--- Begin Message ---
Dear all,
As some of you have hinted (more or less rudely), there is an alternative
to the AE-based encoding of source-specific and TOS-sensitive routes that
I suggested: adding a mandatory
> 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
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
>> - IPv6 link-local addressing: For me it is a perfect example for "the
>> right amount of magic". It would make (at least my) life so much
>> easier. Filling the neighbor cache would require WireGuard to provide
>> (simulated or real) solicited node multicast addresses routing, right?
> Yes,
> - Scalability: I agree with what George said. Broadcast does not scale
> nicely, and IPv6 multicast is intended to help scaling things by
> reaching exactly the node that need to get a copy of a particular
> packet.
Not necessarily. IPv6 link-local multicast replaces IPv4 link-local
> My speeds over scp have been consistently below 2MB/s. Is this normal?
That's 20Mbit/s, which is perfectly respectable for a 1x1 interface in
a 20MHz channel.
If you've plugged both antennas in, you can switch the chip to 2x2 mode
by creating a file /etc/modprobe.d/wl18xx.conf with the
Dear all,
[This message is crossposted between both mailing lists, followups to
babel@ietf, please.]
I think there are at least four people interested in making a unicast-only
version of Babel, and that requires adding support to the protocol for
sending Hellos over unicast. We had a discussion
>> 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
>> 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
> 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
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
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
Dear all,
This is just to remind you that there will be a Babel meeting at IETF-98
in Chicago this Tuesday at 13:00 CDT. That's 19:00 Paris time, if I'm not
confused.
https://datatracker.ietf.org/meeting/98/agenda.html
(The Homenet meeting is on Monday.)
You're all warmly encouraged to
Not applied.
> - Add INCLUDES variable for headers
What for? Why do I need to maintain an extra variable?
> - Add support for tags and TAGS
No objection, but I just use a private shell alias.
> - create "reallyclean" to get rid of tags, TAGS, gmon.out, cscope.out
Rejected. There's no need
Rejected.
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Applied.
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
> In part I broke up the makefile changes because I figured you wouldn't
> like the compile guards
> and whole program stuff, but I found that really helpful later on in the
> rabeld effort, while optimizing and trying to understand how things
> worked.
You're right, don't overdo the squashing.
Thanks a lot, Dave. I've cherry picked the changes that are obviously
correct.
> I am not particularly huge on posting and reviewing patches in-line
> on mailing lists, but I can repost this pull request here, if desired.
Dave, github pull requests are the worst user interface I can imagine.
> The Cortex-M4 processors are similar to the Cortex-M4 micro-controllers
> available from Texas Instruments. They are mostly used for video
> compression/decompression, but you can use them to run then as bear bone
Interesting.
What about interrupt handling? I'd expect the Cortex-A15 to have
> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L48
> Change that to:
> usb_ms_ro=0
Right, thanks.
-- Juliusz
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard"
>> What's the expected way to make the USB mass storage gadget writeable?
>> Should I simply edit the am335x_evm.sh script, or is there some way that
>> will not be overwritten on upgrades?
> A little talk I did at DEFCON 23 about the BBB and the USB gadget.
That's very helpful of you. It's
What's the expected way to make the USB mass storage gadget writeable?
Should I simply edit the am335x_evm.sh script, or is there some way that
will not be overwritten on upgrades?
Thanks,
-- Juliusz
--
For more options, visit http://beagleboard.org/discuss
---
You received this message
>> The LEDE Community is proud to announce the first stable version of the
>> LEDE 17.01 version series.
> Congratulations all around. Great work! :)
Just sysupgraded painlessly. Thanks to everyone.
-- Juliusz
___
Lede-dev mailing list
>> Using Lede 17.01 rc 2 and OpenWRT CC I get some unreachable routes.
>> I'm somewhat puzzled. The setup contains 2 nodes sharing a wireless
>> ad-hoc link.
> .. this happened due to a poor wifi link.
Good. Babel culls asymmetric links, since it's impossible to establish
reliable communication
> Is there a specific emacs or vi "c-style" setting I should use while
> hacking on babeld? (.el file would be helpful)
(setq c-basic-offset 4
indent-tabs-mode nil)
> functions typically start with the { on the first line
Right. In all other cases, { is on the line of the statement
> This is the change i implemented..
> https://github.com/rcn-ee/repos/commit/cc43ffb0374efb0e219863621927f5bc29b12212
Perfect, thanks.
-- Juliusz
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
>>> bb-wl18xx-firmware
>>> Depends: bc
>>> Depends: bsdmainutils
>>> Depends: connman
>>> Depends: coreutils
>>> Depends: dnsmasq
I've rebuilt the package without the spurious dependency. It solves my
local problem, at least until the next upgrade.
>> A low-level piece of firmware should
>> bb-wl18xx-firmware
>> Depends: bc
>> Depends: bsdmainutils
>> Depends: connman
>> Depends: coreutils
>> Depends: dnsmasq
> This is to support the out of box AP mode. Those two depends can be
> reworked in the bb-tether script.
The current dependencies make it *impossible* to install
jch@beaglebone:~$ apt-cache depends bb-wl18xx-firmware
bb-wl18xx-firmware
Depends: bc
Depends: bsdmainutils
Depends: connman
Depends: coreutils
Depends: dnsmasq
So now I cannot install the wireless firmware without installing connman
and dnsmasq?
-- Juliusz
--
For more options, visit
> Sun Feb 19 17:15:45 2017 daemon.info babeld[1171]: Neighbour
> fe80::227:22ff:fe2e:4153 dev wlan0 reach rxcost 256 txcost 65535
> rtt 0.000 rttcost 0 chan 1.
It looks like an asymmetric link -- the local node hears neighbour 4153,
but 4153 doesn't hear the local node. If you manage to
> Under which conditions are rtt and rttcost included?
When we've received a valid timestamp from the neighbour within the last
three minutes (see valid_rtt in neighbour.c).
A zero rtt is strange; could you please send us your configuration?
-- Juliusz
> node2 & node 3 are deliver their routes to node1 and i can see them in the
> routing table or in babelweb (attached screenshot) 10.19.88.0/21 but the route
> that node2 announced is not distributed to node 3.
Plase add
split-horizon false
to the configuration files.
-- Juliusz
> In your case, the problem comes from the split-horizon optimisation: you
> should disable it, because it only makes sense for transitive media.
Right. Add the following to babeld.conf:
split-horizon false
-- Juliusz
___
Babel-users mailing list
>> - extend the IHU timestamp sub-TLV to allow an optional timestamp,
>> perhaps only used when sent over unicast;
> I just checked [1], we should be able to do that without breaking
> interoperability. Nice.
That's by design. Draft-jonglez-babel-rtt-extension (of which you are the
first
>> Based on the patch juliusz supplied me to enable unicast IHU, and
>>
>> default enable-timestamp true
>>
>> this stops sending timestamps (which apparently relies on hellos and
>> IHUs being bundled together)
> Can you provide the patch in question?
I cannot find the original patch, but it
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
> Well, the rabel repo exists for the crazy ideas... and unfortunately
> testing them at scale tends towards being a PITA.
Exactly my point. Ideas are cheap.
-- Juliusz
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
> If that is the only error in two highly speculative documents then I'm
> winning. :)
You'll be helpful (I prefer this to "winning") when you implement some of
your ideas and provide us with hard data to show that they are useful.
(For the record, CS6 and unicast IHU have both been implemented,
> I also fiddled a bit with bloom filters, which strike me as appropo.
Bloom filters trade accuracy for space -- they're arbitrarily smaller than
hash tables, but at the cost of causing more false positives. Since your
tests indicate that perfect hash tables are small enough, a Bloom filter
Hi Mehdi, good to hear from you.
> Ok, so the bug is in the description. Could you please provide a patch which
> enhances the descriptions and makes them less confusing?
No, sorry.
-- Juliusz
Hi Mehdi, good to hear from you.
> Ok, so the bug is in the description. Could you please provide a patch which
> enhances the descriptions and makes them less confusing?
No, sorry.
-- Juliusz
> I think it supports globbing on interfaces (?), which strikes me as
> a useful feature in babeld when interfaces come and go as they do
> nowadays with horrific names like enx2a1c0359e29b as generated by
> systemd. Some way to automagically recognize when an interface (e.g. vpn
> or usb network)
601 - 700 of 3650 matches
Mail list logo
