On Aug 26, 2007, at 21:16, Phil Dibowitz wrote:
I don't see why the vlan's wouldn't allow it, it's still the same
hardware.
And it's not a "I haven't turned it on" its more of a "have I
turned it off"
for most hardware. Try adding:
set ip:dohwcksum=0
to /etc/system and reboot. If you still have the problem, you can
definitively say it's not hardware checksumming.
That would work if I were running Solaris, perhaps. :-) I mentioned
too briefly in my first message that I was running NetBSD 4.0 beta.
The output of ifconfig wm0 shows that the hardware has the
capability,
but that it's not being used:
# ifconfig wm0
wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=2bf00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSU
M_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx,UDP6CSUM_Tx>
enabled=0
If it were being used, the enabled line would indicate the
capabilities
that were in use.
And, I'd like to point out, that tcpdump was complaining about the
ICMP checksum, not the UDP or IP checksums:
18:45:57.844936 IP (tos 0x0, ttl 127, id 12807, offset 0, flags
[none], length: 124) c-69-244-mm-nn.hsd1.md.comcast.net >
vpnsvr2a.xxx.com: icmp 104: c-69-244-mm-nn.hsd1.md.comcast.net udp
port 38037 unreachable (wrong icmp cksum 738f (->52c2)!) for IP (tos
0x20, ttl 105, id 52030, offset 0, flags [none], length: 96)
vpnsvr2a.xxx.com.4500 > c-69-244-mm-nn.hsd1.md.comcast.net.38037: [no
cksum] UDP, length: 68
Thanks. Any other thoughts? It might be hard to create this. I
guess
if you made a bidirectional UDP flow starting in the NAT, then stopped
the listener inside, and the other was trying to send UDP in through the
NAT, this could be manufactured. Not trivial, but possible....
- Chris
