Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[0\/3\]\s+mc

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[0\/3\]\s+mc_filter\s+on\s+big\-endian\s+arch\s*$/: 24 ]

Total 24 documents matching your query.

1. [0/3] mc_filter on big-endian arch (score: 1): Author: x@xxxxxxxxxxxx>; Date: Sun, 6 Jun 2004 18:53:22 +0200; A.J. from VIA Networking Technologies noticed that via-rhine is using cpu_to_le32() when preparing mc_filter hashes. I confirmed that this breaks Rhine hardware multicast filters on big-endian archit; /archives/netdev/2004-06/msg00136.html (8,760 bytes)
2. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: x@xxxxxxxxxxxx>; Date: 06 Jun 2004 22:29:52 -0400; I think typhoon's OK -- I calculate the filter on the host, and then do a cpu_to_le32() on the final values, since the processor on the NIC is in little-endian mode. However, I've never tested it. I'; /archives/netdev/2004-06/msg00139.html (9,251 bytes)
3. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: kondra@xxxxxxx>; Date: 07 Jun 2004 09:52:26 -0400; Thanks for the info; it seems typhoon may have some problems -- I see the 224.1.1.1 packets before I join the group, so I'll need to see what's up. I'll check big endian tonight, if possible. Dave; /archives/netdev/2004-06/msg00149.html (9,925 bytes)
4. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: joe.andonieh@xxxxxxxxx>; Date: Mon, 7 Jun 2004 13:48:32 +0200; Warning: This is a very basic functionality test using standard Linux tools. Some existing multicast problems are detected by this (if you screw up the endianness of the filter hash, you will know :-; /archives/netdev/2004-06/msg00232.html (10,554 bytes)
5. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: t@xxxxxxxxxxxxxxxxx>; Date: Mon, 7 Jun 2004 13:59:21 +0200; One thing maybe worth mentioning: If you want to play with different addresses, remember that IP addresses are in decimal notation, ethernet in hex. So if you set target# ip maddr add 01:00:5e:00:00:; /archives/netdev/2004-06/msg00268.html (9,016 bytes)
6. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: rms@xxxxxxxxxxxx>; Date: Wed, 9 Jun 2004 23:09:53 -0600; netdev-bounce@xxxxxxxxxxx wrote on 06/07/2004 04:59:21 AM: This will add "01:00:5e:00:00:25" to the device multicast address filter, which will mean the host will receive the packet. But because it d; /archives/netdev/2004-06/msg00269.html (9,339 bytes)
7. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: evens@xxxxxxxxxx>; Date: Wed, 9 Jun 2004 22:45:26 -0700; PS - Here's a trivial program that will join a group. If you run this on one side, then a ping to the multicast address will work when it's in the group, and stop answering when it exits. There are m; /archives/netdev/2004-06/msg00271.html (10,331 bytes)
8. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: <evil@xxxxxxxxxx>; Date: Thu, 10 Jun 2004 09:37:59 -0400; Thank you guys for all the info. I've done some testing, and sure enough, there are some problems in typhoon, which I'll fix this weekend. But I think the cpu_to_le32() calls are correct -- it would; /archives/netdev/2004-06/msg00276.html (9,914 bytes)
9. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: git Schubert-While); Date: Thu, 10 Jun 2004 15:47:19 -0700; Roger suggested that I bring to "netdev" the comment I made to him in private e-mail about his FAQ, so here it is: if you add multicast addresses via "ip maddr" in the way described, it won't work fo; /archives/netdev/2004-06/msg00290.html (9,066 bytes)
10. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: s Vlasenko <vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>; Date: 12 Jun 2004 23:01:56 -0400; Thank you for sending this program; it saved me having to write my own, and it helped me to demonstrate that multicast already works properly under typhoon. As it turns out, my copy of tcpdump was tu; /archives/netdev/2004-06/msg00328.html (9,768 bytes)
11. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: xxxxxxxxxxx>; Date: Thu, 10 Jun 2004 12:20:45 +0200; Correct. The method I described does the trick using standard tools (iproute2, packet sniffer), though. Sure, why not? Fixed up and added to the How-To below. Roger Multicast Driver Testing Quick How; /archives/netdev/2004-06/msg00329.html (14,052 bytes)
12. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: garzik@xxxxxxxxx>; Date: Sat, 19 Jun 2004 17:37:37 -0400; you would be kind enough to resend the non-via-rhine patches WRT mc_filter?; /archives/netdev/2004-06/msg00591.html (8,519 bytes)
13. [0/3] mc_filter on big-endian arch (score: 1): Author: Roger Luethi <rl@xxxxxxxxxxx>; Date: Sun, 6 Jun 2004 18:53:22 +0200; A.J. from VIA Networking Technologies noticed that via-rhine is using cpu_to_le32() when preparing mc_filter hashes. I confirmed that this breaks Rhine hardware multicast filters on big-endian archit; /archives/netdev/2004-06/msg01020.html (8,760 bytes)
14. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: David Dillow <dave@xxxxxxxxxxxxxx>; Date: 06 Jun 2004 22:29:52 -0400; I think typhoon's OK -- I calculate the filter on the host, and then do a cpu_to_le32() on the final values, since the processor on the NIC is in little-endian mode. However, I've never tested it. I'; /archives/netdev/2004-06/msg01023.html (9,311 bytes)
15. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: David Dillow <dave@xxxxxxxxxxxxxx>; Date: 07 Jun 2004 09:52:26 -0400; Thanks for the info; it seems typhoon may have some problems -- I see the 224.1.1.1 packets before I join the group, so I'll need to see what's up. I'll check big endian tonight, if possible. Dave; /archives/netdev/2004-06/msg01033.html (10,046 bytes)
16. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: Roger Luethi <rl@xxxxxxxxxxx>; Date: Mon, 7 Jun 2004 13:48:32 +0200; Warning: This is a very basic functionality test using standard Linux tools. Some existing multicast problems are detected by this (if you screw up the endianness of the filter hash, you will know :-; /archives/netdev/2004-06/msg01116.html (10,646 bytes)
17. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: Roger Luethi <rl@xxxxxxxxxxx>; Date: Mon, 7 Jun 2004 13:59:21 +0200; One thing maybe worth mentioning: If you want to play with different addresses, remember that IP addresses are in decimal notation, ethernet in hex. So if you set target# ip maddr add 01:00:5e:00:00:; /archives/netdev/2004-06/msg01152.html (9,137 bytes)
18. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: David Stevens <dlstevens@xxxxxxxxxx>; Date: Wed, 9 Jun 2004 23:09:53 -0600; netdev-bounce@xxxxxxxxxxx wrote on 06/07/2004 04:59:21 AM: This will add "01:00:5e:00:00:25" to the device multicast address filter, which will mean the host will receive the packet. But because it d; /archives/netdev/2004-06/msg01153.html (9,369 bytes)
19. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: David Stevens <dlstevens@xxxxxxxxxx>; Date: Wed, 9 Jun 2004 22:45:26 -0700; PS - Here's a trivial program that will join a group. If you run this on one side, then a ping to the multicast address will work when it's in the group, and stop answering when it exits. There are m; /archives/netdev/2004-06/msg01155.html (10,396 bytes)
20. Re: [0/3] mc_filter on big-endian arch (score: 1): Author: Dave Dillow <dave@xxxxxxxxxxxxxx>; Date: Thu, 10 Jun 2004 09:37:59 -0400; Thank you guys for all the info. I've done some testing, and sure enough, there are some problems in typhoon, which I'll fix this weekend. But I think the cpu_to_le32() calls are correct -- it would; /archives/netdev/2004-06/msg01160.html (10,069 bytes)

Current List: 1 - 20
Page: [1] [2]