> I have been routing a subnet through my PPP link, i.e., 204.178.47.0.
> We "own" 204.178.40.0 -> 204.178.47.255. This has worked fine for about
> a year.
>
> Now some MiCrO$oFt garbage, that I can't control, executes a variation of
> SNMP which sends ARP packets to every possible machine on the LAN. This
> happens at two-second intervals.
Are you sure it's ARP? You'd only see ARP across a PPP link if you're
proxying it (Proxy-ARP). However, you're right in that all the M$
protocols are broadcast-based pollutants, so what you're seeing could be
NetBIOS.
> If these packets go into my PPP Link, they use 100% of the bandwidth
> continuously so I can't use my PPP Link to route a subnet. If I use
> only the first few addresses of the subnet, I should be able to mask
> out the rest and therefore only get ARP packets sent to 7, rather than
> 254 possible nodes. This should make my link usable again.
>
> How do I do this? I don't think the kernel will let me mask out a portion
> of a subnet. Should I just brute-force filter the stuff in the PPP link?
> Note, I had to do this to get rid of the NETBIOS packets encapsulated
> in broadcast packets that MiCrO$oFt calls Netbeui.
You should be able to do this no problem. The man page for route(8)
specifies the "reject" qualifier as follows:
reject Modifier installs a blocking route, which will
force a route lookup to fail. This is for example
used to mask out networks before using the default
route. This is NOT for firewalling.
Or you could use ipfwadm to do something like:
ipfwadm -I -a deny -P udp -S 204.178.40.0/21 -D 204.178.47.0/21 137:139
You could block 139 TCP as well.
> This MiCrO$oFt garbage is being executed by powerful "managers" who have
> taken over the Network, so I can't control them. As a matter of fact, once
> they find out that I have direct access to the Internet, I'm done (gone).
I conducted an informal survey a while back about the amount of Micro$oft
broadcast garbage traffic on the Internet that goes unaccounted for in a
day.. It's very high. There's a cloud of spurious traffic out there
originating from misconfigured NT server, that the owners of their own
machines aren't even aware of.
Hope this helps,
-bp
-- B. James Phillippe Seattle Software Labs, Inc Network Administrator Phone: (206) 521-8346 NIC Handle: BJP4 Fax: (206) 521-8340 http://w3.terran.org/~bryan http://www.sealabs.com