[jcifs] "A duplicate name exists on network" when a host has multiple names

[Andrew Miller]

I'm not that psyched about this workaround, but here's how I got it
working.  I'm not going to post an exact diff because I do not believe
that this is a patch that should be directly applied.  Ideally,
someone who really understands the code should try to address this
somewhere within the smb package.

In NtlmHttpFilter.java, in the two places where this line occurs:

                dc = UniAddress.getByName( domainController, true );

replace with the following two lines:

                dc = UniAddress.getByName( domainController, true );
                dc = UniAddress.getByName( dc.getHostAddress(), true );

Here's why I think this works based on poking around the source and
why some addresses, including IP addresses, were working fine.

UniAddress wraps either an NbtAddress or an InetAddress.  An
NbtAddress is used if UniAddress.getByName determines it is an IP
address or WINS, LMHOSTS, or BCAST name.  An InetAddress is used if it
is a DNS name.

The "duplicate name" errors were occurring when I was attempting to
use a DNS name.  It worked fine for me with an IP address or WINS
name.

The second line of code forces UniAddress to wrap an NbtAddress based
on the IP address it resolved using DNS.

I hope this makes sense.  I'm happy to discuss this further.

--Andy


On 11/29/05, Andrew Miller <pulazzo at gmail.com> wrote:
> I have seen the error described in several deployments since upgrading
> from 0.7.19 (very old I know) to 1.2.6.  In each case I have either
> used a different hostname or used an IP address, but we're about to
> begin a wider release and am not looking forward to the support calls
> this may trigger.
>
> I am working to reproduce the error in my test environment, but it is
> proving a bit difficult given my setup.  If you know what is causing
> this and can suggest a fix, I would be grateful.
>
> --Andy
>
> On 10/17/05, Praveen Tammana <a10pkt8 at gmail.com> wrote:
> > On 10/17/05, Michael B Allen <mba2000 at ioplex.com> wrote:
> >
> > > On Mon, 17 Oct 2005 10:45:03 -0700
> > > Praveen Tammana <praveen.public at gmail.com> wrote:
> > >
> > > > On 10/17/05, Michael B Allen < mba2000 at ioplex.com> wrote:
> > > > >
> > > > > On Mon, 17 Oct 2005 01:32:08 -0700
> > > > > Praveen Tammana <praveen.public at gmail.com> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am working with 1.2.1 and I am getting errors when working with a
> > host
> > > > > > that has multiple names. (eg: deathstar = zpac23 =
> > > > > > 172.25.181.23 <http://172.25.181.23><http://172.25.181.23>).
> > > > > > For example, when I run the ListFiles example:
> > > > > >
> > > > > > java ListFiles smb://deathstar/ ------- works
> > > > > > java ListFiles smb://zpac23/ ------- does not
> > > > > > java ListFiles smb://172.25.181.23/ ------- works
> > > > >
> > > > > Where exactly does it fail? What's the exception?
> > > >
> > > >
> > > > Forgot to add the stack trace, sorry 'bout that.
> > > >
> > > > Exception in thread "main" jcifs.smb.SmbException: A duplicate name
> > exists
> > > > on the network.
> > > > at
> > jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:456)
> > > > at jcifs.smb.SmbTransport.send (SmbTransport.java:556)
> > > > at
> > jcifs.smb.SmbSession.sessionSetup(SmbSession.java:263)
> > > > at jcifs.smb.SmbSession.send(SmbSession.java:220)
> > > > at jcifs.smb.SmbTree.treeConnect(SmbTree.java:137)
> > > > at jcifs.smb.SmbFile.connect (SmbFile.java:791)
> > > > at jcifs.smb.SmbFile.connect0(SmbFile.java:761)
> > > > at jcifs.smb.SmbFile.send(SmbFile.java:660)
> > > > at jcifs.smb.SmbFile.doNetEnum(SmbFile.java:1619)
> > > > at jcifs.smb.SmbFile.listFiles (SmbFile.java:1568)
> > > > at jcifs.smb.SmbFile.listFiles(SmbFile.java:1478)
> > > > at ListFiles.main(ListFiles.java:17)
> > >
> > > This is coming from the server. I don't think there's any way around
> > > this. I think other CIFS clients will give you the same error. If you try
> > > another client and it does not give you the error using the name zpac23
> > > then get a packet capture and we can see how it's avoiding the problem.
> >
> >  That sounds bad.  I'll try some other clients and see if they work.
> >
> >  Thanks
> >  -Praveen
> >
> > > Mike
> > >
> >
> >
>