similar to: [Bug 1113] New: integer overflow in xt_TCPMSS

On Thu, Sep 10, 2015 at 19:34:21 -0400, Nathan Stratton Treadway wrote: > It seems that when the cksum is incorrect, it is always off by 1. > [...] > Am I correct in concluding that this cksum problem is a bug in Tinc? After investigating this further, I'm fairly certain that problem originates in the following lines of the clamp_mss() function in route.c: [...] csum ^=

We have a Zenoss server in our main office monitoring (among many other things) an Apache server in a remote network, with a Tinc link between the two networks. The monitoring simply involves making an HTTP request to a URL once every 5 minutes and confirming that a response page comes back. Most of the requests to this particular web server succeed (and similar requests to other web servers

http://bugzilla.netfilter.org/show_bug.cgi?id=590 Summary: iptables unknown target data Product: iptables Version: CVS (please indicate timestamp) Platform: i386 OS/Version: Ubuntu Status: NEW Severity: normal Priority: P1 Component: iptables AssignedTo: laforge at netfilter.org ReportedBy:

Just looked at your prior mail, and it was using 'usbhid' based on your output. If 'modprobe' exists on your router, what response do you get to 'modprobe usbhid'? - Tim On February 24, 2014 2:56:16 AM CST, Tim Dawson <tadawson at tpcsvc.com> wrote: >Either it is not loaded, or the usb serial and/or hid drivers are not >loaded, which appear to have been used

Either it is not loaded, or the usb serial and/or hid drivers are not loaded, which appear to have been used on your Debian box. - Tim On February 24, 2014 1:12:36 AM CST, Josu Lazkano <josu.lazkano at gmail.com> wrote: >Thanks again. > >This is the lsmod output: > ># lsmod >aead 4256 0 >arc4 1312 2 >b43

Thanks again. This is the lsmod output: # lsmod aead 4256 0 arc4 1312 2 b43 324014 0 bcma 28621 1 b43, button_hotplug 2800 0 cfg80211 172273 2 b43,mac80211, cifs 190077 0 compat 651 3 b43,mac80211,cfg80211, crc16 1015 1 ext4, crc_ccitt

https://bugs.freedesktop.org/show_bug.cgi?id=84424 Priority: medium Bug ID: 84424 Assignee: nouveau at lists.freedesktop.org Summary: nouveau crash log [mesa-10.3.0] Severity: normal Classification: Unclassified OS: All Reporter: reuben.m at gmail.com Hardware: Other Status: NEW

Hi, We've been experiencing repeated (every other day) oopses on hosts with high load glusterfs accesses. Co-occurrent (not immediately tho, but there is some sort of connection) are hanging nginx processes (doing the accessing), which can not be stopped, killed and also block the shutdown of the respective openvz instance. I think I remember at least one instance where this occurred without

https://bugs.freedesktop.org/show_bug.cgi?id=72599 Priority: medium Bug ID: 72599 Assignee: nouveau at lists.freedesktop.org Summary: [NVC0] null pointer dereference (nouveau_fence_wait_uevent.isra.5) QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux

I'm trying to accomplish what I had hoped would be a fairly simple filtering of traffic to my VMs, but I'm hitting a snag. The VMs are allowing traffic when I wouldn't expect them to. Host and Guest are both running the same platform: Ubuntu 12.04.4 LTS 0.9.8-2ubuntu17.19 I have a basic bridge enabled on the host: brctl addbr brdg brctl addif brdg eth1 ip link set brdg up The host

https://bugzilla.netfilter.org/show_bug.cgi?id=662 Phil Oester <netfilter at linuxace.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |netfilter at linuxace.com Resolution|

Make sure you have: /proc/sys/net/bridge/bridge-nf-call-iptables = 1 On 5/26/2014 1:35 PM, Matt LaPlante wrote: > I'm trying to accomplish what I had hoped would be a fairly simple > filtering of traffic to my VMs, but I'm hitting a snag. The VMs are > allowing traffic when I wouldn't expect them to. > > Host and Guest are both running the same platform: > Ubuntu

On 5/28/2014 10:10 AM, Laine Stump wrote: > On 05/27/2014 02:46 AM, Brian Rak wrote: >> Make sure you have: >> >> /proc/sys/net/bridge/bridge-nf-call-iptables = 1 > That doesn't make sense. bridge-nf-call-iptables controls whether or not > traffic going across a Linux host bridge device will be sent through > iptables, but the rules created by nwfilter are applied

Hi, I'm running CentOS 6.5 as NFS server (v3 and v4) and exporting Ext4 and XFS filesystem. After many months that all works fine today the server crash: Jan 30 09:46:13 qb-storage kernel: ------------[ cut here ]------------ Jan 30 09:46:13 qb-storage kernel: WARNING: at lib/list_debug.c:26 __list_add+0x6d/0xa0() (Not tainted) Jan 30 09:46:13 qb-storage kernel: Hardware name: PowerEdge

Dear Devs, I have x4 4TB HDDs formatted with: mkfs.btrfs -L bu-16TB_0 -d raid1 -m raid1 /dev/sd[cdef] /etc/fstab mounts with the options: noatime,noauto,space_cache,inode_cache All on kernel 3.8.13. Upon using rsync to copy some heavily hardlinked backups from ReiserFS, I''ve seen: The following "block rsv returned -28" is repeated 7 times until there is a call trace

On 05/27/2014 02:46 AM, Brian Rak wrote: > Make sure you have: > > /proc/sys/net/bridge/bridge-nf-call-iptables = 1 That doesn't make sense. bridge-nf-call-iptables controls whether or not traffic going across a Linux host bridge device will be sent through iptables, but the rules created by nwfilter are applied to the "vnetX" tap devices that connect the guest to the

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 6 Jan 2011 20:59:08 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=26242 > > Summary: BUG: unable to handle kernel NULL pointer dereference > at (null) > Product: Memory Management >

If lwIP encounters a half-open connection (e.g. due to a restarted application reusing the same port numbers) it will correctly send a RST but will not resend the SYN until one retransmission timeout later (approximately three seconds). This can increase the time taken by lpxelinux.0 to fetch its configuration file from a few milliseconds to around 30 seconds. Fix by immediately retransmitting

Hi all. On Sep 26th I decided to try and get ipp2p working on my machine that acts as a gateway for my Internet connection. This machine is running Debian. I performed the install by doing the following steps: - I installed the Debian package called linux-source-2.6.22 for my Linux kernel source and unpacked the resulting tar.bz2 file. - From the netfilter.org site I downloaded the following

--7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Netfilter Core Team Security Advisory =20 CVE: CAN-2003-0467 Subject: Netfilter / NAT Remote DoS Released: 01 Aug 2003 Effects: Under limited circumstances, a remote user may be able to crash