Patrick McHardy wrote: > Pablo Neira Ayuso wrote: >> Patrick McHardy wrote: >>> Jiri Pirko wrote: >>>> Hi all. >>>> >>>> I want to ask if there is any particular reason for ipt_CLUSTERIP to support >>>> only address length of 6 (ETH_ALEN)? It seems to me reasonable for this to work >>>> even with another types of network hw with different addr_len. >>> None that I'm aware of, but the length is also used in the ABI, >>> so you presently can't supply larger addresses. >> Not directly related to this but I wanted to discuss this time ago. Now >> that we have xt_CLUSTER I think that we can deprecate ipt_CLUSTERIP. > > If xt_cluster supports everything ipt_CLUSTERIP does, thats fine > with me. Yes, xt_cluster supports gateway and back-end clustering while ipt_CLUSTERIP only works for back-end setup. I wanted to have some time to document xt_cluster, I have some scripts lying here and some unfinished documents. I think that we can deprecated as soon as I have that doc ready. >> With regards to this issue, it seems arptables only support EUI-48 (6 >> bytes) for ethernet addresses, so xt_CLUSTER would inherit the same >> problem but the point would be to fix arptables (not sure if possible >> now without breaking ABI or adding some versioning like iptables). > > arptables currently supports up to 16 byte long addresses. Increasing > this is difficult since the addresses are embedded in struct arpt_arp. Hm, so the problem seems to be user-space then: # arptables -I OUTPUT -o eth1 --h-length 8 \ > -j mangle --mangle-mac-s 01:00:5e:00:01:01:00:00 arptables v0.0.3.3: only --h-length 6 supported Try `arptables -h' or 'arptables --help' for more information. As soon as this is fixed. Are 16 bytes long addresses long enough by now? -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
