multihomed linux box IP packets sent on wrong subnet

Hi,

Got a Linux box, fairly old SuSE 6,4 job with 3 network cards all of
which are internal LANS - as follows:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.2.0 * 255.255.255.0 U 0 0 0
eth2
192.168.1.0 * 255.255.255.0 U 0 0 0
eth1
192.168.0.0 * 255.255.255.0 U 0 0 0
eth0
loopback * 255.0.0.0 U 0 0 0
lo
default dsl-gw2.onastic 0.0.0.0 UG 0 0 0
eth0

Samba is configured to run on all 3 interfaces and register with a WINS
server (at 192.168.0.200 so subnet 0) however it only seems to register
the IP address for the 0 subnet. Having a look at the packet trace on
subnet 0 what appears to be happening is that NBNS registration packets
are sent out as follows:

source dest
192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
0.99)
192.168.1.99 -> 192.168.0.200 - Multi-homed registration (registers
1.99)
192.168.2.99 -> 192.168.0.200 - Multi-homed registration (registers
2.99)

So somehow it's putting out a source IP address on the wrong subnet -
what I would expect is to see the 3 packets as follows:

192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
0.99)
192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
1.99)
192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
2.99)

Can't believe this is a Samba problem because having written some socket
based software you don't ever specify your source IP address because the
OS does that so I'm confused as to why it does this.

Any help appreciated.


j.
--
== jon bird - software engineer
== <reply to address _may_ be invalid, real mail below>
== <reduce rsi, stop using the shift key>
== posted as: news 'at' onastick 'dot' clara.co.uk

jon bird wrote:
> Hi,
>
> Got a Linux box, fairly old SuSE 6,4 job with 3 network cards all of
> which are internal LANS - as follows:

Hope your Samba is a _lot_ more current than this Suse version. What
is it?

> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
Use
> Iface
> 192.168.2.0 * 255.255.255.0 U 0 0
0
> eth2
> 192.168.1.0 * 255.255.255.0 U 0 0
0
> eth1
> 192.168.0.0 * 255.255.255.0 U 0 0
0
> eth0
> loopback * 255.0.0.0 U 0 0
0
> lo
> default dsl-gw2.onastic 0.0.0.0 UG 0 0
0
> eth0
>
> Samba is configured to run on all 3 interfaces and register with a
WINS
> server (at 192.168.0.200 so subnet 0) however it only seems to
register
> the IP address for the 0 subnet. ...

Do you mean WINS only registers 192.168.0.99? It's common for
multi-homed machines to only successfully register the first request.
Is that what you think is happening? Errors? Logs?

> ... Having a look at the packet trace on
> subnet 0 what appears to be happening is that NBNS registration
packets
> are sent out as follows:
>
> source dest
> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
> 0.99)
> 192.168.1.99 -> 192.168.0.200 - Multi-homed registration (registers
> 1.99)
> 192.168.2.99 -> 192.168.0.200 - Multi-homed registration (registers
> 2.99)
>
> So somehow it's putting out a source IP address on the wrong subnet -


Not sure what you mean here by "out ... on the wrong subnet". The
registrations are to a server on the 192.168.0.0 subnet, so naturally
the datagrams are routed that way.

> what I would expect is to see the 3 packets as follows:
>
> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
> 0.99)
> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
> 1.99)
> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
> 2.99)

Why? What protocol are these packets (real and presumed)? What do you
think "source" means here? I assumed that they are the source IP of
the registration request, ie., the IP that is to be mapped to NetBios
name. It's been several years since I've looked at SMB packets. Is
that what these are?

> Can't believe this is a Samba problem ...

I'm not sure what the "problem" is that you're referencing, other than
that some packet fields hold IP values you do not expect? Are you
experiencing connection/browsing problems? Errors in logs? What?

> ... because having written some socket
> based software you don't ever specify your source IP address because
the
> OS does that so I'm confused as to why it does this.

I'm not sure what sockets programming has to do with the above
captures. Your Linux machine must register three IPs to what NetBios
name? A group name? Unique name(s)?

Multi-homed boxes often cause headaches with SMB networking. Are you
having any?

The most consice review of multi-home issues I know is:
1.4.3.1.4 Registering Multi-Homed Hosts
found in
"Implementing CIFS" in the Samba docs.
[q]
The annoying thing about multi-homed hosts in an NBT environment is
that they try to register their NetBIOS names on each interface, which
means multiple IP addresses per name. This is not a problem for group
names because group names map to several IP addresses anyway--that's
what NBT group names are all about. Unique names _are_ a problem
because, from the network's point of view, there is no difference
between a multi-homed host and multiple machines. To an NBNS, or to B
nodes on a local LAN, multiple registrations for the same name will
look like a name conflict.
[eq]

It's just not clear to me what the nature of your problem really is.
It could be me -- it's Friday Clarify?

You might also try the linux.samba list/ng (via Google if need be)
where the sharper Samba minds may reside.

If you think this _is_ a Suse config/setup problem, why? Just because
of the packets appearring on the 192.168.0.0 subnet? Where else would
they show up; that's where they are being sent?

Am I missing something?

regards,
prg

In article <(E-Mail Removed) .com>, prg
<(E-Mail Removed)> writes
>
>jon bird wrote:
>> Hi,
>>
>> Got a Linux box, fairly old SuSE 6,4 job with 3 network cards all of
>> which are internal LANS - as follows:
>
>Hope your Samba is a _lot_ more current than this Suse version. What
>is it?
>
no, its the original version - 2.06 with kernel 2.2.19. Yes, a bit old I
know but don't really want to start upgrading things since for the most
part everything works.

>
>Do you mean WINS only registers 192.168.0.99? It's common for
>multi-homed machines to only successfully register the first request.
>Is that what you think is happening? Errors? Logs?
>
Ok, this is what I see on the WINS (Samba) server on the 192.168.0.x
subnet:

Apr 23 13:01:59 fridge kernel: martian source 192.168.0.200 from
192.168.1.99, on dev eth0
Apr 23 13:01:59 fridge kernel: ll header:
00:10:b5:40:d7:ea:00:50:bf:d7:81:a5:08:00
Apr 23 13:01:59 fridge kernel: martian source 192.168.0.200 from
192.168.2.99, on dev eth0
Apr 23 13:01:59 fridge kernel: ll header:
00:10:b5:40:d7:ea:00:50:bf:d7:81:a5:08:00

This tells me that there are packets going out on this subnet which
shouldn't be there - hence they get ignored.

>Not sure what you mean here by "out ... on the wrong subnet". The
>registrations are to a server on the 192.168.0.0 subnet, so naturally
>the datagrams are routed that way.
>
true - but they shouldn't originate from an IP address not on that
subnet - a packet trace shows:

Frame 191 (110 bytes on wire, 110 bytes captured)

Internet Protocol, Src Addr: 192.168.1.99 (192.168.1.99), Dst Addr:
192.168.0.200 (192.168.0.200)
Version: 4
Header length: 20 bytes
[...]
NetBIOS Name Service
Transaction ID: 0x3ebd
[...]
Additional records
TOASTER<20>: type NB, class inet
Name: TOASTER<20> (Server service)
Type: NB
Class: inet
Time to live: 3 days
Data length: 6
Flags: 0x4000 (M-node, unique)
0... .... .... .... = Unique name
.10. .... .... .... = M-node
Addr: 192.168.1.99

>> what I would expect is to see the 3 packets as follows:
>>
>> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
>> 0.99)
>> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
>> 1.99)
>> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
>> 2.99)
>

>Why? What protocol are these packets (real and presumed)? What do you
>think "source" means here? I assumed that they are the source IP of
>the registration request, ie., the IP that is to be mapped to NetBios
>name. It's been several years since I've looked at SMB packets. Is
>that what these are?
>
well in the context above, I would expect to see the packet originate
from 192.168.0.99 - it's the address (in the packet data) I presume it's
trying to register rather than using the originating IP.

>> Can't believe this is a Samba problem ...
>
>I'm not sure what the "problem" is that you're referencing, other than
>that some packet fields hold IP values you do not expect? Are you
>experiencing connection/browsing problems? Errors in logs? What?
>
>> ... because having written some socket
>> based software you don't ever specify your source IP address because
>the
>> OS does that so I'm confused as to why it does this.
>
>I'm not sure what sockets programming has to do with the above
>captures. Your Linux machine must register three IPs to what NetBios
>name? A group name? Unique name(s)?
>
Principally because from an application point of view I've not seen
anything that lets you specify the originating IP address - that's a
given. You would specify the destination IP address and let the OS worry
about how/which interface it routes it on. Thus I can't see why this
problem is in the Samba application, it feels more like a routing
problem.

>Multi-homed boxes often cause headaches with SMB networking. Are you
>having any?
>
not really got that far yet..... Might not work anyway, wouldn't be
surprised if it didn't considering the age of one of the machines but
just confused as to why this is happening.

>It's just not clear to me what the nature of your problem really is.
>It could be me -- it's Friday Clarify?
>
hopefully its as clear as mud now......

rgs,


j.
--
== jon bird - software engineer
== <reply to address _may_ be invalid, real mail below>
== <reduce rsi, stop using the shift key>
== posted as: news 'at' onastick 'dot' clara.co.uk

fixed it - course it's okay, i just need to sort out the subnet on
192.168.x to accept traffic from the other 'nets.

cheers.

In article <MvHbAAB$xjaCFwx+@onasticksoftware.net>, jon bird
<(E-Mail Removed)> writes
>In article <(E-Mail Removed) .com>, prg
><(E-Mail Removed)> writes
>>
>>jon bird wrote:
>>> Hi,
>>>
>>> Got a Linux box, fairly old SuSE 6,4 job with 3 network cards all of
>>> which are internal LANS - as follows:
>>
>>Hope your Samba is a _lot_ more current than this Suse version. What
>>is it?
>>
>no, its the original version - 2.06 with kernel 2.2.19. Yes, a bit old I
>know but don't really want to start upgrading things since for the most
>part everything works.
>
>>
>>Do you mean WINS only registers 192.168.0.99? It's common for
>>multi-homed machines to only successfully register the first request.
>>Is that what you think is happening? Errors? Logs?
>>
>Ok, this is what I see on the WINS (Samba) server on the 192.168.0.x
>subnet:
>
>Apr 23 13:01:59 fridge kernel: martian source 192.168.0.200 from
>192.168.1.99, on dev eth0
>Apr 23 13:01:59 fridge kernel: ll header:
>00:10:b5:40:d7:ea:00:50:bf:d7:81:a5:08:00
>Apr 23 13:01:59 fridge kernel: martian source 192.168.0.200 from
>192.168.2.99, on dev eth0
>Apr 23 13:01:59 fridge kernel: ll header:
>00:10:b5:40:d7:ea:00:50:bf:d7:81:a5:08:00
>
>This tells me that there are packets going out on this subnet which
>shouldn't be there - hence they get ignored.
>
>>Not sure what you mean here by "out ... on the wrong subnet". The
>>registrations are to a server on the 192.168.0.0 subnet, so naturally
>>the datagrams are routed that way.
>>
>true - but they shouldn't originate from an IP address not on that
>subnet - a packet trace shows:
>
>Frame 191 (110 bytes on wire, 110 bytes captured)
>
>Internet Protocol, Src Addr: 192.168.1.99 (192.168.1.99), Dst Addr:
>192.168.0.200 (192.168.0.200)
> Version: 4
> Header length: 20 bytes
>[...]
>NetBIOS Name Service
> Transaction ID: 0x3ebd
>[...]
> Additional records
> TOASTER<20>: type NB, class inet
> Name: TOASTER<20> (Server service)
> Type: NB
> Class: inet
> Time to live: 3 days
> Data length: 6
> Flags: 0x4000 (M-node, unique)
> 0... .... .... .... = Unique name
> .10. .... .... .... = M-node
> Addr: 192.168.1.99
>
>>> what I would expect is to see the 3 packets as follows:
>>>
>>> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
>>> 0.99)
>>> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
>>> 1.99)
>>> 192.168.0.99 -> 192.168.0.200 - Multi-homed registration (registers
>>> 2.99)
>>
>
>>Why? What protocol are these packets (real and presumed)? What do you
>>think "source" means here? I assumed that they are the source IP of
>>the registration request, ie., the IP that is to be mapped to NetBios
>>name. It's been several years since I've looked at SMB packets. Is
>>that what these are?
>>
>well in the context above, I would expect to see the packet originate
>from 192.168.0.99 - it's the address (in the packet data) I presume it's
>trying to register rather than using the originating IP.
>
>>> Can't believe this is a Samba problem ...
>>
>>I'm not sure what the "problem" is that you're referencing, other than
>>that some packet fields hold IP values you do not expect? Are you
>>experiencing connection/browsing problems? Errors in logs? What?
>>
>>> ... because having written some socket
>>> based software you don't ever specify your source IP address because
>>the
>>> OS does that so I'm confused as to why it does this.
>>
>>I'm not sure what sockets programming has to do with the above
>>captures. Your Linux machine must register three IPs to what NetBios
>>name? A group name? Unique name(s)?
>>
>Principally because from an application point of view I've not seen
>anything that lets you specify the originating IP address - that's a
>given. You would specify the destination IP address and let the OS worry
>about how/which interface it routes it on. Thus I can't see why this
>problem is in the Samba application, it feels more like a routing
>problem.
>
>>Multi-homed boxes often cause headaches with SMB networking. Are you
>>having any?
>>
>not really got that far yet..... Might not work anyway, wouldn't be
>surprised if it didn't considering the age of one of the machines but
>just confused as to why this is happening.
>
>>It's just not clear to me what the nature of your problem really is.
>>It could be me -- it's Friday Clarify?
>>
>hopefully its as clear as mud now......
>
>rgs,
>
>
>j.

--
== jon bird - software engineer
== <reply to address _may_ be invalid, real mail below>
== <reduce rsi, stop using the shift key>
== posted as: news 'at' onastick 'dot' clara.co.uk