My Windows 7 Media Center can’t stream to my PS3, but the Windows Media Player that’s built into the same PC can, (well it should be able to!) However when I tried, this is what the Playstation told me.
Media Server Error:
A DNLA protocol error (2104) has occurred.
Solution
Note: Your local firewall on the Windows 7 machine can also cause this problem. I have a decent firewall at home, so I disabled the local firewall on the Media Center, (Start > Run > firewall.cpl).
1. On your Windows 7 Machine open Windows Explorer (Windows Key+E) > Select Homegroup > View homegroup settings.
2. Make sure you’re set to location type Home, if not change it (mine was set to public!).
3. Now “choose what you want to share…”.
4. Select as appropriate > Next.
5. Choose Media Streaming options.
6. Allow All, (or if you know the MAC address of the Playstation it will be listed as “Unknown Device” and, (if you can see it on the list), you can add that in on it’s own, and allow).
7. Accept the warning.
8. If you allowed all, this is what you should see.
9. Finally open the services (Start > Windows key+R > services.msc {enter}) and ensure that the “Windows Media Player Network Sharing Service” Service is started > Set to Automatic > and set to logon as either the Network Service, or the Local System.
Related Articles, References, Credits, or External Links
I love packet-tracer, I use it a lot, especially when I’ve been told that the firewall I’ve installed is stopping a particular port. I had set up a simple port forward the other day, and when I went to check it with packet-tracer this happened.
This happens because the packet-tracer command is expecting to see the address that exists on the outside interface. So it’s the opposite way round to the way you would write an ACL. (Unless you are an old school Cisco tech, then it’s the same way we used to write ACL’s (before version 8.3)).
So, as I’m port forwarding the port that I’m tracing (tcp port 443 or https if you prefer) from the outside interface (100.100.100.100), that’s the IP address I should be using.
Note: If you are testing a static translation, then you would use the public IP for testing inbound traffic.
Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 5844584, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
[/box]
Do the same from the ADSM
As you can see below, the same thing happens if you use the graphical Packet Tracer in the ASDM
Related Articles, References, Credits, or External Links
After setting up some firewalls last week I quickly jumped on them whilst VPN’d into the my work network to make sure I’d be able to log into and administer them remotely via SSH, and ASDM (in case anyone else wanted to use it). SSH gave me the new certificate prompt and logged me in, ADSM logged in. I left site a happy chap.
I went to login today via SSH and I could logon fine but I could not get to enable mode?
Well that was odd? Perhaps I’d had ‘fat fingers’ when typing the enable password? I logged into the ASDM and reset it. Still the problem persisted.
Solution
After scratching my head and getting a coffee I grabbed my boss and said, watch while I reset the password, and the password does not work? “Type YOUR password in again” he said, and annoyingly, the prompt went straight to enable. “That’s not normal behavior, I said”.
Luckily I have many firewalls to jump on and comparing the configs, pointed me to the answer. I didn’t setup the AAA on this firewall, someone else did. Take a look at the line indicated;
Essentially this lets you use your user account password to get to enable mode, (caveat see below). By using MY password twice I can get to enable mode;
Caveat
The account you are using must have the correct privilege level.
Top Tip:
With newer versions of ASA code you can use the following command;
[box] aaa authorization exec LOCAL auto-enable [/box]
To, automatically log straight into privilege mode.
Related Articles, References, Credits, or External Links
Packet-tracer is a brilliant troubleshooting tool, but sometimes interpreting the output proves to be more difficult that actually fixing the problem.
If your output fails at the access-list section this is the sort of thing you will see;
[box]
Petes-ASA# packet-tracer input inside tcp 10.2.2.10 80 123.123.123.123 80----Output removed for the sake of brevity---
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Additional Information:
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
Solution
1. Re-run the packet-tracer and append the keyword ‘detailed’ on the end.
2. At this point if you are being specifically blocked by a ‘deny’ rule it should tell you like so;
[box]
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group outbound in interface inside <--
access-list outbound extended deny ip any any <--
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbb9ba040, priority=13, domain=permit, deny=true
hits=0, user_data=0xb94669e0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=any
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
3. Or you may see output like the following, this indicates you are being denied by the ‘implicit rule’.
[box]
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule<--
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbc057320, priority=11, domain=permit, deny=true
hits=8, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=any
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
If you didn’t already know,as soon as you allow one piece of traffic though an interface with an ACL, everything else is blocked, it’s called the ‘implicit deny rule’. At the end of every ACL there is a deny, so if you traffic does not match any of the rules it gets dropped. So find the ACL name and add the traffic you want to it.
[box]
Petes-ASA# show run access-group
access-group outbound in interface inside
Petes-ASA# configure terminal
Petes-ASA(config)# access-list outbound permit tcp host 10.2.2.20 host 123.123.123.123 eq 80
[/box]
It Still Does Not Work!
There is another reason, that the traffic can be blocked by the ‘Implicit Rule’ if both interfaces have the same security level like so;
[box]
Petes-ASA# show run interface
!
interface GigabitEthernet0
nameif outside
security-level 0
ip address 192.168.253.254 255.255.255.0
!
interface GigabitEthernet1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.0.0
!
interface GigabitEthernet2
nameif Partner
security-level 100
ip address 123.123.123.1 255.255.255.0
!
[/box]
To fix that you need to allow traffic between interfaces with the same security level;
