Dear list,
I have the following setting in which a client that resides on the same
physical network as a server wants to receive any UDP packet that
arrives on any of its interfaces sent by that server.
The code sets the broadcast flag, calls bind to INADDR_ANY and
uses recvfrom from there on.
Let's say the server resides in the subnet 192.168.6.255 and the
client in 192.168.3.255. The server uses its real IP as the packet's
sender ip (192.168.6.5).
Now the first problem I've encountered is the following:
If the client removes its default route and doesn't have any route
pointing into the subnet the server is in, the packets get discarded
(still tcpdump sees them).
The second problem is that if the server uses the broadcast address as
its sender address (255.255.255.255), the packets get always discarded
(again, tcpdump sees them).
Now if the server fakes its sender address to be in the client's subnet,
every packet arrives again.
So my real question is:
When does Linux discard packets and how can I prevent it from doing
that?
As I'm not yet subscribed to the list, please CC me directly.
Cheers,
Philipp
On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
> Dear list,
>
> I have the following setting in which a client that resides on the same
> physical network as a server wants to receive any UDP packet that
> arrives on any of its interfaces sent by that server.
>
> The code sets the broadcast flag, calls bind to INADDR_ANY and
> uses recvfrom from there on.
>
> Let's say the server resides in the subnet 192.168.6.255 and the
> client in 192.168.3.255. The server uses its real IP as the packet's
> sender ip (192.168.6.5).
You don't say what the client IP is. Let's assume that it is 192.168.3.1
for simplicity.
>
> Now the first problem I've encountered is the following:
> If the client removes its default route and doesn't have any route
> pointing into the subnet the server is in, the packets get discarded
> (still tcpdump sees them).
>
Are you saying that the server sent to 192.168.3.1 with source ip of
192.168.6.5 and the client did not see it?
> The second problem is that if the server uses the broadcast address as
> its sender address (255.255.255.255), the packets get always discarded
> (again, tcpdump sees them).
Again, what was the destination IP address?
> Now if the server fakes its sender address to be in the client's subnet,
> every packet arrives again.
So the only thing you change is the sender address?
What tools are you using to read the packets, and how do you know it is
dropped?
-- Steve
>
> So my real question is:
> When does Linux discard packets and how can I prevent it from doing
> that?
Oh, btw, you don't need to strip LKML from replys (or any Cc), unless it
is off topic. LKML is a public forum, and as long as things are on topic,
it is nice to show others the solutions that are found.
>
> On Thu, 4 Jun 2009, Philipp Reh wrote:
>
> > I'm not really sure it is dropped but tcpdump sees the packet and
> > recvfrom doesn't see it, so I think that the kernel might drop it
> > somewhere when processing the IP stack logic.
>
> Looking at the udp stack, selinux plays a role, and looks like it will
> drop a packet if it is not in the routing table.
>
> Try:
>
> # setenforce 0
>
> and see if you start seeing packets.
BTW, I used ftrace to look into this:
Enable:
CONFIG_FTRACE
CONFIG_FUNCTION_TRACER
CONFIG_FUNCITON_GRAPH_TRACER
CONFIG_DYNAMIC_FTRACE
Compile and boot:
# mount -t debugfs nodev /sys/kernel/debug
# cd /sys/kernel/debug
# echo udp_rcv > set_graph_function
# echo function_graph > current_tracer
# cat trace
and this is what I see:
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | | | | | |
1) | udp_rcv() {
1) | __udp4_lib_rcv() {
1) | __udp4_lib_lookup() {
1) 0.584 us | T.757();
1) 2.905 us | }
1) | udp_queue_rcv_skb() {
1) 0.584 us | nf_reset();
1) 0.996 us | _spin_lock();
1) | __udp_queue_rcv_skb() {
1) | sock_queue_rcv_skb() {
1) | sk_filter() {
1) | security_sock_rcv_skb() {
1) | selinux_socket_sock_rcv_skb() {
1) | selinux_parse_skb() {
1) 0.584 us | skb_header_pointer();
1) 0.569 us | skb_header_pointer();
1) 3.074 us | }
1) | selinux_netlbl_sock_rcv_skb() {
1) 0.561 us | netlbl_enabled();
1) 1.748 us | }
1) 6.792 us | }
1) 8.095 us | }
1) | local_bh_disable() {
1) 0.599 us | __local_bh_disable();
1) 1.790 us | }
1) | local_bh_enable() {
1) | _local_bh_enable_ip() {
1) 0.566 us | T.445();
1) 1.906 us | }
1) 3.149 us | }
1) + 15.722 us | }
1) | skb_queue_tail() {
1) 1.059 us | _spin_lock_irqsave();
1) | _spin_unlock_irqrestore() {
1) 0.596 us | T.263();
1) 1.913 us | }
1) 4.718 us | }
1) 0.565 us | sock_flag();
1) | sock_def_readable() {
1) 0.981 us | _read_lock();
1) | __wake_up_sync_key() {
1) 0.887 us | _spin_lock_irqsave();
1) | __wake_up_common() {
1) | pollwake() {
1) | default_wake_function() {
1) | try_to_wake_up() {
1) | task_rq_lock() {
1) 0.951 us | _spin_lock();
1) 2.030 us | }
1) 0.768 us | update_rq_clock();
1) | select_task_rq_fair() {
1) 0.501 us | effective_load();
1) 0.494 us | effective_load();
-- Steve
On Thu, 4 Jun 2009, Steven Rostedt wrote:
>
> Oh, btw, you don't need to strip LKML from replys (or any Cc), unless it
> is off topic. LKML is a public forum, and as long as things are on topic,
> it is nice to show others the solutions that are found.
>
> >
> > On Thu, 4 Jun 2009, Philipp Reh wrote:
> >
> > > I'm not really sure it is dropped but tcpdump sees the packet and
> > > recvfrom doesn't see it, so I think that the kernel might drop it
> > > somewhere when processing the IP stack logic.
> >
> > Looking at the udp stack, selinux plays a role, and looks like it will
> > drop a packet if it is not in the routing table.
> >
> > Try:
> >
> > # setenforce 0
> >
> > and see if you start seeing packets.
>
> BTW, I used ftrace to look into this:
>
> Enable:
>
> CONFIG_FTRACE
> CONFIG_FUNCTION_TRACER
> CONFIG_FUNCITON_GRAPH_TRACER
> CONFIG_DYNAMIC_FTRACE
>
> Compile and boot:
>
> # mount -t debugfs nodev /sys/kernel/debug
> # cd /sys/kernel/debug
> # echo udp_rcv > set_graph_function
> # echo function_graph > current_tracer
> # cat trace
>
Could you do the above and send me (off list) the output of the trace?
-- Steve
On Thu, 2009-06-04 at 12:34 -0400, Steven Rostedt wrote:
> BTW, I used ftrace to look into this:
>
> Enable:
>
> CONFIG_FTRACE
> CONFIG_FUNCTION_TRACER
> CONFIG_FUNCITON_GRAPH_TRACER
> CONFIG_DYNAMIC_FTRACE
>
> Compile and boot:
>
> # mount -t debugfs nodev /sys/kernel/debug
Very glad to see you following standards ;-)
> # cd /sys/kernel/debug
hmm you mean # cd /sys/kernel/debug/tracing
> # echo udp_rcv > set_graph_function
> # echo function_graph > current_tracer
> # cat trace
>
Anyway you can also see UDP packet drops when you increase network and
CPU load.
--
JSR
On Thu, 4 Jun 2009, Steven Rostedt wrote:
> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
>> Dear list,
>>
>> I have the following setting in which a client that resides on the same
>> physical network as a server wants to receive any UDP packet that
>> arrives on any of its interfaces sent by that server.
>>
>> The code sets the broadcast flag, calls bind to INADDR_ANY and
>> uses recvfrom from there on.
>>
>> Let's say the server resides in the subnet 192.168.6.255 and the
>> client in 192.168.3.255. The server uses its real IP as the packet's
>> sender ip (192.168.6.5).
>
> You don't say what the client IP is. Let's assume that it is 192.168.3.1
> for simplicity.
>
>>
>> Now the first problem I've encountered is the following:
>> If the client removes its default route and doesn't have any route
>> pointing into the subnet the server is in, the packets get discarded
>> (still tcpdump sees them).
>>
>
> Are you saying that the server sent to 192.168.3.1 with source ip of
> 192.168.6.5 and the client did not see it?
>
>> The second problem is that if the server uses the broadcast address as
>> its sender address (255.255.255.255), the packets get always discarded
>> (again, tcpdump sees them).
>
> Again, what was the destination IP address?
>
>> Now if the server fakes its sender address to be in the client's subnet,
>> every packet arrives again.
>
> So the only thing you change is the sender address?
>
> What tools are you using to read the packets, and how do you know it is
> dropped?
I have seen the same thing. I have syslog servers on one subnet without a
default route. If I configure a server on another subnet to send it logs I
can see the packets with tcpdump, but syslogd will not record them.
If I configure a route on the recieving box that makes it think that it
can get to the sender (note that the route can be completely bogus,
pointing at a wrong or non-existing gateway) the kernel is happy and the
packets show up to syslogd
the systems I am running do _not_ have selinux on them.
I have seen this as far back as 2.6.12 so it's not a recent change.
if you need examples with IP addresses
box 1
IP 10.1.1.2
router
IP 10.1.1.1
IP 192.168.1.1
box 2
IP 192.168.1.2
If I configure box 2 to have a route to box1, but do not configure box 1
to have any route (including not having a default route) that would get it
to a 192.168.1.x subnet tcpdump on box 1 will show the syslog packets, but
syslog (and any non-pcap tool) will not see the packets)
if I configure a route on box 1 to have a default route of 10.1.1.3 (which
does not exist, so cannot possibly route packets anywhere) then everything
works.
>> So my real question is:
>> When does Linux discard packets and how can I prevent it from doing
>> that?
for this problem, set a default route that points at a non-existing
gateway and I believe that your problem will go away.
David Lang
[email protected] a ?crit :
> On Thu, 4 Jun 2009, Steven Rostedt wrote:
>
>> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
>>> Dear list,
>>>
>>> I have the following setting in which a client that resides on the same
>>> physical network as a server wants to receive any UDP packet that
>>> arrives on any of its interfaces sent by that server.
>>>
>>> The code sets the broadcast flag, calls bind to INADDR_ANY and
>>> uses recvfrom from there on.
>>>
>>> Let's say the server resides in the subnet 192.168.6.255 and the
>>> client in 192.168.3.255. The server uses its real IP as the packet's
>>> sender ip (192.168.6.5).
>>
>> You don't say what the client IP is. Let's assume that it is 192.168.3.1
>> for simplicity.
>>
>>>
>>> Now the first problem I've encountered is the following:
>>> If the client removes its default route and doesn't have any route
>>> pointing into the subnet the server is in, the packets get discarded
>>> (still tcpdump sees them).
>>>
>>
>> Are you saying that the server sent to 192.168.3.1 with source ip of
>> 192.168.6.5 and the client did not see it?
>>
>>> The second problem is that if the server uses the broadcast address as
>>> its sender address (255.255.255.255), the packets get always discarded
>>> (again, tcpdump sees them).
>>
>> Again, what was the destination IP address?
>>
>>> Now if the server fakes its sender address to be in the client's subnet,
>>> every packet arrives again.
>>
>> So the only thing you change is the sender address?
>>
>> What tools are you using to read the packets, and how do you know it is
>> dropped?
>
>
> I have seen the same thing. I have syslog servers on one subnet without
> a default route. If I configure a server on another subnet to send it
> logs I can see the packets with tcpdump, but syslogd will not record them.
>
> If I configure a route on the recieving box that makes it think that it
> can get to the sender (note that the route can be completely bogus,
> pointing at a wrong or non-existing gateway) the kernel is happy and the
> packets show up to syslogd
>
> the systems I am running do _not_ have selinux on them.
>
> I have seen this as far back as 2.6.12 so it's not a recent change.
>
> if you need examples with IP addresses
>
> box 1
> IP 10.1.1.2
>
> router
> IP 10.1.1.1
> IP 192.168.1.1
>
> box 2
> IP 192.168.1.2
>
> If I configure box 2 to have a route to box1, but do not configure box 1
> to have any route (including not having a default route) that would get
> it to a 192.168.1.x subnet tcpdump on box 1 will show the syslog
> packets, but syslog (and any non-pcap tool) will not see the packets)
>
> if I configure a route on box 1 to have a default route of 10.1.1.3
> (which does not exist, so cannot possibly route packets anywhere) then
> everything works.
I guess you need to change rp_filter settings
Documentation/networking/ip-sysctl.txt
rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check will fail.
By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB
and if the source address is not reachable via any interface
the packet check will fail.
Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.
conf/all/rp_filter must also be set to non-zero to do source validation
on the interface
Default value is 0. Note that some distributions enable it
in startup scripts.
>
>>> So my real question is:
>>> When does Linux discard packets and how can I prevent it from doing
>>> that?
>
> for this problem, set a default route that points at a non-existing
> gateway and I believe that your problem will go away.
On Thu, 4 Jun 2009, Eric Dumazet wrote:
> [email protected] a ?crit :
>> On Thu, 4 Jun 2009, Steven Rostedt wrote:
>>
>>> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
>>>> Dear list,
>>>>
>>>> I have the following setting in which a client that resides on the same
>>>> physical network as a server wants to receive any UDP packet that
>>>> arrives on any of its interfaces sent by that server.
>>>>
>>>> The code sets the broadcast flag, calls bind to INADDR_ANY and
>>>> uses recvfrom from there on.
>>>>
>>>> Let's say the server resides in the subnet 192.168.6.255 and the
>>>> client in 192.168.3.255. The server uses its real IP as the packet's
>>>> sender ip (192.168.6.5).
>>>
>>> You don't say what the client IP is. Let's assume that it is 192.168.3.1
>>> for simplicity.
>>>
>>>>
>>>> Now the first problem I've encountered is the following:
>>>> If the client removes its default route and doesn't have any route
>>>> pointing into the subnet the server is in, the packets get discarded
>>>> (still tcpdump sees them).
>>>>
>>>
>>> Are you saying that the server sent to 192.168.3.1 with source ip of
>>> 192.168.6.5 and the client did not see it?
>>>
>>>> The second problem is that if the server uses the broadcast address as
>>>> its sender address (255.255.255.255), the packets get always discarded
>>>> (again, tcpdump sees them).
>>>
>>> Again, what was the destination IP address?
>>>
>>>> Now if the server fakes its sender address to be in the client's subnet,
>>>> every packet arrives again.
>>>
>>> So the only thing you change is the sender address?
>>>
>>> What tools are you using to read the packets, and how do you know it is
>>> dropped?
>>
>>
>> I have seen the same thing. I have syslog servers on one subnet without
>> a default route. If I configure a server on another subnet to send it
>> logs I can see the packets with tcpdump, but syslogd will not record them.
>>
>> If I configure a route on the recieving box that makes it think that it
>> can get to the sender (note that the route can be completely bogus,
>> pointing at a wrong or non-existing gateway) the kernel is happy and the
>> packets show up to syslogd
>>
>> the systems I am running do _not_ have selinux on them.
>>
>> I have seen this as far back as 2.6.12 so it's not a recent change.
>>
>> if you need examples with IP addresses
>>
>> box 1
>> IP 10.1.1.2
>>
>> router
>> IP 10.1.1.1
>> IP 192.168.1.1
>>
>> box 2
>> IP 192.168.1.2
>>
>> If I configure box 2 to have a route to box1, but do not configure box 1
>> to have any route (including not having a default route) that would get
>> it to a 192.168.1.x subnet tcpdump on box 1 will show the syslog
>> packets, but syslog (and any non-pcap tool) will not see the packets)
>>
>> if I configure a route on box 1 to have a default route of 10.1.1.3
>> (which does not exist, so cannot possibly route packets anywhere) then
>> everything works.
>
> I guess you need to change rp_filter settings
>
> Documentation/networking/ip-sysctl.txt
>
> rp_filter - INTEGER
>
> 0 - No source validation.
> 1 - Strict mode as defined in RFC3704 Strict Reverse Path
> Each incoming packet is tested against the FIB and if the interface
> is not the best reverse path the packet check will fail.
> By default failed packets are discarded.
> 2 - Loose mode as defined in RFC3704 Loose Reverse Path
> Each incoming packet's source address is also tested against the FIB
> and if the source address is not reachable via any interface
> the packet check will fail.
>
> Current recommended practice in RFC3704 is to enable strict mode
> to prevent IP spoofing from DDos attacks. If using asymmetric routing
> or other complicated routing, then loose mode is recommended.
>
> conf/all/rp_filter must also be set to non-zero to do source validation
> on the interface
>
> Default value is 0. Note that some distributions enable it
> in startup scripts.
thanks, On my Debian based systems I have commented this out of the
sysctl.conf file, but apparently there is some other script that is
setting it anyway. I'll have to track down what it's doing.
David Lang
>
>>
>>>> So my real question is:
>>>> When does Linux discard packets and how can I prevent it from doing
>>>> that?
>>
>> for this problem, set a default route that points at a non-existing
>> gateway and I believe that your problem will go away.
>
>
>
On Thu, 4 Jun 2009, Jaswinder Singh Rajput wrote:
> On Thu, 2009-06-04 at 12:34 -0400, Steven Rostedt wrote:
>
> > BTW, I used ftrace to look into this:
> >
> > Enable:
> >
> > CONFIG_FTRACE
> > CONFIG_FUNCTION_TRACER
> > CONFIG_FUNCITON_GRAPH_TRACER
> > CONFIG_DYNAMIC_FTRACE
> >
> > Compile and boot:
> >
> > # mount -t debugfs nodev /sys/kernel/debug
>
> Very glad to see you following standards ;-)
I only did that to not hear the debugfs nazis squack.
>
> > # cd /sys/kernel/debug
>
> hmm you mean # cd /sys/kernel/debug/tracing
A mistake I would not have made if I just did /debug
>
> > # echo udp_rcv > set_graph_function
> > # echo function_graph > current_tracer
> > # cat trace
> >
>
> Anyway you can also see UDP packet drops when you increase network and
> CPU load.
That's not the issue here.
-- Steve
Philipp Reh <[email protected]> wrote:
>
> I have the following setting in which a client that resides on the same
> physical network as a server wants to receive any UDP packet that
> arrives on any of its interfaces sent by that server.
>
Read up about multicasting, it will do what you want, does not depend on
the IP address of the destination workstation and will also cross
subnets if you want it to.
It's dead easy to transmit and receive multicast traffic, broadcasting
network traffic is so 1980's :)
> As I'm not yet subscribed to the list, please CC me directly.
>
Have a look at GMANE for following large volumn mailing lists.
Cheers
--
Alexander Clouter
.sigmonster says: Familiarity breeds attempt.
On Thu, 4 Jun 2009, Alexander Clouter wrote:
> Philipp Reh <[email protected]> wrote:
>>
>> I have the following setting in which a client that resides on the same
>> physical network as a server wants to receive any UDP packet that
>> arrives on any of its interfaces sent by that server.
>>
> Read up about multicasting, it will do what you want, does not depend on
> the IP address of the destination workstation and will also cross
> subnets if you want it to.
>
> It's dead easy to transmit and receive multicast traffic, broadcasting
> network traffic is so 1980's :)
there is only a difference between multicast and broadcast traffic if you
are spanning subnets.
but the issue here is the rp_filter, and that would also filter out
multicast packets from sources that you don't have routes to.
David Lang
Hi,
* [email protected] <[email protected]> [2009-06-04 16:19:56-0700]:
>
> On Thu, 4 Jun 2009, Alexander Clouter wrote:
>
> > Philipp Reh <[email protected]> wrote:
> > >
> > > I have the following setting in which a client that resides on the same
> > > physical network as a server wants to receive any UDP packet that
> > > arrives on any of its interfaces sent by that server.
> > >
> > Read up about multicasting, it will do what you want, does not depend on
> > the IP address of the destination workstation and will also cross
> > subnets if you want it to.
> >
> > It's dead easy to transmit and receive multicast traffic, broadcasting
> > network traffic is so 1980's :)
>
> there is only a difference between multicast and broadcast traffic if you
> are spanning subnets.
>
Well yes and no. Broadcast traffic is *always* handled by the kernel as
only the kernel can tell if it is interested in it or not. With
multicast the NIC is configured to only pass particular
Ethernet multicast packets up to the kernel.
By using broadcast traffic the load (okay, hardly a big problem
now-a-days) hits *all* the workstations on the subnet, with multicast,
only those interested in the traffic receive it.
Cheers
--
Alexander Clouter
.sigmonster says: You were s'posed to laugh!
On Fri, 5 Jun 2009, Alexander Clouter wrote:
> Hi,
>
> * [email protected] <[email protected]> [2009-06-04 16:19:56-0700]:
>>
>> On Thu, 4 Jun 2009, Alexander Clouter wrote:
>>
>>> Philipp Reh <[email protected]> wrote:
>>>>
>>>> I have the following setting in which a client that resides on the same
>>>> physical network as a server wants to receive any UDP packet that
>>>> arrives on any of its interfaces sent by that server.
>>>>
>>> Read up about multicasting, it will do what you want, does not depend on
>>> the IP address of the destination workstation and will also cross
>>> subnets if you want it to.
>>>
>>> It's dead easy to transmit and receive multicast traffic, broadcasting
>>> network traffic is so 1980's :)
>>
>> there is only a difference between multicast and broadcast traffic if you
>> are spanning subnets.
>>
> Well yes and no. Broadcast traffic is *always* handled by the kernel as
> only the kernel can tell if it is interested in it or not. With
> multicast the NIC is configured to only pass particular
> Ethernet multicast packets up to the kernel.
>
> By using broadcast traffic the load (okay, hardly a big problem
> now-a-days) hits *all* the workstations on the subnet, with multicast,
> only those interested in the traffic receive it.
true, but only for some NICs, and even those tend to have a fairly small
number of slots for the filters. past these limits the OS handles it all
just like broadcasts.
David Lang
Hi,
* [email protected] <[email protected]> [2009-06-05 12:15:27-0700]:
>
> On Fri, 5 Jun 2009, Alexander Clouter wrote:
>
> > * [email protected] <[email protected]> [2009-06-04 16:19:56-0700]:
> > >
> > > On Thu, 4 Jun 2009, Alexander Clouter wrote:
> > > >
> > > > It's dead easy to transmit and receive multicast traffic, broadcasting
> > > > network traffic is so 1980's :)
> > >
> > > there is only a difference between multicast and broadcast traffic if you
> > > are spanning subnets.
> > >
> > Well yes and no. Broadcast traffic is *always* handled by the kernel as
> > only the kernel can tell if it is interested in it or not. With
> > multicast the NIC is configured to only pass particular
> > Ethernet multicast packets up to the kernel.
> >
> > By using broadcast traffic the load (okay, hardly a big problem
> > now-a-days) hits *all* the workstations on the subnet, with multicast,
> > only those interested in the traffic receive it.
>
> true, but only for some NICs, and even those tend to have a fairly small
> number of slots for the filters. past these limits the OS handles it all
> just like broadcasts.
>
I *think* only the early ones have a naff non-hashing based to filter
multicast flows, could be wrong though.
Either way, as a packet pusher by day, I dream of the venduh's
discovering that multicast can be used for device discovery rather than
expecting everything to be on the same subnet :-/
In this day and age, using broadcast to do a job is just plain lazy and
braindead.
Cheers
--
Alexander Clouter
.sigmonster says: Misuse may cause suffocation.
On Thu, Jun 04, 2009 at 11:57:41AM -0400, Steven Rostedt wrote:
> On Thu, Jun 04, 2009 at 04:53:47PM +0200, Philipp Reh wrote:
> > Dear list,
> >
> > I have the following setting in which a client that resides on the same
> > physical network as a server wants to receive any UDP packet that
> > arrives on any of its interfaces sent by that server.
> >
> > The code sets the broadcast flag, calls bind to INADDR_ANY and
> > uses recvfrom from there on.
> >
> > Let's say the server resides in the subnet 192.168.6.255 and the
> > client in 192.168.3.255. The server uses its real IP as the packet's
> > sender ip (192.168.6.5).
>
> You don't say what the client IP is. Let's assume that it is 192.168.3.1
> for simplicity.
>
> >
> > Now the first problem I've encountered is the following:
> > If the client removes its default route and doesn't have any route
> > pointing into the subnet the server is in, the packets get discarded
> > (still tcpdump sees them).
> >
>
> Are you saying that the server sent to 192.168.3.1 with source ip of
> 192.168.6.5 and the client did not see it?
>
> > The second problem is that if the server uses the broadcast address as
> > its sender address (255.255.255.255), the packets get always discarded
> > (again, tcpdump sees them).
>
> Again, what was the destination IP address?
>
> > Now if the server fakes its sender address to be in the client's subnet,
> > every packet arrives again.
>
> So the only thing you change is the sender address?
>
> What tools are you using to read the packets, and how do you know it is
> dropped?
>
> -- Steve
>
> >
> > So my real question is:
> > When does Linux discard packets and how can I prevent it from doing
> > that?
What subnet masks?
If two mutually exclusive TCP/IP subnets are on the same physical network
they will be all but invisible to each other unless there is routing
between them. With modern switches this is very much. With modern
smart router/switches interesting things can be done.
The server can have a single MAC configured to send
and receive data on two subnets.
If the server is faking its sender address then other things are happening
(switch, arp, zeroconfig, bogus broadcast address...) so why fake it
set it up to be live on both nets.... make both real.
eth0:0 192.168.6.5/24
eth0:1 192.168.3.5/24
http://www.faqs.org/docs/Linux-mini/IP-Alias.html
Zeroconfig may also make things work in unexpected ways.
http://www.zeroconf.org/
# the almost obvious...
# 10.0.0.0 - 10.255.255.255 (10/8 prefix)
# 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
# 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
# 169.254.0.0/16 - 169.254.255.255 (link-local 169.254.0.0/16 prefix)
--
T o m M i t c h e l l
Found me a new hat, now what?
[email protected] wrote:
>
> there is only a difference between multicast and broadcast traffic if you
> are spanning subnets.
Which is always the case if you invest in some intelligent switches.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, 24 Jun 2009, Herbert Xu wrote:
> [email protected] wrote:
>>
>> there is only a difference between multicast and broadcast traffic if you
>> are spanning subnets.
>
> Which is always the case if you invest in some intelligent switches.
given that each subnet will be a minimum of 4 IP addresses (the network
address, two useable, and thr broadcast address), putting each machine on
it's own subnet and routing between them on the switch would be very
wasteful of addresses.
if you use larger subnets, your switch still has the ability to filter
things out when they move from port to port, but broadcasts (unless you
filter them) still cover the entire subnet.
so No, buying intelligent switches doesn't mean that you are always
spanning subnets.
David Lang
[email protected] wrote:
>
> given that each subnet will be a minimum of 4 IP addresses (the network
> address, two useable, and thr broadcast address), putting each machine on
> it's own subnet and routing between them on the switch would be very
> wasteful of addresses.
What I mean is that if you have snooping switches then multicasts
and broadcasts are not the same even when you're on the same subnet.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, 25 Jun 2009, Herbert Xu wrote:
> [email protected] wrote:
>>
>> given that each subnet will be a minimum of 4 IP addresses (the network
>> address, two useable, and thr broadcast address), putting each machine on
>> it's own subnet and routing between them on the switch would be very
>> wasteful of addresses.
>
> What I mean is that if you have snooping switches then multicasts
> and broadcasts are not the same even when you're on the same subnet.
please explain more? how do they differ?
David Lang
On Wed, Jun 24, 2009 at 10:37:14PM -0700, [email protected] wrote:
>
> please explain more? how do they differ?
An IGMP-snooping switch will only forward multicast traffic to
ports that have subscribed to that group. Broadcast traffic
on the otherhand is forwarded to all ports.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi,
* Herbert Xu <[email protected]> [2009-06-25 14:13:48+0800]:
>
> On Wed, Jun 24, 2009 at 10:37:14PM -0700, [email protected] wrote:
> >
> > please explain more? how do they differ?
>
> An IGMP-snooping switch will only forward multicast traffic to
> ports that have subscribed to that group. Broadcast traffic
> on the otherhand is forwarded to all ports.
>
[directing over to David...]
The more intelligent switches actually peek at L3/L4 (even if it's just
a L2 switch, like a Cisco 2950) to decode IGMP packets as they come out
from the hosts. The switch uses that to build up an Ethernet multicast
routing table, in addition to it's usual unicast based one.
If you bought a managed switch in the past five years (ours from 8 years
ago that we have just binned also supported it) it should support
IGMP snooping. Any one buying switches now needs to make sure they
support IPv6 and MLD snooping...bearing in mind you are going to be
lumbered with those switches for at least five years.
In addition and mentioned before, the NIC in hardware will also filter
any multicast traffic that is un-needed if you are using el-cheapo
switches; crime and punishment. Broadcast traffic *always* spans the
whole VLAN and *always* gets passed up to the OS to make decisions on
whether to process the packet or not.
Now, when you roll back in the 'automaticness' of service discovery and
other such things on the network...multicast is a very powerful tool.
Just because it can be many<->many or one<->many does not mean it cannot
be just as efficiently used to bootstrap one<->one communications.
Cheers
--
Alexander Clouter
.sigmonster says: Don't take life seriously, you'll never get out alive.