Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*SIOCADDMULTI\s+for\s+unicast\s+broken\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*SIOCADDMULTI\s+for\s+unicast\s+broken\s*$/: 42 ]

Total 42 documents matching your query.

1. SIOCADDMULTI for unicast broken (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Fri, 3 Jan 2003 16:46:40 -0500 (EST); Some programs require ability to accept packets destined to certain MAC addresses (in addition to their own). Example Jerome Ettienes vrrpd (http://w3.arobas.net/~jetienne/vrrpd/) The trick is to add; /archives/netdev/2003-01/msg00010.html (8,387 bytes)
2. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Donald Becker <becker@xxxxxxxxx>; Date: Fri, 3 Jan 2003 19:07:11 -0500 (EST); This is a very specialized requirement, so specialized that it should not be added as general-purpose requirement for drivers or the network stack. This capability was supported as a special case for; /archives/netdev/2003-01/msg00011.html (9,584 bytes)
3. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Fri, 03 Jan 2003 20:18:00 -0500; jamal wrote: Some programs require ability to accept packets destined to certain MAC addresses (in addition to their own). Example Jerome Ettienes vrrpd (http://w3.arobas.net/~jetienne/vrrpd/) The tr; /archives/netdev/2003-01/msg00012.html (9,285 bytes)
4. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Donald Becker <becker@xxxxxxxxx>; Date: Fri, 3 Jan 2003 20:39:50 -0500 (EST); Yes, it is totally a hack, not an interface. It was "If you need this capability for a RESEARCH PROJECT, you can buy this specific board and thus not need to modify the kernel or device driver. " You; /archives/netdev/2003-01/msg00013.html (9,923 bytes)
5. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Fri, 03 Jan 2003 17:45:31 -0800; Donald Becker wrote: It was "If you need this capability for a RESEARCH PROJECT, you can buy this specific board and thus not need to modify the kernel or device driver. " You can also find a few peo; /archives/netdev/2003-01/msg00014.html (10,738 bytes)
6. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Donald Becker <becker@xxxxxxxxx>; Date: Fri, 3 Jan 2003 21:18:24 -0500 (EST); The problems are - The extensions people (very few people) want are completely unpredictable. - Unique features are, well, unique You might think it's Really Very Important to change the LED meanings; /archives/netdev/2003-01/msg00015.html (10,721 bytes)
7. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Fri, 03 Jan 2003 20:52:13 -0500; Ben Greear wrote: Donald Becker wrote: It was "If you need this capability for a RESEARCH PROJECT, you can buy this specific board and thus not need to modify the kernel or device driver. " You can a; /archives/netdev/2003-01/msg00016.html (10,720 bytes)
8. Re: SIOCADDMULTI for unicast broken (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Fri, 3 Jan 2003 23:11:45 -0500 (EST); Too many emails to respond to at once. Q: Is this a hack? A: Yes, indeed it is. wrong API is the main culprit. Q: Is this a feature needed by only a few people? A: No, Absolutely not. RFC2338 is one; /archives/netdev/2003-01/msg00017.html (10,461 bytes)
9. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Donald Becker <becker@xxxxxxxxx>; Date: Sat, 4 Jan 2003 01:33:11 -0500 (EST); The common way of handling this is unsolicited ARP. Not very common. I mentioned the 21*4* explicitly because few other common chips implement this feature. The Digital design implemented it because; /archives/netdev/2003-01/msg00018.html (10,929 bytes)
10. Re: SIOCADDMULTI for unicast broken (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Sat, 04 Jan 2003 02:32:54 -0500; I wonder if there are any good uses for more advanced RX filtering that is beginning to appear. I could certainly imagine an interface that was a more generic RX filtering interface, and [just by acc; /archives/netdev/2003-01/msg00020.html (9,597 bytes)
11. Re: SIOCADDMULTI for unicast broken (score: 1): Author: xxxxxx>; Date: Sat, 4 Jan 2003 12:41:23 -0500 (EST); unsolicited ARPs on failover are good. You send the arp with one of the allocated MAC addresses as the source. The hosts sending data use that MAC address as the dst MAC. Did i miss something or how; /archives/netdev/2003-01/msg00024.html (12,335 bytes)
12. Re: SIOCADDMULTI for unicast broken (score: 1): Author: xxxxxx>; Date: Sat, 4 Jan 2003 12:43:49 -0500 (EST); Davem had some nifty ideas on this at least for TOE. I think we ought to start looking at that direction. Anyone who is working on this please involve me, i have some ideas (and it would avoid me str; /archives/netdev/2003-01/msg00025.html (9,934 bytes)
13. Re: SIOCADDMULTI for unicast broken (score: 1): Author: xxxxxxxxxxxxxx>; Date: Sat, 4 Jan 2003 13:24:26 -0500 (EST); I disagree: it's a hack usable by the very few people that need it. Defining an API would add little-used complexity. This is good example of why an API is a bad idea: there is no general case. The T; /archives/netdev/2003-01/msg00027.html (11,582 bytes)
14. Re: SIOCADDMULTI for unicast broken (score: 1): Author: cker@xxxxxxxxx>; Date: Sat, 4 Jan 2003 20:36:38 +0200 (EET); You can do it with arptables (still not sure how) or with arprules+iparp: ip arp add table output from 1.2.3.4 llsrc 00:00:5E:00:01:10 http://www.ssi.bg/~ja/#iparp But this is not enough for VRRP. F; /archives/netdev/2003-01/msg00028.html (10,631 bytes)
15. Re: SIOCADDMULTI for unicast broken (score: 1): Author: sov <ja@xxxxxx>; Date: Sat, 4 Jan 2003 13:55:32 -0500 (EST); Somehow i (and people using VRRP or trying to write HSRP like apps) need to have multiple MAC addresses accepted by a single NIC. It is not really a science project reqnmt, rather needed by real-worl; /archives/netdev/2003-01/msg00029.html (12,372 bytes)
16. Re: SIOCADDMULTI for unicast broken (score: 1): Author: adi@xxxxxxxxxx>; Date: Sat, 4 Jan 2003 14:04:17 -0500 (EST); I havent seen user-space arptables around. I like this concept. This + the patch i posted should resolve the problem of getting multiple VRIDs on a single interface. [Although you could do it in a lo; /archives/netdev/2003-01/msg00030.html (11,104 bytes)
17. Re: SIOCADDMULTI for unicast broken (score: 1): Author: niv@xxxxxxxxxx>; Date: Sun, 5 Jan 2003 13:45:45 +0200 (EET); yes, that is what I mean I hope there will be support for altering any bit in the skb->head - skb->end area, even by using negative offsets based on skb->nh.raw - this is needed for eth header manip; /archives/netdev/2003-01/msg00032.html (11,693 bytes)
18. Re: SIOCADDMULTI for unicast broken (score: 1): Author: xxxxxxxxxxxxxx>; Date: Mon, 6 Jan 2003 08:44:30 -0500 (EST); I wanted to use u32 as the basis; which means u32 type matching is needed. then use vi/sed type substitution s/OL/V where: O = offset (from skb->data, could be -ve), L = length (cant go beyond head o; /archives/netdev/2003-01/msg00036.html (13,585 bytes)
19. Re: SIOCADDMULTI for unicast broken (score: 1): Author: adi@xxxxxxxxxx>; Date: Mon, 6 Jan 2003 17:00:30 +0200 (EET); IMO, using skb->nh.raw as basis is preferred. By this way the filters can be used from different places in the net stack. Yes, changing skb len is problematic mostly for TCP. As for L and V: I assum; /archives/netdev/2003-01/msg00037.html (12,235 bytes)
20. Re: SIOCADDMULTI for unicast broken (score: 1): Author: sov <ja@xxxxxx>; Date: 06 Jan 2003 16:00:33 +0100; Still, SIOCDEVPRIVATE should _not_, in my opinion, be used for anything but hacks. For example, we should stop using it for configuring ethernet bridges: net/bridge/br_device.c: if (cmd != SIOCDEVPRI; /archives/netdev/2003-01/msg00038.html (8,657 bytes)

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