Re: Can you create a FreeBSD gateway, with private IPs, without NAT/divert ?
I've seen this setup with IPv4 before when the ISP does native IPv6. Maybe you can get global IPv6 addresses and can SSH directly over that. If not, at least go on record requesting IPv6 with your provider to push them along. Tom > On Jun 7, 2014, at 10:12 AM, None Secure via freebsd-net > wrote: > > Matthew, > > Thanks for your response - I suspect that was the problem I was encountering > (that the ISP will NAT for my external address) and that is why I switched to > natd/divert, and it is indeed working properly. > > So what is the problem ? Well, the problem is I am trying to use sshuttle, > which inserts it's own set of divert rules into the ipfw table ... so I have > one natd_enable, and a set of divert rules ... and then we add another set of > divert rules from sshuttle (which does not, btw, start it's own natd). > > So when you say that I can NAT multiple times ... can I NAT multiple times on > the same system ? If I start a second natd (which sounds ridiculous to me) > how does it know which set of diverts it is supposed to work on ? > > Basically my system is working fine with natd/divert, but now I either need > to make it work without natd/divert (so that sshuttle can do its own) or I > need to find a way to use two sets of natd/divert ... > > Comments ? > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: patch: bad ipv6 neighbor solicitation
I didn't think this routing patch was related to the "bad neighbor solicitation messages" as suggested in the subject field but I tried it anyway. It does not fix my IPv6 problem. I still get "bad neighbor solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 pings. Thanks, Tom On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: > Please find the more proper fix at > > http://people.freebsd.org/~qingli/nd6-patch.diff > > I realized I was slightly off in my previous email after > I spent a bit more time looking through the problem. > Both prefixes are present but one was marked off-link due > to the fact only a single prefix route was installed in > the routing table (non RADIX_MPATH system). > > I evaluated various options to fixing this issue, however, > due to the association between NDPRF_ONLINK and the route > installation, I decided to go with what I have here for > the time being. > > I have verified the fix in my setup. Please apply the > patch and report back. > > Thanks, > > -- Qing > > >> -Original Message- >> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- >> n...@freebsd.org] On Behalf Of Li, Qing >> Sent: Monday, December 14, 2009 3:00 PM >> To: Dennis Glatting; JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd) >> >> >> You don't need to perform all that route-foo. I believe the root cause >> of >> this issue may be due to a bit of regression in the IPv6 prefix >> management >> code, and I am in the process of putting together a permanent fix. >> >> The issue as it stands today, is due to how the prefix was inserted in >> the first place. Since bce0 was configured first, the interface >> associated >> with the prefix is bce0. Later the reference count on the prefix is >> simply incremented when bce1 configures another IPv6 address of the >> same prefix. >> >> When ND6 NS arrives for bce1, due to the interface mismatch of the >> prefix >> interface against the input interface, the NS packet was considered >> invalid and thus dropped. >> >> Again, in case you didn't see my earlier reply, try the temporary hack >> at >>http://people.freebsd.org/~qingli/nd6-ns.diff >> >> until I commit a permanent patch. The problem was easily reproducible >> and >> I have verified with limited unit testing the patch works. >> >> -- Qing >> >> >> -Original Message- >> From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting >> Sent: Mon 12/14/2009 2:03 PM >> To: JASSAL Aman >> Cc: freebsd-net@freebsd.org >> Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd) >> >> >> Thanks. Responses in-line. >> >> >> >> On Mon, 14 Dec 2009, JASSAL Aman wrote: >> >>> Hello Mr.Glatting, >>> >>> Not that I'm an IPv6 genius, but at first sight your problem seems > to >> be a >>> route-related. I've put comments in-line. >>> >>> >>> Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit : Elmer# netstat -rn Routing tables Internet6: Destination Gateway >> Flags Netif Expire ::/96 ::1 > UGRS lo0 => default fd7c:3f2b:e791:1::1 UGSbce0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 >> UGRS lo0 fd7c:3f2b:e791:1::/64 link#1 >> U bce0 fd7c:3f2b:e791:1::ac13:a0alink#1 >> UHS lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2 >> UHS lo0 fe80::/10 ::1 >> UGRS lo0 fe80::%bce0/64link#1 >> U bce0 fe80::213:72ff:fe60:ac52%bce0 link#1 >> UHS lo0 fe80::%bce1/64link#2 >> U bce1 fe80::213:72ff:fe60:ac50%bce1 link#2 >> UHS lo0 fe80::%lo0/64 link#3 >> U lo0 fe80::1%lo0 link#3 >> UHS lo0 ff01:1::/32 fe80::213:72ff:fe60:ac52%bce0 >> U bce0 ff01:2::/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U bce1 ff01:3::/32 ::1 >> U lo0 ff02::/16 ::1 >> UGRS lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0 >> U bce0 ff02::%bce1/32 > fd7c:3f2b:e791:1:0:1:ac13:a0a >> U bce1 ff02::%lo0/32 ::1 >> U lo0 >>> >>> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I > was >>> expecting bce1 rather than lo0, I suppose you were as well :) If I'm >> not >>> mistaken, the packets emanating from bce1 go to the loopback >> interface, >>> thus not really going out. You can try specifying the route manually >>> with "route add *your parameters*" or even set it in /etc/rc.conf so >>> that it's loaded at boot-time. There's no reason why among 2 > physical >>> interfaces sharing the same fabric, one can ship packets out and the >>> other can't. >>> >> >> I was wondering abou
Re: patch: bad ipv6 neighbor solicitation
You are correct. I added the route and it works fine. route add -inet6 2610:28:1800:4001::/64 -iface em0 Thanks, Tom On Dec 15, 2009, at 5:00 PM, Li, Qing wrote: > Thanks for sending me the routing table output. > > Actually I believe both your problems are indeed related to the > prefix route. > > I was able to reproduce Dennis Glatting's problem, which was due > to one of the prefix entry being off-link. > > In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad > disappeared and is not in the routing table. If you add the route > by hand the problem should go away. > > I guess the question is what triggered the prefix route deletion. > > -- Qing > > >> -Original Message- >> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- >> sta...@freebsd.org] On Behalf Of Li, Qing >> Sent: Tuesday, December 15, 2009 1:46 PM >> To: Tom Pusateri >> Cc: freebsd-net@freebsd.org; freebsd-sta...@freebsd.org >> Subject: RE: patch: bad ipv6 neighbor solicitation >> >> Thanks for reporting back. I asked you for a routing table dump >> in my previous email, would you mind emailing it to me privately? >> >> -- Qing >> >> >>> -Original Message- >>> From: Tom Pusateri [mailto:pusat...@bangj.com] >>> Sent: Tuesday, December 15, 2009 1:28 PM >>> To: Li, Qing >>> Cc: freebsd-net@freebsd.org; freebsd-sta...@freebsd.org >>> Subject: Re: patch: bad ipv6 neighbor solicitation >>> >>> I didn't think this routing patch was related to the "bad neighbor >>> solicitation messages" as suggested in the subject field but I tried >> it >>> anyway. It does not fix my IPv6 problem. I still get "bad neighbor >>> solicitation messages" and freebsd 8 doesn't respond to 4/5 IPv6 >> pings. >>> >>> Thanks, >>> Tom >>> >>> On Dec 14, 2009, at 11:53 PM, Li, Qing wrote: >>> >>>> Please find the more proper fix at >>>> >>>>http://people.freebsd.org/~qingli/nd6-patch.diff >>>> >>>> I realized I was slightly off in my previous email after >>>> I spent a bit more time looking through the problem. >>>> Both prefixes are present but one was marked off-link due >>>> to the fact only a single prefix route was installed in >>>> the routing table (non RADIX_MPATH system). >>>> >>>> I evaluated various options to fixing this issue, however, >>>> due to the association between NDPRF_ONLINK and the route >>>> installation, I decided to go with what I have here for >>>> the time being. >>>> >>>> I have verified the fix in my setup. Please apply the >>>> patch and report back. >>>> >>>> Thanks, >>>> >>>> -- Qing >>>> >>>> >>>>> -Original Message- >>>>> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd- >>>>> n...@freebsd.org] On Behalf Of Li, Qing >>>>> Sent: Monday, December 14, 2009 3:00 PM >>>>> To: Dennis Glatting; JASSAL Aman >>>>> Cc: freebsd-net@freebsd.org >>>>> Subject: RE: Understanding multiple IPv6 interfaces under 8.0 > (fwd) >>>>> >>>>> >>>>> You don't need to perform all that route-foo. I believe the root >>> cause >>>>> of >>>>> this issue may be due to a bit of regression in the IPv6 prefix >>>>> management >>>>> code, and I am in the process of putting together a permanent > fix. >>>>> >>>>> The issue as it stands today, is due to how the prefix was >> inserted >>> in >>>>> the first place. Since bce0 was configured first, the interface >>>>> associated >>>>> with the prefix is bce0. Later the reference count on the prefix >> is >>>>> simply incremented when bce1 configures another IPv6 address of >> the >>>>> same prefix. >>>>> >>>>> When ND6 NS arrives for bce1, due to the interface mismatch of > the >>>>> prefix >>>>> interface against the input interface, the NS packet was >> considered >>>>> invalid and thus dropped. >>>>> >>>>> Again, in case you didn't see my earlier reply, try the temporary >>> hack >>>>> at >>>>> http://people.free
Re: re0 link UP/DOWN on 8.1-STABLE amd64
On Aug 11, 2010, at 3:11 PM, Zeus V Panchenko wrote: > Pyun YongHyeon (pyu...@gmail.com) [10.08.11 19:31] wrote: >> On Wed, Aug 11, 2010 at 03:50:14PM +0300, Zeus V Panchenko wrote: >>> Hi All, >>> >>> can enybody help with the subj, please? >>> >>> problem: onboard interface re0 link state UP/DOWN flapping >>> >>> >>> i have: >>> # uname -a >>> FreeBSD 8.1-STABLE #0: Mon Aug 9 10:33:17 EEST 2010 amd64 >>> >>> # dmidecode >>> ... >>> Base Board Information >>> Manufacturer: ASUSTeK Computer INC. >>> Product Name: AT5NM10-I >>> ... >>> >>> # pciconf -lcv >>> r...@pci0:2:0:0: class=0x02 card=0x83a31043 chip=0x816810ec rev=0x03 >>> hdr=0x00 >>>vendor = 'Realtek Semiconductor' >>>device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' >>>class = network >>>subclass = ethernet >>>cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 >>>cap 05[50] = MSI supports 1 message, 64 bit enabled with 1 message >>>cap 10[70] = PCI-Express 2 endpoint IRQ 2 max data 128(256) link x1(x1) >>>cap 11[ac] = MSI-X supports 4 messages in map 0x20 >>>cap 03[cc] = VPD >>> >>> >>> # ifconfig re0 >>> re0: flags=8843 metric 0 mtu 1500 >>> >>> options=389b >>>ether 20:cf:30:89:5e:95 >>>inet 10.10.0.111 netmask 0x broadcast 10.10.255.255 >>>media: Ethernet 1000baseT >>>status: active >>> >>> >>> >>> >>> sporadically interface begins to flap and dmesg shows: >>> ... >>> Aug 11 14:29:44 kernel: re0: link state changed to DOWN >>> Aug 11 14:29:47 kernel: re0: link state changed to UP >>> Aug 11 14:29:58 kernel: re0: link state changed to DOWN >>> Aug 11 14:30:01 kernel: re0: link state changed to UP >>> ... >>> >>> >>> systat doesn't show high interrupts on the card >>> # systat -v >>>1 usersLoad 0.06 0.02 0.00 Aug 11 15:45 >>> >>> Mem:KBREALVIRTUAL VN PAGER SWAP >>> PAGER >>>Tot Share TotShareFree in out in out >>> Act 1069020 177580 2968312 209660 455852 count >>> All 1149408 184236 1076855k 251780 pages >>> Proc:Interrupts >>> r p d s w Csw Trp Sys Int Sof Flt278 cow8057 total >>> 1 74 885 842 1181 57 268 736278 zfodatkbd0 >>> 1 >>> ozfod22 rl0 >>> irq17 >>> 0.4%Sys 0.1%Intr 0.2%User 0.0%Nice 99.3%Idle%ozfod 2000 cpu0: >>> time >>> ||||||||||| daefr33 re0 >>> irq256 >>> 379 prcfr 2 ahci0 >>> 257 >>>29 dtbuf 704 totfr 2000 cpu1: >>> time >>> Namei Name-cache Dir-cache10 desvn react 2000 cpu3: >>> time >>> Callshits %hits % 87484 numvn pdwak 2000 cpu2: >>> time >>> 921 921 100 24183 frevn pdpgs >>>3 intrn >>> Disks ada0 ada1 pass0 pass1 576392 wire >>> KB/t 21.40 0.00 0.00 0.00 1040084 act >>> tps 2 0 0 0 1948900 inact >>> MB/s 0.04 0.00 0.00 0.00 cache >>> %busy 0 0 0 0 455852 free >>> 427520 buf >>> >>> >>> i have changed motherboards ... the same effect. after some time the >>> problem appears again >>> >>> >>> is there any info i can provide? >>> >> >> Show me the output of dmesg and "devinfo -rv | rgephy". > > dmesg contains lines as above: > ... > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > re0: link state changed to DOWN > re0: link state changed to UP > ... > > # dmesg|wc -l >1917 > > as for the devinfo, here it is: > > # devinfo -rv | grep rgephy >rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 > > now all of the boxes which were trasfered to that motherboard shows the same > simptoms :( ... > > and what i have to add is that external card doesn't show this behaviour! :( > > on the ather box with the same hardware but additional nic: > > # devinfo -rv | grep rgeph
Re: RFC 7217
I read the draft and wasn't sure what problem they were trying to solve. They
talk about moving from network to network which seems aimed at laptops or
mobile devices. But randomizing the interface id but keeping it the same on a
particular network allows consistency on each network but you could still be
tracked on that network (like using the MAC address) even though you couldn't
be tracked across networks (unlike using the MAC address).
Why not just use temporary addresses (RFC 4941)?
On the server side, this draft could be implemented in rtadvd. Not sure who
maintains that.
Is that what you're looking for? To see if someone is working on changes to
rtadvd?
Thanks,
Tom
> On Sep 6, 2014, at 6:46 PM, Garrett Wollman wrote:
>
> So is anyone working on an RFC 7217 ("Stable and Opaque IIDs with
> SLAAC") implementation for FreeBSD yet?
>
> -GAWollman
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: UDP/IPv6 handling
Lots of embedded devices (like Cisco IP Phones) send TFTP requests with 0
checksums.
Tom
> On Oct 1, 2014, at 12:58 PM, Michael Tuexen
> wrote:
>
> Dear all,
>
> in udp6_input() we have the following code:
>
>if (nxt == IPPROTO_UDP && plen != ulen) {
>UDPSTAT_INC(udps_badlen);
>goto badunlocked;
>}
>/*
> * Checksum extended UDP header and data.
> */
>if (uh->uh_sum == 0) {
>if (ulen > plen || ulen < sizeof(struct udphdr)) {
>UDPSTAT_INC(udps_nosum);
>goto badunlocked;
>}
>}
>
> I'm trying to understand the UDP code path...
>
> So (ulen > plen) can't be true. I'm wondering why do we only check the ulen
> is not too
> short only in the case when the UDP checksum is zero. A zero checksum should
> also never happen.
>
> I think we should check for ulen < sizeof(struct udphdr) in any case.
>
> Opinions?
>
> Best regards
> Michael
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq
> On Oct 31, 2014, at 11:23 PM, Chris Inacio wrote:
>
> Hello all,
>
> I've tried to find this information in so many ways, but I just can't piece
> it together, maybe my Google fu is failing me.
>
> I have my router/gateway device running FreeBSD 10p11 - so its up to date.
> On my internal network interface, re1, I'm using dnsmasq to serve both IPv4
> DHCP and current private network IPv6 (fc00::).
>
> I can successfully configure my public interface (re0) to get IPv6
> information from Comcast. I'm getting both a /128 NA for the interface as
> well as a prefix /64 to allocate IPv6 addresses.
>
> The problem is that I get the /64 via dhcp6c operating on my re0 interface,
> and then I can't figure out how to pass that information to dnsmasq to use
> it for my internal network. I could only see the /64 by running dhcp6c in
> foreground+debug mode.
>
> Is there a simple solution to this? I'm okay with variations such as "stop
> using dhcp6c to get the /64 prefix and add `X` to dnsmasq to do it" or
> "use dhcp6s to serve the /64 prefix".
>
> I am currently having a few issues with dnsmasq, but generally, I still
> like it. (It keeps crashing with signal 11, but I'm using the version from
> pkg which doesn't call out to an init script.) But the way dnsmasq handles
> DHCP, local DNS, and support DNSSEC I like a lot.
>
> I find the man pages for dhcp6 pretty awful. The man pages describe the
> options - but not being able to find what /64 is assigned to dhcp6c other
> than running in debug mode seems crazy.
>
> My configs are really basic. dhcp6c.conf:
>
> interface re0 {
>
>send ia-pd 0;
>
>send ia-na 1;
>
> };
>
>
> id-assoc na 1 {
>
> };
>
>
> id-assoc pd {
>
>prefix ::/56 infinity;
>
>prefix-interface re0 {
>
>sla-len 4;
>
>sla-id 1;
>
>};
>
> };
>
>
> dnsmasq.conf:
>
>
> interface=re1
>
> dhcp-range=re1,192.168.1.1,192.168.1.150,255.255.255.0,12h
>
> domain-needed
>
> bogus-priv
>
> resolv-file=/usr/local/etc/dnsmasq-resolv.conf
>
>
> #
>
> # serve up our own name
>
> #
>
> interface-name=aticusjr,re1
>
>
>
> #
>
> # enable DNSSEC
>
> #
>
> conf-file=/usr/local/share/dnsmasq/trust-anchors.conf
>
> dnssec
>
> dnssec-check-unsigned
>
>
> #
>
> # do IPv6 router advertisements for internal network
>
> #
>
> dhcp-range=::,constructor:re1,ra-only
>
> enable-ra
>
>
> Any help would be greatly appreciated.
>
>
> thanks
>
> Chris
I have a similar setup on Time Warner that is working. However, I am using
rtadvd for advertising to my internal networks. Also, I was under the
impression that Comcast only would delegate a /64 or a /60, not a /56. Timer
Warner does delegate a /56. Maybe Comcast has changed.
In your case, you are asking for a /56 but then only want to assign 4 bits off
the /64 so your config is inconsistent.
You should change to sla-len 8 for a /56 or change the prefix to /60 for an
sla-len of 4.
dhcp6c should configure the delegated prefix on your downstream interface(s) if
configured correctly and rtadvd will advertise them automatically.
I have described my configuration here and what should work on Comcast. Ignore
the initial rant about NAT. :)
http://stateful.blogspot.com/2014/09/global-ip-addresses-for-end-to-end.html
If this doesn't help, let me know and I can help you figure it out.
Thanks,
Tom
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq
> On Oct 31, 2014, at 11:43 PM, Tom Pusateri wrote:
>
>>
>> On Oct 31, 2014, at 11:23 PM, Chris Inacio wrote:
>>
>> My configs are really basic. dhcp6c.conf:
>>
>> interface re0 {
>>
>> send ia-pd 0;
>>
>> send ia-na 1;
>>
>> };
>>
>>
>> id-assoc na 1 {
>>
>> };
>>
>>
>> id-assoc pd {
>>
>> prefix ::/56 infinity;
>>
>> prefix-interface re0 {
>>
>> sla-len 4;
>>
>> sla-id 1;
>>
>> };
>>
>> };
In addition to my earlier post, you are missing the ID for the ia-pd
association.
replace:
id-assoc pd {
with:
id-assoc pd 0 {
and you are referencing your upstream interface instead of your downstream
interface in the delegated prefix-interface statement.
replace:
prefix-interface re0 {
with
prefix-interface re1 {
Thanks,
Tom
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq
> On Nov 1, 2014, at 1:53 AM, Rui Paulo wrote: > >> I find the man pages for dhcp6 pretty awful. The man pages describe the >> options - but not being able to find what /64 is assigned to dhcp6c other >> than running in debug mode seems crazy. > > There's an alternative: dhclient from ports which includes DHCPv6 support > with prefix delegation. > Chris' config error caused dhcp6c not to configure his downstream interface. dhclient from ports will only work with the default prefix length assigned by the provider. For all providers I have encountered, this is /64 and a good choice. But if you want multiple /64's for multiple interfaces, you have to request a larger prefix (/56 or /60 depending on the policy of the provider). dhclient in ports will not let you do this. In Chris' case, he only has a single downstream interface (for now) and so dhclient in ports would work for that. Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv6 bridge0 link-local address
I've configured a bridge0 interface that bridges fxp0 and em0. I have a global IPv6 address configured on it and IPv6 works fine. # ifconfig bridge0 bridge0: flags=8043 mtu 1500 inet x.x.x.82 netmask 0xfff0 broadcast x.x.x.95 inet6 2001:4877:1777:1001::1 prefixlen 64 ether ac:de:48:49:71:91 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: fxp0 flags=3 member: em0 flags=3 I'm trying to run route6d and it aborts because there is no link local address on the bridge0 interface. I can't even tell route6d to ignore the interface because it won't get past initialization. Is anyone routing route6d over a bridge0 interface and if so, did you add a link local address manually (can you even do that) or some other trick? # route6d -d newif fxp0 found address fe80:1::202:a5ff:fe87:4012/64 index: 1, mtu: 1500, metric: 0 join fxp0 ff02::9 newif em0 found address fe80:2::20e:cff:fe9f:f40a/64 index: 2, mtu: 1500, metric: 0 join em0 ff02::9 newif fxp1 found address fe80:3::2d0:b7ff:fe3c:9dae/64 index: 3, mtu: 1500, metric: 0 join fxp1 ff02::9 found address 2001:4877:1713:1002::1/64 newif fxp2 found address fe80:4::2d0:b7ff:fe3f:42c0/64 index: 4, mtu: 1500, metric: 0 join fxp2 ff02::9 found address 2001:4877:1713:1003::1/64 newif lo0 found address ::1/128 found address fe80:6::1/64 index: 6, mtu: 1500, metric: 0 newif bridge0 found address 2001:4877:1713:1001::1/64 newif gif0 found address fe80:8::202:a5ff:fe87:4012/64 -- :: index: 8, mtu: 1280, metric: 0 join gif0 ff02::9 found address 2001:4877:1700:29::2/128 -- :: newif tun0 found address fe80:9::202:a5ff:fe87:4012/64 -- :: index: 9, mtu: 1500, metric: 0 join tun0 ff02::9 newif gif1 found address 2001:4877:1713:1011::1/64 -- :: found address fe80:b::202:a5ff:fe87:4012/64 -- :: index: 11, mtu: 1280, metric: 0 join gif1 ff02::9 No ifindex found at bridge0 (no link-local address?) Thanks, Tom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
