I guess I figured it out somewhat, and searching the very
old archives did play a part in this.
http://www.mail-archive.com/[email protected]/msg07513.html
The tcpdump problems are cosmetic and related to hardware
checksum offloading. However, even after setting the flag
to zero and rebooting, the problem persists as in the
reproduction scenario quoted below.
That is, tcpdump on the router host no longer complains
about checksums in most cases, but some still persist i.e.
15:17:11.448413 08:00:27:f6:dc:bd > 00:e0:81:5e:9f:cb, ethertype
IPv4 (0x0800), length 60: (tos 0x0, ttl 1, id 32159, offset 0,
flags [none], proto: ICMP (1), length: 40) 192.168.186.250 >
194.67.183.19: ICMP echo request, id 33306, seq 0, length 20
15:17:11.448450 00:e0:81:5e:9f:cb > 08:00:27:f6:dc:bd, ethertype
IPv4 (0x0800), length 82: truncated-ip - 17340 bytes missing!
(tos 0x0, ttl 255, id 39119, offset 512, flags [none],
proto: ICMP (1), length: 17408, bad cksum ec9a (->e89e)!)
192.168.186.2 > 192.168.186.250: icmp
So I'm back into debugging the networking setup.
Jim Klimov wrote:
I forgot to mention that, like before, this system is a Sun
Fire X2100 (pre-M2) server with an nge and a bge couple of
interfaces, so most of OS interfaces are VLANs. The one in
question as the external connection certainly is, bge126000.
Maybe some hardcoded offset stuff breaks when Ethernet VLAN
tag bytes come into play?
Jim Klimov wrote:
Hello Darren et al,
I think I have a de-ja-vu again: with IPF 4.1.33 active my
firewall does not respond to pings while tracing through it.
This happens specifically after the rules are touched by
the driver, i.e. reproduction:
1) /etc/init.d/ipfilter stop
- module is unloaded, my router responds to tracert
2) modload /usr/kernel/drv/ipf
- host still responds
3) ipf -Fy
- host stops responding even while the rule list is empty
When I load rules which pass all packets in and out, host
is still out of the traces.
Since other hosts "around" it respond to traces, it may be
that packets entering and exiting the system are mangled
in a similar manner, and packets originating or terminating
on the host are only mangled once - so they break. However
SSH to the machine works well, so there's something deeper
than that.
Seems this also breaks NAT. At the very least, it is not
working for me now (but packets don't panic the kernel
either, which is an improvement compared to my previous
experimental builds).
16:45:28.354506 IP (tos 0x0, ttl 127, id 1150, offset 0,
flags [DF], proto: TCP (6), length: 48) 93.175.31.2.1821
> 193.169.34.3.22107: S, cksum 0x957f (correct),
738265398:738265398(0) win 64240 <mss 1366,nop,nop,sackOK>
16:45:28.500340 IP (tos 0x0, ttl 64, id 42280, offset 0,
flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->354a)!)
93.175.31.2.1821 > 193.169.34.3.22107: R, cksum 0x0000
(incorrect (-> 0xbcd2), 738265399:738265399(0) win 0
--
+============================================================+
| |
| Климов Евгений, Jim Klimov |
| технический директор CTO |
| ЗАО "ЦОС и ВТ" JSC COS&HT |
| |
| +7-903-7705859 (cellular) mailto:[email protected] |
| CC:[email protected],[email protected] |
+============================================================+
| () ascii ribbon campaign - against html mail |
| /\ - against microsoft attachments |
+============================================================+
