Problem with IPv6 autoconfiguration and DFE-550TX
Hi, IPv6 autoconfiguration with -STABLE and Dlink DFE-550TX network adapters is not working as it should. My network topology is simple : 3 machines on the same ethernet segment, connected by a 10/100 hub. They are running 4.4-RC as of today and use the same NIC, a Dlink DFE-550TX (ste driver). Initialy running the 'rtsol ste0' command on a client machines did not give any result. I then tried to see what was going on on the wire by running tcpdump. This modified the behavior of the machine running it. Here are some tcpdump results observed after running a single 'rtsol' command on the client: Router and client interfaces in normal mode. traffic captured from an other machine on the same hub: 10:19:50.036 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:19:54.055 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:19:58.075 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation Tcpdump running on the router. The router and an other machine on the wire show the same results: 10:20:42.590 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:20:42.882 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement 10:20:46.609 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:20:46.742 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement 10:20:50.629 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:20:50.802 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement The client does not get configured. Tcpdump running on the client, router interface in normal mode The client and the observation machine show the same results: 10:22:04.575 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:22:08.595 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:22:12.615 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation The client does not get configured. Tcpdump running on the client and the router. All three machines show the same results: 10:25:23.608 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 10:25:24.083 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement 10:25:24.084 :: > ff02::1:ff71:bded: icmp6: neighbor sol: who has [client] Here, the client machine gets configured. It seems that only the machines having their interface in promiscuous mode were able to receive the multicast datagrams. They then ran as they should have, which leads me to think the problem is not with the card itself. Is this a known problem with the ste driver ? How can I be sure the client does not receive the advertisement without running tcpdump ? Thanks in advance, Francois Tigeot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
all router address "ff02::02"
Hi, I found that in the rtadvd daemon code there is a function which is called to join to the all router multicast address( ff02::02). My doubt is if rtadvd is disabled for a router then whether it will join the all routers multicast list? one reason i find for such a implementation is that joining the all router multicast address (ff02::02) is useless for a router if it is not running rtadvd. Is my understanding correct? or is the router joins the all router multicast address at some other place other than rtadvd? Kindly reply. regards ravi prasad __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
gctimer default value
Hi, When a link address enters the stale state you have added a nd6_gctimer ( garbage collection timer) so that the entry is removed after the address time expires in the stale state. I found that the value of this is one day. Is this the default value. Or this value can changed by the system administrator according to his convinence? Kindly reply. regards ravi prasad __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
No Subject
Hello all, I hope this time (the second attempt) somebody can help me, because I know other users have the solution. What do I need to do with my kernel or configuration files or whatsoever in order to be able to see a Link Address fe80::8007:544%gif0 link#... 8007:544 is derived from the IPv4 address 128.7.5.68. It belongs to the so named IPv6 compatible addresses important for tunnels. thanks a lot Anastasia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: TFTP sorcerer's apprentice syndrome
Hello Peter,
Now I used the tftp-hpa-0.21 client with a tftp server (SuSE 6.4,
where a tftpd runs in whose binary code I found:
tftp-hpa $Id: tftd.c,v 1.4 1999/09/26 07:12:54 hpa Exp).
I inserted in tftp/tftp.c after line
285 if (dp->th_block == block) {
following lines:
if (block == 1) {
sleep(6);
}
So the first ACK is delayed and the server sends DATA block # 1 again.
The duplicate ACKs and DATA packets remain until ACK block # 09
and DATA block # 0a
So it is not the syndrome until the end of the transfer, but
for the first 10 packets (in this special setup). I don't know how
the syndrome is resolved in this case (by server or by client?).
(This can be seen with tftp options trace,verbose on or with tcpdump).
Of course in this case it doesn't matter if whithin a part of a second
10 data packets and 10 acks are duplicated. But I am still not sure
if the server conforms with the RFC.
Gerhard
A part of tcpdump output follows:
09:32:12.632661 client.registrar > server.tftp: 23 RRQ "/tftpboot/file"
4500 0033 4ebd 4011 278a c0a8 4217
c0a8 410b 06b0 0045 001f 6e36 0001 2f74
6674 7062 6f6f 742f 6669 6c65 006f 6374
6574 00
09:32:12.680322 server.1043 > client.registrar: udp 516
4500 0220 67d0 4011 0c8a c0a8 410b
c0a8 4217 0413 06b0 020c cefe 0003 0001
b8c0 078e d8b8 0090 8ec0 b900 0129 f629
fffc f3a5 ea19
09:32:17.680152 server.1043 > client.registrar: udp 516
4500 0220 6852 4011 0c08 c0a8 410b
c0a8 4217 0413 06b0 020c cefe 0003 0001
b8c0 078e d8b8 0090 8ec0 b900 0129 f629
fffc f3a5 ea19
09:32:18.687882 client.registrar > server.1043: udp 4
4500 0020 55b1 4011 20a9 c0a8 4217
c0a8 410b 06b0 0413 000c f09a 0004 0001
09:32:18.688000 client.registrar > server.1043: udp 4
4500 0020 55b2 4011 20a8 c0a8 4217
c0a8 410b 06b0 0413 000c f09a 0004 0001
09:32:18.688095 server.1043 > client.registrar: udp 516
4500 0220 686b 4011 0bef c0a8 410b
c0a8 4217 0413 06b0 020c 41fd 0003 0002
eb24 4864 7253 0102 0010 0903
0001 0080
09:32:18.688237 server.1043 > client.registrar: udp 516
4500 0220 686c 4011 0bee c0a8 410b
c0a8 4217 0413 06b0 020c 41fd 0003 0002
eb24 4864 7253 0102 0010 0903
0001 0080
09:32:18.688537 client.registrar > server.1043: udp 4
4500 0020 55b4 4011 20a6 c0a8 4217
c0a8 410b 06b0 0413 000c f099 0004 0002
09:32:18.688618 server.1043 > client.registrar: udp 516
4500 0220 686d 4011 0bed c0a8 410b
c0a8 4217 0413 06b0 020c 9f54 0003 0003
0303 2ef6 0611 0001 7402 eb25 b800 018c
cd83 ed20 2e8b
09:32:18.688653 client.registrar > server.1043: udp 4
4500 0020 55b6 4011 20a4 c0a8 4217
c0a8 410b 06b0 0413 000c f099 0004 0002
09:32:18.688800 server.1043 > client.registrar: udp 516
4500 0220 686e 4011 0bec c0a8 410b
c0a8 4217 0413 06b0 020c 9f54 0003 0003
0303 2ef6 0611 0001 7402 eb25 b800 018c
cd83 ed20 2e8b
09:32:18.689040 client.registrar > server.1043: udp 4
4500 0020 55b7 4011 20a3 c0a8 4217
c0a8 410b 06b0 0413 000c f098 0004 0003
09:32:18.689134 server.1043 > client.registrar: udp 516
4500 0220 686f 4011 0beb c0a8 410b
c0a8 4217 0413 06b0 020c 5275 0003 0004
6d65 6d6f 7279 2e20 2047 6976 696e 6720
7570 2e00 6651
09:32:18.689208 client.registrar > server.1043: udp 4
4500 0020 55b8 4011 20a2 c0a8 4217
c0a8 410b 06b0 0413 000c f098 0004 0003
09:32:18.689298 server.1043 > client.registrar: udp 516
4500 0220 6870 4011 0bea c0a8 410b
c0a8 4217 0413 06b0 020c 5275 0003 0004
6d65 6d6f 7279 2e20 2047 6976 6
Re: Problem with IPv6 autoconfiguration and DFE-550TX
> Hi, > > IPv6 autoconfiguration with -STABLE and Dlink DFE-550TX network adapters is > not working as it should. > > My network topology is simple : 3 machines on the same ethernet segment, > connected by a 10/100 hub. They are running 4.4-RC as of today and use the > same NIC, a Dlink DFE-550TX (ste driver). I need you do "pciconf -l | grep ste" so that I can see which revision of the Sundance Technologies "alta" chip you have on your card. I have samples of these cards (which I used to write the driver) but they're old. I want to be sure this problem isn't due to behavioral differences between your chip rev and mine. > Here are some tcpdump results observed after running a single 'rtsol' command > on the client: For the record, the best way to run tcpdump is: # tcpdump -n -e -i foo0 This will show you the ethernet frame header, which is sort of important when you're trying to debug an ethernet problem. In this case, had you used the -e flag, we would have seen that the problem is you aren't receiving multiast packets, or at least certain multicast packets. Forcing the NIC into promisc mode gets around the problem, but the real issue is that the multicast filter isn't being programmed correctly. This is usually one of the things I test during driver development though, so I'm a little confused to see that it's not working now. (It should have been working before, or I would not have committed the driver.) I'm going to stick one of my sample DFE-550TX cards in a test box in the lab and see if I can duplicate this problem, but it would help if you could run tcpdump -n -e -i ste0 so that we can see just what multicast address the NIC should be receiving. > Is this a known problem with the ste driver ? Ok, you know, I'm getting tired of people asking this question. It makes it sound like I leave bugs lying around just for people to trip on. If I knew about this problem, I would have fixed it. > How can I be sure the client does not receive the advertisement without > running tcpdump ? You can also run tcpdump -n -e -p -i ste0. The -p flag means "don't put the interface into promisc mode." -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with IPv6 autoconfiguration and DFE-550TX
>IPv6 autoconfiguration with -STABLE and Dlink DFE-550TX network adapters is >not working as it should. my guess is that either of the machines (the router, or the end node) have a broken multicast packet filter on the card, or the driver is broken in terms of multicast packet filter initialization. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with IPv6 autoconfiguration and DFE-550TX
On 23 Aug, [EMAIL PROTECTED] wrote: > > >IPv6 autoconfiguration with -STABLE and Dlink DFE-550TX network adapters is > >not working as it should. > > my guess is that either of the machines (the router, or the end node) > have a broken multicast packet filter on the card, or the driver is > broken in terms of multicast packet filter initialization. Since everything works when the interface is put in promiscuous mode, the problem is certainly in the driver. I'll try to see if I can figure something obvious, but ethernet drivers are not really my cup of tea... Francois To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
No Subject
> I hope this time (the second attempt) somebody can help me, because I know >other users have the solution. >What do I need to do with my kernel or configuration files or whatsoever >in order to be able to see a Link Address > >fe80::8007:544%gif0 link#... > >8007:544 is derived from the IPv4 address 128.7.5.68. > >It belongs to the so named IPv6 compatible addresses important for tunnels. - it is not an IPv4 compatible address, as mentioned in RFC2373. (it is like ::8007:544, or ::128.7.5.68) - freebsd (KAME) does not support automatic tunnels as mentioned in RFC1933 (which uses IPv4 compatible address). to configure tunnel endpoint for configured IPv6-over-IPv4 tunnels, use gifconfig(8). itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
No Subject
>> I hope this time (the second attempt) somebody can help me, because I know >>other users have the solution. >>What do I need to do with my kernel or configuration files or whatsoever >>in order to be able to see a Link Address >> >>fe80::8007:544%gif0 link#... >> >>8007:544 is derived from the IPv4 address 128.7.5.68. >> >>It belongs to the so named IPv6 compatible addresses important for tunnels. > - it is not an IPv4 compatible address, as mentioned in RFC2373. > (it is like ::8007:544, or ::128.7.5.68) > - freebsd (KAME) does not support automatic tunnels as mentioned in > RFC1933 (which uses IPv4 compatible address). > to configure tunnel endpoint for configured IPv6-over-IPv4 tunnels, > use gifconfig(8). > >itojun thank you for writing! My problem is that, when trying a tunnel between a Linux box to the FreeBSD box, in the Linux routing table, the nexthop address is fe80::8007:54. (here 8007:54 is in hexadecimal the IPv4 address of the FreeBSD box -or sit1 for Linux (endpoint of the tunnel). This is not a compatible address as you say, but is it possible to have this address on the FreeBSD box. I think its necessary for the tunnel. Anastasia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with IPv6 autoconfiguration and DFE-550TX
Hi, Are you sure that all your nodes are running 10 Mbit or 100 Mbit ? Will the hub get confused by a mixture of 10 and 100 Mbit cards? I have recently seen a case like this (on NetBSD 1.5 sending NS). Try using a cross-over cable between your router and each of your hosts - one at a time. This will isolate the case of the failure - in my case the hub... regards Palle Francois Tigeot wrote: > Hi, > > IPv6 autoconfiguration with -STABLE and Dlink DFE-550TX network adapters is > not working as it should. > > My network topology is simple : 3 machines on the same ethernet segment, > connected by a 10/100 hub. They are running 4.4-RC as of today and use the > same NIC, a Dlink DFE-550TX (ste driver). > > Initialy running the 'rtsol ste0' command on a client machines did not give > any result. > I then tried to see what was going on on the wire by running tcpdump. This > modified the behavior of the machine running it. > > Here are some tcpdump results observed after running a single 'rtsol' command > on the client: > > Router and client interfaces in normal mode. > traffic captured from an other machine on the same hub: > > 10:19:50.036 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:19:54.055 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:19:58.075 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > > Tcpdump running on the router. > The router and an other machine on the wire show the same results: > > 10:20:42.590 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:20:42.882 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement > 10:20:46.609 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:20:46.742 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement > 10:20:50.629 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:20:50.802 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement > > The client does not get configured. > > Tcpdump running on the client, router interface in normal mode > The client and the observation machine show the same results: > > 10:22:04.575 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:22:08.595 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:22:12.615 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > > The client does not get configured. > > Tcpdump running on the client and the router. > All three machines show the same results: > > 10:25:23.608 fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation > 10:25:24.083 fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement > 10:25:24.084 :: > ff02::1:ff71:bded: icmp6: neighbor sol: who has [client] > > Here, the client machine gets configured. > > It seems that only the machines having their interface in promiscuous mode > were able to receive the multicast datagrams. They then ran as they should > have, which leads me to think the problem is not with the card itself. > > Is this a known problem with the ste driver ? > > How can I be sure the client does not receive the advertisement without > running tcpdump ? > > Thanks in advance, > > Francois Tigeot > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with IPv6 autoconfiguration and DFE-550TX
Ok, I think I found the bug. There was a problem with the way I was loading the hash table for the multicast filter. The chip actually uses 4 16-bit registers, not two 32-bit ones. Please apply the patch at: http://www.freebsd.org/~wpaul/Sundance/ste.diff # cd /tmp # fetch http://www.freebsd.org/~wpaul/Sundance/ste.diff # cd /sys/pci # patch < /tmp/ste.diff Then compile a new kernel and/or new if_ste.ko kernel module. Please let me know if this helps. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with IPv6 autoconfiguration and DFE-550TX
On 23 Aug, Bill Paul wrote: > > IPv6 autoconfiguration with -STABLE and Dlink DFE-550TX network adapters is > > not working as it should. > > I need you do "pciconf -l | grep ste" All cards have the same behavior. Here you go: ste0@pci0:15:0: class=0x02 card=0x10021186 chip=0x10021186 rev=0x00 hdr=0x00 ste0@pci0:9:0: class=0x02 card=0x10021186 chip=0x10021186 rev=0x00 hdr=0x00 ste0@pci0:8:0: class=0x02 card=0x10021186 chip=0x10021186 rev=0x00 hdr=0x00 > so that I can see which revision > of the Sundance Technologies "alta" chip you have on your card. I have > samples of these cards (which I used to write the driver) but they're > old. I want to be sure this problem isn't due to behavioral differences > between your chip rev and mine. [...] > but the > real issue is that the multicast filter isn't being programmed > correctly. Yes. I have patched your driver to force the card to listen to all multicast datagrams and not use the filter. It works perfectly. > I'm going to stick one of my sample DFE-550TX cards in a test box > in the lab and see if I can duplicate this problem, but it would help > if you could run tcpdump -n -e -i ste0 so that we can see just what > multicast address the NIC should be receiving. tcpdump -n -e -i ste0 ip6 on the client: 20:59:09.335613 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 20:59:09.460728 0:50:ba:15:69:fc 33:33:0:0:0:1 86dd 142: fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement 20:59:09.461028 0:50:ba:71:bd:ed 33:33:ff:71:bd:ed 86dd 78: :: > ff02::1:ff71:bded: icmp6: neighbor sol: who has 2002:c1fc:3606:0:250:baff:fe71:bded and on the router: 21:00:43.207059 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 21:00:43.332052 0:50:ba:15:69:fc 33:33:0:0:0:1 86dd 142: fe80::250:baff:fe15:69fc > ff02::1: icmp6: router advertisement 21:00:43.332464 0:50:ba:71:bd:ed 33:33:ff:71:bd:ed 86dd 78: :: > ff02::1:ff71:bded: icmp6: neighbor sol: who has 2002:c1fc:3606:0:250:baff:fe71:bded > > Is this a known problem with the ste driver ? > > Ok, you know, I'm getting tired of people asking this question. It > makes it sound like I leave bugs lying around just for people to > trip on. If I knew about this problem, I would have fixed it. Hey, relax. I didn't imply you write buggy drivers. It just seemed strange nobody else had seen this problem before... > > How can I be sure the client does not receive the advertisement without > > running tcpdump ? > > You can also run tcpdump -n -e -p -i ste0. The -p flag means "don't > put the interface into promisc mode." If I do that, I get the following results : 20:47:24.524999 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 20:47:28.545067 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation 20:47:32.565102 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded > ff02::2: icmp6: router solicitation Other machines (in promiscuous mode, or with a patched driver) show the router advertisements. Francois To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with IPv6 autoconfiguration and DFE-550TX
On 23 Aug, Bill Paul wrote: > Ok, I think I found the bug. There was a problem with the way I was > loading the hash table for the multicast filter. The chip actually > uses 4 16-bit registers, not two 32-bit ones. Please apply the patch > at: > > http://www.freebsd.org/~wpaul/Sundance/ste.diff > > Then compile a new kernel and/or new if_ste.ko kernel module. > > Please let me know if this helps. The patched systems work like a charm. Many thanks for your prompt reaction ! Francois To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Serious i386 interrupt mask bug in RELENG_4 (was Re: 4.4-RC NFS panic)
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>
>I think that might be due to a bug in the shared interrupt code that
>Ian Dowse sent me about earlier today.
Just to add a few details - there is a bug in the update_masks()
function in i386/isa/intr_machdep.c that can cause some interrupts
to occur at times when they should be masked. The problem only
occurs with certain configurations of shared interrupts and devices,
and this code is only present in RELENG_4.
The update_masks() function is called after an interrupt handler
has been registered or removed. Its main function is to update the
interrupt masks (tty_imask, net_imask etc) if necessary (e.g if
IRQ11 is registered by a tty-type device, IRQ11 will be added to
tty_imask so that future spltty()'s will mask IRQ11).
A second function of update_masks() is to update the cached copy
of the interrupt mask stored with each handler for a multiplexed
interrupt. This is done via the call to update_mux_masks().
The bug is that update_masks() returns without calling update_mux_masks()
in some cases where it should call it. Specifically, if a newly-added
multiplexed interrupt handler has the same maskptr as another
handler on the same IRQ line, that new handler doesn't get it's
cached mask set. For example if a single IRQ has a usb device and
a modem (tty), the second device to register it's handler will get
its idesc->mask set to 0 instead of the value of tty_imask because
update_mux_masks() may never be called to set it. Of course, if
update_masks() is called later for some other device it may correct
the situation.
Interrupt handlers are called with intr_mask[irq] or'd into the
cpl to block further interrupts; for non-multiplexed interrupts
intr_mask[irq] will set from one of the *_imask masks. However with
multiplexed interrupts, only the IRQ itself (and SWI_CLOCK_MASK)
are blocked, and the multiplex handler intr_mux() needs to raise
the cpl further when necessary. It uses idesc->mask to control
this.
When this bug occurs, idesc->mask == 0, so the device interrupt
handler gets called with only the IRQ and SWI_CLOCK_MASK masked,
instead of the full *_mask that it requested. Not good.
On my laptop, this bug causes hangs within minutes of starting to
use a pccard modem, but as should be apparent from the above it
could strike virtually anywhere that multiplexed interrupts are
used. The patch below seems to solve the problem; it just causes
update_masks() to unconditionally update the masks.
Ian
Index: intr_machdep.c
===
RCS file: /home/iedowse/CVS/src/sys/i386/isa/intr_machdep.c,v
retrieving revision 1.29.2.2
diff -u -r1.29.2.2 intr_machdep.c
--- intr_machdep.c 2000/08/16 05:35:34 1.29.2.2
+++ intr_machdep.c 2001/08/23 20:24:17
@@ -651,15 +651,9 @@
if (find_idesc(maskptr, irq) == NULL) {
/* no reference to this maskptr was found in this irq's chain */
- if ((*maskptr & mask) == 0)
- return;
- /* the irq was included in the classes mask, remove it */
*maskptr &= ~mask;
} else {
/* a reference to this maskptr was found in this irq's chain */
- if ((*maskptr & mask) != 0)
- return;
- /* put the irq into the classes mask */
*maskptr |= mask;
}
/* we need to update all values in the intr_mask[irq] array */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Proposed change to icmp_may_rst induced ENETRESET
As another heavy nmap user, I'd vote just the other way. It's useful to differentiate between a reset coming back from the destination host and an unreachable from a firewall/router-acl. Ordinary apps probably don't care all that much about why a connection could not be established, and just report the error to the user. Barney Wolff On Wed, Aug 22, 2001 at 02:05:04AM -0700, Scott Renfro wrote: > On Tue, Mar 27, 2001 at 10:48:26AM -0600, Jonathan Lemon wrote: > > On Tue, Mar 27, 2001 at 06:36:46PM +0200, Jesper Skriver wrote: > > > On Tue, Mar 27, 2001 at 10:19:22AM -0600, Jonathan Lemon wrote: > > > > > > > > I forget why I picked ENETRESET; probably because it was the > > > > first thing that leaped out at me when I quickly skimmed over > > > > looking for an appropriate error code; but I > > > > didn't consider the UDP case. > > > > > > --- src/sys/netinet/ip_input.c2001/03/08 23:14:54 > > > 1.130.2.21 > > > +++ src/sys/netinet/ip_input.c2001/03/27 16:35:15 > > > @@ -1484,7 +1484,7 @@ > > > EHOSTUNREACH, EHOSTUNREACH, ECONNREFUSED, ECONNREFUSED, > > > EMSGSIZE, EHOSTUNREACH, 0, 0, > > > 0,0, > > > 0, 0, > > > - ENOPROTOOPT, ENETRESET > > > + ENOPROTOOPT, ECONNREFUSED > > > }; > > > > Yes, I think this probably is the best approach; just get rid > > of the ENETRESET altogether for this case. > > In follow-up to this discussion from March (yes, I'm a slow reader ;-), > I'd like to propose that we do, in fact, s/ENETRESET/ECONNREFUSED/ in > the inetctlerrmap in ip_input.c. > > At work, we make extensive use of nmap, which uses a mixture of > OS-provided stack features and direct packet capture/generation. We > discovered that the icmp_may_rst code added to FreeBSD causes nmap to > report incorrect results when ICMP_UNREACH_*_PROHIB messages are > received in response to connect(2). > > We've considered just disabling the tunable, changing nmap, or changing > FreeBSD. After much analysis, we've concluded that most sensible change > is for FreeBSD to generate an ECONNREFUSED in response to the icmp > unreach prohib messages. I'm sure other applications expect > ECONNREFUSED but not ENETRESET in response to connect(2) calls as well. > > Since this only occurs in the TCPS_SYN_SENT state, there cannot be an > actual tcp connection in place to reset. And, since we're in a SYN_SENT > state, what is most likely happening is that our connection request is > being refused by the remote host (or an upstream router/firewall). > > Finally, ECONNREFUSED is, and long has been, a documented error in the > connect(2) man page. > > While I'm at it, I'll be bold and request that if this change is > acceptable, it be MFC'd for 4.4-RELEASE (I think this is a low-risk, > high-payoff change, but opinions may vary). (I do like the icmp_may_rst > behavior in general, of course.) > > I've attached a copy of the desired patch since the one above may be > hosed by message reformatting. > > cheers, > --Scott > > -- > Scott Renfro <[EMAIL PROTECTED]> +1 650 862 4206 > --- src/sys/netinet/ip_input.c.orig Wed Aug 22 01:49:43 2001 > +++ src/sys/netinet/ip_input.cWed Aug 22 01:50:06 2001 > @@ -1562,7 +1562,7 @@ > EHOSTUNREACH, EHOSTUNREACH, ECONNREFUSED, ECONNREFUSED, > EMSGSIZE, EHOSTUNREACH, 0, 0, > 0, 0, 0, 0, > - ENOPROTOOPT,ENETRESET > + ENOPROTOOPT,ECONNREFUSED > }; > > /* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Serious i386 interrupt mask bug in RELENG_4 (was Re: 4.4-RC NFS panic)
Ian Dowse writes: > In message <[EMAIL PROTECTED]>, Warner Losh writes: > > > >I think that might be due to a bug in the shared interrupt code that > >Ian Dowse sent me about earlier today. > > Just to add a few details - there is a bug in the update_masks() > function in i386/isa/intr_machdep.c that can cause some interrupts > to occur at times when they should be masked. The problem only > occurs with certain configurations of shared interrupts and devices, > and this code is only present in RELENG_4. Congratulations! I've applied your patch together with the one posted by Warner Losh and now the PCMCIA card is working again and the find/cat test passed without panic. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Proposed change to icmp_may_rst induced ENETRESET
On Thu, Aug 23, 2001 at 04:53:26PM -0400, Barney Wolff wrote: > > As another heavy nmap user, I'd vote just the other way. It's useful > to differentiate between a reset coming back from the destination host > and an unreachable from a firewall/router-acl. Ordinary apps probably > don't care all that much about why a connection could not be > established, and just report the error to the user. I suspect that most (good) applications use strerror(3) to map errors into messages for the user. Today, users get "Network dropped connection on reset"; with the patch they'd get "Connection refused". I think the latter is preferred under POLA, especially when the former is not a documented response to connect(2). You have a valid point that icmp_may_rst changes nmap's behavior, even with the proposed patch. If you want nmap's historic behavior (admin prohib ==> filtered), then turning off icmp_may_rst works. With icmp_may_rst turned on and the patch commited, you get the other behavior (admin prohib ==> closed). Without the patch, nmap spews errors and would need a FreeBSD-specific change. regards, --Scott -- Scott Renfro <[EMAIL PROTECTED]> +1 650 862 4206 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
No Subject
>thank you for writing! >My problem is that, when trying a tunnel between a Linux box to the >FreeBSD box, in the Linux routing table, the nexthop address >is fe80::8007:54. (here 8007:54 is in hexadecimal the IPv4 address of the >FreeBSD box -or sit1 for Linux (endpoint of the tunnel). >This is not a compatible address as you say, but is it possible to have >this address on the FreeBSD box. I think its necessary for the tunnel. it shouldn't really matter. but if you really care, remove fe80:: you have and then add the new one. # ifconfig gif0 up # ifconfig gif0 inet6 fe80:: -alias # ifconfig gif0 inet6 fe80::8007:54 prefixlen 64 alias itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
