Re: Linux kernel error stack
Michal Kubecek wrote: > On Mon, Aug 06, 2018 at 01:15:37AM +0200, Florian Westphal wrote: > > Michal Kubecek wrote: > > > Oops, exactly this issue was already discussed almost a year ago: > > > > > > http://lkml.kernel.org/r/20170824104824.2c318a0...@unicorn.suse.cz > > > > > > But something more urgent came and I forgot to get back to it. :-( > > > > I did not even remeber, thanks for the pointer. > > So I think best course of action is to update man page to clearly > > say this only works in postrouting and with udp, and is ONLY > > intended for working around old dhcp software. > > As GSO for UDP is on its way to mainline, one might get into trouble > even with UDP if the rule is not specific enough. Yes, we still need a fix to ignore GSO too.
Re: Linux kernel error stack
On Mon, Aug 06, 2018 at 01:15:37AM +0200, Florian Westphal wrote: > Michal Kubecek wrote: > > Oops, exactly this issue was already discussed almost a year ago: > > > > http://lkml.kernel.org/r/20170824104824.2c318a0...@unicorn.suse.cz > > > > But something more urgent came and I forgot to get back to it. :-( > > I did not even remeber, thanks for the pointer. > So I think best course of action is to update man page to clearly > say this only works in postrouting and with udp, and is ONLY > intended for working around old dhcp software. As GSO for UDP is on its way to mainline, one might get into trouble even with UDP if the rule is not specific enough. > From kernel, have checkentry emit a warning > when this is used for protocols other than udp, > and make this a no-op for everything else. > > Same for postrouting: warn from checkentry if the hook is something > else, and have target function not do anything for !postrouting. > > Does that make sense? It sounds reasonable to me. > I can work on a patch later this week if needed. I'll be on vacation until Sunday so that I certainly won't get to it earlier than next week. Michal Kubecek
Re: Linux kernel error stack
Michal Kubecek wrote: > Oops, exactly this issue was already discussed almost a year ago: > > http://lkml.kernel.org/r/20170824104824.2c318a0...@unicorn.suse.cz > > But something more urgent came and I forgot to get back to it. :-( I did not even remeber, thanks for the pointer. So I think best course of action is to update man page to clearly say this only works in postrouting and with udp, and is ONLY intended for working around old dhcp software. >From kernel, have checkentry emit a warning when this is used for protocols other than udp, and make this a no-op for everything else. Same for postrouting: warn from checkentry if the hook is something else, and have target function not do anything for !postrouting. Does that make sense? I can work on a patch later this week if needed.
Re: Linux kernel error stack
On Sun, Aug 05, 2018 at 11:03:42PM +0200, Florian Westphal wrote: > Satish Patel wrote: > > Florian, > > > > It seems those rules coming from here > > https://github.com/openstack/openstack-ansible-os_neutron/blob/master/files/post-up-metadata-checksum > > This is crazy, and, as you found, it doesn't even do what they seem to > think it does. > > I see no reason for these rules at all. Oops, exactly this issue was already discussed almost a year ago: http://lkml.kernel.org/r/20170824104824.2c318a0...@unicorn.suse.cz But something more urgent came and I forgot to get back to it. :-( Michal Kubecek
Re: Linux kernel error stack
Satish Patel wrote: > Florian, > > It seems those rules coming from here > https://github.com/openstack/openstack-ansible-os_neutron/blob/master/files/post-up-metadata-checksum This is crazy, and, as you found, it doesn't even do what they seem to think it does. I see no reason for these rules at all.
Re: Linux kernel error stack
Satish Patel wrote: > After reading further related DHCP checksum issue, it seems we need > that rules when you running DHCP on same host machine where your guest > using host DHCP service, in that case virtual nic won't do checksum. > If your DHCP running on different host then your physical nic perform > checksum. Partially right, its only needed for older dhcp software that relies on packet-header checksum correctness (metadata contains info when checksum will be filled in by nic later, modern servers will use that and ignore the packet-header checksums in this case). If you remove the rule and your VMs still get leases via DHCP then the CHECKSUM workaround isn't needed.
Re: Linux kernel error stack
After reading further related DHCP checksum issue, it seems we need that rules when you running DHCP on same host machine where your guest using host DHCP service, in that case virtual nic won't do checksum. If your DHCP running on different host then your physical nic perform checksum. On Sun, Aug 5, 2018 at 4:39 PM, Satish Patel wrote: > Florian, > > I have removed those port 80 CHECKSUM rules and everything looks good > i didn't see kernel WARN mesg. > > Thank you so much! You just nailed it :) > > On Sun, Aug 5, 2018 at 4:15 PM, Satish Patel wrote: >> Florian, >> >> It seems those rules coming from here >> https://github.com/openstack/openstack-ansible-os_neutron/blob/master/files/post-up-metadata-checksum >> >> On Sun, Aug 5, 2018 at 4:09 PM, Satish Patel wrote: >>> Yes this is openstack-ansible deployment tool which set them up. I am >>> wondering where are these rules saved? I believe openstack-ansible use >>> LXC container to deploy services so must be part of LXC startup >>> scripts. >>> >>> I have checked there is no firewalld and iptables service running on >>> system.. >>> >>> You think i should get rid of all CHEKSUM option in iptables rules? Am i >>> right? >>> >>> >>> On Sun, Aug 5, 2018 at 4:02 PM, Florian Westphal wrote: Satish Patel wrote: > > [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM > > --checksum-fill > > [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM > > --checksum-fill These rules make no sense to me, and are also source of your backtrace. Who set this up? If this is coming from openstack, I suggest asking openstack developers WTH this is supposed to do. > > [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp > > --dport 68 -j CHECKSUM --checksum-fill This was needed to work around dhcpd issues w. checksum offloading but I guess that DCHCP will work fine without this rule too nowadays. So I suggest you simply get rid of these rules.
Re: Linux kernel error stack
Florian, I have removed those port 80 CHECKSUM rules and everything looks good i didn't see kernel WARN mesg. Thank you so much! You just nailed it :) On Sun, Aug 5, 2018 at 4:15 PM, Satish Patel wrote: > Florian, > > It seems those rules coming from here > https://github.com/openstack/openstack-ansible-os_neutron/blob/master/files/post-up-metadata-checksum > > On Sun, Aug 5, 2018 at 4:09 PM, Satish Patel wrote: >> Yes this is openstack-ansible deployment tool which set them up. I am >> wondering where are these rules saved? I believe openstack-ansible use >> LXC container to deploy services so must be part of LXC startup >> scripts. >> >> I have checked there is no firewalld and iptables service running on system.. >> >> You think i should get rid of all CHEKSUM option in iptables rules? Am i >> right? >> >> >> On Sun, Aug 5, 2018 at 4:02 PM, Florian Westphal wrote: >>> Satish Patel wrote: > [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM > --checksum-fill > [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM > --checksum-fill >>> >>> These rules make no sense to me, and are also source of your backtrace. >>> Who set this up? >>> >>> If this is coming from openstack, I suggest asking openstack developers >>> WTH this is supposed to do. >>> > [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp > --dport 68 -j CHECKSUM --checksum-fill >>> >>> This was needed to work around dhcpd issues w. checksum offloading but I >>> guess that DCHCP will work fine without this rule too nowadays. >>> >>> So I suggest you simply get rid of these rules.
Re: Linux kernel error stack
Florian, It seems those rules coming from here https://github.com/openstack/openstack-ansible-os_neutron/blob/master/files/post-up-metadata-checksum On Sun, Aug 5, 2018 at 4:09 PM, Satish Patel wrote: > Yes this is openstack-ansible deployment tool which set them up. I am > wondering where are these rules saved? I believe openstack-ansible use > LXC container to deploy services so must be part of LXC startup > scripts. > > I have checked there is no firewalld and iptables service running on system.. > > You think i should get rid of all CHEKSUM option in iptables rules? Am i > right? > > > On Sun, Aug 5, 2018 at 4:02 PM, Florian Westphal wrote: >> Satish Patel wrote: >>> > [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM >>> > --checksum-fill >>> > [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM >>> > --checksum-fill >> >> These rules make no sense to me, and are also source of your backtrace. >> Who set this up? >> >> If this is coming from openstack, I suggest asking openstack developers >> WTH this is supposed to do. >> >>> > [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp >>> > --dport 68 -j CHECKSUM --checksum-fill >> >> This was needed to work around dhcpd issues w. checksum offloading but I >> guess that DCHCP will work fine without this rule too nowadays. >> >> So I suggest you simply get rid of these rules.
Re: Linux kernel error stack
Yes this is openstack-ansible deployment tool which set them up. I am wondering where are these rules saved? I believe openstack-ansible use LXC container to deploy services so must be part of LXC startup scripts. I have checked there is no firewalld and iptables service running on system.. You think i should get rid of all CHEKSUM option in iptables rules? Am i right? On Sun, Aug 5, 2018 at 4:02 PM, Florian Westphal wrote: > Satish Patel wrote: >> > [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM >> > --checksum-fill >> > [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM >> > --checksum-fill > > These rules make no sense to me, and are also source of your backtrace. > Who set this up? > > If this is coming from openstack, I suggest asking openstack developers > WTH this is supposed to do. > >> > [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp >> > --dport 68 -j CHECKSUM --checksum-fill > > This was needed to work around dhcpd issues w. checksum offloading but I > guess that DCHCP will work fine without this rule too nowadays. > > So I suggest you simply get rid of these rules.
Re: Linux kernel error stack
Satish Patel wrote: > > [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM > > --checksum-fill > > [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM > > --checksum-fill These rules make no sense to me, and are also source of your backtrace. Who set this up? If this is coming from openstack, I suggest asking openstack developers WTH this is supposed to do. > > [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp > > --dport 68 -j CHECKSUM --checksum-fill This was needed to work around dhcpd issues w. checksum offloading but I guess that DCHCP will work fine without this rule too nowadays. So I suggest you simply get rid of these rules.
Re: Linux kernel error stack
I am configured where are those rules stored why iptables -L -n -t nat not showing them? On Sun, Aug 5, 2018 at 3:56 PM, Satish Patel wrote: > Oh wait!! I think you are right there i didn't notice that iptables > has following setting. > > "CHECKSUM --checksum-fill" > > On Sun, Aug 5, 2018 at 3:54 PM, Satish Patel wrote: >> I have following kernel logging set. >> >> [root@ostack-infra-02 tools]# cat /proc/sys/kernel/printk >> 3 4 1 3 >> >> >> iptables output >> >> [root@ostack-infra-02 tools]# iptables-save -c >> # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 >> *raw >> :PREROUTING ACCEPT [42284573:38782693391] >> :OUTPUT ACCEPT [219668:42675751] >> COMMIT >> # Completed on Sun Aug 5 15:52:56 2018 >> # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 >> *nat >> :PREROUTING ACCEPT [656413:38450886] >> :INPUT ACCEPT [5524:564390] >> :OUTPUT ACCEPT [3217:212903] >> :POSTROUTING ACCEPT [559058:34193539] >> [5197:311820] -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE >> COMMIT >> # Completed on Sun Aug 5 15:52:56 2018 >> # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 >> *mangle >> :PREROUTING ACCEPT [42209568:38687818558] >> :INPUT ACCEPT [170634:197796840] >> :FORWARD ACCEPT [42939243:38526139954] >> :OUTPUT ACCEPT [198956:41288636] >> :POSTROUTING ACCEPT [43138199:38567428590] >> [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM >> --checksum-fill >> [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM >> --checksum-fill >> [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp >> --dport 68 -j CHECKSUM --checksum-fill >> COMMIT >> # Completed on Sun Aug 5 15:52:56 2018 >> # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 >> *filter >> :INPUT ACCEPT [164954:197217701] >> :FORWARD ACCEPT [42801701:38377075499] >> :OUTPUT ACCEPT [198963:41289860] >> [0:0] -A INPUT -i lxcbr0 -p tcp -m tcp --dport 53 -j ACCEPT >> [4932:328918] -A INPUT -i lxcbr0 -p udp -m udp --dport 53 -j ACCEPT >> [0:0] -A INPUT -i lxcbr0 -p tcp -m tcp --dport 67 -j ACCEPT >> [755:250585] -A INPUT -i lxcbr0 -p udp -m udp --dport 67 -j ACCEPT >> [80745:145594351] -A FORWARD -o lxcbr0 -j ACCEPT >> [56801:3471569] -A FORWARD -i lxcbr0 -j ACCEPT >> COMMIT >> # Completed on Sun Aug 5 15:52:56 2018 >> >> On Sun, Aug 5, 2018 at 3:42 PM, Florian Westphal wrote: >>> Satish Patel wrote: Thanks Florian, FYI, I don't have any CHECKSUM configure in my iptables, >>> >>> You have, according to WARN stacktrace you provided. >>> >>> iptables-save -c >>> ip6tables-save -c
Re: Linux kernel error stack
Oh wait!! I think you are right there i didn't notice that iptables has following setting. "CHECKSUM --checksum-fill" On Sun, Aug 5, 2018 at 3:54 PM, Satish Patel wrote: > I have following kernel logging set. > > [root@ostack-infra-02 tools]# cat /proc/sys/kernel/printk > 3 4 1 3 > > > iptables output > > [root@ostack-infra-02 tools]# iptables-save -c > # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 > *raw > :PREROUTING ACCEPT [42284573:38782693391] > :OUTPUT ACCEPT [219668:42675751] > COMMIT > # Completed on Sun Aug 5 15:52:56 2018 > # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 > *nat > :PREROUTING ACCEPT [656413:38450886] > :INPUT ACCEPT [5524:564390] > :OUTPUT ACCEPT [3217:212903] > :POSTROUTING ACCEPT [559058:34193539] > [5197:311820] -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE > COMMIT > # Completed on Sun Aug 5 15:52:56 2018 > # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 > *mangle > :PREROUTING ACCEPT [42209568:38687818558] > :INPUT ACCEPT [170634:197796840] > :FORWARD ACCEPT [42939243:38526139954] > :OUTPUT ACCEPT [198956:41288636] > :POSTROUTING ACCEPT [43138199:38567428590] > [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM > --checksum-fill > [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM > --checksum-fill > [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp > --dport 68 -j CHECKSUM --checksum-fill > COMMIT > # Completed on Sun Aug 5 15:52:56 2018 > # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 > *filter > :INPUT ACCEPT [164954:197217701] > :FORWARD ACCEPT [42801701:38377075499] > :OUTPUT ACCEPT [198963:41289860] > [0:0] -A INPUT -i lxcbr0 -p tcp -m tcp --dport 53 -j ACCEPT > [4932:328918] -A INPUT -i lxcbr0 -p udp -m udp --dport 53 -j ACCEPT > [0:0] -A INPUT -i lxcbr0 -p tcp -m tcp --dport 67 -j ACCEPT > [755:250585] -A INPUT -i lxcbr0 -p udp -m udp --dport 67 -j ACCEPT > [80745:145594351] -A FORWARD -o lxcbr0 -j ACCEPT > [56801:3471569] -A FORWARD -i lxcbr0 -j ACCEPT > COMMIT > # Completed on Sun Aug 5 15:52:56 2018 > > On Sun, Aug 5, 2018 at 3:42 PM, Florian Westphal wrote: >> Satish Patel wrote: >>> Thanks Florian, >>> >>> FYI, I don't have any CHECKSUM configure in my iptables, >> >> You have, according to WARN stacktrace you provided. >> >> iptables-save -c >> ip6tables-save -c
Re: Linux kernel error stack
I have following kernel logging set. [root@ostack-infra-02 tools]# cat /proc/sys/kernel/printk 3 4 1 3 iptables output [root@ostack-infra-02 tools]# iptables-save -c # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 *raw :PREROUTING ACCEPT [42284573:38782693391] :OUTPUT ACCEPT [219668:42675751] COMMIT # Completed on Sun Aug 5 15:52:56 2018 # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 *nat :PREROUTING ACCEPT [656413:38450886] :INPUT ACCEPT [5524:564390] :OUTPUT ACCEPT [3217:212903] :POSTROUTING ACCEPT [559058:34193539] [5197:311820] -A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE COMMIT # Completed on Sun Aug 5 15:52:56 2018 # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 *mangle :PREROUTING ACCEPT [42209568:38687818558] :INPUT ACCEPT [170634:197796840] :FORWARD ACCEPT [42939243:38526139954] :OUTPUT ACCEPT [198956:41288636] :POSTROUTING ACCEPT [43138199:38567428590] [84166:59495417] -A POSTROUTING -p tcp -m tcp --sport 80 -j CHECKSUM --checksum-fill [68739:5153476] -A POSTROUTING -p tcp -m tcp --sport 8000 -j CHECKSUM --checksum-fill [755:275452] -A POSTROUTING -s 10.0.3.0/24 -o lxcbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill COMMIT # Completed on Sun Aug 5 15:52:56 2018 # Generated by iptables-save v1.4.21 on Sun Aug 5 15:52:56 2018 *filter :INPUT ACCEPT [164954:197217701] :FORWARD ACCEPT [42801701:38377075499] :OUTPUT ACCEPT [198963:41289860] [0:0] -A INPUT -i lxcbr0 -p tcp -m tcp --dport 53 -j ACCEPT [4932:328918] -A INPUT -i lxcbr0 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i lxcbr0 -p tcp -m tcp --dport 67 -j ACCEPT [755:250585] -A INPUT -i lxcbr0 -p udp -m udp --dport 67 -j ACCEPT [80745:145594351] -A FORWARD -o lxcbr0 -j ACCEPT [56801:3471569] -A FORWARD -i lxcbr0 -j ACCEPT COMMIT # Completed on Sun Aug 5 15:52:56 2018 On Sun, Aug 5, 2018 at 3:42 PM, Florian Westphal wrote: > Satish Patel wrote: >> Thanks Florian, >> >> FYI, I don't have any CHECKSUM configure in my iptables, > > You have, according to WARN stacktrace you provided. > > iptables-save -c > ip6tables-save -c
Re: Linux kernel error stack
Satish Patel wrote: > Thanks Florian, > > FYI, I don't have any CHECKSUM configure in my iptables, You have, according to WARN stacktrace you provided. iptables-save -c ip6tables-save -c
Re: Linux kernel error stack
Thanks Florian,
FYI, I don't have any CHECKSUM configure in my iptables, i have
following rules, also do you think this kernel WARNNING is just
warning and not impacting my performance, based on that i have to
decided criticality of this issue.
[root@ostack-infra-02 ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/00.0.0.0/0tcp dpt:53
ACCEPT udp -- 0.0.0.0/00.0.0.0/0udp dpt:53
ACCEPT tcp -- 0.0.0.0/00.0.0.0/0tcp dpt:67
ACCEPT udp -- 0.0.0.0/00.0.0.0/0udp dpt:67
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/00.0.0.0/0
ACCEPT all -- 0.0.0.0/00.0.0.0/0
On Sun, Aug 5, 2018 at 5:48 AM, Florian Westphal wrote:
> Satish Patel wrote:
>> I am installing openstack and as you know i have lots of bridges and
>> vlan interface on my Linux CentOS 7.5
>>
>> I was getting following error stack on 3.10 kernel and found this is
>> kernel bug which required kernel upgrade so now i have upgraded my
>> kernel to 4.17.12 but i am still seeing same kernel stack error on my
>> dmesg
>>
>> I have disable TSO, LRO, SG & GSO on my NIC but still getting error
>> just wanted to understand what is this and why it popping up
>
> Get rid of CHECKSUM target in the iptables rules.
> This thing was added 8 years ago to work around dhcp bugs, I don't
> think its use is needed anymore.
> Try removing it and see that all VMs can still retrieve IP address
> via DHCP.
>
> I'm curious as to the rules, normally CHECKSUM target should be
> limited to -p udp --dport bootp; its bad idea to feed it normal
> packets, its expensive to do this in software rather than have device
> do the checksumming.
>
> As for fix, I'm tempted to send patch to make checksum target
> eval a no-op & add deprecation warning on init...
>
> Other "fix" is to
>
> diff --git a/net/netfilter/xt_CHECKSUM.c b/net/netfilter/xt_CHECKSUM.c
> index 9f4151ec3e06..23a17dda604d 100644
> --- a/net/netfilter/xt_CHECKSUM.c
> +++ b/net/netfilter/xt_CHECKSUM.c
> @@ -25,8 +25,12 @@ MODULE_ALIAS("ip6t_CHECKSUM");
> static unsigned int
> checksum_tg(struct sk_buff *skb, const struct xt_action_param *par)
> {
> - if (skb->ip_summed == CHECKSUM_PARTIAL)
> - skb_checksum_help(skb);
> + if (skb->ip_summed == CHECKSUM_PARTIAL) {
> + if (skb_shinfo(skb)->gso_size)
> + skb->ip_summed = CHECKSUM_NONE;
> + else
> + skb_checksum_help(skb);
> + }
>
> return XT_CONTINUE;
> }
>
> (unfortunately, the target isn't restricted to POSTROUTING, sigh).
Re: Linux kernel error stack
Satish Patel wrote:
> I am installing openstack and as you know i have lots of bridges and
> vlan interface on my Linux CentOS 7.5
>
> I was getting following error stack on 3.10 kernel and found this is
> kernel bug which required kernel upgrade so now i have upgraded my
> kernel to 4.17.12 but i am still seeing same kernel stack error on my
> dmesg
>
> I have disable TSO, LRO, SG & GSO on my NIC but still getting error
> just wanted to understand what is this and why it popping up
Get rid of CHECKSUM target in the iptables rules.
This thing was added 8 years ago to work around dhcp bugs, I don't
think its use is needed anymore.
Try removing it and see that all VMs can still retrieve IP address
via DHCP.
I'm curious as to the rules, normally CHECKSUM target should be
limited to -p udp --dport bootp; its bad idea to feed it normal
packets, its expensive to do this in software rather than have device
do the checksumming.
As for fix, I'm tempted to send patch to make checksum target
eval a no-op & add deprecation warning on init...
Other "fix" is to
diff --git a/net/netfilter/xt_CHECKSUM.c b/net/netfilter/xt_CHECKSUM.c
index 9f4151ec3e06..23a17dda604d 100644
--- a/net/netfilter/xt_CHECKSUM.c
+++ b/net/netfilter/xt_CHECKSUM.c
@@ -25,8 +25,12 @@ MODULE_ALIAS("ip6t_CHECKSUM");
static unsigned int
checksum_tg(struct sk_buff *skb, const struct xt_action_param *par)
{
- if (skb->ip_summed == CHECKSUM_PARTIAL)
- skb_checksum_help(skb);
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ if (skb_shinfo(skb)->gso_size)
+ skb->ip_summed = CHECKSUM_NONE;
+ else
+ skb_checksum_help(skb);
+ }
return XT_CONTINUE;
}
(unfortunately, the target isn't restricted to POSTROUTING, sigh).
