We have come across something that may be a bug, unless this behavior was intentional. The problem can be simulated by creating a socket, setting SO_BINDTODEVICE, and binding to a port. Then, in a s
We have come across something that may be a bug, unless this behavior was intentional. The problem can be simulated by creating a socket, setting SO_BINDTODEVICE, and binding to a port. Then, in a se
Well, I would buy that as reasonable, acceptable behavior, but I think the reverse is true. We are binding specifically to say, eth0 on port 694. Someone comes along and binds to "no interface" on po
Kevin Dwyer wrote: On Mon, 06 Oct 2003 17:50:53 -0500 Casey Carter <Casey@xxxxxxxxxx> wrote: This is not a bug, it's a feature! It is possible to use multiple sockets with the same port number bound
Any possibility of getting this behavior into 2.4 as well? Albeit, without the scoring since that's obviously a new concept introduced by 2.6. (Which I prefer; well done.) I confess that I don't know
Kevin Dwyer wrote: On Tue, 07 Oct 2003 15:51:57 -0500 Casey Carter <ccarter@xxxxxxxxxxx> wrote: IMHO, the delivery should weigh sk_bound_dev_if much more strongly (7 instead of 2), so that if-bound s
Hello, We have come across something that may be a bug, unless this behavior was intentional. The problem can be simulated by creating a socket, setting SO_BINDTODEVICE, and binding to a port. Then,
Hello, We have come across something that may be a bug, unless this behavior was intentional. The problem can be simulated by creating a socket, setting SO_BINDTODEVICE, and binding to a port. Then,
Well, I would buy that as reasonable, acceptable behavior, but I think the reverse is true. We are binding specifically to say, eth0 on port 694. Someone comes along and binds to "no interface" on po
This is not a bug, it's a feature! It is possible to use multiple sockets with the same port number bound to different interfaces (where "no interface" is one possible choice). The UDP packet delive
Any possibility of getting this behavior into 2.4 as well? Albeit, without the scoring since that's obviously a new concept introduced by 2.6. (Which I prefer; well done.) I confess that I don't know
IMHO, the delivery should weigh sk_bound_dev_if much more strongly (7 instead of 2), so that if-bound sockets are always favored over non-if-bound. I would be happy to submit the (trivial) patch to