F5F Stay Refreshed Software Operating Systems DSCP guidelines don't apply to TCP. Identical settings functioned prior to the system update.

DSCP guidelines don't apply to TCP. Identical settings functioned prior to the system update.

DSCP guidelines don't apply to TCP. Identical settings functioned prior to the system update.

C
CloseToToast
Member
Find
125
07-30-2016, 02:42 PM
#1
I apply these guidelines to assign tags to packets from browsers for easier distinction in your pfSense rules. No modifications were made to pfSense itself. Wireshark displays only UDP traffic with the tags.
Reply
Reply
C
CloseToToast
07-30-2016, 02:42 PM #1

I apply these guidelines to assign tags to packets from browsers for easier distinction in your pfSense rules. No modifications were made to pfSense itself. Wireshark displays only UDP traffic with the tags.

Reply
Reply
J
jonipaok123
Junior Member
Find
11
08-01-2016, 12:22 PM
#2
Have you attempted to switch off your router and then restart it?
Reply
Reply
J
jonipaok123
08-01-2016, 12:22 PM #2

Have you attempted to switch off your router and then restart it?

Reply
Reply
Y
yDropped
Junior Member
Find
10
08-01-2016, 03:32 PM
#3
The issue isn't related to the router. Windows isn't identifying the packets correctly. The Wireshark capture exists for a valid reason. I'm certain the CS1/8 marking functions on the router side, since I have a comparable Linux setup nearby. Updated: New-NetQosPolicy -Name "Edge_Mark_Traffic" -AppPathNameMatchCondition "msedge.exe" -PolicyStore ActiveStore -DSCPAction 8 -IPProtocolMatchCondition "Both" works, though I prefer the gpedit method over this one because it's more complex to manage. Update2 Rule is removed after reboot. Update3 is a major Windows troubleshooting challenge. I shouldn't have reinstalled it. Update4 points to Microsoft's side. The command used is persistent: New-NetQosPolicy -Name "MS-Edge_PBR_Tag" -AppPathNameMatchCondition "APPNAME.EXE" -PolicyStore YOURPCNAME -DSCPAction 8 -IPProtocolMatchCondition "Both".
Reply
Reply
Y
yDropped
08-01-2016, 03:32 PM #3

The issue isn't related to the router. Windows isn't identifying the packets correctly. The Wireshark capture exists for a valid reason. I'm certain the CS1/8 marking functions on the router side, since I have a comparable Linux setup nearby. Updated: New-NetQosPolicy -Name "Edge_Mark_Traffic" -AppPathNameMatchCondition "msedge.exe" -PolicyStore ActiveStore -DSCPAction 8 -IPProtocolMatchCondition "Both" works, though I prefer the gpedit method over this one because it's more complex to manage. Update2 Rule is removed after reboot. Update3 is a major Windows troubleshooting challenge. I shouldn't have reinstalled it. Update4 points to Microsoft's side. The command used is persistent: New-NetQosPolicy -Name "MS-Edge_PBR_Tag" -AppPathNameMatchCondition "APPNAME.EXE" -PolicyStore YOURPCNAME -DSCPAction 8 -IPProtocolMatchCondition "Both".

Reply
Reply