Well, I'm screwed.
I set up the Linksys router so that the FreeBSD machine is the "DMZ" host on the inside. Sending 6to4 to the router's outside address results in tcpdump showing these on the inside:
22:09:36.138924 [linksys mac address] > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has [linksys outside ip] tell [linksys inside ip]
Which, quite frankly, is laughable. If that weren't enough, the packets come out of the linksys router with the source IP address being from the inside (meaning, it didn't get NATted). Humph.
So it appears that for now, I will have to keep a 2nd interface active on this box solely for the purpose of doing IPv6. What a nightmare.
On Mar 11, 2005, at 4:38 PM, Nick Sayer wrote:
Hajimu UMEMOTO wrote:
I posted my proposed patch to current@ for review in the past. But,
no one responded. Could you test this? This is for 6-CURRENT at Feb 1.
If it doesn't apply cleanly, please let me know.
Domo arigato gozaimasu!
It had fuzz when applied to 5.3-RELEASE, but it did apply.
I am at work, behind the wrong firewall, so I cannot test this completely, but with your patch applied and turned on, I can see that configuring my machine (which lives in 172.16 space) with a "foreign" 6to4 prefix on stf0 results in ping6 packets being transmitted correctly (tcpdump shows a correct ipv6 packet and shows an ipv4 header with the packet being from my 172.16 machine and going to the correct destination). I have high hopes that the return side will work when it's deployed for real.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
