Weird Enterprise T5220 issue

Question

I'm getting strange results when using the last Gigabit ethernet port (port #3) on my brand new Enterprise 5220. Here is the output from ifconfig -a:
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000802<BROADCAST,MULTICAST,IPv4> mtu 1500 index 9
inet 0.0.0.0 netmask 0
ether 0:14:4f:ec:bc:1c
e1000g1: flags=1000843<BROADCAST,MULTICAST,IPv4> mtu 1500 index 8
inet 0.0.0.0 netmask 0
ether 0:14:4f:ec:bc:1d
e1000g2: flags=1000802<BROADCAST,MULTICAST,IPv4> mtu 1500 index 10
inet 0.0.0.0 netmask 0
ether 0:14:4f:ec:bc:1e
e1000g3: flags=1000802<BROADCAST,MULTICAST,IPv4> mtu 1500 index 11
inet 0.0.0.0 netmask 0
ether 0:0:6:0:5a:a5
I find it very odd that the MAC address is 0:0:6:0:5a:a5 and not 0:14:4f:ec:bc:1f. I seem to recall earlier that it was reporting a MAC of 0:0:0:0:0:0. Running speed tests through it also gives lower than expected results. The switch and system both show that it's connected 1000 Mbps/full duplex but I only get around 400 Mbps, while I get 600-700 Mbps through the other Ethernet ports.
Wondering if I have a faulty ethernet port.. Has anybody else seen similar behavior?
Thanks!
Jim
Edited by: JimBuitt on Aug 6, 2008 1:13 PM

Answer 1

I may have to test this on my machine but it may be that the filename that got pass the filter was in uppercase maybe and that's how it sneaked through. Your filter looks for only lowercase filenames that end with ".wmv".
The only thing that is case-insensitive by default is the "mail-from" and "rcpt-to". Almost everything else (subject, message-body, other-headers, filenames) are case sensitive. To make these things case insensitive, you'll want to prepend your filter with this:
Attachment-filename == "(?i)\\.wmv"
or
Attachment-filename == "(?i)\\.(exe|bat|com|sh)"
(?i) --> means ignore the case on whatever follows this regex. You pretty much want to use this in most cases to be safe since match whether it's upper or lowercase. Performance-wise, it should be okay.
By the way, Ironport filters use Python regex.
Again, I'll have to test this on my side.
I have had a weird issue come up with our content filtering today, and am wondering if anyone else has come accross it.
We have a number of Content Filters setup. One of these it looking for various media files including .wmv files (We have used a "Attachment-filename == "\\.wmv"" to look for them).
This works as required. However this morning out outbound Media File content filter trapped a message containing a wmv file going out that had been received by the user the night before.
this message last night was processed by the IronPort, the wmv was not hidden or re-named in any way. It was just not stopped by the content filter.
I have checked everything I can think of and I can see no reason why the message wasn't stopped. WMV's are being stopped OK as I type this.
Has anyone else come accross or noticed this.
This is on a C650 Appliance running 5.5.1