You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently using Mac OS X 10.10, and it seems that comcast has some critical limitations that should probably be mentioned (or fixed if possible?)
The biggest one seems to be that upstream is not affected, only downstream. Both --packet-loss and --target-bw only seem to affect data received on the network device, and not data sent. This looks deliberate from 'dummynet in all pipe 1' | sudo pfctl -a mop -f - and no mention of "out". (Well, there is mention of both "src-ip" and "dst-ip" in the following dnctl rules. And maybe dummynet is supposed to apply to both directions. But it definitely doesn't work.) It should probably be mentioned somewhere in the README?
Another thing is that the downstream seems to be affected for all ip addresses, not just the --target-addr (even though I do see the target-addr mentioned in the rules applied).
My tests: I'm working on a webrtc server-side headless peer thingie (a gateway) and monitoring NACKs (packet losses) under various video bitrates and conditions in each direction. I also threw in a quick dslreports.com/speedtest run when I suspected that the --target-addr was not the only one affected by --target-bw.
Here's some more info in case it helps:
[pierce@plo-pro sysop]$ sudo dnctl list
00001: 600.000 Kbit/s 0 ms 50 sl. 2 queues (64 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000034/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
mask: 0x00 0x00000000/0x0000 -> 0x00000034/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
48 ip 0.0.0.0/0 0.0.0.48/0 11 1184 0 0 0
52 ip 0.0.0.0/0 0.0.0.52/0 2 126 0 0 0
[pierce@plo-pro sysop]$ sudo pfctl -sa
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat-anchor "com.apple/*" all
rdr-anchor "com.apple/*" all
FILTER RULES:
scrub-anchor "com.apple/*" all fragment reassemble
anchor "com.apple/*" all
anchor "mop" all
DUMMYNET RULES:
dummynet-anchor "com.apple/*" all
dummynet-anchor "mop" all
INFO:
Status: Enabled for 0 days 00:00:11 Debug: Urgent
State Table Total Rate
current entries 0
searches 2188637 198967.0/s
inserts 0 0.0/s
removals 0 0.0/s
Counters
match 809773 73615.7/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 0 0.0/s
normalize 0 0.0/s
memory 0 0.0/s
bad-timestamp 0 0.0/s
congestion 0 0.0/s
ip-option 295 26.8/s
proto-cksum 0 0.0/s
state-mismatch 0 0.0/s
state-insert 0 0.0/s
state-limit 0 0.0/s
src-limit 0 0.0/s
synproxy 0 0.0/s
dummynet 671538 61048.9/s
I must admit that I was hoping "comcast" would prevent me from needing to figure out any of this OS X firewall+traffic-control stuff 😁
The text was updated successfully, but these errors were encountered:
I'm currently using Mac OS X 10.10, and it seems that comcast has some critical limitations that should probably be mentioned (or fixed if possible?)
The biggest one seems to be that upstream is not affected, only downstream. Both --packet-loss and --target-bw only seem to affect data received on the network device, and not data sent. This looks deliberate from
'dummynet in all pipe 1' | sudo pfctl -a mop -f -
and no mention of "out". (Well, there is mention of both "src-ip" and "dst-ip" in the following dnctl rules. And maybe dummynet is supposed to apply to both directions. But it definitely doesn't work.) It should probably be mentioned somewhere in the README?Another thing is that the downstream seems to be affected for all ip addresses, not just the --target-addr (even though I do see the target-addr mentioned in the rules applied).
My tests: I'm working on a webrtc server-side headless peer thingie (a gateway) and monitoring NACKs (packet losses) under various video bitrates and conditions in each direction. I also threw in a quick dslreports.com/speedtest run when I suspected that the --target-addr was not the only one affected by --target-bw.
Here's some more info in case it helps:
I must admit that I was hoping "comcast" would prevent me from needing to figure out any of this OS X firewall+traffic-control stuff 😁
The text was updated successfully, but these errors were encountered: