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
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
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
edited 19 Sep '12, 05:03