[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Frame Relay under Linux report and questions
On 26 Jun 1997, Alexander L. Belikoff wrote:
> 1. Stay with a driver provided with the Linux kernel; or
> 2. Use a package provided by Sangoma.
>
> I started with option 2 - you know, after all THEY made the card, THEY
> have to support it. Immediately, I found that their package
> (wantools-1.?) was a) very sysadmin-unfriendly. It's ironic - they
> tried to make it as friendly as possible; so instead of using the
> "standard" UNIX standards for packaging/installation (make; make
wantools 2 hasn't improved the situation, I tried it a while ago and fell
back to frad 0.15 again.
> ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz
>
> I got the package and installed it without much hassle. Thanks to Ira,
> he provided us with a sample configuration, so I managed to tailor it
> to our needs as much as I could. The thing started working and it is
> working, although I have a couple problems which I'd like to fix:
> 1. At a boot time I get a message:
>
> ... Bc/CIR overflow, acceptable size is 2
happens all the time to me too, ignore it, it never gave me any problems.
> 2. I get an 'invalid flag' message every minute. The message is:
>
> kernel: dlci01: Invalid header flag 0x20.
>
> it shows up only on that dlci (link to the Internet router) - not
> on the first one.
ahh, that's some weird unsupported arp packet that some Ciscos send to
other ciscos. the ISP can disable it, but they probably wouldn't know what
you are talking about, I finally Alan Cox himself gave up and told me I
could just use ifconfig's option "-arp" and it goes away :-)
> 3. Every 10 seconds (!!!) I receive a packet from the Internet
> router. The firewall message is:
>
> kernel: IP fw-in deny dlci01 PROTO=89 192.116.75.157 224.0.0.5 L=80 S=0xC0 I=3770 F=0x0000 T=1
>
> There are several points about it:
>
> a) The protocol field of the packets is IP_OSPFIGP
> b) I *don't* run any OSPF-related software - all routes are static.
> c) 192.116.75.157 (source IP) is the Internet router we are connected to.
> d) 224.0.0.5 (dest IP) is OSPF-ALL.MCAST.NET (what the heck?!)
> e) The only thing changing in those packets is the 'I' field (I take
> it is the Identification field of the IP packet)
cool, sounds like some multicast protocol... funny it should be routed to
you if you don't have equipment to support it, but then again, most ISPs
can't support it yet...
do " host -l -a mcast.net " and you will see some interesting machine
names :-) the multicast project is in testing by the IETF, AFAIK, and it
will (in the end) be used to save bandwidth on multicast data. there are a
few ISPs in on it in the US, I didn't know Netvision joined it too. I
wonder why they are forwarding you the packets though (you should probably
ask them to block it for now, it's just some detection protocol, "some
scanning beam from planet zarkon" if you want a better sci-fi name :-)
> I talked to the ISP guys and after some investigation they told me
> that "their router is replying to *our* OSPF messages which we send
> out". According to the firewall setup, I only let TCP and UDP outgoing
> packets, so either they are wrong or some low-level software (drivers)
> is sending OSPF packets avoiding the firewall, or even the card send
> them itself (!). My wild guess is that it is *their router's*
> misconfiguration.
nope, no OSPF in the kernel as far as I saw... I think they should start
using a sniffer if their FW doesn't log (or block!) those packets...
------------------------------------------------------
Ira Abramov <ira@interHDL.com>
Webmaster @ interHDL Inc. - The HDL Technology Company
Tel: (415) 428-4200 4984 El Camino Real #210
Fax: (415) 428-4201 Los Altos CA, 94022-1433
References: