> Being a meshy protocol, though, if something escapes, usually over
> a "backup" link, suddenly a whole bunch more specific routes end up
> going through that backup link and life goes to hell quickly.
Yeah, that's a common user interface issue.
Now that we have mandatory bits, though, this
> Also it would be really helpful if that remaining PR (prefsrc) could be
> considered.
Christof, are you willing to send me a clean patch against the rfc6126bis
branch, or shall I do the merge myself?
-- Juliusz
___
Babel-users mailing list
> the box doing the injection ate a cpu for all of the 5 minutes the
> test ran
How did the BIRD box behave?
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> struct babel_addrs { // could use a better name
> unsigned char src_prefix[16]
> unsigned char prefix[16];
> unsigned char src_plen;
> unsigned char plen;
> unsigned short nexthop; // an index, not a ptr, into the nexthop
> table, sometimes unused
> };
> struct resend
0. Pro memoria, babeld-1.8.1 and later are safe to use in networks with
the new source-specific code.
1. I've added a new per-interface flag "rfc6126-compatible" to the babeld
config file. It's a noop in the 1.8 branch, in the 1.9 branch it
prevents sending of packets that might confuse
> * Unless you want to setup unicast Babel you need an individual port and
> tunnel for every Babel connection.
(You mean every Babel neighbour association. Babel is an unconnected protocol.)
> Wireguard's secure IP's feature won't allow you to use the peer
> discovery broadcast address twice
> 92.52 18.1718.17 38243948 0.00 0.00 find_resend
Thanks, that's helpful.
> fix with binary search? timer wheel? ?
Binary heap?
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> is your preferred workflow still patches to the mailing list?
I now know how to generate a patch from a github pull request (ghi --patch),
so either is fine.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I keep seeing people talk about running tunnels via babel. Is there a howto
> about how to do it? With wireguard? ipsec ? ssh? Or ?
We've had good success with both GRE (insecure) and OpenVPN over UDP.
In both cases, it's pretty trivial:
- start the tunnel;
- make sure the tunnel endpoints
> Following a more-or-less recent trend, I wrote some time ago a Meson
> build file for babeld.
I'm an old man, Antonin, and I've learnt to avoid recent trends.
> On my laptop, a clean build takes 5s with Meson+Ninja, from 10s with
> make.
Are you running "make -j"?
> The pull-request lives on
> And I'm *not* importing proto 51 of this list into babeld, but when it
> does a kernel dump, it gets it all, hits an internal memory limit
> processing the netlink data and doesn't manage to import *any* kernel
> routes.
Right. As I've mentioned previously, the redistribution code in babeld is
> Well, I will go test in the lab. You are saying that even relaying
> routes through a 1.8.0/1 box will mess things up?
No, it's redistribution that's broken.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> I can confirm now that this has been happening for quite some time, both
> my lab gws are 1.8.0.
Cool, known bug then. Fixed in 1.8.2.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> And yes, reverting the apu2 to 1.7.1 fixed the default route issue.
Can you confirm that 1.8.2 didn't work? There was a bug in 1.8.[01] that
could be what you're seeing.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> --- a/kernel_netlink.c
> +++ b/kernel_netlink.c
> +static int ipv4_metric = 0;
> +static int ipv6_metric = 1024;
That's exactly the wrong layer at which to do that. Policy should be
happening at least 17 layers higher.
What problem is that intended to solve?
> -const int ds = 0xc0;/* CS6 - Network Control */
> +const int ds = 0xc2;/* CS6 - Network Control + ECN */
Nope. If we start lying about ECN, people will start disabling ECN in
routers, which would not be a good thing.
___
> I used to have a patch to update_neighbour that logged late hellos. The
> new update_neighbor code in 1.8.3, well, in a half hour of staring at it
> I didn't figure out a good place to stick this. But it was a useful
> patch to have. you can't fix what you can't measure.
Try the "missed_hellos
>>> Received prefix with no router id.
>>> Couldn't parse packet (8, 13) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
>>> Received prefix with no router id.
>>> Couldn't parse packet (8, 14) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
>>
>> Toke, are you mis-parsing retractions? No router-id is
> Received prefix with no router id.
> Couldn't parse packet (8, 13) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
> Received prefix with no router id.
> Couldn't parse packet (8, 14) from fe80::eea8:6bff:fefe:9a2 on enp6s0.
Toke, are you mis-parsing retractions? No router-id is necessary for
a
> Well, I took a stab at some of that. In particular, babeld has to compare
> a lot of bytes, and while profiling it on these loads, was totally
> bottlenecked on memcmp.
Yep, the code in xroute.c is pretty pessimal, since I wan't expecting
people to have massive numbers of redistributed routes.
> I've lost track of where that repo is, but if you find a version of
> babeld that speaks the new source-specific protocol, bird should
> interoperate just fine with that :)
I'm working on merging the Matthieu's new source-specific code into
the unicast branch of babeld. Please hold your breath
Your config looks fine to me. Perhaps I've missed something.
Please run babeld with "-g 33123" and do
echo dump | nc ::1 33123
and send us the output.
Also send us the output of "ip route show".
-- Juliusz
___
Babel-users mailing list
>> B) you run out of cpu - babeld uses linked lists,
Not quite -- the route table is a flat array, with per-destination
linked-lists. We don't walk the linked lists often, we mostly walk the
flat arary.
>> and tries to recalc bellman-ford every 4 seconds also.
No, it doesn't. It only does the
Dear all,
Babeld-1.8.3 is available from
https://www.irif.fr/~jch/software/files/babeld-1.8.3.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.8.3.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
The main news
> It happens with almost no data at all being passed except the babel overhead.
> I
> can watch it in wireshark.
Could you please try reproducing this with "babeld -d2", and send me the
logs by private mail?
___
Babel-users mailing list
>> I'll point out that the BIRD codebase is cleaner and better designed
>> than babeld, and might be able to scale better. I'd be interested in
>> seeing a comparison.
> Yeah, me too.
Toke, perhaps you'd like to post some instructions?
-- Juliusz
___
> One of my environments uses BGP full-table from 3 upstream ISPs (each
> with 785k routes currently).
Well, that's a lot. BGP is designed with that in mind -- it uses
incremental updates layered over a reliable protocol, and therefore scales
beautifully in a stable network. Babel uses
>> I tested the babel-1.8.3 release under some extreme loads with 90
>> routes present (30 ipv6 total)
> BTW, I disagree with the word "extreme".
We should have no problem with this kind of load on wired. OTOH, it's
rather extreme for wireless -- 802.11 doesn't behave well in dense
networks.
>
> I also discussed issues with tim (cc'd) was having on his raspberri pi
> (arm) based version. He seems to have got a much stabler result after
> reverting to 1.7.1.
Correct. In 1.7.1, babeld got more stable and less reactive. We tweaked
the logic again in 1.8.0 to make it more reactive again.
>> Interesting. AFAIK, ECN is only considered by AQM queues, so this implies
>> there's a queue in the way that's dropping Babel packets.
> There's fq_codel on every queue, which does FQ, and codel assumes
> everything is at least moderately TCP friendly (and/or reasonably
> responsive to ecn
> Recently I tried to deploy a few babel 1.8.2 nodes with the latest
> openwrt, which I had to back out rapidly because I was dropping so many
> babel packets under contention.
That's interesting. Could I please see a log?
> A patch to universally enable babel ecn in net.c "solves" this
> (I ran across this babelweb pic from my old c.h.i.p + rtod experience,
> which cracked 16sec of delay in the mcast queue:
Bufferbloat in the driver queues?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> in https://github.com/jech/babeld/pull/16 I provided a small patch that
> fixes a crash on ipv6-only nodes
The issue, I believe, was with interfaces that don't have a link-local
address (yet) when they are being monitored over the local interface. It
was triggered by your netlink patch --
Hi,
A number of fixes have accumulated in the master branch. I'd like to
release a 1.8.3 fairly soon, so if anyone has time to do some testing, I'd
appreciate the help.
Thanks.
babeld-1.8.3 (unreleased)
* Fixed a read-only two byte buffer overflow in the packet parser.
This is a
> I see a seprate repo for the new hmac code, the revised source
> specific stuff is where?, the rfc-bis stuff is in a branch. etc. It's
> confusing. can it all get rolled up into one thing now? :)
Yeah, it's a mess. I badly need a technician to give me a hand.
We've got the following branches:
> I think I agree that the manpage needs some clarification to note that
> the --cache option only affects the stream cache.
> In the meantime I uploaded mpv 0.29 which has adjusted the cache sizes a
> bit (although the behavior of --cache has not changed). Can you see if
> it has improved the
> I think I agree that the manpage needs some clarification to note that
> the --cache option only affects the stream cache.
> In the meantime I uploaded mpv 0.29 which has adjusted the cache sizes a
> bit (although the behavior of --cache has not changed). Can you see if
> it has improved the
> That's correct. The --cache option only affects the stream cache (which
> is correctly disabled by that option). The issue here was the size of
> the demuxer cache (which caches already demuxed packets).
This is completely unintuitive, and undocumented. From the manual page:
--cache=
> That's correct. The --cache option only affects the stream cache (which
> is correctly disabled by that option). The issue here was the size of
> the demuxer cache (which caches already demuxed packets).
This is completely unintuitive, and undocumented. From the manual page:
--cache=
> Juliusz is saying that he wants a nearly stateless homenet;
No, I'm not.
> for him, putting the public/primary functional block in the cloud makes
> sense
No, it doesn't.
Ted, please don't put words into my mouth. It's unpleasant, and it's
disrespectful.
-- Juliusz
> if the homenet loses its memory, it can simply refresh it from the cloud.
What?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
>> neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything
>> else that normal people run in their home relies on the DNS for
>> locating remote peers.
> If publishing things into global DNS worked reliably and automatically,
> and we had IPv6 everywhere, such designs would not be
> Why? What is wrong with the owner of the network selecting which devices
> / services he/she wants globally reachable
I don't think this is about global reachability (which is hopefully managed
by PCP), it's about exporting names into the global DNS. We ought to
distinguish the two -- you can
> Apparently my comment was clear as mud. I meant this:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-25
Quote, "YANG-based JSON that describes a Thing", unquote. 61 pages.
Revision 25, and still a draft. I wish you a lot of fun implementing that.
> Having a public/private zone pair
> By using DynDns are you proposing to remove the requirement of having
> a naming resolution mechanism internally in the homenet ?
No. Naming *internal* to the Homenet needs another mechanism, perhaps
what Ted is designing (and implementing), perhaps something else.
Exporting names from the
> One way to automate this would be using mud.
A bright light shines from the heavens, bathing you in its warm glow. An
enormous, white temple stands to the north, taking most of your view.
In order to enter the Temple of Homenet Naming, you must travel up the
large staircase that stands in
> On the other hand same thing using nsupdate (using TSIG and dynamic
> dns) is one command line + input file for nsupdate:
Cool.
Whichever end-to-end (host to DNS provider with no intermediate proxying)
encrypted and authentified protocol you pick, I'm with you.
-- Juliusz
>> And it's literally four lines of shell:
> vs
> while true; do
> (omitted for brevity)
You're doing end-to-end dynamic update over DNS, which is fine with me.
The exact transport we end up using doesn't matter that much.
You're not doing the proxying through a hidden master mandated by
> I am not speaking about discovery within the Homenet. I am speaking about
> exporting names into the global DNS, which is what Daniel's draft is
> about.
> Yes, but the problem is that you are treating this as if these are two
> separate problems, but they are not.
These are two
> I think the local ULA should be used for all intra-ULA connections. We had a
> debate about this about four years ago, and apparently the text in the HNCP
> spec reflects the outcome of that discussion, but I think we understand the
> problem better now and we should fix this.
Agreed.
I've re-read Section 6.5 of 7788, and it looks like I was wrong. Sorry,
I should not be writing technical mails in the middle of the night.
As far as I can tell from the wording of 6.5:
- creating ULA is SHOULD if there's no global IPv6, MUST NOT otherwise;
- creating private IPv4 is MAY if
> In order for services to be discoverable on the homenet, they have to
> publish their contact info on the homenet. The protocol that everyone
> uses for this is DNSSD. This is how you find your printer when you want
> to print to it. Nobody uses the ad-hoc DynDNS protocol for this.
I am not
>> But if we want homenet to be widely adopted, I do not think this is the
>> correct default behavior: it violates the principle of least surprise.
> There's no surprise, it just works. RFC 6724, Section 6, Rule 8.
Er, no. ULAs have global scope. My bad.
-- Juliusz
> In order for IPv6 to be useful, you need naming to work.
No argument here.
> But if we want homenet to be widely adopted, I do not think this is the
> correct default behavior: it violates the principle of least surprise.
There's no surprise, it just works. RFC 6724, Section 6, Rule 8.
--
> All of this can be done in the DNS without resorting to any other protocol.
Excellent.
So what technical reasons are there to prefer the complexity of
draft...front-end-naming-delegation over a trivial update protocol,
whether encapsulated in HTTPS or DNS?
-- Juliusz
During his talk, Ted claimed that he lost all connectivity when his uplink
went down. This should not happen -- HNCP normally maintains an IPv6 ULA
that remains stable no matter what happens to DHCPv6 prefix delegations or
DHCPv4 leases. This is described in Section 6.5 of RFC 7788, and it is
Dear all,
Since the 1990s, people have been putting their dynamically allocated IPv4
addresses into global DNS by using a family of gratuitiously incompatible
trivial protocols. The technique doesn't have an official name (let alone
a specification), and is usually referred to as DDNS, DynDNS or
For people who have missed the Babel meeting, both David and I have done
our best to write self-contained slides. They're here:
https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-hmac-in-babel-00
>REQ5: a Homenet implementation of Babel MUST use metrics that are of
>a similar magnitude to the values suggested in Appendix A of
>RFC 6126bis.
> "MUST" and "similar magnitude" are not a great pairing.
Fixed. This is now "must", the exact values are still SHOULD.
> I agree with
> §2.1, REQ5: I agree with Benjamin Kaduk that " MUST use metrics that are of
>a similar magnitude" is a bit vague to be used with a MUST.
This is now "must". Exact values are still SHOULD.
> §1.1: Please consider using the 8174 boilerplate. There is at least one
> instance of a lower case
> I do have some non-blocking comments:
Thank you very much, Alvaro.
> (1) I think that this document walks a fine line when Normatively
> referring to Appendix A in rfc6126bis given that it is an informative
> appendix.
Fixed to use non-normative language, as you suggested.
> (2) This reminds
Hi,
I've just watched Richard's presentation about DHCP health, and I'm
wondering whether at least the planned maintenance use case couldn't be
solved much more simply and elegantly by FORCERENEW (RFC 3203 + RFC 6704).
At the very least, I'd like to see it mentioned in the draft.
Thanks,
--
Dear all,
The Babel working group of the IETF will be meeting on Tuesday 17 July at
9:30 Montréal time (EDT, UTC-4)
1:30 UTC
3:30 Paris time (UTC+2)
Highlights include a presentation by David Schinazi about DTLS security
for Babel (joint work with Antonin Décimo), and a presentation by
> - draft-ietf-homenet-babel-profile-06 waiting on Juliusz for updated draft
My current draft of -07 is here:
https://raw.githubusercontent.com/jech/babel-drafts/master/draft-ietf-homenet-babel-profile/draft-ietf-homenet-babel-profile.xml
It addresses all of Tim Chown's Opsdir review, almost
> 2a02 is assigned to br-wan 2a06 is assigned to local-node which is
> a veth-pair bridged into br-client. The mesh is mesh0, mesh1 and so on.
> The node can be addressed by its 2a06 address. This is the default setup
> of gluon. When now communicating over the mesh, neither the 2a02 nor
> the
Hi, and sorry for the massive cross-posting. I suggest followups should
go to babel@ietf.
The mails that I'm receiving indicate that we (Babel@IETF) have confused
some people with our crypto plans. Thanks to all for your questions, and
let me please try to clarify things publicly.
Considering
>> [babel 1.9.0 will introduce incompatible wire-format for src-specific
>> routing]
> If I am building a network now that utilises source-specific routing, how
> can I best prepare for a migration path?
Make sure you run 1.8.2 or later, not an earlier version. Deploy your
network with no fear.
> For multi-homed devices it would be interesting being able to specify
> a preferred source address for routes exported via babel. If the preferred
> src address is not specified, the kernel will select the src address and
> thus will leak ipv6 addresses into a network where they are foreign.
>> If I am building a network now that utilises source-specific routing,
>> how can I best prepare for a migration path?
> If you can just deploy the new version everywhere and reboot the
> network, that would be the best. The 1.9.0 branch (and all future
> versions) are not experimental and will
> My biggest problem is that I don't have a very clear idea of how this all fits
> together.
Same here.
As I mentioned at the microphone in London, there's a lot of moving pieces
here, and everybody would feel much more comfortable if
1. we could have a look at Ted's implementation; and
2.
>> The draft lives here:
>>
>> https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls
> As far as the commit history goes, the file was first added to the
> repository above on 25 June 2018 (four days ago), then it was updated
> three times on 27 June 2018 and two times on 29
Dear all,
While working on the HMAC security mechanism, we have found an off-by-two
error in the packet parser which could cause babeld to read two octets
after the end of the read buffer. The overflow is not believed to be
exploitable -- a maliciously crafted packet will merely cause two octets
Dear Denis,
Thank you very much for your kind mail.
Unfortunately, I think there might be some confusion:
- DTLS is Stenberg-style security;
- HMAC is Ovsienko-style security,
- it has four variants (7298, 7298bis, DKC, Stenberg)
- two of which have fatal flaws (7298 and
Dear all,
I've just rebased the "unicast" branch over 1.8.2. This means that:
- if you're tracking branch "unicast", you'll need to "git pull --rebase";
- if you've got a branch based on "unicast", you'll need to rebase
(Antonin, Clara, Weronika -- that means you).
Happy rebasing,
--
Dear all,
Clara Dô and Weronika Kołodziejak, in copy of this mail, are currently
working on adding symmetric authentication (à la RFC 7298) to babeld.
We're wondering how to provision the keys.
My current choice would be have a new configuration statement
hmac 1 sha1
> Well, let me invent something. I throw together my network and it
> names the printers as printer1 and printer2. Being a stickler,
> I decide to rename them as Printer 1 and Printer 2. I mess around
> and find a config file somewhere and manually edit it.
Let me rephrase it:
«
https://bugs.kde.org/show_bug.cgi?id=394496
Bug ID: 394496
Summary: KTorrent sends upload_only as a string
Product: ktorrent
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity:
> You could also take a look
> at https://godoc.org/github.com/mailru/easygo/netpoll
I don't have a net.Conn, just a raw file descriptor.
-- Juliusz
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
> If you do this in Go, you should use golang.org/x/sys/unix package
> rather than the syscall package.
What's the advantage? (In this particular case, not in general.)
> But since you have to call C anyhow, I would suggest just doing it in C.
Yeah, I guess it's simpler.
> There isn't any way
I'm interfacing with a C library that expects to do its own I/O, but
wants to be called after a file descriptor is ready for read. My code
currently looks roughly like this:
var fdset syscall.FdSet
var bits = unsafe.Sizeof(fdset.Bits[0]) * 8
fdset.Bits[uintptr(fd)/bits] |= (1 << (fd
Package: babeld
Version: 1.8.1-1
Hi,
Babeld-1.8.1 has a rather serious bug, that makes it unsuitable for
traditional IPv4 networks (as opposed to pure meshes). 1.8.2 fixes the
bug.
https://github.com/jech/babeld/commit/157e44a4a507786f5626070d9b1f3e371389
Please upgrade to 1.8.2.
>> https://play.golang.org/p/f_qy1ZI56w7
> Got it, thanks.
It took me a while. I think the point Ian is making is that an
unexported field is not CanSet.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
Package: mpv
Version: 0.27.2-1
The flag ytdl is set by default, which breaks opening m3u playlists over
the network -- only the last entry of the playlist is played. Running
with --ytdl=no works around the issue.
Also confirmed in 0.28.2-1.
Package: mpv
Version: 0.28.2-1
When streaming over HTTP from localhost, the in-memory cache grows
seemingly without bound (RSS just got up to 700MB). Running
with --cache=no does *not* work around the issue.
Downgrading to 0.27.2-1 fixes the issue.
Package: mpv
Version: 0.27.2-1
The flag ytdl is set by default, which breaks opening m3u playlists over
the network -- only the last entry of the playlist is played. Running
with --ytdl=no works around the issue.
Also confirmed in 0.28.2-1.
Package: mpv
Version: 0.28.2-1
When streaming over HTTP from localhost, the in-memory cache grows
seemingly without bound (RSS just got up to 700MB). Running
with --cache=no does *not* work around the issue.
Downgrading to 0.27.2-1 fixes the issue.
/
This version fixes a bug introduced in 1.8.1 that prevented IPv4 routes
from being redistributed. There are no other changes.
Enjoy,
-- Juliusz Chroboczek
pgpF4ODGV1yUo.pgp
Description: OpenPGP Digital Signature
___
Babel-users mailing list
Babel
> it works!
Thanks for the info. It's a serious bug, so I'll make a release this
week-end -- please let me know if you see anything bad.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
Babeld-1.8.1 breaks redistribution of IPv4 routes (but not of IPv4 local
addresses). Sorry for that.
Here's the bug report:
https://github.com/jech/babeld/issues/13
I've committed a quick fix into master:
https://github.com/jech/babeld/commit/157e44a4a507786f5626070d9b1f3e371389
The
> Using master / 1.8.1 really does improve the situation with triggered
> updates. They happen consistently and quickly.
Thanks for the info.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
> Perhaps he refers to the RFC8174 update to the boilerplate:
Ah, thanks. Will do.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> you should refer to 8174.
Perhaps you could kindly justify your advice? Non-capitalised "must" is
used just once in this document, and I don't see any opportunity for
ambiguity.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
> Callbacks are rarely used in Go's ecosystem.
https://golang.org/pkg/sort/#Slice
https://golang.org/pkg/sync/#Map.Range
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
Hi,
I've just spent four days in Osijek, a small city in the East of Croatia,
invited by Valent Turković (in copy of this mail). It was an interesting
stay.
For those of you who are not up to scratch in European Geography, the part
of Croatia that everyone knows about is the west, on the
>> Please be also aware that it currently doesn't do source-specific
>> routing (if you don't know what that is, it's not a problem for you.)
> What a pity. SADR is exactly the reason I'm using Babel for.
Give me two-three weeks, then.
-- Juliusz
___
Hi,
> I know Babel can now run over unicast addresses.
Yes, and I would welcome help testing this feature.
> How can I improve my babeld configuration to utilize the new feature?
First, you need to switch to branch "unicast":
git checkout unicast
Then, rebuild babeld, and put the following
>> Recently, I've been mulling over move semantics and their
>> implication for WireGuard's support for anycast addressing.
Perhaps you could explain the purpose of having anycast support in a VPN
implementation?
___
WireGuard mailing list
> i need to reset the tcp connection manually , if one request come from
> ipLayer.SrcIP
> = 10.2.3.1 then i need to sent the reset connection packet
I could be wrong, but I don't think the sockets API makes this
possible -- RST segments are normally only sent by the kernel upon
receiving a
Dear all,
Version 1.8.1 of babeld, the Babel routing daemon, is available from
https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz
https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz.asc
This release makes two important changes, and upgrading is strongly
recommended.
> you may find this video interesting:
> https://youtu.be/agPdI7cY5eU
Cool. I see some more info on https://meshpoint.me/
> We are using Babel routing for MeshPoint, and we would like to become
> a more active contributors to Babel project.
Let's try to arrange to meet and have a chat. I'll
401 - 500 of 3650 matches
Mail list logo
