Trying to figure out why redirect host is showing up in my ping

[nosenseatall]

I've been trying to diagnose a printer problem over the last couple of days and still can't figure out what is going on. When I send something to the printer it starts by printing a couple of lines and then stops. There is a message on the screen "receiving data" but it never finishes the print job. It only happens from one specific host all other host can send and print normally with no issues.

My printer is wireless and connected to the AP with an address of 192.168.80.118. My computer is connected to the AP with an address of 192.168.80.101. As I was trying to solve the problem I ran some pings. When I ping any host other than the printer I get normal looking return

but when I ping the printer at .118 it looks different with some verbiage about "Redirect Host".

Is it possible that this redirect has something to do with why the print jobs are failing from host at .101? At one point I was trying to solve a different issue and set my computer to a static ip address (DHCP with manual address) and not sure if when I changed it back to just DHCP caused the problem.

The AP is pulling its IP address from pfSense, which has its own interface assignment at em4. I also logged in to AP and didn't see anything abnormal since it is in AP mode.

Any suggestions or help would be great as I can't print anything at the moment.

[JKnott]

@nosenseatall

This is a time when Wireshark or Packet Capture come in handy, to see what's actually happening on the wire.

[stephenw10]

Make sure everything has the same subnet mask set. It is behaving as though it's sending those pings to its default gateway which is presumably the 'AP' at 192.168.80.1. Though that must in fact be a router. It should be pinging the printer directly if they are in the same subnet.

Make sure the AP allows direct connections between clients, they often have an option to block that.

Steve

[nosenseatall]

@jknott I do happen to have a Wireshark capture. I don't have enough experience yet to analyze exactly what it is saying. There is more history to the capture than what I have posted, but here are 2 different spots.

Thank you for your help!

[JKnott]

@nosenseatall said in Trying to figure out why redirect host is showing up in my ping:

I do happen to have a Wireshark capture. I don't have enough experience yet to analyze exactly what it is saying. There is more history to the capture than what I have posted, but here are 2 different spots.

Please upload the actual capture. It contains a lot more info than a screen capture.

[nosenseatall]

@stephenw10 The DHCP server in pfSense for 192.168.80.0 subnet shows 255.255.255.0. The .101 and .118 hosts are on that same subnet.

[nosenseatall]

@jknott OK I just recaptured the info again, but it will take me a minute to figure out how to filter out all of the other chatter and provide specifics for .101 and .118 hosts.

[johnpoz]

That redirect screams of mask mismatch..

Or bad arp, or bad routing.. If your client is in the same network, it should never send traffic to 80.1

I take it your client is windows?

Can we see output of ipconfig /all
arp -a after you have pinged 192.168.80.118

And route print output

[JKnott]

@nosenseatall

With Wireshark, you can filter on IP, MAC or protocol or some combo of those, as needed.

[johnpoz]

Yeah your not going to want to filter too much, you would need to see the traffic going to 80.1 as the redirect.

Your screenshot don't show any answers at all.

[nosenseatall]

Here is the full capture. Sorry in advance if it is too much info, but I don't have the knowledge on what to filter and how, so that those of you that are helping only get what you need.

printer_capture_01272021.pcapng

[johnpoz]

Ok looking at it for 2 seconds.. Can say yeah your sending traffic to your gateway that you shouldn't

You can see the mac of where your sending the data, is not the mac of the .118 box

And that is the mac of your gateway. See where your sending traffic to what is clearly not your network the 143.244 address - its going to your gateway..

Let me comb through it a bit more.. But yeah the redirect is clearly sent - why your sending traffic to 80.1 when your trying to talk to 80.118 which should be on your network..

Can we see the output of your ipconfig to validate mask..

[johnpoz]

Why do you have traffic going to 1337

https://www.speedguide.net/port.php?port=1337

That wireshark is saying is wireguard? Are you using some a vpn client on this .101 box?

[nosenseatall]

@johnpoz Yes I am using PIA VPN locally on .101. Also I don't know why what the port 1337 traffic is.

[johnpoz]

Turn that OFF!!! Bet you your redirects go away..

[JKnott]

@johnpoz

I also see a redirect, in packet 451, coming from the gateway, which means the original packet is being sent to it. According to the message, the source was 192.168.80.101 and the destination .118. The packet in 450 shows a destination IP of .118, but the MAC shows the gateway. So, that means the sending device thinks the destination is off the local network and so is forwarding packets for it via the gateway.

[johnpoz]

@nosenseatall said in Trying to figure out why redirect host is showing up in my ping:

Also I don't know why what the port 1337 traffic is.

That is the vpn service using a port that they shouldn't be for that protocol..

https://www.privateinternetaccess.com/helpdesk/kb/articles/understanding-the-wireguard-protocol
A WireGuard connection, therefore, requires connectivity to both TCP 1337 and UDP 1337 on the VPN server.

[stephenw10]

Yup, looks like they are adding some BS route.

Try running a route print on the Windows client there with the VPN connected and not connected. See what they are actually adding.

VPN providers; discuss....

Steve

[nosenseatall]

@johnpoz Thank you very much. That fixed the issue. I have no clue why it started malfunctioning. I have used PIA on WireGuard for a while and have not had any problems until recently. At any rate I have uninstalled and will try a fresh install and see if the problem comes back.

Once again thank you for help.

[nosenseatall]

@johnpoz @JKnott @stephenw10 Thank you all for help. This issue was resolved with @johnpoz suggestion of turning off the VPN.