Bug#1010246: dibbler-client: dibbler is splitting a /60 into 2 /68 preventing RA from being able
Package: dibbler-client
Version: 1.0.1-1.1
Severity: normal
Tags: patch
Dear Maintainer,
When you run dibbler-client and configure it to request a prefix
delegation and receive a /60 and want it to be split on 2 interfaces,
the current version of dibbler as packaged by Debian will create 2 /68
prefixes. Because of this you can't use router announcement as an easy
way to get IPv6 configured on the interfaces.
For instance:
21:35 Client NoticePD: Adding prefix 2601:1234:5678:9a00::/60 to all
interfaces (prefix will be split to /68 prefixes if necessary).
^^^
21:35 Client Info PD: Using 2 suitable interface(s):eth2.10 eth2.30
21:35 Client NoticePD: Adding prefix 2601:1234:5678:9a00:9000::/68 on the
eth2.10/9 interface.
21:35 Client NoticePD: Adding prefix 2601:1234:5678:9a00:7000::/68 on the
eth2.30/7 interface.
It turns out that upstream code for dibbler-client has already a better
solution with this this commit:
https://github.com/tomaszmrugalski/dibbler/commit/41fa1dbc148331ec1a465ee3be449cf37d05943a
It would be great to fix this in the patched version of dibbler.
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-13-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dibbler-client depends on:
ii cdebconf [debconf-2.0] 0.260
ii debconf [debconf-2.0] 1.5.77
ii libc6 2.31-13+deb11u3
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii ucf 3.0043
Versions of packages dibbler-client recommends:
pn dibbler-doc
ii resolvconf 1.87
dibbler-client suggests no packages.
-- debconf information:
* dibbler-client/start: true
* dibbler-client/options: dns
* dibbler-client/interfaces: eth1
dibbler-client/title:
diff -ur dibbler-1.0.1.bak/ClntIfaceMgr/ClntIfaceMgr.cpp
dibbler-1.0.1/ClntIfaceMgr/ClntIfaceMgr.cpp
--- dibbler-1.0.1.bak/ClntIfaceMgr/ClntIfaceMgr.cpp 2015-07-30
14:35:53.0 -0700
+++ dibbler-1.0.1/ClntIfaceMgr/ClntIfaceMgr.cpp 2022-04-26 22:18:09.259630252
-0700
@@ -433,6 +433,21 @@
return modifyPrefix(iface, prefix, prefixLen, 0, 0, PREFIX_MODIFY_DEL,
params);
}
+/// Returns number of bits required to store specific number of interfaces
+///
+/// @param i
+/// @return ceil(log2(i)) or 0 for 0
+int TClntIfaceMgr::numBits(int i) {
+int bits = 0;
+if (i == 0) {
+return (0);
+} else {
+i--;
+}
+while (i >>= 1) { ++bits; }
+return (bits + 1);
+}
+
bool TClntIfaceMgr::modifyPrefix(int iface, SPtr prefix, int
prefixLen,
unsigned int pref, unsigned int valid,
PrefixModifyMode mode,
@@ -562,66 +577,47 @@
stringstream prefix_split; // textual representation, used to pass as
script
for (TIfaceIfaceLst::const_iterator i=ifaceLst.begin(); i!=ifaceLst.end();
++i) {
-char buf[16];
-int subprefixLen;
-memmove(buf, prefix->getAddr(), 16);
-
-if (ifaceLst.size() == 1) {
-// just one interface - use delegated prefix as is
-subprefixLen = prefixLen;
-} else if (ifaceLst.size()<256) {
-subprefixLen = prefixLen + 8;
-int offset = prefixLen/8;
-if (prefixLen%8 == 0) {
-// that's easy, just put ID in the next octet
-buf[offset] = (*i)->getID();
-} else {
-// here's fun
-uint16_t existing = readUint16(buf+offset);
-uint16_t bitmask = 0xff00;
-uint16_t infixmask = ((uint8_t)(*i)->getID()) << 8;
-bitmask = bitmask >> (prefixLen%8);
-infixmask = infixmask >> (prefixLen%8);
-
-// clear out if there is anything there, i.e. server assigned
prefix
-// with garbage in host section
-existing = existing & (~bitmask);
-existing = existing | (bitmask & infixmask);
-writeUint16(buf+offset, existing);
-}
+int subprefixLen = 0;
-} else {
+int numPrefixes = ifaceLst.size();
+
+if (numPrefixes > 256) {
// users with too much time that play with virtual interfaces are
out of luck
Log(Error) << "Something is wrong. Detected more than 256
interface." << LogEnd;
return false;
}
-SPtr tmpAddr = new TIPv6Addr(buf, false);
+SPtr subprefix = calculateSubprefix(prefix, prefixLen,
+ numPrefixes,
Bug#635847: libkrb5support0: library initialization errors in Perl module context
Hello, I face this bug. For me it's quite anoying because I use Authen::Krb5 in order to read a keytab and get a tgt ticket so that I can do GSSAPI in SASL without the need to have a password in clear text. Would be great to see this bug fixed. Matthieu. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525391: cyrus-imapd-2.3: Can we get this into unstable yet?
Package: cyrus-imapd-2.3 Followup-For: Bug #525391 Almost one year since last report, and still no sign of life in sid, unstable, not to speak about testing or the future squeeze. New version of cyrus imap brings new functionnalities that could be useful to mail administrators and users. I'm for example thinking about the sharedseen flag that was introduced in 2.3.10. What is stopping/blocking the debian cyrus team to push it to sid ? Regards. Matthieu. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572841: postfix: smtpd crash with signal 6 when using ldap with starttls for domain maps lookup
Package: postfix Version: 2.5.5-1.1 Severity: important My postfix is using ldap for virtual_mailbox_map validation (ie. virtual_mailbox_map = /etc/postfix/ldap.cf). When trying to add start_tls = yes to the /etc/postfix/ldap.cf it makes smtpd crash when the server receive a RCPT TO message from the client (can be tested with netcat or telnet to simulate an SMTP exchange between a client and postfix). Here are the messages: Mar 7 02:15:12 ecvfwle02 postfix/master[30346]: warning: process /usr/lib/postfix/smtpd pid 31245 killed by signal 6 Mar 7 02:15:12 ecvfwle02 postfix/master[30346]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling Several trials yield the same error. Testing the ldap.cf file on command line postmap -q m...@matws.net ldap:/etc/postfix/ldap.cf works with start_tls. I made tests without start_tls: no crash. I made tests with ldaps (and no start tls of course): no crash. Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages postfix depends on: ii adduser 3.110 add and remove users and groups ii debconf [debconf- 1.5.24 Debian configuration management sy ii dpkg 1.14.28Debian package management system ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [ ii libsasl2-22.1.22.dfsg1-23+lenny1 Cyrus SASL - authentication abstra ii libssl0.9.8 0.9.8g-15+lenny6 SSL shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii netbase 4.34 Basic TCP/IP networking system ii ssl-cert 1.0.23 simple debconf wrapper for OpenSSL postfix recommends no packages. Versions of packages postfix suggests: ii bsd-mailx [mail-r 8.1.2-0.20071201cvs-3 A simple mail user agent ii libsasl2-modules 2.1.22.dfsg1-23+lenny1 Cyrus SASL - pluggable authenticat pn postfix-cdb none (no description available) ii postfix-ldap 2.5.5-1.1 LDAP map support for Postfix pn postfix-mysql none (no description available) ii postfix-pcre 2.5.5-1.1 PCRE map support for Postfix pn postfix-pgsql none (no description available) pn procmail none (no description available) pn resolvconfnone (no description available) ii sasl2-bin 2.1.22.dfsg1-23+lenny1 Cyrus SASL - administration progra pn ufw none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: ntp server didn't support mssntp
Subject: ntp server didn't support mssntp Package: ntp Version: 4.2.4p4+dfsg-8lenny3 Severity: wishlist Tags: patch Current version of ntp in debian do not support MS SNTP extension. This extension is needed by Windows workstation in order to trust ntp source from AD server. Lately the Samba project made great improvement in the next version of Samba: Samba4 which is supposed to be a real replacement to Microsoft Active Directory. In order to act completely as an Domain Controller the Samba4 server must be able to act as a ntp server with the MS SNTP extension. Version 4.2.6 of ntp (released on 12/12/09) now include patches for allowing this extension but must be complied specifically with the option --enable-ntp-signd to effectively build this extension. Building this extension do not mean that it wil be active by default, in fact it has to be opted in by adding the following directive to ntp.conf: restrict foobar mssntp Where foobar is either default or a network address. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On 22/12/2009 20:53, Kurt Roeckx wrote:
On Tue, Dec 22, 2009 at 02:33:54PM +0300, Matthieu Patou wrote:
Subject: ntp server didn't support mssntp
Package: ntp
Version: 4.2.4p4+dfsg-8lenny3
Severity: wishlist
Tags: patch
You tagged it patch, but you don't provide any patch?
No good excuse, but I was missing a category saying that the patch is
already in the upstream source.
Current version of ntp in debian do not support MS SNTP extension.
[...]
Version 4.2.6 of ntp (released on 12/12/09) now include patches for
allowing this extension but must be complied specifically with the
option --enable-ntp-signd to effectively build this extension.
So this is a wishlist bug asking for a new upstream version
with tht configure option? Any idea why this isn't on by default?
See the talk in this bug
https://support.ntp.org/bugs/show_bug.cgi?id=1405. Basically I'll say
that Ph. D. Mills is a bit overcautious as he don't want ntp to be
blamed for an admin that activated this option and get flooded. It's in
fact the same problem as refclock that has to be explicitly activated
during configure if you want to have it (as debian does).
I am not of course willing to make debian user run a risk when using the
new version of ntp with this extension. So it must be noted that even if
the extension is built in the ntp server it must be opted in to start to
work. This piece of code protects the emission to the signed socket:
if (flags RES_MSSNTP) {
send_via_ntp_signd(rbufp, xmode, xkeyid, flags, xpkt);
return;
}
If no restrict is defined or if didn't match the user ip address then
the send_via_ntp_signd is not called.
It's obvious that any publicly available server shoudn't have this
activated.
In any case if this option is activated and no samba4 server is there to
answer (because the admin has misconfigurated his/her server). There
will be no such hang. The local kernel knows if the socket does not
exist, or no process is bound to it (because the author of the patch
choose to use unix domain socket).
(from an strace of ux_client, the code I based the ntp code on):
connect(3, {sa_family=AF_FILE, path=/tmp/ux_demo}, 110) = -1
ECONNREFUSED (Connection refused)
So it will cost 1 syscall.
Of course if the option is activated and a samba4 server is running then
there is a risk of DOS _but_ it means that the admin is making his
active directory directly available on internet so I guess that there
worse problems in this case.
Matthieu.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On 22/12/2009 22:25, Kurt Roeckx wrote:
On Tue, Dec 22, 2009 at 09:53:00PM +0300, Matthieu Patou wrote:
On 22/12/2009 20:53, Kurt Roeckx wrote:
On Tue, Dec 22, 2009 at 02:33:54PM +0300, Matthieu Patou wrote:
Subject: ntp server didn't support mssntp
Package: ntp
Version: 4.2.4p4+dfsg-8lenny3
Severity: wishlist
Tags: patch
You tagged it patch, but you don't provide any patch?
No good excuse, but I was missing a category saying that the patch
is already in the upstream source.
Current version of ntp in debian do not support MS SNTP extension.
[...]
Version 4.2.6 of ntp (released on 12/12/09) now include patches for
allowing this extension but must be complied specifically with the
option --enable-ntp-signd to effectively build this extension.
So this is a wishlist bug asking for a new upstream version
with tht configure option? Any idea why this isn't on by default?
See the talk in this bug
https://support.ntp.org/bugs/show_bug.cgi?id=1405. Basically I'll
say that Ph. D. Mills is a bit overcautious as he don't want ntp to
be blamed for an admin that activated this option and get flooded.
It's in fact the same problem as refclock that has to be explicitly
activated during configure if you want to have it (as debian does).
I am not of course willing to make debian user run a risk when using
the new version of ntp with this extension. So it must be noted that
even if the extension is built in the ntp server it must be opted in
to start to work. This piece of code protects the emission to the
signed socket:
if (flags RES_MSSNTP) {
send_via_ntp_signd(rbufp, xmode, xkeyid, flags,xpkt);
return;
}
If no restrict is defined or if didn't match the user ip address
then the send_via_ntp_signd is not called.
It's obvious that any publicly available server shoudn't have this
activated.
As I understand David L. Mills, it always opens a TCP socket
independent of the configuration file, and that that can be
used to DoS the server. If that's not the case I see no
problem with enabling this by default.
I'm sorry to put it through David L. Mills was wrong on this.
The patch never used a TCP socket but a unix socket. And since the
initial patch the code has been reworked to be wrapped in a test that
avoid trying to open the unix socket unless the requester has been
allowed to do so in the configuration.
It's this piece of code that check and if allowed open the signd socket.
if (flags RES_MSSNTP) {
send_via_ntp_signd(rbufp, xmode, xkeyid, flags,xpkt);
return;
}
Matthieu.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On 23/12/2009 00:00, Kurt Roeckx wrote: On Tue, Dec 22, 2009 at 11:29:24PM +0300, Matthieu Patou wrote: I'm sorry to put it through David L. Mills was wrong on this. The patch never used a TCP socket but a unix socket. And since the initial patch the code has been reworked to be wrapped in a test that avoid trying to open the unix socket unless the requester has been allowed to do so in the configuration. I guess I'm missing something here. I'm just going to make a guess of how this works (if enabled): 1) We wait to get a UDP message 2) We send something to samba over the unix domain socket He thought this was over TCP, and that's beside the point, we need to wait until there is room in the kernel buffer. This is only if there is a request for a signed packet. 3) We wait for a reply from samba, we do not process any other packages while waiting. 4) We send a message back 5) go to 1) And the restrict lines controls if we're going to send something to samba or not. Right An other alternative could be that we don't wait for packet back but that samba actually sends back the reply, doesn't make much difference. We have to wait for ntp to use event pooling as it will greatly ease the developpement of an async behavior, that is a todo of next version as far as I understand. Anyway, in either case I don't see a problem with giving the admin the option of enabling it in the config file. My point of view is we make it available by compiling it and leave up to the admin to activate it or not. We can in order to avoid problem not put this option in the ntp.conf so that only admins really willing to activate it will do (hopefully). Matthieu. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
