query_name_response: Multiple responses received

[Mac]

Howdy,

>>For the dual homed (and additional virtual interfaces) machine, 
>>surely the nmbd is samrt enough only to send out any given response 
>>packet onto any given subnet exactly once, no matter how many 
>>interfaces it has open to it?  To do otherwise is surely nonsense.
>
>Ok.

Thanks.  That's clearer now.


>>So, assuming it _is_ doing that, where is the extraneous response 
>>coming from?
>
>It comes from the extraneous request nmbd receives. :-)

[comprehensive explanation removed for brevity]

>Well, you could say, nmbd has two feet in the physical network, one in
>logical network 1.2, the other in the logical network (lets say) 3.4.
>So why should interface 3.4.x.x answer to requests to 1.2.255.255?
>Shouldn't it really know it can't be meant?

Absolutely it should.  Especially when it's already got an interface
onto the 1.2.0.0 network.  Blatant nonsense for it to do otherwise.
What's even more nonsensical is that this additional request packet it
recevied on the 3.4.0.0 network is replied to by sending a response to
the 1.2.0.0 network!


>I think this has to do with nmbd being not unnecessarily silent to
>stations in other logical networks probably behind routers. A stroll
>through the sources may give an authoritative answer. :-)

I'm no code expert, but in principle, the handling of broadcasts should
always be restricted to the local broadcast doamin ('remote announce ='
notwithstanding)

>>With two subnets on the same wire, a machine in only one of the 
>>subnets with a lousy IP stack might see the broadcasts from the other 
>>subnet, and log them  (older versions of SunOS did this) but even 
>>this doesn't explain why two identical packets arrive.
>
>I don't think broadcasts from another logical net are suppressed at the
>kernel level. I can see such packets with tcpdump on a Linux machine
>and most people won't argue Linux has a lousy IP stack.

Does tcpdump sniff the packets as they arrive at the interface, or as
the kernel processes them?  Can tcpdump see spoofed IP packets (such as
a TCP packet with ACK set that doesn't correspond to an exisiting
connection)?.  Such a packet would be discarded by the kernel (since it
has no connection to match it with, but would be of great interest to a
packet dumper).


>With "netstat -an" I can see nmbd listens with "*.137", so no way for
>the kernel to decide "nmbd should not see that packet".

For _directed_ broadcasts it can make the decision already, if a packet
(albeit a MAC-level broadcast) arrives at interface 3.4.X.X but it's
addressed to 1.2.255.255, surely it should be binned regardless?


>>The dual-homed machine must have sent two identical packets, 
>
>_nearly_ identical.

If they're not identical, why is the single-homed machine complaining
about duplicates?

And anyway, what's the difference between them?


>>_on_the_same_subnet_, and it's this behaviour that I can't fathom.
>
>It has and I think its ok to do so ... the switch "doubled" the request
>packet.

Indeed.  The switch behaves correctly (it's a MAC level broadcast so,
unless it's a level 3 switch which understands IP broadcasts etc. and
it's using that info too, it has to duplicate the packet).

My problem is with nmbd (or the kernel) which reacts to a packet not
addressed to it.


                               Mac
          Assistant Systems Adminstrator @nibsc.ac.uk
                        dmccann at nibsc.ac.uk
   Work: +44 1707 654753 x285      Everything else: +44 7956 237670 (anytime)