This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Bad packets - UDP port incrementing - Network Canon printer

0

Hello and thank you for reading my post.

Here is my problem:

  • My PC IP address is x.y.z.w1.
  • On the same LAN, I have a Canon printer which IP address is x.y.z.w2.
  • When I observe the traffic on my PC network interface using Wireshark, I observe lots of packets like these:

No.  Time         Source    Destination Protocol Length Info
---------------------------------------------------------------------------------------------------------
1    0.000000000  x.y.z.w1  x.y.z.w2    UDP      154    Source port: 57101  Destination port: canon-mfnp
3    4.003164000  x.y.z.w1  x.y.z.w2    UDP      154    Source port: 57102  Destination port: canon-mfnp
5    8.006314000  x.y.z.w1  x.y.z.w2    UDP      154    Source port: 57103  Destination port: canon-mfnp
7   12.009452000  x.y.z.w1  x.y.z.w2    UDP      154    Source port: 57104  Destination port: canon-mfnp
10  16.012623000  x.y.z.w1  x.y.z.w2    UDP      154    Source port: 57105  Destination port: canon-mfnp
---------------------------------------------------------------------------------------------------------

and it goes on and on like this with the source port incrementing.

The colouring rules indicate "Bad TCP" packets (in this case UDP packets).

I also have "good" packets like this one:

---------------------------------------------------------------------------------------------------------
No.  Time         Source    Destination Protocol Length Info
---------------------------------------------------------------------------------------------------------
4    4.004840000  x.y.z.w2  x.y.z.w1    UDP      74     Source port: canon-mfnp  Destination port: 53724
---------------------------------------------------------------------------------------------------------

I don't really understand what it means, I just know they are bad packets.

Nonetheless, I've tried adding a rule (an outbound rule) in my Windows firewall:

  • applying to UDP
  • for all remote ports
  • for domain and private use
  • for the IP x.y.z.w2 ("Scope" -> "Local IP address").

It hasn't changed anything. Can you see what the problem is?

Thank you for helping and best regards.

asked 19 Sep '12, 04:40

L%C3%A9a%20Massiot's gravatar image

Léa Massiot
1112
accept rate: 0%


2 Answers:

2

The packets are four seconds apart. The source port numbers are changing because the application considers each transmission to be a separate and distinct communication, not part of an ongoing session, so it's selecting a new source port number instead of re-using a recently used port number. No, the PC is not looking for a suitable UDP port. Whatever ephemeral source port the PC chooses for the communication is a suitable port. All that matters is that the destination port is the correct port that the printer is listening to.

To see what coloring rule a packet matched, expand the Frame section in the Packet Details pane and look for "Coloring Rule Name". Two different coloring rules might use the same colors, so you can't tell what coloring rule was matched simply by looking at the colors under "View > Coloring Rules." Since these are UDP packets, by definition they can't be "Bad TCP."

You probably don't have a checksum problem. Most modern NICs/PCs implement checksum offloading, meaning that the checksum is calculated by the NIC, not by the operating system. The checksum has not been calculated when Wireshark sees the packet, but the checksum will be correct when the packet is transmitted onto the wire. The clues that checksum offloading is in use are: 1) the bad checksum is 0x0000 and not some random value, and 2) the checksum error only appears on outgoing packets. Checksum errors are usually cosmetic errors that can be disregarded. Many of us disable checksum validation or disable the Checksum Errors coloring rule.

You don't need to add a firewall rule. The traffic was already getting through, so the firewall was not blocking it.

I agree with @Jasper. This is normal PC-to-printer traffic initiated by the printer driver.

answered 20 Sep '12, 13:52

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

Ok then. Thank you very much for these very interesting and detailed information :) Best regards.

(21 Sep '12, 01:24) Léa Massiot

1

I guess this is just normal PC-to-Printer traffic, usually initiated by the printer driver, and containing printer status requests, like toner/ink status etc. I don't think these are bad packet, just a little chatty maybe. And how do you know the coloring is "Bad TCP"? Did you compare color schemes, or did you look at the first section in the frame decode? There is a line in there telling you which color rule matched. My guess is that the UDP checksum is incorrect, but that is not a problem. It is usually caused by the way you capture the packets on the affected system, and UDP checksums do not have to be correct anyway (unless we're talking about IPv6).

answered 19 Sep '12, 05:00

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 19 Sep '12, 05:03

Hello and thank you for your answer.

Quote Jasper: I guess this is just normal PC-to-Printer traffic, usually initiated by the printer driver, and containing printer status requests, like toner/ink status etc.

Really? Why is the "Source port" changing endlessly (by increments of 1)?

Quote Jasper: And how do you know the coloring is "Bad TCP"?

I compared the color schemes from the "View" -> "Colouring Rules..." Wireshark menu: (sort of) salmon foreground + black blackground. These are the "out of the box" Wireshark settings, I didn't change anything.

Quote Jasper: My guess is that the UDP checksum is incorrect

Indeed, it looks like there is a checksum problem:

Frame 1001: 154 bytes on wire (1232 bits), 154 bytes captured (1232 bits) on interface 0
Interface id: 0
WTAP_ENCAP: 1
Arrival Time: Sep 20, 2012 13:48:53.158749000 Pacific Daylight Time
Time shift for this packet: 0.000000000 seconds
Epoch Time: 1348174133.158749000 seconds
Time delta from previous captured frame: 0.850133000 seconds
Time delta from previous displayed frame: 0.850133000 seconds
Time since reference or first frame: 284.812729000 seconds
Frame Number: 1001
Frame Length: 154 bytes (1232 bits)
Capture Length: 154 bytes (1232 bits)
Frame is marked: False
Frame is ignored: False
Protocols in frame: eth:ip:udp:data
Coloring Rule Name: Checksum Errors
Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || sctp.checksum_bad==1 || mstp.checksum_bad==1
[...]
Internet Protocol Version 4, Src: 192.168.2.240 (192.168.2.240), Dst: 192.168.2.65 (192.168.2.65)
[...]
Header checksum: 0x0000 [incorrect, should be 0x84c2 (may be caused by "IP checksum offload"?)]
[...]

User Datagram Protocol, Src Port: 50683 (50683), Dst Port: canon-mfnp (8610) […] Checksum: 0x870b [validation disabled] Good Checksum: False Bad Checksum: False […]

Quote Jasper: It is usually caused by the way you capture the packets on the affected system

On the printer or on the PC?

Do you have any idea why all these packets are being sent all the time with the “Source port” incrementing? I mean, it looks like a lot of useless traffic on the LAN… And also, it looks like it (the PC) is trying to find a suitable UDP port, don’t you think?

Thank you and best regards.

(20 Sep ‘12, 06:21) Léa Massiot

A few packets every few seconds isn’t something to worry about (in the big scheme of things). SRC port incrementing could be a bug or the way the app works. It wants to open multiple connections for some reason.

(21 Sep ‘12, 14:18) hansangb

Quote Léa Massiot: Do you have any idea why all these packets are being sent all the time with the “Source port” incrementing?

As Jasper said. That’s most certainly status monitoring traffic.

I mean, it looks like a lot of useless traffic on the LAN…

Well, there is a lot of ‘useless’ traffic on a standard network ;-) Those few bytes won’t cause any trouble.

And also, it looks like it (the PC) is trying to find a suitable UDP port, don’t you think?

it’s probably just using a different socket every 4 seconds. That’s a bit strange, but not strange enough to worry about.

BTW: Look at the data part of the packets. What do you see there?

(22 Sep ‘12, 11:43) Kurt Knochner ♦

Kurt wrote: Look at the data part of the packets. What do you see there?

Not much (to me)… the only humanly readable part is the PC’s name.

Thank you and best regards.

(26 Sep ‘12, 02:18) Léa Massiot