Problem Accessing a Yahoo Server with SMC2804WBRP-G Barric..

Archived from groups: comp.dcom.lans.ethernet,alt.internet.wireless (More info?)

Cannot download files, ping or tracert from Yahoo Groups file server
f4.grp.yahoofs.com through my SMC Barricade-G router and Bell Sympatico DSL.
Other Yahoo file servers (f3, f6) are accessible. Substituting my old
Linksys BEFSR11 clears the problem. Returning to the SMC restores it. I have
set no blocking addresses.

If you have the same router, please try pinging f4.grp.yahoofs.com and
f3.grp.yahoofs.com and let me know what you get.

Thanks,
Tom
13 answers Last reply
More about problem accessing yahoo server smc2804wbrp barric
  1. Archived from groups: comp.dcom.lans.ethernet,alt.internet.wireless (More info?)

    In alt.internet.wireless Tom Holden <holden_family@sympatico.ca> wrote:
    > Cannot download files, ping or tracert from Yahoo Groups file server
    > f4.grp.yahoofs.com through my SMC Barricade-G router and Bell Sympatico DSL.
    > Other Yahoo file servers (f3, f6) are accessible. Substituting my old
    > Linksys BEFSR11 clears the problem. Returning to the SMC restores it. I have
    > set no blocking addresses.

    > If you have the same router, please try pinging f4.grp.yahoofs.com and
    > f3.grp.yahoofs.com and let me know what you get.

    Okay, I bit.
    I read news from a unix ISP, and from there I can ping f4 just fine.
    At home, I have an SMC7004WFW router, and it won't ping. Times out.
    Traceroute fails after my router/gateway.

    A look in the logs:
    05/15/2004 07:45:21 **smurf** 192.168.x.x->> 66.218.66.255, Type:8, Code:0

    That site is being trapped as sending a smurf packet.
    http://www.netscan.org doesn't agree.

    Maybe SMC doesn't like the address .255 ?
    You can relax some of the intrusion detection in the SMC setup.

    http://www.smc.com/index.cfm?action=support_tools_show_FAQ&note_id=174

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8-122.5
  2. Archived from groups: comp.dcom.lans.ethernet,alt.internet.wireless (More info?)

    I have an SMC2804WBR (Barricade-G) connected to an SMC7004BR which is
    connected to my broadband connection. If I ping f4.grp.yahoofs.com from a
    client attached to the 7004 I get success. If I ping from a client attached
    to the Barricade-G (wireless or wired), I get the same result as Clarence:
    the router log shows a smurf attack. Strangely, it says the attack is
    inbound.

    Ron Bandes, CCNP, CTT+, etc.

    <dold@ProblemXAc.usenet.us.com> wrote in message
    news:c85bc6$dv9$2@blue.rahul.net...
    > In alt.internet.wireless Tom Holden <holden_family@sympatico.ca> wrote:
    > > Cannot download files, ping or tracert from Yahoo Groups file server
    > > f4.grp.yahoofs.com through my SMC Barricade-G router and Bell Sympatico
    DSL.
    > > Other Yahoo file servers (f3, f6) are accessible. Substituting my old
    > > Linksys BEFSR11 clears the problem. Returning to the SMC restores it. I
    have
    > > set no blocking addresses.
    >
    > > If you have the same router, please try pinging f4.grp.yahoofs.com and
    > > f3.grp.yahoofs.com and let me know what you get.
    >
    > Okay, I bit.
    > I read news from a unix ISP, and from there I can ping f4 just fine.
    > At home, I have an SMC7004WFW router, and it won't ping. Times out.
    > Traceroute fails after my router/gateway.
    >
    > A look in the logs:
    > 05/15/2004 07:45:21 **smurf** 192.168.x.x->> 66.218.66.255, Type:8,
    Code:0
    >
    > That site is being trapped as sending a smurf packet.
    > http://www.netscan.org doesn't agree.
    >
    > Maybe SMC doesn't like the address .255 ?
    > You can relax some of the intrusion detection in the SMC setup.
    >
    > http://www.smc.com/index.cfm?action=support_tools_show_FAQ&note_id=174
    >
    > --
    > ---
    > Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8-122.5
    >
  3. Archived from groups: comp.dcom.lans.ethernet,alt.internet.wireless (More info?)

    Ron Bandes wrote:

    > I have an SMC2804WBR (Barricade-G) connected to an SMC7004BR which is
    > connected to my broadband connection. If I ping f4.grp.yahoofs.com from a
    > client attached to the 7004 I get success. If I ping from a client attached
    > to the Barricade-G (wireless or wired), I get the same result as Clarence:
    > the router log shows a smurf attack. Strangely, it says the attack is
    > inbound.

    try comp.protocols.tcp-ip as this is an IP layer question,
    and not an ethernet layer question.

    -- glen
  4. Archived from groups: comp.dcom.lans.ethernet,alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    dold@ProblemXAc.usenet.us.com wrote:
    > In alt.internet.wireless Tom Holden
    > <holden_family@sympatico.ca> wrote:
    >> Cannot download files, ping or tracert from Yahoo Groups
    >> file server f4.grp.yahoofs.com through my SMC
    >> Barricade-G router and Bell Sympatico DSL. Other Yahoo
    >> file servers (f3, f6) are accessible. Substituting my
    >> old Linksys BEFSR11 clears the problem. Returning to the
    >> SMC restores it. I have set no blocking addresses.
    >
    >> If you have the same router, please try pinging
    >> f4.grp.yahoofs.com and f3.grp.yahoofs.com and let me
    >> know what you get.
    >
    > Okay, I bit.
    > I read news from a unix ISP, and from there I can ping f4
    > just fine.
    > At home, I have an SMC7004WFW router, and it won't ping.
    > Times out. Traceroute fails after my router/gateway.
    >
    > A look in the logs:
    > 05/15/2004 07:45:21 **smurf** 192.168.x.x->>
    > 66.218.66.255, Type:8, Code:0
    >
    > That site is being trapped as sending a smurf packet.
    > http://www.netscan.org doesn't agree.
    >
    > Maybe SMC doesn't like the address .255 ?
    > You can relax some of the intrusion detection in the SMC
    > setup.
    >
    > http://www.smc.com/index.cfm?action=support_tools_show_FAQ&note_id=174

    Right ON! The built-in Firewall is blocking access to the server. I disabled
    it and access to the server opened up for all ping, tracert and http
    download.

    Now this should not be the case, right? Is there something special about
    address .255 that would cause the Firewall to take action? Is this common to
    all Firewalls? If so, shouldn't .255 be avoided for servers?

    Tom
  5. Archived from groups: comp.dcom.lans.ethernet,alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    Tom Holden wrote:
    > dold@ProblemXAc.usenet.us.com wrote:
    >> In alt.internet.wireless Tom Holden
    >> <holden_family@sympatico.ca> wrote:
    >>> Cannot download files, ping or tracert from Yahoo Groups
    >>> file server f4.grp.yahoofs.com through my SMC
    >>> Barricade-G router and Bell Sympatico DSL. Other Yahoo
    >>> file servers (f3, f6) are accessible. Substituting my
    >>> old Linksys BEFSR11 clears the problem. Returning to the
    >>> SMC restores it. I have set no blocking addresses.
    >>
    >>> If you have the same router, please try pinging
    >>> f4.grp.yahoofs.com and f3.grp.yahoofs.com and let me
    >>> know what you get.
    >>
    >> Okay, I bit.
    >> I read news from a unix ISP, and from there I can ping f4
    >> just fine.
    >> At home, I have an SMC7004WFW router, and it won't ping.
    >> Times out. Traceroute fails after my router/gateway.
    >>
    >> A look in the logs:
    >> 05/15/2004 07:45:21 **smurf** 192.168.x.x->>
    >> 66.218.66.255, Type:8, Code:0
    >>
    >> That site is being trapped as sending a smurf packet.
    >> http://www.netscan.org doesn't agree.
    >>
    >> Maybe SMC doesn't like the address .255 ?
    >> You can relax some of the intrusion detection in the SMC
    >> setup.
    >>
    >> http://www.smc.com/index.cfm?action=support_tools_show_FAQ&note_id=174
    >
    > Right ON! The built-in Firewall is blocking access to the
    > server. I disabled it and access to the server opened up
    > for all ping, tracert and http download.
    >
    > Now this should not be the case, right? Is there
    > something special about address .255 that would cause the
    > Firewall to take action? Is this common to all Firewalls?
    > If so, shouldn't .255 be avoided for servers?

    I found that with the Firewall enabled, I had to disable "SPI and Anti-DoS
    firewall protection" found on the SMC Firewall > Intrusion Detection page in
    order to access the .255 address. I have asked SMC Tech Support to confirm
    my observations, advise whether it is a bug, and, if so, when a fix is
    expected. Should I hold my breath?

    Tom
  6. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    (comp.dcom.lans.ethernet removed)

    Tom Holden wrote:

    (snip)
    (someone wrote)

    >>Right ON! The built-in Firewall is blocking access to the
    >>server. I disabled it and access to the server opened up
    >>for all ping, tracert and http download.

    >>Now this should not be the case, right? Is there
    >>something special about address .255 that would cause the
    >>Firewall to take action? Is this common to all Firewalls?
    >>If so, shouldn't .255 be avoided for servers?

    > I found that with the Firewall enabled, I had to disable "SPI and Anti-DoS
    > firewall protection" found on the SMC Firewall > Intrusion Detection page in
    > order to access the .255 address. I have asked SMC Tech Support to confirm
    > my observations, advise whether it is a bug, and, if so, when a fix is
    > expected. Should I hold my breath?

    ..255 is special in a class C address, or any /24 address.
    As there is no way to determine the netmask from outside
    the net in question, blocking on 255 for anything but a
    class C net seems to me to be a mistake.

    It sounds like guilty whether or not proved innocent.

    -- glen
  7. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    It is definitely a mistake on SMC's part. The router has no way to know the
    subnet mask of any remote network that is not in its routing table (usually
    the case for networks across the Internet). The SMC SPI Firewall is intent
    on detecting outbound attacks as well as inbound. Maybe if they stuck to
    inbound attacks things would work better.

    Ron Bandes, CCNP, CTT+, etc.

    "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
    news:eyYpc.65273$xw3.3782562@attbi_s04...
    > (comp.dcom.lans.ethernet removed)
    >
    > Tom Holden wrote:
    >
    > (snip)
    > (someone wrote)
    >
    > >>Right ON! The built-in Firewall is blocking access to the
    > >>server. I disabled it and access to the server opened up
    > >>for all ping, tracert and http download.
    >
    > >>Now this should not be the case, right? Is there
    > >>something special about address .255 that would cause the
    > >>Firewall to take action? Is this common to all Firewalls?
    > >>If so, shouldn't .255 be avoided for servers?
    >
    > > I found that with the Firewall enabled, I had to disable "SPI and
    Anti-DoS
    > > firewall protection" found on the SMC Firewall > Intrusion Detection
    page in
    > > order to access the .255 address. I have asked SMC Tech Support to
    confirm
    > > my observations, advise whether it is a bug, and, if so, when a fix is
    > > expected. Should I hold my breath?
    >
    > .255 is special in a class C address, or any /24 address.
    > As there is no way to determine the netmask from outside
    > the net in question, blocking on 255 for anything but a
    > class C net seems to me to be a mistake.
    >
    > It sounds like guilty whether or not proved innocent.
    >
    > -- glen
    >
  8. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    In alt.internet.wireless Ron Bandes <RunderscoreBandes @yah00.com> wrote:
    > It is definitely a mistake on SMC's part. The router has no way to know the
    > subnet mask of any remote network that is not in its routing table (usually
    > the case for networks across the Internet). The SMC SPI Firewall is intent
    > on detecting outbound attacks as well as inbound. Maybe if they stuck to
    > inbound attacks things would work better.

    Why do think it is detecting an outbound packet?

    It is detecting the inbound packet from that server as a SMURF.
    And it is not .255 specific. The other address was .250.

    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8-122.5
  9. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    dold@ProblemXAc.usenet.us.com wrote:
    > In alt.internet.wireless Ron Bandes <RunderscoreBandes
    > @yah00.com> wrote:
    >> It is definitely a mistake on SMC's part. The router
    >> has no way to know the subnet mask of any remote network
    >> that is not in its routing table (usually the case for
    >> networks across the Internet). The SMC SPI Firewall is
    >> intent on detecting outbound attacks as well as inbound.
    >> Maybe if they stuck to inbound attacks things would work
    >> better.
    >
    > Why do think it is detecting an outbound packet?

    "outbound" vs "inbound" is confusing me. When I ping a .255 address, the SMC
    log reports:
    "05/18/2004 22:38:52 **Smurf** 192.168.2.100->> 66.218.66.255, Type:8,
    Code:0 (from LAN Inbound)"
    I'm definitely attempting to ping from my LAN to the Yahoo server. From my
    position that's "outbound" but from the Internet it would be "inbound". I
    would have thought the firewall would be preventing attacks from the
    Internet into my LAN, not the other way around.

    >
    > It is detecting the inbound packet from that server as a
    > SMURF.

    Wrong. As far as I can tell, the ping from my LAN does not get past the
    firewall just as TRACERT gets nothing back from any point beyond the router.
    The firewall perceives a ping of an Internet .255 address as a SMURF attack.
    I also see random logs of SMURF attacks from the Internet so it may not be
    discriminating between inbound and outbound.

    > And it is not .255 specific. The other address was .250.

    Wrong. It is specific only to .255 and to .0 addresses. I made a batch file
    to ping every value in the 4th octet from 0 to 255 - the only ones blocked
    by a SMURF detection were these two. I also tried pinging every .255 address
    within a domain by incrementing the 3rd octet from 0 to 255. It reported
    SMURF every time.

    Isn't 255 in the 4th octet a broadcast address?

    Regards,
    Tom
  10. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    "Tom Holden" <holden_family@sympatico.ca> writes:

    > > And it is not .255 specific. The other address was .250.
    >
    > Wrong. It is specific only to .255 and to .0 addresses. I made a batch file
    > to ping every value in the 4th octet from 0 to 255 - the only ones blocked
    > by a SMURF detection were these two. I also tried pinging every .255 address
    > within a domain by incrementing the 3rd octet from 0 to 255. It reported
    > SMURF every time.
    >
    > Isn't 255 in the 4th octet a broadcast address?

    Your firewall is trying to prevent you attacking other hosts in the
    Internet, as well as preventing them from attacking you. (This is in
    general a good idea, as many worms will try to use you to spread to
    other hosts).

    An IP address is made up of a network part and a host part. The
    addresses having all host bits 1 and all host bits 0 are special, and
    are not normally used for actual hosts.

    Since CIDR, there is no way to know where the split between network
    and host is; this is encoded in the "netmask", and normally written
    as a slash followed by the number of network bits, thus: "/22" (which
    as a netmask is "255.255.252.0").

    Your firewall is assuming that the network you are pinging is a /24,
    and therefore that you shouldn't be talking to the .255 or .0
    addresses. It has no way to know this, and so this is a bug.

    HTH.

    --KW 8-)
    --
    Keith Wansbrough <kw217@cl.cam.ac.uk>
    http://www.cl.cam.ac.uk/users/kw217/
    University of Cambridge Computer Laboratory.
  11. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    In alt.internet.wireless Keith Wansbrough <kw217@cl.cam.ac.uk> wrote:
    > Your firewall is trying to prevent you attacking other hosts in the
    > Internet, as well as preventing them from attacking you. (This is in
    > general a good idea, as many worms will try to use you to spread to
    > other hosts).

    > Your firewall is assuming that the network you are pinging is a /24,
    > and therefore that you shouldn't be talking to the .255 or .0
    > addresses. It has no way to know this, and so this is a bug.

    Why do you think it is an outbound ping being blocked?
    That server does have an address of .255, and presumably is responding to
    the ping or http access.
    The incoming packet should be what is [mistakenly] blocked by the firewall.

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8-122.5
  12. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    dold@ProblemXAc.usenet.us.com wrote in message news:<c8fvvj$9nj$1@blue.rahul.net>...
    > Why do you think it is an outbound ping being blocked?
    > That server does have an address of .255, and presumably is responding to
    > the ping or http access.
    > The incoming packet should be what is [mistakenly] blocked by the firewall.

    I think and am 99.9% certain that my ping is blocked because TRACERT
    on this address does not get beyond the router and because the
    security log reports that it has detected a SMURF attack from my
    computer toward the server, not the other way around. If the server
    was receiving the ping and the reply made it all the way back to be
    blocked at my firewall, then I would think that TRACERT would also
    report all the hops up to but not including the .255 server and the
    security log would show that the SMURF attack was FROM the server.

    Regards,

    Tom
  13. Archived from groups: alt.internet.wireless,comp.protocols.tcp-ip (More info?)

    In alt.internet.wireless tom Holden <holden_family@sympatico.ca> wrote:

    > I think and am 99.9% certain that my ping is blocked because TRACERT
    > on this address does not get beyond the router and because the

    I agree with your "tracert" logic.

    > security log reports that it has detected a SMURF attack from my
    > computer toward the server, not the other way around. If the server
    > was receiving the ping and the reply made it all the way back to be
    > blocked at my firewall, then I would think that TRACERT would also
    > report all the hops up to but not including the .255 server and the
    > security log would show that the SMURF attack was FROM the server.

    I haven't paid attention to the direction of the SMURF warnings that I
    receive. But in the last couple of days, my email has been alive with
    SMURF warnings. The two addresses are always on the same network, in my
    ISP range, according to nslookup, one is always 255, and the other might be
    my own address. I'll have a look when I get home.

    I haven't saved the emails, but I can look in the logs.
    I know that the the SMC SPI filters have to have settings increased because
    they are just too tight, and report lots of problems in the default
    settings, but this yahoo address seemed to be something different.

    But why would there be a bunch of them, like 30 or 40 today, when I haven't
    seen any in weeks before trying this "yahoo" test? I was trying the ping
    earlier from my laptop, which is with me now.

    --
    ---
    Clarence A Dold - Hidden Valley (Lake County) CA USA 38.8-122.5
Ask a new question

Read More

Yahoo Servers Wireless Networking