Re: DMI deactivated - why?
> On 30 Apr 2001 08:08:45 +0200, Michael Reinelt wrote: > > > > Can someone explain why this has been deactivated? I would find these > > values quite useful! Shouldn't that be "un"activated? (Sorry...couldn't resist). Jack - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DMI deactivated - why?
On 30 Apr 2001 08:08:45 +0200, Michael Reinelt wrote: snip Can someone explain why this has been deactivated? I would find these values quite useful! Shouldn't that be unactivated? (Sorry...couldn't resist). Jack - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
too long mac address for --mac-source netfilter option
I am trying to use the --mac-source option in the netfilter code to better refine access to my linux box. However, I have run up against something. The router through which my private subnet work box passes sends a 14-group "invalid" mac address, presumably as an attempt to conceal the real hextile mac address. However, the code for the --mac-source netfilter option is looking for a valid hextile mac address and complains loudly as such (numerals converted to x's): iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx' to the respective iptable line: $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT The idea here is to allow VNC access to my home box with the access filtered by both IP and mac address. Is there a resolution to this other than a rewrite and recompile of the relevant sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as experimental still so I would assume that the code is open for feedback ;) The question could be rephrased as: is there any chance of allowing "invalid" mac addresses to be recognized by the --mac-source option of the netfilter code? Running Redhat v7/kernel 2.4.1-ac15. Jack Bowling mailto: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
too long mac address for --mac-source netfilter option
I am trying to use the --mac-source option in the netfilter code to better refine access to my linux box. However, I have run up against something. The router through which my private subnet work box passes sends a 14-group "invalid" mac address, presumably as an attempt to conceal the real hextile mac address. However, the code for the --mac-source netfilter option is looking for a valid hextile mac address and complains loudly as such (numerals converted to x's): iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx' to the respective iptable line: $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT The idea here is to allow VNC access to my home box with the access filtered by both IP and mac address. Is there a resolution to this other than a rewrite and recompile of the relevant sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as experimental still so I would assume that the code is open for feedback ;) The question could be rephrased as: is there any chance of allowing "invalid" mac addresses to be recognized by the --mac-source option of the netfilter code? Running Redhat v7/kernel 2.4.1-ac15. Jack Bowling mailto: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/