From nobody@FreeBSD.org  Fri Apr  2 20:46:44 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 39A04106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  2 Apr 2010 20:46:44 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 271BF8FC0A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  2 Apr 2010 20:46:44 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o32Kkh73055212
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 2 Apr 2010 20:46:43 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o32KkhYc055211;
	Fri, 2 Apr 2010 20:46:43 GMT
	(envelope-from nobody)
Message-Id: <201004022046.o32KkhYc055211@www.freebsd.org>
Date: Fri, 2 Apr 2010 20:46:43 GMT
From: Terrence Koeman <root@mediamonks.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ipfw problems, panics, data corruption, ipv6 socket weirdness
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         145305
>Category:       kern
>Synopsis:       [ipfw] ipfw problems, panics, data corruption, ipv6 socket weirdness
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-ipfw
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 02 20:50:05 UTC 2010
>Closed-Date:    Tue Jun 21 12:40:27 UTC 2011
>Last-Modified:  Tue Jun 21 12:40:27 UTC 2011
>Originator:     Terrence Koeman
>Release:        8.0-STABLE
>Organization:
MediaMonks B.V.
>Environment:
FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #9: Fri Apr  2 21:20:04 CEST 2010     terrence@xxx:/usr/obj/usr/src/sys/ADINAVA-SMP  amd64
>Description:
Several things break with the current 8-STABLE:

What broke:

It's a mail server, running Communigate Pro (tried 5.1, 5.2 & 5.3) and accepting connections on both ipv4 and ipv6. The server uses v6 sockets for v4 addresses, like this:

CGServer 826 root   45u  IPv6 0xffffff00174c8a50      0t0  TCP [2001:610:xxx:xxx:xxx:xxx:xxx:200]:smtp (LISTEN)
CGServer 826 root   47u  IPv6 0xffffff0001faf370      0t0  TCP [::217.xxx.xxx.xxx]:smtp (LISTEN)

Directly after the upgrade I noticed that connections *out* to other ipv4 mailservers were no longer succeeding and ipfw was seeing some weird packets:

Mar 30 06:27:34 adinava kernel: ipfw: 65530 Accept TCP 1.23.2.0:28859 65.55.92.152:25 out via bce0

Obviously 1.23.2.0 is not a local IP, so I checked lsof:

CGServer 824 root   49u  IPv6 0xffffff00174b3a50      0t0  TCP [2001:610:xxx:xxx:xxx:xxx:xxx:200]:28859->[::65.55.92.152]:smtp (SYN_SENT)

Somehow the server was trying to connect to an ipv4 address from an ipv6 address, where the ipv6 address apparently overflows ipv4 storage and ends up being '1.23.2.0'...

For comparison, this is what it looks like when it works:

CGServer 105 root   94u  IPv6 0xffffff00a4ccd000      0t0  TCP [::217.195.117.200]:14532->[::65.55.92.152]:smtp  (ESTABLISHED)

At first I assumed this was a problem in the daemon, so I temporarily disabled ipv6 for CGatePro (the ipv6 is not yet added as MX anyway) and forced it to use ipv4 sockets. That worked, until I tried to reload the ipfw rules and hit a panic:

---
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff803e3b77
stack pointer           = 0x28:0xffffff8076d73890
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1467 (ipfw)
trap number             = 9
panic: general protection fault
cpuid = 0
Uptime: 4m24s
Cannot dump. Device not defined or unavailable.
panic: bufwrite: buffer is not busy???
cpuid = 0
Uptime: 4m24s
Cannot dump. Device not defined or unavailable.
Automatic reboot in 15 seconds - press a key on the console to abort
Automatic reboot in 15 seconds - press a key on the console to abort
ipfw: ouch!, skip past end of rules, denying packet
---

It should have dumped (device is defined) and rebooted, but it hung there.

When I rebooted it, my rules file (/etc/ipfw.rules.sh) was truncated to zero. Assuming this was an ipfw problem I left the rules out temporarily (I have IPFIREWALL_DEFAULT_TO_ACCEPT).

After ~4 minutes the server hung again, this time with the screen filled with 'ipfw: ouch!, skip past end of rules, denying packet' messages, these were also logged to /var/log/messages. This seemed a bit weird as only the default 'allow-all' rule was present.

So I decided to recompile the kernel without ipfw and reboot (no module loaded either). After again ~4m I got the following panic:

---
dev = mfid0s1f, block = 1, fs = /var
panic: ffs_blkfree: freeing free block
cpuid = 3
Uptime: 4m34s
Cannot dump. Device not defined or unavailable.
Automatic reboot in 15 seconds - press a key on the console to abort
---

Again the server didn't reboot but just froze (no num-lock LED action either).

Reverting to 8-STABLE from 1 march 2010 makes all this go away.

dmesg & kernconf @ http://ra.phid.ae/dmesg.txt, see also: http://forums.freebsd.org/showthread.php?p=75765
>How-To-Repeat:
Even without ipfw in the kernel and the module not loaded there are problems, so I don't think this is ipfw specific. However, I've not found a way to reliably reproduce the problems without ipfw. The following run a couple of times in a row will either deny all packets (skip past end of rules) or panic:

---
#/bin/sh

ipfw disable firewall
ipfw -f flush
ipfw add 00001 allow any from any to any
ipfw enable firewall
ipfw show          
---

When I run this script and a panic occurs, the file is then truncated to zero or garbage is added to the end, so somehow there's also data corruption.
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw 
Responsible-Changed-By: remko 
Responsible-Changed-When: Sat Apr 3 07:57:03 UTC 2010 
Responsible-Changed-Why:  
reassign to ipfw team 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145305 

From: "Terrence Koeman" <root@mediamonks.net>
To: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>, 
	"root@mediamonks.net" <root@mediamonks.net>
Cc:  
Subject: Re: kern/145305: [ipfw] ipfw problems, panics, data corruption, ipv6 socket weirdness
Date: Sun, 09 May 2010 10:01:12 +0200

 Still present on 8-STABLE as of 30 April.
 
 FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #45: Fri Apr 30 05:32:09 CEST 201=
 0     terrence@xxx.mediamonks.net:/usr/obj/usr/src/sys/ADINAVA-SMP  amd64
 
 -- 
 Regards,
 T. Koeman, MTh/BSc/BPsy; Technical Monk
 
 MediaMonks B.V. (www.mediamonks.com)
 Please quote all replies in correspondence.
 
 
 
 
 

From: "Terrence Koeman" <root@mediamonks.net>
To: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/145305: [ipfw] ipfw problems, panics, data corruption, ipv6 socket weirdness
Date: Tue, 22 Jun 2010 17:59:35 +0200

 This is a multi-part message in MIME format.
 
 ------=_NextPart_000_0000_01CB1234.A95D1440
 Content-Type: text/plain;
 	charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 
 This *seems* to be fixed in 8-STABLE (8.1-PRERELEASE) of today.
 
 -- 
 Regards,
 T. Koeman, MTh/BSc/BPsy; Technical Monk
 
 MediaMonks B.V. (www.mediamonks.com)
 Please quote all replies in correspondence.
 
 
 ------=_NextPart_000_0000_01CB1234.A95D1440
 Content-Type: application/x-pkcs7-signature;
 	name="smime.p7s"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
 	filename="smime.p7s"
 
 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ2zCCA3Uw
 ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD
 VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT
 aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC
 RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS
 R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O
 o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9
 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU
 uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF
 Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq
 wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
 BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB
 ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6
 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s
 uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW
 MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY
 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggPjMIICy6ADAgECAgsEAAAAAAEeRKXfMTAN
 BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ
 MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTk5MDEyODEz
 MDAwMFoXDTE3MDEyNzEyMDAwMFowbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
 bnYtc2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ
 cmltYXJ5IENsYXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCSjP7v9EWO
 F0Fu/Ni/IW+rBp1SwSwAnT+Ohbh/So+9oGMqykknrlqC9HTiVZL/wtGqeaK2+tWdggRPxrLGXmOn
 OrrY7uuKb5+2uyhBwCL7TkgaBpLXv9fPudm9OE87DURuVUH+/Anb2L/zjiHx6BK19hOl08ZMkyKw
 Av/uHQzEqGtPdWhW6NwoElD3qCSdLiQ5+wkF3uWjZEkh0Gh+cTCRsWDgOfRQ+HpNmABrfHm6Ts5K
 4ro2HbfFNhWVnGRC6l/EuvVABb7hOlm9hKcZuN5NU1DOB9HSUdPvDYFs5udty118P3zM7E+DJyX/
 cFD2g1l1hAZmWCzeiY0Apkn5pUN3AgMBAAGjgZkwgZYwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB
 /wQFMAMBAf8wHQYDVR0OBBYEFHznsrEs3rGna+l2DOGj/U5sx7n2MDMGA1UdHwQsMCowKKAmoCSG
 Imh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvUm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJ
 UC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAGgRjjoMPFOdxJ3nyglVKuQrH6KYOV5XvygO
 qKU7oR8o61w4Wvxshe/xCYNSPAM5NUVGRbfsjcECetbplZ0zrDfca5m7Y9/9HFqOTdwAW1dXMgdx
 TilR1VTRttdOXK5MtwT9AHk/6TnPxXjRrSd9y4uPfFE5ZTC3pAkl33yi5Nbre36D3aopA8KlbExA
 f8/A8p/X08+Cxn/NYHwlCPfyng9Adr+z/t0y6KuRGdLghNqMZyUxp46qipaieWDFVVewpWfuSkh5
 LsB24B9BblchvubpnUskLG2hhqyA454ZZ9oyYVsVhNvE12F0hAS5NPhQ+3e9ep74CIVQFFgJcyHU
 FvUwggS2MIIDnqADAgECAgsBAAAAAAElc8eP4zANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC
 RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENsYXNz
 IDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0EwHhcNMDkx
 MjA5MTMyMjQ0WhcNMTIxMjA5MTMyMjQxWjCBwTELMAkGA1UEBhMCTkwxGzAZBgNVBAwTElRlY2hu
 aWNhbCBEaXJlY3RvcjEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJSGlsdmVyc3Vt
 MSswKQYDVQQKEyJNZWRpYU1vbmtzIE11bHRpbWVkaWEgSG9sZGluZyBCLlYuMRgwFgYDVQQDEw9U
 ZXJyZW5jZSBLb2VtYW4xIjAgBgkqhkiG9w0BCQEWE3Jvb3RAbWVkaWFtb25rcy5uZXQwgZ8wDQYJ
 KoZIhvcNAQEBBQADgY0AMIGJAoGBAKvtl7cjemV/ISLtXrfngKiW/bkpT3EeSim++dmCSfvWVJqC
 bxN6cj1wWEfstozl84be8M5/3O2U4spihbm4jkE5E5+jjeFbDJKRmgcx2ZXpKdTL8LTg970SeRFr
 1VxnPAwgrjLtFpy4KcOMgtBh2DrDCAqbuUlqyNqkNqqAAFQ3AgMBAAGjggF6MIIBdjAfBgNVHSME
 GDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBWBggrBgEFBQcBAQRKMEgwRgYIKwYBBQUHMAKGOmh0
 dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5uZXQvY2FjZXJ0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcnQw
 QQYDVR0fBDowODA2oDSgMoYwaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25D
 bGFzczIuY3JsMB4GA1UdEQQXMBWBE3Jvb3RAbWVkaWFtb25rcy5uZXQwCQYDVR0TBAIwADAOBgNV
 HQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEsGA1UdIAREMEIwQAYJ
 KwYBBAGgMgEoMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZ2xvYmFsc2lnbi5uZXQvcmVwb3Np
 dG9yeS8wEQYJYIZIAYb4QgEBBAQDAgWgMA0GCSqGSIb3DQEBBQUAA4IBAQAj71rVZ+4k8tUMca3Z
 Ej67QXe9OnHCJlUIdyfRFyqn07QRLm4ElOAlcWSX6OOuc1Uz9zDLzcJl+2kSUfQ0OyZsoQGyRD0x
 Ypd0qG8yZxJN38S1K6C/qgilTzft9bb0OSgfPJ3FJUk3zIzwmgWEBE0DbiOccyaAwu1lmsAXJMYa
 SpCELzWNBfGdMBJPRBX+jQbcK0pR8mT6P1hYLYsgDW+9SA732Z2VR9aXdzytPVe+BBj4celz8pob
 51vLq08G0RUWu52K9NEkXUOWCzEEYladdQ0MWkznXQkXlK/gSXTH5RsnTPDSlM0N7DVYd3yrDBY4
 e9ADriQBXWN5hc0oUg0XMIIEvTCCA6WgAwIBAgILBAAAAAABHkSl6CowDQYJKoZIhvcNAQEFBQAw
 bTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExGzAZBgNVBAsTElByaW1h
 cnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQcmltYXJ5IENsYXNzIDIgQ0EwHhcN
 MDQwMTIyMTAwMDAwWhcNMTcwMTI3MTEwMDAwWjB3MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv
 YmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMT
 Ikdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
 DwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyh
 f1LFzVmOaZX8X41n93Eu/7L34wHM192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74
 gV6TeE4EVwrkUXgqs+j5JLtJXkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiU
 ngjpMlAxvmr/9+6KMug0ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5
 SHFLXIWLhCSlZAGJ9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjggFSMIIBTjAOBgNV
 HQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUbcQrwX2FEKD5ExYNVSsD
 ujZMITEwSgYDVR0gBEMwQTA/BgkrBgEEAaAyASgwMjAwBggrBgEFBQcCARYkaHR0cDovL3d3dy5n
 bG9iYWxzaWduLm5ldC9yZXBvc2l0b3J5MDkGA1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xv
 YmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5jcmwwTgYIKwYBBQUHAQEEQjBAMD4GCCsGAQUFBzAChjJo
 dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24ubmV0L2NhY2VydC9QcmltQ2xhc3MyLmNydDARBglghkgB
 hvhCAQEEBAMCAQYwHwYDVR0jBBgwFoAUfOeysSzesadr6XYM4aP9TmzHufYwDQYJKoZIhvcNAQEF
 BQADggEBACHomV6TRHH0FST5Evl4te2y0JSEWH1AFpd+e+mSfOPQcDfStZDOI/MYODDKl8UNy6Cb
 /8iPaeqn6q7nW/JuGl5HiP9OQEFwYbwdNF6FS7R7sn5k3E5g8D29WhxvINqeSNIuP8Om8lOVcmNu
 2l/XeE4zfyMVs20SL0CIcfjkdqviKWJyub8upan0jqldIeX4uuCasnCKi+3gM50D8SvwBY0bpct+
 kG52JISw2S3cbBHcHNuOzGsu8tv17IyvKjCiMr75AMEtogrs2FXNsqDhD6bY2YCi7JWDAVsz8B1v
 QtCG/ft/mX84UPC/vzfh9O8HD9v2CwQunIYPYe/ZYRkqyG8xggN+MIIDegIBATCBhjB3MQswCQYD
 VQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWdu
 IENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0EC
 CwEAAAAAASVzx4/jMAkGBSsOAwIaBQCgggJNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
 KoZIhvcNAQkFMQ8XDTEwMDYyMjE1NTkyOVowIwYJKoZIhvcNAQkEMRYEFN8BL/Qi60F2vSq2m1MM
 W/D+ZuqLMIGXBgkrBgEEAYI3EAQxgYkwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh
 bFNpZ24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH
 bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAElc8eP4zCBmQYLKoZIhvcN
 AQkQAgsxgYmggYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExIDAe
 BgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJHbG9iYWxTaWduIFBlcnNv
 bmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAElc8eP4zCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCG
 SAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMC
 AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglg
 hkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0B
 AQEFAASBgAFoIhJckb3cY59ZwCQtLiSlrGzUJh7gTbvYqb0qnkE4q0IjA6Nth3Zvvd3I4ykB+OQW
 pmV13M6V00jdZL/v5WW1CBcgJNQyJEO+NY/7185pxQ/PZZLIZs0bvTXCMaXS2Qv89xK9JYufTdcv
 sH1QElXMvUoz1t9TV1Vn66Gt+bBLAAAAAAAA
 
 ------=_NextPart_000_0000_01CB1234.A95D1440--
 

From: "Terrence Koeman" <root@mediamonks.net>
To: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/145305: [ipfw] ipfw problems, panics, data corruption, ipv6 socket weirdness
Date: Wed, 30 Jun 2010 12:08:36 +0200

 I spoke too soon. The panics and corruption are gone, but there's still the=
  problem of local ipv6 addresses being used 'as' ipv4 addresses which resul=
 ts in bad source addresses:
 
 Jun 30 10:50:42 adinava kernel: ipfw: 65529 Accept TCP 1.23.2.0:28593 <some=
  ext. IP>:25 out via bce0
 
 I'm having tons of those, where 1.23.2.0 is obviously not a locally bound I=
 P but the result of the local system trying to send a SYN from a local ipv6=
  address to a remote ipv4 address.
 
 PS: Excuse me for signing my previous followup.
 
 -- 
 Regards,
 T. Koeman, MTh/BSc/BPsy; Technical Monk
 
 MediaMonks B.V. (www.mediamonks.com)
 Please quote all replies in correspondence.
 
 
 
 
 

From: "Terrence Koeman" <root@mediamonks.net>
To: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/145305: [ipfw] ipfw problems, panics, data corruption, ipv6 socket weirdness
Date: Wed, 30 Jun 2010 12:35:38 +0200

 Example output of 'lsof -i 6 -nP':
 
 CGServer 1096 root  158u  IPv6 0xffffff001087f6e0      0t0  TCP [2001:610:x=
 x:xxx:xxx:xxx:117:200]:18187->[::213.136.12.237]:25 (SYN_SENT)
 <hundreds more>
 
 These are accompanied by entries in /var/log/security like so:
 
 Jun 30 12:12:28 adinava kernel: ipfw: 65529 Accept TCP 1.23.2.0:18187 213.1=
 36.12.235:25 out via bce0
 
 Obviously these will hang in SYN_SENT until they time out because the SYN p=
 acket with source 1.23.2.0 gets dropped at the border (and there wouldn't b=
 e a return route anyway).
 
 I'm assuming the ipv6 '2001:610:xx:xxx:xxx:xxx:117:200' ends up being ipv4 =
 '1.23.2.0' due to some conversion error.
 
 -- 
 Regards,
 T. Koeman, MTh/BSc/BPsy; Technical Monk
 
 MediaMonks B.V. (www.mediamonks.com)
 Please quote all replies in correspondence.
 
 
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: ae 
State-Changed-When: Tue Jun 21 12:06:21 UTC 2011 
State-Changed-Why:  
Can you still reproduce this? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=145305 
State-Changed-From-To: feedback->closed 
State-Changed-By: ae 
State-Changed-When: Tue Jun 21 12:39:19 UTC 2011 
State-Changed-Why:  
Submitter has confirmed that the problem is already fixed.  

http://www.freebsd.org/cgi/query-pr.cgi?pr=145305 
>Unformatted:
