Re: Bridge rules

2012-06-30 Thread Henning Brauer
* sven falempin sven.falem...@gmail.com [2012-06-30 02:06]: - ea = ether_aton(argv[0]); + m_size = strnlen(argv[0], ETHER_ADDR_LEN+1 ); + if ( m_size ETHER_ADDR_LEN || m_size 3 ) { + warnx(mac

Re: Bridge rules

2012-06-30 Thread Stuart Henderson
On 2012/06/29 20:05, sven falempin wrote: ifconfig bridge0 rule pass in on fxp0 src de:ff:* wouldn't it be simpler to just allow a mask value to be set, then you don't need to mess with extra flag variables, just mask the MAC address with this value before comparison. ifconfig bridge0 rule

Re: Bridge rules

2012-06-30 Thread sven falempin
Stuart, The flag is there to not change old behavior. Of course matching the beggining of mac make sense the rest is just strange behavior. But a mac address could be spoof, so it may be used. Its just a - and an if else. thx. I do not understand the other complain. especilly when it s

Re: Bridge rules

2012-06-30 Thread Henning Brauer
* sven falempin sven.falem...@gmail.com [2012-06-30 15:49]: I do not understand the other complain. especilly when it s userland code (the string stuff was done inside ifconfig) using string matching for this is the wrong approach to begin with. mac addresses are just numbers, after all. so a

Re: Bridge rules

2012-06-30 Thread Stuart Henderson
On 2012/06/30 09:47, sven falempin wrote: Stuart, The flag is there to not change old behavior. Since masking with all 0's is pointless, you can use that to identify the standard behaviour, checking against 0 is a fast way to determine if the mask should be applied at all (this means a mask

Re: Bridge rules

2012-06-30 Thread sven falempin
should be more likely an expected diff 2012/6/30 Stuart Henderson s...@spacehopper.org On 2012/06/30 09:47, sven falempin wrote: Stuart, The flag is there to not change old behavior. Since masking with all 0's is pointless, you can use that to identify the standard behaviour, checking

Re: Bridge rules

2012-06-30 Thread sven falempin
beyond the missing in bzero in brconfig.c i certainly broke something bridge0: flags=0 groups: bridge priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp vether0 flags=3LEARNING,DISCOVER port 6 ifpriority 0 ifcost 0 re0

bug fix: 'opencvs log' mangles RCS branch number

2012-06-30 Thread Michael W. Bombardieri
Hi tech, I noticed this OpenCVS bug a couple of months ago but I've only just written this report. Comparing cvs log output between GNU CVS 1.11.1p1 and OpenCVS... $ diff -U 6 log_c.h_cvs log_c.h_ocvs --- log_c.h_cvs Sun Jul 1 07:08:57 2012 +++ log_c.h_ocvsSun Jul 1 07:09:10 2012 @@

Re: bug fix: 'opencvs log' mangles RCS branch number

2012-06-30 Thread Ted Unangst
On Sun, Jul 01, 2012 at 08:28, Michael W. Bombardieri wrote: Hi tech, I noticed this OpenCVS bug a couple of months ago but I've only just written this report. Comparing cvs log output between GNU CVS 1.11.1p1 and OpenCVS... - mwb: 1.1.1 + mwb: 1.1.0.1 OpenCVS mangles the