Hello and thank you for reading my post. Here is my problem:
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: 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:
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éa Massiot |
2 Answers:
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 Aragon |
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 ♦♦ edited 19 Sep '12, 05:03 Hello and thank you for your answer.
Really? Why is the "Source port" changing endlessly (by increments of 1)?
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.
Indeed, it looks like there is a checksum problem:
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
As Jasper said. That’s most certainly status monitoring traffic.
Well, there is a lot of ‘useless’ traffic on a standard network ;-) Those few bytes won’t cause any trouble.
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 ♦
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 |
Ok then. Thank you very much for these very interesting and detailed information :) Best regards.