[Bug 33008] New: UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

Bug #: 33008
           Summary: UDP listening on specific IP address does not work
                    properly
           Product: Wine
           Version: 1.5.24
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

Wine updated from 1.5.6 to 1.5.24.
My app uses UDP listening on specific address (not 0.0.0.0). It is running on
machine with NAT, there are two interfaces with IP A.A.A.A (public) and IP
B.B.B.B (private) My app is set to listen only on one IP address, IP A.A.A.A
It works properly on Wine 1.5.6. Traffic from subnet B.B.B.B is NATed to
A.A.A.A interface and application running in wine receives it correctly.

After update to 1.5.24 it does not work anymore. 
Application does not receive data from private subnet B.B.B.B, however it works
properly for traffic incoming on A.A.A.A interface.

Please see attached schema.

results of "netstat --listening"
with Wine 1.5.6 it is listening on A.A.A.A address correctly.
with Wine 1.5.24 it is listening on 0.0.0.0 (obviously incorrect, socket
binding is set to A.A.A.A address in application and although it is saying
0.0.0.0 app does not receive any data from B.B.B.B network)

This application has to be listening only on one interface and do not mix
public and private addresses. In this case it is not accessible for clients in
private network, so it is critical bug.

Main strange thing is, that it is listening on all addresses 0.0.0.0 although
socket binding in application is set to address A.A.A.A

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #1 from [e-mail] 2013-02-18 13:53:58 CST ---
Created attachment 43617
  --> http://bugs.winehq.org/attachment.cgi?id=43617
Traffic schema

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal

--- Comment #2 from Bruno Jesus  2013-02-18 15:19:50 CST ---
Not critical, read http://bugs.winehq.org/page.cgi?id=fields.html#importance

Please attach the console log:
http://wiki.winehq.org/FAQ#get_log

AFAIK specific IP binding was not present in 1.5.6, it was introduced in
1.5.15.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #3 from [e-mail] 2013-02-19 13:07:30 CST ---
Sorry for bad "Importance" value, I thought that this bug is critical, because
all applications using specific IP (interface) binding will not work. In my
case I had to downgrade to Wine 1.5.6 (version available from openSuse 12.2
repository)

You said that Wine 1.5.6 does not have implementation for specific IP binding,
but it works correctly there. 
It does not work in Wine 1.5.24

There is nothing in console, no error (fixme etc) message.

As I have mentioned above, I can just check it via "netstat --listening":

Tested again on another system (openSuse), there is NAT (masquerade) from B to
A, simple test application created.
Interface A, IP 10.0.0.1
Interface B, IP 192.168.0.1
TestApp: Binding (UDP) is set to 10.0.0.1:999

netstat shows:
Wine 1.5.6: 10.0.0.1:999
Wine 1.5.24: 0.0.0.0:999

It could look that it is not problem, but it is critical issue on systems with
NAT.
Wine 1.5.24 problem:
although it is saying 0.0.0.0, app does not receive any data from 192.168.0.1
interface (somehow internally blocked in Wine?). From app point of view it
looks ok, data are received only from 10.0.0.x, but system can see that it is
listening on all addresses (0.0.0.0) and traffic from 192.168.0.x with target
10.0.0.1 is not NATed, but directly sent to 0.0.0.0:999 - however data from
192.168.0.x are blocked.
So clients in 192.168.0.x network are not able to connect to app.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #4 from Bruno Jesus  2013-02-19 13:14:17 CST ---
Please attach a +winsock log if possible for both cases (1.5.6 and 1.5.24).

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #5 from [e-mail] 2013-02-19 14:38:10 CST ---
Created attachment 43642
  --> http://bugs.winehq.org/attachment.cgi?id=43642
WinSock log for Wine 1.5.6

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #6 from [e-mail] 2013-02-19 14:38:50 CST ---
Created attachment 43643
  --> http://bugs.winehq.org/attachment.cgi?id=43643
WinSock log for Wine 1.5.24

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

Bruno Jesus  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #7 from Erich Hoover  2013-02-19 14:54:49 CST ---
This sounds like Wine is now properly implementing the behavior that the
application should have under Windows in a similar circumstance.  So, I would
guess that how you're routing the traffic is responsible for Wine dropping the
packet.

However, it is possible that something needs to be done in the packet filter to
address your rather peculiar use case.  What I read of how you're trying to
setup things is that you want it to work like so:
B.B.B.x -> A.A.A.Address -> Wine
If your NAT rule is not changing the source information (I believe that's the
"MASQUERADE" option) then the packet is being dropped because Wine is detecting
that the packet is coming in on the wrong interface.  That is how an
interface-specific bind on Windows is supposed to work.  How Wine used to
behave is to make a Unix-like interface-specific bind (which works differently
than on Windows), which would allow that packet from the wrong interface.  To
operate in a Windows-like way Wine now binds to 0.0.0.0 and uses a Linux Socket
Filter to screen packets that come in to make sure they're on the correct
interface.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #8 from Erich Hoover  2013-02-19 15:24:24 CST ---
Sorry I forgot to say this in my earlier message, but if you send me your
iptables configuration then I can use that to help figure out the problem.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #9 from Bruno Jesus  2013-04-20 22:16:14 CDT ---
Invalid then? Since wine now implements the same behavior from windows.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #10 from Erich Hoover  2013-05-06 15:55:39 CDT ---
(In reply to comment #9)
> Invalid then? Since wine now implements the same behavior from windows.

Unless we can get some more information then I would say so, it would be nice
to go over his routing rules and make sure that we can get it to work though.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #11 from Erich Hoover  ---
Note: It's also possible that this bug was fixed by commit
74010aa0e774b8b4e32455e6a42306f714ee66dd.  If this is still an issue I would
like to know.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #12 from [e-mail] ---
Hello,
unfortunately bug is not fixed, even after a year. Tested on Wine 1.7.16
Problem is in the fact, that wine is listening on all interfaces (0.0.0.0) but
traffic is filtered.
Two interfaces: IF-A and IF-B, there is NAT (masquerading) running. IF-A is
LAN, IF-B is interface with public IP.

I have created testing application to reproduce and investigate the problem.
Application is listening on IF-B (public) only.
When UDP datagram is sent from LAN (private) to IF-B (public) address, it is
received on IF-A, NAT-ed to IF-B and received by application.
Application is receiving UDP datagrams properly.
Then the response is generated and sent back to client, but this response is
filtered out by wine. Nothing is sent back.
Application writes in log that UDP is received (from client's IP address) to
0.0.0.0 even it is listening only on specific IP (of IF-B). 
And this is the problem. Response is sent from binding 0.0.0.0 to target
address from LAN (IF-A), but "it is not configured" to listen on this IF-A).
(filtered!)

If I understand it correctly, wine is listening on 0.0.0.0 and filters UDP
datagrams according to bindings that are set by application. So if application
does not want to listen on some interface, this traffic is filtered, but in
this specific case (two interfaces, NAT) also the response is filtered out.
Destination address of response belongs to network of IF-A (where application
is not listening), but in this case response should be sent via IF-B,
translated back in NAT and flow via IF-A to LAN network. But such UDP datagram
is blocked by wine.

I am afraid it is bad solution. When you check this in Windows, it is correctly
listening on specific interface only, not on the all interfaces. Maybe there is
another behaviour that prevents some applications to work properly in
wine/linux (the reason why this filtering was added), but I am afraid this is
also not correct solution and now another applications are/could be
incompatible.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #13 from Erich Hoover  ---
(In reply to decimusmaximus from comment #12)
> ...
> If I understand it correctly, wine is listening on 0.0.0.0 and filters UDP
> datagrams according to bindings that are set by application. So if
> application does not want to listen on some interface, this traffic is
> filtered, but in this specific case (two interfaces, NAT) also the response
> is filtered out.
> Destination address of response belongs to network of IF-A (where
> application is not listening), but in this case response should be sent via
> IF-B, translated back in NAT and flow via IF-A to LAN network. But such UDP
> datagram is blocked by wine.
> ...

If you help me to do some testing I'd be happy to help fix this.  This means
that Wine is dropping the packet with the BPF that we're using to screen for
interface-specific packets.  Would it be possible for you to capture the packet
meant for Wine with Wireshark and send me the packet?  Also, what version of
Wine are you running?

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #14 from Erich Hoover  ---
(In reply to decimusmaximus from comment #12)
> ...
> Two interfaces: IF-A and IF-B, there is NAT (masquerading) running. IF-A is
> LAN, IF-B is interface with public IP.
> ...

I'd also like to reiterate that I need to know how you setup your masquerading
to help with this issue.  For the type of behavior it seems that you're
expecting you need to be using "Destination NAT" instead of "Source NAT".  For
details on the distinction between the two this article may be helpful:
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #15 from [e-mail] ---
(copied from https://github.com/mirrors/wine/issues/8 )

I just updated my Debian and compiled latest wine version.
What I can reproduce with Wine version 1.7.16-91-ged51082 :
1/ on Linux 3.13-1, an UDP server does not bind the IP address specified, but
binds 0.0.0.0.
2/ on the same machine, but if the IP address is a virtual one (eth0:1 for
example), Wine works properly and binds the IP address specified.
3/ there is no issue whatsoever with Linux kernel 2.6.32-5 for example.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #16 from Erich Hoover  ---
(In reply to facoptere from comment #15)
> (copied from https://github.com/mirrors/wine/issues/8 )
>
> I just updated my Debian and compiled latest wine version.
> What I can reproduce with Wine version 1.7.16-91-ged51082 :
> 1/ on Linux 3.13-1, an UDP server does not bind the IP address specified,
> but binds 0.0.0.0.
> 2/ on the same machine, but if the IP address is a virtual one (eth0:1 for
> example), Wine works properly and binds the IP address specified.
> 3/ there is no issue whatsoever with Linux kernel 2.6.32-5 for example.

Hi facoptere, this is intentional behavior to allow broadcast packets on
sockets that are "bound" to a specific interface (broadcast packets only work
when binding to 0.0.0.0).  The new code will set a kernel option (not available
on old kernels) that sets the packet to go out through the interface associated
with the specified address.  There's also a packet filter to only accept
packets that come in through (or are destined for) the provided address.  Could
you give more detail on the specific problem you are running into?

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #17 from Erich Hoover  ---
(In reply to facoptere from comment #15)
> ...
> 1/ on Linux 3.13-1, an UDP server does not bind the IP address specified,
> but binds 0.0.0.0.
> ...

This brings something to mind, is your application possibly trying to use
getsockname() on these sockets?  (I really need a lot more information to help
you, but this would be something to look for in the log)

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #18 from [e-mail] ---
Hello,

I did some further tests on another machine, I can reproduce the problem.

With 2.6 linux kernel:

~$ uname -a
Linux ... 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux
~$ wine --version
wine-1.7.17-175-gc1bf61e
~$ sudo ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:13:a9:8f:f0:e0  
          inet addr:10.0.0.11  Bcast:10.0.0.255  Mask:255.255.255.0
...

** I start the server with
WINEDEBUG=+winsock,+winediag,+iphlpapi,+wininet,+icmp,+rpc,+ole **
(I put all debug flags where a least a bind() is done in the respective code)

~$ sudo lsof -P -n -i udp|grep -P '(wine|arma)'
wineserve 5349   fab  304u  IPv4  14973      0t0  UDP 10.0.0.11:2304 
wineserve 5349   fab  310u  IPv4  15131      0t0  UDP 10.0.0.11:2302 
wineserve 5349   fab  319u  IPv4  15555      0t0  UDP *:44237 
arma2oase 5415   fab  231u  IPv4  14973      0t0  UDP 10.0.0.11:2304 
arma2oase 5415   fab  234u  IPv4  14973      0t0  UDP 10.0.0.11:2304 
arma2oase 5415   fab  238u  IPv4  15131      0t0  UDP 10.0.0.11:2302 
arma2oase 5415   fab  241u  IPv4  15131      0t0  UDP 10.0.0.11:2302 
arma2oase 5415   fab  249u  IPv4  15555      0t0  UDP *:44237

So the server bound 10.0.0.11:2302 (the main UDP port) properly.
Wine dump in winedebug-linux2.6.dmp.gz as attachment.

Now with 3.13 linux kernel:

~$ uname -a
Linux ... 3.13-1-686-pae #1 SMP Debian 3.13.7-1 (2014-03-25) i686 GNU/Linux
~$ wine --version
wine-1.7.17-175-gc1bf61e
~$ sudo ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:13:a9:8f:f0:e0  
          inet addr:10.0.0.11  Bcast:10.0.0.255  Mask:255.255.255.0
...

** I start the server with
WINEDEBUG=+winsock,+winediag,+iphlpapi,+wininet,+icmp,+rpc,+ole **

~$ sudo lsof -P -n -i udp|grep -P '(wine|arma)'
wineserve 5126   fab  304u  IPv4  13166      0t0  UDP *:2304 
wineserve 5126   fab  310u  IPv4  13167      0t0  UDP *:2302 
wineserve 5126   fab  319u  IPv4  14716      0t0  UDP *:43667 
arma2oase 5193   fab  231u  IPv4  13166      0t0  UDP *:2304 
arma2oase 5193   fab  238u  IPv4  13167      0t0  UDP *:2302 
arma2oase 5193   fab  239u  IPv4  13167      0t0  UDP *:2302 
arma2oase 5193   fab  241u  IPv4  13166      0t0  UDP *:2304 
arma2oase 5193   fab  249u  IPv4  14716      0t0  UDP *:43667

This time, the server bound * .
Wine dump in winedebug-linux3.13.dmp.gz

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #19 from [e-mail] ---
Created attachment 48355
  --> http://bugs.winehq.org/attachment.cgi?id=48355
Wine-1.7.17 - Linux 2.6

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48355|Wine-1.7.17 - Linux 2.6     |Logs of Wine-1.7.17 with
        description|                            |Linux 2.6

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #20 from [e-mail] ---
Created attachment 48356
  --> http://bugs.winehq.org/attachment.cgi?id=48356
Logs of Wine-1.7.17 with Linux 3.13

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #21 from Erich Hoover  ---
(In reply to facoptere from comment #18)
> ... 
> This time, the server bound * .
> Wine dump in winedebug-linux3.13.dmp.gz

Is the program not working properly or is it just that the application bound to
"*"?  Because that's the new intended behavior, other kernel options make it
effectively bound to the requested address but it's bound to "*" to support
broadcast packets.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #22 from [e-mail] ---
The application works, but not properly since 0.0.0.0 is bound ;)
Consequence of which I can't start 2 UDP servers on the same machine...

If you know some sysctl options, assuming it's a Linux "feature", that tell
Linux kernel to bind the IP address specified instead of the whole interfaces,
please give them. I can't find them.
If you know some Wine options that tell to respect arguments given in bind(), I
would like to know them either.

The application does not process any broadcast packets, and if it does I would
have written 0.0.0.0 in the startup parameters since it seems to be a Windows
prerequisite.

According to me, it's a bug that can leads to some security issue, since a
server can be accessed from some interfaces it does not meant to be.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #23 from Erich Hoover  ---
(In reply to facoptere from comment #22)
> The application works, but not properly since 0.0.0.0 is bound ;)
> Consequence of which I can't start 2 UDP servers on the same machine...

You should be able to bind as many servers as you want to 0.0.0.0, when Wine
activates this codepath it turns on SO_REUSEADDR on the socket so that other
binds are not prohibited.  What exactly happens when you try to start another
UDP server?
> If you know some sysctl options, assuming it's a Linux "feature", that tell
> Linux kernel to bind the IP address specified instead of the whole
> interfaces, please give them. I can't find them.
> If you know some Wine options that tell to respect arguments given in
> bind(), I would like to know them either.

At the moment you have to edit the Wine source to disable the option due to a
problem with glibc not properly updating a header.  If you edit
dlls/ws2_32/socket.c line 166 by adding "#undef IP_UNICAST_IF" then it will go
back to the old behavior.
> The application does not process any broadcast packets, and if it does I
> would have written 0.0.0.0 in the startup parameters since it seems to be a
> Windows prerequisite.

Unfortunately we don't know at bind-time whether the application needs
broadcast packets, so this option is enabled on all UDP sockets that are bound
to a specific interface.
> According to me, it's a bug that can leads to some security issue, since a
> server can be accessed from some interfaces it does not meant to be.

Wine sets the kernel option IP_UNICAST_IF to ensure that outbound packets go
out the requested interface and it also configures a Linux Packet Filter to
only accept packets on the interface you requested.  Unless you are doing
something really screwy with your routing table then the application is only
going to see packets from the interface that was specified (this included
broadcast packets, broadcast packets that come in on the wrong interface will
be dropped).

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #24 from [e-mail] ---
(In reply to Erich Hoover from comment #23)
> (In reply to facoptere from comment #22)
> > The application works, but not properly since 0.0.0.0 is bound ;)
> > Consequence of which I can't start 2 UDP servers on the same machine...
>
> You should be able to bind as many servers as you want to 0.0.0.0, when Wine
> activates this codepath it turns on SO_REUSEADDR on the socket so that other
> binds are not prohibited.  What exactly happens when you try to start
> another UDP server?

The server that binds the primary IP, binds obviously 0.0.0.0 and so catches
all the UDP traffic. The other server, which bound properly the second
(virtual) IP, does not work anymore after that. BTW, the 2 servers run in
separate unix accounts, separate windows "c:" drives, and there are 2
/usr/local/bin/wineserver running, that may explain the situation. The 2
servers need some regular restarts at different times.

...
> > If you know some Wine options that tell to respect arguments given in
> > bind(), I would like to know them either.
>
> At the moment you have to edit the Wine source to disable the option due to
> a problem with glibc not properly updating a header.  If you edit
> dlls/ws2_32/socket.c line 166 by adding "#undef IP_UNICAST_IF" then it will
> go back to the old behavior.

Thanks a lot for the tip. I will have a look at this.

...
> Wine sets the kernel option IP_UNICAST_IF to ensure that outbound packets go
> out the requested interface and it also configures a Linux Packet Filter to
> only accept packets on the interface you requested.  Unless you are doing
> something really screwy ...

I use shorewall as firewall. I don't know whether this meets the "screwy"
definition.

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #25 from Erich Hoover  ---
(In reply to facoptere from comment #24)
> ...
> The server that binds the primary IP, binds obviously 0.0.0.0 and so catches
> all the UDP traffic. The other server, which bound properly the second
> (virtual) IP, does not work anymore after that. BTW, the 2 servers run in
> separate unix accounts, separate windows "c:" drives, and there are 2
> /usr/local/bin/wineserver running, that may explain the situation. The 2
> servers need some regular restarts at different times.

I'll have to look into this a little bit, it's possible that you're
encountering an edge case that we didn't consider.
> ...
> I use shorewall as firewall. I don't know whether this meets the "screwy"
> definition.

Nope, that's fine.  You would know if you were doing screwy things with your
routing table :)

[Bug 33008] UDP listening on specific IP address does not work properly

http://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #26 from Bruno Jesus  ---
Can anyone provide sample source code to reproduce the issue here? With proper
steps also. This would help other people to reproduce and study it.

[Bug 33008] UDP listening on specific IP address does not work properly

https://bugs.winehq.org/show_bug.cgi?id=33008

--- Comment #27 from Austin English  ---
This is your friendly reminder that there has been no bug activity for over a
year. Is this still an issue in current (1.7.51 or newer) wine?

[Bug 33008] UDP listening on specific IP address does not work properly

https://bugs.winehq.org/show_bug.cgi?id=33008

tokktokk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 33008] UDP listening on specific IP address does not work properly

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=33008

James  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |50499

[Bug 33008] UDP listening on specific IP address does not work properly

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=33008

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]