[svlug] You may ask yourself: How do I work this? (impasq, diald, pppd)

Ward Willats ward at wardco.com
Sun Jan 24 10:05:37 PST 1999


Greetings, you big lug:

Nice to meet you.

Been reading list traffic for a while now and hope you very smart people
can shower me with a great LOAD of knowledge -- I've got my RedHat 5.1
machine limping along in the corner now; doing that firewall/masquerade
thang to my ISP for my three node (mac,winders,linux) private 192.168.23.x
(network 23, you know) LAN using PPP over ISDN via a 3Com ImpactIQ -- and
if you can read this, it must work!

My first hurdle was thrashing the RedHat installer into putting the OS on
the SCSI drives and ignoring the IDE drives so they could spin down, since
the Linux box is on 24/7 and I don't need a bunch of drives in that case
sucking power and making heat. Somehow with various partitioning commando
tactics I got this to work and the BIOS/Adaptec 2940UW to boot LILO
directly to SCSI. Yes!

Next I hacked around with minicom and setserial so I could talk to the 3Com
ImpactIQ via my LavaLink 16650 UART card at 230Kbs on ttyS2. A little
baud_base 460800 divisor 2 spd_cust and viola! Hand me another drink....

Next got my good friend pppd 2.3.3 to call up my ISP. Okie doakie. But hey,
no second B channel -- Dynamic Bandwidth allocation not very dynamic!
Ignore for now.

Install diald 16.4. Hey, if the chat script fails the process hangs
forever. Install diald 16.5-201 RPM from the hurricane /contrib tree (what
the heck is hurricane?) Mmmm. That's better -- no more hangs.

Hey, lets install pppd 2.3.4 RPM and see if that fixes the 2nd B channel.
Ugh! Nope, promptly segment faults. Back off back to 2.3.3.

Okay, lets configure masquerade. Turn on forwarding, OK. Now onto ipfwadm
(chains is scary and I'm RH5.1)  Now, all the HOW-TO stuff says we can do
something like:

/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a -m -S 192.168.23.0/24 -D 0.0.0.0/0
...or...
/sbin/ipfwadm -F -a -m -S192.168.23.0/24 -D167.227.105.2/32

...but, nope, looks like the syntax has changed so that "-a" has to have a
policy, so:

/sbin/ipfwadm -F -a accept -m -S 192.168.23.0/24 -D 0.0.0.0/0
...or...
/sbin/ipfwadm -F -a accept -m -S192.168.23.0/24 -D167.227.105.2/32

...but, dang, this still doesn't forward along any packet from the private
192.168.23.x network on the eth0 interface. At this point, get frustrated
and turn Linux box off for 3 weeks. That'll show it.

(BTW, wardco.com is static 167.227.105.2 thanks to the good folks at
tycho.net; the NAS at their end varies...)

Upon return to the problem, in a bleary late night desperation move,
configure specific masquerade rules for each host instead of trying to do
the whole ehternet. So:

/sbin/ipfwadm -F -a accept -m -S 192.168.23.2/32
/sbin/ipfwadm -F -a accept -m -S 192.168.23.3/32

...Yes! This works. Yippie.

------------------ lap dissolve ------------

So, NOW the whole mess is alive, but these hiccups and DEEP MYSTERIES
remain (in no particular order):

1. Every so often this starts happening and I can't dial out (and in fact I
reboot the entire system like a pathetic looser intead of issuing a barrage
of clever "kill" commands and then restarting stuff):

Jan 10 11:07:39 hawkline diald[287]: SIGHUP: modem got hung up on.
Jan 10 11:07:39 hawkline diald[287]: could not get initial terminal
attributes: Input/output error
Jan 10 11:07:39 hawkline diald[287]: failed to set terminal attributes:
Input/output error
Jan 10 11:07:39 hawkline diald[287]: Running connect (pid = 3505).
Jan 10 11:07:39 hawkline dd-dialer: Initializing Modem
Jan 10 11:07:39 hawkline chat[3507]: Can't get terminal parameters:
Input/output error
Jan 10 11:07:39 hawkline dd-dialer: Failed to initialize modem
Jan 10 11:07:39 hawkline diald[287]: Connect script failed.
Jan 10 11:07:40 hawkline diald[287]: Delaying 10 seconds before clear to dial.

....repeat ad nauseum. Why? What to do?

2.  Why can't I masquerade the entire private net with a single ipfwadm
command like the REAL LINUX STUDS do? (You know who you are.) Must I learn
Finnish?

3. 2 B or not 2 B. The ImpactIQ ISDN box has a default protocol detection
algorithm called QuickSelect that decides whether to place a async-sync PPP
call or a V.120 call.  If I leave this alone I get my single (working) B
channel. (Init string: AT&FS0=0S60=64S71=0S80=1) IF, I force a async-sync
PPP connection (Init string: AT&FS0=0S60=64S71=1S80=1, S71 to 1) _BOTH_ B
channels come up, LCP negotiation completes, everything looks great BUT
IPCP doesn't seem to work. (I send packets all day, but never receive any
inbound traffic.) What's the deal? My insane serial speed? And what about
DBA -- don't seem to be any docs and how it interacts with the async-sync
code is a mystery to me. Can I get that second B to come and go "on the
fly?" Am I hosed until  DSL to arrives in the Santa Cruz mountains and such
concerns are meaningless?  Or must I start reading RFCs...?

4. Does that ip-up script _really_ execute? Even if I do my dialing with
scripts down in a subdir from /etc/ppp. ( /etc/ppp/myisp) -- it doesn't
seem to ever execute....

5. Why is "Ivory" Liquid now clear? Are their too many marketing/MBAs
running around or what?

I AM HAVING FUN! I AM HAVING FUN!
This IS better than NT Server! This IS better than NT Server!

BLAM!   ...thud

Kitos (ask Linus) and best regards,

-- Ward













--
echo "unsubscribe svlug" | mail majordomo at svlug.org
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to unsubscribe
see http://www.svlug.org/mdstuff/lists.shtml for posting guidelines.



More information about the svlug mailing list