TR Forums

I have never seen this one before.

We have:
- Computer A (the problem one), running Windows 8
- Computer B, running Windows 8.1
- Some Samsung printer that is networked
- Everything wired (there are computers on the LAN as well)
- All using static IP, within the same class C network

Problem:
- A cannot ping the printer, and trying to ping resulted in error. The Samsung printer management software was able to find the printer for some reason (using network broadcast?)
- A can ping B
- B can ping A
- B can ping the printer, and most certainly can print to it
- Tests ran with all firewalls disabled
- Tried swapping network cables, no dice
- Tried plug A directly into printer (static IPs anyway), still no go
- All using numbered addresses, nothing to do with DNS/netbios we think.

So we were scratching our heads wondering what else to try next... Then, I said, "let's try switching the printer's IP just for kicks". And then everything works, printer was pingable from A and B, printing for both machines were fine. This is weird.

Can someone make any sense out of this?

That is weird. We have a Samsung printer so I feel your pain. It's actually working quite fine, probably the most trouble-free printer we have, just an oddball. The software finds the printer based on MAC address, so not IP based. You can assign it an IP from there, obviously. I'm going to say IP conflict?

Flying Fox wrote:

Can someone make any sense out of this?

Right off-hand, I can't think of why, but then again, I've seen plenty of oddball stuff in the field, so...

just for grins, can you share the IP/mask of the device? You doing CIDR vs classful? Did the printers MAC ever show up in A's ARP table? Think there's an issue with just Win8 as opposed to 8.1? I haven't used it much, so I dunno about what the changes were beyond the whole desktop boondoggle.

drsauced wrote:

That is weird. We have a Samsung printer so I feel your pain. It's actually working quite fine, probably the most trouble-free printer we have, just an oddball. The software finds the printer based on MAC address, so not IP based. You can assign it an IP from there, obviously. I'm going to say IP conflict?

You'd think it would've thrown an error, if there was a conflict. And wrkstn B *could* print from it, so...

*shrugs*

I say blame it all on neutrinos, and be done with it, since changing IPs seemed to resolve the problem. That is, if no other station reports being unable to print. Then I'd firmly affix my tinfoil hat and start looking around for a rogue DHCP server or something.

First thought would be wrong netmask on either A or the printer.

Hz so good wrote:

just for grins, can you share the IP/mask of the device? You doing CIDR vs classful?

The computers and printer are all 192.168.3.x, with netmask 255.255.255.0 typical of class C networks. Not too sure about CIDR vs classful. The computers are running Windows so can't do "/24" anyways. Printer's configuration screen is the same.

Hz so good wrote:

Did the printers MAC ever show up in A's ARP table? Think there's an issue with just Win8 as opposed to 8.1? I haven't used it much, so I dunno about what the changes were beyond the whole desktop boondoggle.

That's the speculation (something messed up with ARP) we had after we got everything working. I have discounted 8 vs 8.1 since ping worked from B to printer. Now that stuff is working we are not going to go back and break it.

Hz so good wrote:

drsauced wrote:

That is weird. We have a Samsung printer so I feel your pain. It's actually working quite fine, probably the most trouble-free printer we have, just an oddball. The software finds the printer based on MAC address, so not IP based. You can assign it an IP from there, obviously. I'm going to say IP conflict?

You'd think it would've thrown an error, if there was a conflict. And wrkstn B *could* print from it, so...

Since B can ping and print, to me that killed the theory of IP conflict?

Hz so good wrote:

Then I'd firmly affix my tinfoil hat and start looking around for a rogue DHCP server or something.

Everything static IP, no computers with server OS.

TwistedKestrel wrote:

First thought would be wrong netmask on either A or the printer.

Fairly certain they are correct. Besides, how do you explain how B could ping A and B could print and ping to printer if the netmask is wrong?

Ugh, printer problems. The primary cause of PTSD amongst competent sysadmins.

Captain Ned wrote:

Ugh, printer problems. The primary cause of PTSD amongst competent sysadmins.

Gah! Wait, did you hear that? I thought I heard something printing. Shh. Phew. Just the toilet flushing. For a minute there...

Flying Fox wrote:

Everything static IP, no computers with server OS.

I've been in environments like that, and had someone add a device that "unknowingly" had a DHCP server handing out the same scope of IPs. I would've believed that person, except we weren't using any of the standard addressing you'd normally expect.

*shrug*

/Sometimes stuff just happens. Mark it down, and move on. If it pops up again, TAKE COPIUS NOTES, especially for those of us in the class that can't be there in person.

What's the error returned by the A -> Printer ping?

SuperSpy wrote:

What's the error returned by the A -> Printer ping?

Your usual "request time out" as if the node is totally not there.

(I missed the 'change printer IP and everything automagically started working part of your OP)

That does make it sound more like broken ARP data on A, but I was under the impression that stuff is cleared on a reboot.

If it's ARP issues, it could be down to something as innocuous as a badly-behaving switch between A and the printer, but not B.

A bad netmask will cause issues like what you describe. If the printer's netmask was typo'd such that B was within the configured subnet and A was "outside" it, then the printer would send all responses to A to its configured default gate, if it had one. What is the last octet of the IP address of the two computers?

--SS

SecretSquirrel wrote:

A bad netmask will cause issues like what you describe. If the printer's netmask was typo'd such that B was within the configured subnet and A was "outside" it, then the printer would send all responses to A to its configured default gate, if it had one. What is the last octet of the IP address of the two computers?

The last octet of subnet mask (I believe) should be 0, as we used defaults from the UI which almost always assume class C style /24 networks. Or did you mean the last octet IP addresses? Well, A was 102, B was 104 (?), and printer was 107 before when it had issues, 99 after we changed it.

We have seen similar behavior when the IP address had previously been used by another device on that computer.
That may be why changing the printer IP address solved the issue.