Bug#1023958: Request to enable CONFIG_AF_KCM

2022-11-13 Thread Harald Welte
Package: src:linux
Version: 6.0.8-1
Severity: wishlist

It has been 6 years (since Linux kernel v4.10) that upstream introduced
a rather useful feature for protocols implementing binary message based
protocols on top of TCP called KCM.  Unfortunately during all those
years and even until Debian unstable today, it is not possible to use
this feature as the kernels are compiled with CONFIG_AF_KCM disabled.

This creates a rather unfortunate chicken-and-egg situation where there
are userspace programs/libraries that would benefit from its related
performance, but cannot use it with unmodified Debian kernels and hence
are less motivated to enable it.  So lack of distribution support
hinders adoption by more applications.

Background on KCM can be found at https://lwn.net/Articles/657999/ and
in the kernel source at Documentation/networking/kcm.rst

I would hence like to request enabling CONFIG_AF_KCM in the Debian
kernel packages.  Since STREAM_PARSER and BPF_SYSCALL are both already
enabled, there are no additional dependencies.

AF_KCM can be built as module, so it should not affect any systems where
no applications use it.  It would only be auto-loaded once an AF_KCM
socket is being used for the first time.

Thanks for your consideration.

-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.0.0-4-amd64 depends on:
it  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20220905-1
ii  linux-base  4.9

Versions of packages linux-image-6.0.0-4-amd64 recommends:
iu  apparmor 3.0.7-1+b2
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.0.0-4-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-pc 2.06-4
pn  linux-doc-6.0   

Versions of packages linux-image-6.0.0-4-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20221012-1
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20221012-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information



Bug#1013330: linux-image-5.18.0-0.bpo.1-arm64: kernel panic in dpaa2_eth_free_tx_fd

2022-06-21 Thread Harald Welte
[   46.826808] Memory Limit: none
[   46.829852] ---[ end Kernel panic - not syncing: Oops: Fatal exception in 
interrupt ]---


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-15-arm64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.18.0-0.bpo.1-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.18.0-0.bpo.1-arm64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.18.0-0.bpo.1-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.18  

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)



Bug#846913: Acknowledgement (CONFIG_GTP is not set / gtp.ko module not built)

2016-12-04 Thread Harald Welte
Not that this would have any significance to Debian, but just for your
information, the latest Fedora, OpenSUSE and Ubuntu releases (shipping
4.8.0 or later) have all enabled CONFIG_GTP.

It would be great if people (myself included) could run their GTP-using
software also on Debian :)

Regards,
Harald

-- 
- Harald Welte <lafo...@gnumonks.org>   http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)



Bug#846913: CONFIG_GTP is not set / gtp.ko module not built

2016-12-04 Thread Harald Welte
Package: src:linux
Version: 4.8.7-1
Severity: wishlist

Dear Debian kernel team, it would be great if you could activate the
(newly-introduced) CONFIG_GTP kernel option to build the related kernel
module.  The Module implements the 3GPP GTP (Generic Tunneling Protocol)
and has no impact on any other parts of the kernel or networking
sub-system, except that one addtiional tunneling protocol is present,
which some users might use and others not.

There are several Free Software userspace programs using the GTP module,
including OpenGGSN, ergw and OpenAirInterface.

Thanks in advance for your consideration!

-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-rc2+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.8.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kmod23-1
ii  linux-base  4.5

Versions of packages linux-image-4.8.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2

Versions of packages linux-image-4.8.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.03+dfsg-14
ii  grub-efi-amd64  2.02~beta3-3
pn  linux-doc-4.8   

Versions of packages linux-image-4.8.0-1-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20160824-1
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20160824-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information



Bug#798375: Stale SCTP sockets / recovery only by reboot

2015-09-08 Thread Harald Welte
Package: src:linux
Version: 3.16.5-1
Severity: normal
Tags: patch

I appear to have run into a SCTP bug that has been around since 2009:
http://sourceforge.net/p/lksctp/mailman/message/23492403/
and has been fixed in mainline as part of commit
bdf6fa52f01b941d4a80372d56de465bdbbd1d23.

However, the bug was still visible in the Debian kernel version
3.16.5-1, and I suppose all that's needed is a cherry-pick.

It is possible to reproduce as follows:

* start a SCTP server socket (bind/listen) on linux
* make the client connect to that
* accept() the connection on the server
* make the client disappear suddenly (e.g. power it down, disconnect its
  network cable) in a way that there is no handshake to terminate the
  association
* close the server program
** linux sends SHUTDOWN and associated retansmissions
* start the server program again
* make the client re-connect
** INIT/INIT_ACK/HEARTBEAT/HEARTBEAT_ACK/DT1/SACK messages can be seen
   in wireshark on the server and traverse nicely to and from the client,
   but none of that data ever arrives on th socket.  The re-started
   server never even receives any notification about the new connection,
   thre is subequently no socket being created.

I double-checked, no other process had a clone of that socket open from
the userspace point of view.

The only way I fould to recover was to reboot the server system, which
of course is quite annoying.  Unloading the sctp kernel module was not
an option, as it still had a reference count, despite no SCTP sockets
existing anymore in the system.

The issue was possible to reproduce several times, so itw as not some
strange one-off behavior.

-- Package-specific info:
** Version:
Linux version 3.16-3-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 
(Debian 4.8.3-12) ) #1 SMP Debian 3.16.5-1 (2014-10-10)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16-3-amd64 
root=UUID=2fa8d876-a03f-447f-bda0-d7f6fed53004 ro

** Not tainted

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-3.16-3-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.57
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod21-1
ii  linux-base  4.0
ii  module-init-tools   21-1

Versions of packages linux-image-3.16-3-amd64 recommends:
ii  firmware-linux-free  3.4

Versions of packages linux-image-3.16-3-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.03+dfsg-10
ii  grub-pc 2.02~beta2-26
pn  linux-doc-3.16  

Versions of packages linux-image-3.16-3-amd64 is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
ii  firmware-iwlwifi0.44
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
ii  firmware-ralink 0.44
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
  linux-image-3.16-3-amd64/postinst/depmod-error-initrd-3.16-3-amd64: false
  linux-image-3.16-3-amd64/prerm/removing-running-kernel-3.16-3-amd64: true
  linux-image-3.16-3-amd64/postinst/mips-initrd-3.16-3-amd64:



Bug#337713: [netfilter-core] [PATCH] Null pointer access in nf_queue()

2005-11-07 Thread Harald Welte
On Mon, Nov 07, 2005 at 05:39:53PM +0900, Horms wrote:

 I did some disasembling fun and games, and I'm pretty sure the patch
 below will fix your problem. I'll fire of a build, I'd be greateful if
 you could test it.

Sorry, Horms, you must have missed my previos fix (that does exactly the
same).  I've already posted it to netdev, and IIRC, Arnaldo has merged
it for net-2.6.15.

Sorry for not Cc'ing you with the fix, it seems like I only reported
back to bugzilla :(

-- 
- Harald Welte [EMAIL PROTECTED] http://netfilter.org/

  Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed.-- Paul Vixie


pgpWjsIM8gAda.pgp
Description: PGP signature


Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)

2005-11-05 Thread Harald Welte
On Sat, Nov 05, 2005 at 12:21:00AM +, Christoph Hellwig wrote:
 On Fri, Nov 04, 2005 at 12:29:20PM +0900, Horms wrote:
  do I take that comment to mean that upstream can't update the
  drivers but Debian can? And if so, do you recommend updating 
  Debian's kernel packages, or putting the updates elsewhere?
 
 Well, we could upstream, but so far no one is annoyed enough to
 overrid the driver maintainer.  

This is outrageous.

Do you know any contacts at Intel to whom we could complain?  I guess
there would be many people willing to write a nice email about how
impractical (actually, insane) such a policy is?

-- 
- Harald Welte [EMAIL PROTECTED]  http://gnumonks.org/

Privacy in residential applications is a desirable marketing option.
  (ETSI EN 300 175-7 Ch. A6)


pgptj6y6wwuGN.pgp
Description: PGP signature


Bug#336431: [PATCH] fix ip_conntrack_helper_pptp build when CONFIG_IP_NF_NAT_NEEDED=n

2005-11-03 Thread Harald Welte
On Mon, Oct 31, 2005 at 06:13:55PM -0700, dann frazier wrote:
 As reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336431,
 ip_conntrack_helper_pptp in 2.6.14 fails to build if
 CONFIG_IP_NF_NAT_NEEDED isn't enabled.  This patch fixes this by
 disabling manipulation of the dir field of ip_conntrack_expect
 structures when full nat isn't configured.  Compile tested only.

Thanks for reporting this bug.   Yasuyuki Kozakai has submitted a
slightly cleaner version, so I'm merging his patch.

-- 
- Harald Welte [EMAIL PROTECTED] http://netfilter.org/

  Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed.-- Paul Vixie


pgpYYW3XykCb9.pgp
Description: PGP signature


Bug#336431: [PATCH] fix ip_conntrack_helper_pptp build when CONFIG_IP_NF_NAT_NEEDED=n

2005-11-03 Thread Harald Welte
On Thu, Nov 03, 2005 at 09:29:53AM -0700, dann frazier wrote:
 tags 336431 + upstream
 tags 336431 + patch
 stop
 
 On Thu, 2005-11-03 at 10:54 +0100, Harald Welte wrote:
  On Mon, Oct 31, 2005 at 06:13:55PM -0700, dann frazier wrote:
   As reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336431,
   ip_conntrack_helper_pptp in 2.6.14 fails to build if
   CONFIG_IP_NF_NAT_NEEDED isn't enabled.  This patch fixes this by
   disabling manipulation of the dir field of ip_conntrack_expect
   structures when full nat isn't configured.  Compile tested only.
  
  Thanks for reporting this bug.   Yasuyuki Kozakai has submitted a
  slightly cleaner version, so I'm merging his patch.
 
 Thanks for the response Harald.
 
 Looks like this is the patch we should use:
   http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=2991

no, it's 

http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3001

sorry for the confusion.

-- 
- Harald Welte [EMAIL PROTECTED] http://netfilter.org/

  Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed.-- Paul Vixie


pgpznfMHzC1Cl.pgp
Description: PGP signature