em driver doesn't set multicast ethernet address
While testing -CURRENT in VMWare environment, I discovered that em driver doesn't properly set destination address in Ethernet header. In the other words, when I start listening multicast session with mcastread (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is 224.0.0.22, but its destionation Ethernet address doesn't look like 01:00:5e:... Other machines that I run in same environment (like FreeBSD-7) behave in good manner. ___ 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: em driver doesn't set multicast ethernet address
ipre...@freebsd.org wrote: While testing -CURRENT in VMWare environment, I discovered that em driver doesn't properly set destination address in Ethernet header. In the other words, when I start listening multicast session with mcastread (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is 224.0.0.22, but its destionation Ethernet address doesn't look like 01:00:5e:... Other machines that I run in same environment (like FreeBSD-7) behave in good manner. It seems that the introduction of IGMPv3 may have exposed some driver/hardware issues, where certain network interfaces are not able to transmit on groups which haven't been joined for receive. This is a bug, and would likely break production use of IPv6, which makes heavier use of link-scope groups than IPv4 does. Can you provide the following information please, so that someone can better help you: 1) the date of the -CURRENT code you are using; 2) tcpdump or wireshark capture output, containing the actual output generated by em(4). Does this issue occur if you use the 'mtest' tool to join 224.0.0.22 inside the guest? The kernel will *not* listen to 224.0.0.22, unless you're running a multicast routing daemon -- as it doesn't have to; that link-scope group is for reports only. This issue doesn't appear with IGMPv2, because it only ever transmits its reports on the group thus joined. This has the disadvantage that multicast routers have to have functioning promiscuous multicast receive, just to proxy or forward traffic. Can you force the use of IGMPv2 using the sysctls as defined in the igmp(4) man page as a workaround? thanks, BMS ___ 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: em driver doesn't set multicast ethernet address
On Sat, Jul 11, 2009 at 09:14:29AM +0100, Bruce Simpson wrote: > ipre...@freebsd.org wrote: >> While testing -CURRENT in VMWare environment, I discovered that em >> driver doesn't properly set destination address in Ethernet header. In >> the other words, when I start listening multicast session with mcastread >> (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is >> 224.0.0.22, but its destionation Ethernet address doesn't look like >> 01:00:5e:... Other machines that I run in same environment (like >> FreeBSD-7) behave in good manner. >> > > It seems that the introduction of IGMPv3 may have exposed some > driver/hardware issues, where certain network interfaces are not able to > transmit on groups which haven't been joined for receive. This is a bug, > and would likely break production use of IPv6, which makes heavier use of > link-scope groups than IPv4 does. > > Can you provide the following information please, so that someone can > better help you: > 1) the date of the -CURRENT code you are using; > 2) tcpdump or wireshark capture output, containing the actual output > generated by em(4). 1) Problem emerged after I upgraded to BETA1 and stayed there after I upgraded to p4 version dated 10th of July. Before that I used few months old snapshot (can't exactly tell the date). 2) dump file generated by wireshark is attached > > Does this issue occur if you use the 'mtest' tool to join 224.0.0.22 inside > the guest? The kernel will *not* listen to 224.0.0.22, unless you're > running a multicast routing daemon -- as it doesn't have to; that > link-scope group is for reports only. There is no difference, ethernet destination is still usual unicast address. > > This issue doesn't appear with IGMPv2, because it only ever transmits its > reports on the group thus joined. This has the disadvantage that multicast > routers have to have functioning promiscuous multicast receive, just to > proxy or forward traffic. > > Can you force the use of IGMPv2 using the sysctls as defined in the igmp(4) > man page as a workaround? Well, now, something really interesting happened. I changed default IGMP version via sysctl # sysctl net.inet.igmp.default_version=2 but, then I tested it with mtest and generated packets were still IGMPv3 Membership reports, but first two of them had proper mcast ethernet address. They generated sent by mtest. > > thanks, > BMS > ___ > 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" igmp.dump Description: Binary data ___ 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: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
Li, Qing wrote: Hi, Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the patch but turned out I didn't. I apply the patch, reset my pf.conf to its previous content and all is running smoothly. By the way, I discover after my post that my "solution" was not working for long (many bytes) connections and this is solved too. Many thank for your time Henri PS please commit as soon as possible On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: This is by design as part of the new architecture in 8.0, which maintains the L2 ARP/ND6 and L3 routing tables separately. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-sta...@freebsd.org; freebsd...@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.100:1d:60:ad:2a:ce 2001:41d0:2:2d29:1:1::00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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: kern/127050: [carp] ipv6 does not work on carp interfaces [regression]
The following reply was made to PR kern/127050; it has been noted by GNATS. From: =?ISO-8859-1?Q?Angelo_H=F6ngens?= To: bug-follo...@freebsd.org, maddo...@maddog2k.net Cc: Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] Date: Sat, 11 Jul 2009 12:06:30 +0200 A few months ago I could not ping any virtual ipv6 addresses. However, I'm running 7.2 now, and decided to pick up this issue. Something seems to have changed, and I can ping at least the first ipv6 address of a carp interface (just not the others) Some more info: I have four reverse cache machines (simple Dell R300's), running Squid. The four machines are balanced by round robin DNS. The DNS publishes 4 virtual carp addresses, and each node has 4 carp interfaces, but is always the master over its own one. This way, up to three nodes can fail, and the other takes over. Works like a charm, but of course I want to enable ipv6 over the same infrastructure. I've configured ipv6 aliases on all interfaces, and rebooted all nodes. Now the funny thing is, I can ping all ipv4 ip's (it's been running in production for months), I can ping6 the the dedicated ip's of all nodes (2001:81:82::206:113 for the node below), and I can ping to all the FIRST ipv6 addresses of the carp interfaces. Could very well be something I'm doing wrong, but I think it's a bug in carp. (Of course I could work around it by creating 16 carp interfaces on each machine, but I don't know what's the best solution.) So: I can ping6 to 2001:81:82::206:81 I can ping6 to 2001:81:82::206:82 I can ping6 to 2001:81:82::206:83 I can ping6 to 2001:81:82::206:84 I can NOT ping6 to 2001:81:82::206:85 I can NOT ping6 to 2001:81:82::206:86 I can NOT ping6 to 2001:81:82::206:87 I can NOT ping6 to 2001:81:82::206:88 I can NOT ping6 to 2001:81:82::206:121 I can NOT ping6 to 2001:81:82::206:122 I can NOT ping6 to 2001:81:82::206:123 I can NOT ping6 to 2001:81:82::206:124 Here you see pings on the cluster node. Pings to :81 get answered, but the node does not answer of neighbor solicitaions to :85: $ sudo tcpdump -ni nic0 icmp6 listening on nic0, link-type EN10MB (Ethernet), capture size 96 bytes 11:54:09.846489 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 > 2001:81:82::206:81: ICMP6, echo request, seq 0, length 16 11:54:09.846524 IP6 2001:81:82::206:81 > 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 0, length 16 11:54:10.845796 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 > 2001:81:82::206:81: ICMP6, echo request, seq 1, length 16 11:54:10.845829 IP6 2001:81:82::206:81 > 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 1, length 16 11:54:11.848522 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 > 2001:81:82::206:81: ICMP6, echo request, seq 2, length 16 11:54:11.848539 IP6 2001:81:82::206:81 > 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 2, length 16 11:54:13.949889 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:14.846703 IP6 2001:81:82::206:113 > 2001:81:82::1: ICMP6, neighbor solicitation, who has 2001:81:82::1, length 32 11:54:14.847034 IP6 2001:81:82::1 > 2001:81:82::206:113: ICMP6, neighbor advertisement, tgt is 2001:81:82::1, length 24 11:54:14.948194 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:15.948203 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:16.954932 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:17.952257 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 11:54:18.952558 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6, neighbor solicitation, who has 2001:81:82::206:85, length 32 I am running: $ uname -a FreeBSD balancer3.domain.local 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue Jun 16 12:08:00 CEST 2009 r...@balancer3.domain.local:/usr/obj/usr/src/sys/GENERIC-CARP amd64 IP's below are scrambled and are not the real addresses: -- /etc/rc.conf - ifconfig_bge0_name="nic0" ifconfig_bge1_name="nic1" ipv6_enable="YES" ifconfig_nic0="inet 81.82.206.113 netmask 255.255.255.192" ifconfig_nic0_alias0="inet6 2001:81:82::206:113 prefixlen 48" ifconfig_nic1="inet 10.82.20.113 netmask 255.255.255.0" defaultrouter="81.82.206.65" ipv6_defaultrouter="2001:81:82::1" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 103 pass blabla 81.82.206.81/26 advskew 0" ifconfig_carp0_alias0="inet6 2001:81:82::206:81 prefixlen 48" ifconfig_carp0_alias1="inet 81.82.206.85 netmask 255.255.255.192" ifconfig_carp0_alias2="inet6 2001:81:82::206:85 prefixlen 48" ifconfig_carp0_alias3="inet 81.82.206.121 netmask 255.255.255.192" ifconfig_carp0_alias4="inet6
Re: em driver doesn't set multicast ethernet address
Hi, Thanks for the feedback. ipre...@freebsd.org wrote: Well, now, something really interesting happened. I changed default IGMP version via sysctl # sysctl net.inet.igmp.default_version=2 but, then I tested it with mtest and generated packets were still IGMPv3 Membership reports, but first two of them had proper mcast ethernet address. They generated sent by mtest. Sorry, forgot to mention -- this sysctl won't take effect immediately. It needs to be set before the interface's driver is loaded and IPv4 is attached to the interface. Do you have any unusual ARP table entries or routing setup? That would be where to look next. There haven't been any other reports of this issue as far as I know. The IGMP code does not fill out the Ethernet address field -- it leaves it up to ip_output() to do that. Do you see this with other multicast traffic, or just IGMP reports? thanks, BMS ___ 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: em driver doesn't set multicast ethernet address
On Sat, Jul 11, 2009 at 01:57:49PM +0100, Bruce Simpson wrote: > Hi, > > Thanks for the feedback. > > ipre...@freebsd.org wrote: >> Well, now, something really interesting happened. I changed default IGMP >> version via sysctl >> >> # sysctl net.inet.igmp.default_version=2 >> >> but, then I tested it with mtest and generated packets were still IGMPv3 >> Membership reports, but first two of them had proper mcast ethernet >> address. They generated sent by mtest. >> > > Sorry, forgot to mention -- this sysctl won't take effect immediately. > It needs to be set before the interface's driver is loaded and IPv4 is > attached to the interface. > I placed config in sysctl.conf and rebooted but mcastread still generates IGMPv3 membership report. Am I missing something? > Do you have any unusual ARP table entries or routing setup? That would be > where to look next. > Nope. > There haven't been any other reports of this issue as far as I know. The > IGMP code does not fill out the Ethernet address field -- it leaves it up > to ip_output() to do that. > > Do you see this with other multicast traffic, or just IGMP reports? > I generated multicast traffic with nc and examined packets still have wrong ether dest address. So, it seems that no IGMP code is wrong. Can someone please try to reproduce this with different hardware? I have no other configuration but this in VMWare environment. > thanks, > BMS > ___ 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: em driver doesn't set multicast ethernet address
ipre...@freebsd.org wrote: I placed config in sysctl.conf and rebooted but mcastread still generates IGMPv3 membership report. Am I missing something? Only other thing I can think of right now: Are any multicast queriers/routers present on the virtual subnet? I'm tied up, so probably can't look at the sysctl in detail, until in the week. cheers, BMS ___ 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: em driver doesn't set multicast ethernet address
On Sat, Jul 11, 2009 at 02:55:40PM +0100, Bruce Simpson wrote:
> ipre...@freebsd.org wrote:
>> I placed config in sysctl.conf and rebooted but mcastread still generates
>> IGMPv3
>> membership report. Am I missing something?
>>
>
> Only other thing I can think of right now:
> Are any multicast queriers/routers present on the virtual subnet?
>
> I'm tied up, so probably can't look at the sysctl in detail, until in the
> week.
>
There is no such. I'm implementing IGMP snooping extensions in ng_bridge
and luckily, they are based on IPv4 addresses, so I can probably
temporarly disable preliminary {multi/other}cast discrimination based on
ethernet address and stick to IPv4 until bug is fixed. In a meantime,
I'll try to figure out some different hardware configuration to make
sure this is not "feature" of VMWare, even everything worked fine until
now.
> cheers,
> BMS
___
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: Re: kern/135222: [igb] low speed routing between two igb interfaces
>>Intel 82575EB (and friends) are *the* premier ethernet controllers to >>use with FreeBSD in a server. igb should be the most stable and >>supported driver in the whole kernel. I can't think of any other driver >>and series of controllers I would rather use in a server like this. Well, the good NIC is no good at all without good driver, sadly, it's the case with stock igb driver shipped with FB. I hate to say this, but igb driver sucks, there're many obvious issue in the code like wrong DMA allocation etc. You just have to re-write completely to get igb work, i.e., to support msi-x with multiqueue. >>If the drivers for these chips are now "bad", this is a very sad day for >>people who wanted to use FreeBSD in their dual socket servers. Either stick to em or re-write the igb driver. It's just funny that everybody keeps quite on this, is it too difficulty to let people know it's the known issue with igb driver? Ricky ___ freebsd-...@free... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@free..." -- This message was sent on behalf of ricky.packetlo...@gmail.com at openSubscriber.com http://www.opensubscriber.com/message/freebsd-net@freebsd.org/12445915.html ___ 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: Re: kern/135222: [igb] low speed routing between two igb interfaces
--- On Sat, 7/11/09, ricky.packetlo...@gmail.com wrote: > From: ricky.packetlo...@gmail.com > Subject: Re: Re: kern/135222: [igb] low speed routing between two igb > interfaces > To: freebsd-net@freebsd.org > Date: Saturday, July 11, 2009, 10:46 AM > >>Intel 82575EB (and > friends) are *the* premier ethernet controllers to > >>use with FreeBSD in a server. igb should be > the most stable and > >>supported driver in the whole kernel. I can't > think of any other driver > >>and series of controllers I would rather use in a > server like this. > > Well, the good NIC is no good at all without good driver, > sadly, it's the case with stock igb driver shipped with FB. > > I hate to say this, but igb driver sucks, there're many > obvious issue in the code like wrong DMA allocation etc. You > just have to re-write completely to get igb work, i.e., to > support msi-x with multiqueue. > > >>If the drivers for these chips are now "bad", this > is a very sad day for > >>people who wanted to use FreeBSD in their dual > socket servers. > Either stick to em or re-write the igb driver. > > It's just funny that everybody keeps quite on this, is it > too difficulty to let people know it's the known issue with > igb driver? > > Ricky I thought packetlogic ran on Linux, have you finally abandoned that pig? Barney ___ 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: NTP - default /etc/ntp.conf
On Fri, 10 Jul 2009 at 01:53 -, David Malone wrote: > > Is 3.freebsd.pool.ntp.org intentionally commented? It does > > resolve. Reminder: if you do uncomment it, remember to change the > > "three servers" to four. > > I've no problem commenting in all 4 if people think that's a better > config. 4 ntp servers are usually recommended. If one is down and one is wacky the remaining two can out vote the wacky one. Kinda like using raid-5 with a hot spare. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone ___ 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"
