Menu
▾
▴
Re: [Linux-ATM-General] CLIP over PVC: an atmarpd issue
|
From: Giampaolo T. <g.t...@li...> - 2004-07-15 13:49:55
|
On Thursday 15 July 2004 15:35, Mike Westall wrote: > I don't kow if this is your problem or not, but it is common > for atm device drivers NOT to support all possible vpi:vci > combinations. The hardware has to be set up to decode > and map the vpi:vci of incoming cells to onboard hardware > defined data structures that represent open VCC's. > > The number of concurrently open VCC's is limited by the > amount of onboard RAM and is << than the number of > possible vpi:vci combinations. The mapping mechanism > is hardware (and thus device driver) dependent and commonly > allows one to determine which bits of the vpi number and > vci number are "significant". > > Some device drivers, by default only support VPI 0. Well, I'm fair acquainted with Ellis' driver, and I believe there is no such limitation. In a preceding post I told that when registering the driver with the ATM stack, it sets the ci_range struct with vpi_bits=8 and vci_bits=16. The vcc open function (popen() in the driver) always returns 0. Also, the card is basicly an ADSL interface with no hardware knowledge of the ATM cell structure: cells are build and disassembled directly by the driver though the Johan Verrept's SARLIB for raw<->aal5 decoding/encoding, which has no inherent limit on vpi/vci ranges (apart the ATM imposed ones). > Mike Thanks, Giampaolo > Giampaolo Tomassoni wrote: > >On Thursday 15 July 2004 14:46, you wrote: > >>I have actually no ATM NIC to verify my assertions but: > >>_Can you set an atmarp entry in the same VP plane than signalling stack > >>(atmarp -s 10.9.8.254 0.0.35 => VP 0 instead 8)? > > > >It works!!!! > > > >>_I don't know the > >>behaviour of the linux CLIP but some stack needs to send and receice an > >>inATMarp request/reply packet to declare a CLIP "connection" open: if > >> your card is not connected to the right client perhaps it is your error > >> case? > > > >I don't know either, but I have the feeling that no signaling is involved > > in non-server, static, atmarp entries setup: it is a PVC setup, not an > > SVC one. > > > >Also, the fact that the connection must be active and running in order to > >setup a PVC seems to me a GREAT limitation: what if it isn't available, > > for whichever reason, when you setup the PVC? What if it drops and then > > restarts? Do I have to monitor it continuosly? Aaagh! > > > >>_It seems you don't need SVC or ILMI features so perhaps you can avoid to > >>launch atmsigd and ilmid deamon? > > > >Well, being not that expert in the Linux ATM stack, I pedantly followed > > the instructions about CLIP setup that I found in the > >linux-atm-2.4.x/doc/atm-linux-howto.txt file... > > > >However, I right now tried to follow your hint (you were right once, why > > not two? :) ). Everything seems fine, but atmarpd complained at startup > > (SVCs are not available): > > > > atmarpd:ARPD: Linux ATM ARP, version 2.4.0 > > atmarpd:IO: SVCs are not available > > atmarpd:IO: ---------- > > atmarpd:ARP: arp_ioctl 3 > > atmarpd:TABLE: ----- Unknown incoming connections ----- > > atmarpd:TABLE: ----- Incoming unidirectional connections ----- > > atmarpd:TABLE: ----- End of dump ----- > > > >Apart from this, the atmarpd daemon worked as expected. > > > >>Regards... > > > >You too. This means there is some type of error in the ATM kernel modules, > >right? The problem is that my ISP uses VPI=8, not =0... What a big drama! > > > > Giampaolo > > > >>-----Original Message----- > >>From: lin...@li... > >>[mailto:lin...@li...]On Behalf Of > >>Giampaolo Tomassoni > >>Sent: mardi 13 juillet 2004 14:49 > >>To: lin...@li... > >>Subject: [Linux-ATM-General] CLIP over PVC: an atmarpd issue > >> > >> > >>Dears, > >> > >>I'm testing CLIP over a PVC through a Pulsar-based ADSL card, which is > >> seen by the ATM stack thanks to the Guy Ellis' latest driver. I actually > >> don't have a working ADSL line, but the question should be still valid. > >> It is the only ATM interface in my machine, so that it is seen as atm > >> dev#0. > >> > >>My test is accomplished by first loading Ellis' driver: > >> insmod pulsar_atm.o > >> > >> > >>After this /proc/net/atm/devices reports: > >> > >> Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ... > >> 0 Pulsar 000afa10022f 0 ( 0 0 0 0 0 ) 5 ( 0 0 0 0 0 ) > >> > >> > >>then I start the following daemons: > >> > >> atmsigd -b -l syslog -D /var/tmp -t 20 > >> ilmid -b -l syslog > >> sleep 3 > >> atmarpd -b -l syslog -m > >> > >> > >>after this the /proc stat files contain: > >> > >> /proc/net/atm/svc: > >> > >> Itf VPI VCI State Remote > >> N/A@d0402a00 LISTEN > >> > >> > >> /proc/net/atm/pvc: > >> > >> Itf VPI VCI AAL RX(PCR,Class) TX(PCR,Class) > >> 0 0 5 5 0 UBR 0 UBR > >> 0 0 16 5 0 UBR 0 UBR > >> > >> > >> /proc/net/atm/vc: > >> Address Itf VPI VCI Fam Flags Reply Send buffer Recv buffer > >> d04e1200 0 0 5 PVC 0043 0 0/ 65535 0/ 65535 > >> d04e1800 0 0 16 PVC 0043 0 0/ 65535 0/ 65535 > >> d0402a00 Unassigned SVC 04d8 0 0/ 65535 0/ 65535 > >> > >> > >>and /proc/net/atm/arp is empty. Then I would create an atm-based ip > >>interface, start it and set my isp's router as my default route: > >> > >> atmarp -c atm0 > >> ipconfig atm0 inet 10.9.8.7 netmask 255.255.255.0 > >> atmarp -s 10.9.8.254 0.8.35 > >> route add -net 0.0.0.0/0 gw 10.9.8.254 > >> > >> > >>of course, 10.9.8.x is not the address I'm actually using, but it isn't > >>important for our purposes. Basicly, my ISP told me that the CLIP > >>connection has VPI=8, VCI=35, that my ip address will be 10.9.8.7 on a > >> zone with netmask 255.255.255.0, that the default gateway is 10.9.8.254 > >> and that they use LLC encapsulation. > >> > >>Now, the two question. The command of the set: > >> > >> atmarp -s 10.9.8.254 0.8.35 > >> > >>fails reporting the error: > >> > >> atmarp: No route to host > >> > >>which is the perror(3) message for EHOSTUNREACH. Searching further, I get > >>the idea that atmarpd didn't yet put my atm0 device in its 'itfs' device > >>list. I'm using an ATM-enabled Linux kerner 2.4.20-64GB-SMP from SuSE, > >>while the ATM commands came from linux-atm-2.4.1. Is it some version > >>mismatch between atm kernel module and atm tools that drive to this > >> error? Which linux-atm version should I use to match the Linux 2.4.20 > >> kernel atm modules version? > >> > >>Thanks, > >> > >> Giampaolo Tomassoni > >> > >> > >> > >>------------------------------------------------------- > >>This SF.Net email sponsored by Black Hat Briefings & Training. > >>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > >>digital self defense, top technical experts, no vendor pitches, > >>unmatched networking opportunities. Visit www.blackhat.com > >>_______________________________________________ > >>Linux-atm-general mailing list > >>Lin...@li... > >>https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > >------------------------------------------------------- > >This SF.Net email is sponsored by BEA Weblogic Workshop > >FREE Java Enterprise J2EE developer tools! > >Get your free copy of BEA WebLogic Workshop 8.1 today. > >http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > >_______________________________________________ > >Linux-atm-general mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linux-atm-general |