VOIP with a linksys PAP2

Kevin J. Cummings cummings at kjchome.homeip.net
Tue Jun 14 20:30:44 UTC 2005


THUFIR HAWAT wrote:
> On 6/14/05, Kevin J. Cummings <cummings at kjchome.homeip.net> wrote:

> I unplugged the wl-330g, turning it off.  then I plugged its power
> cable in and connected it to the PAP2 with a crossover cable. (it has
> a power cord and ethernet jack, seperate.)  I played around with the
> squence, trying the PAP2 with power first and so on, plugging in the
> crossover cable before the wl-330g's power cable, etc.  the phone was
> always plugged in.  I used the phone not long ago, so I "know" that
> the phone works ;)
> 
> the best I could get were some pretty lights from the PAP2, then a
> blinking, intermittent light.  no dial-tone from the phone.

I would think that if it matters at all, you want to cable it all up 
with the power off to both devices.  Then power up the dl-330g, then 
power up the PAP2.  If it works, then it will negotiate an IP address 
with the wl-330g (or through it).  I have no idea if further 
configuration of the PAP2 is then necessary.

> this setup is premised on the wl-330g's ability to renegotiate the MAC
> on the fly?  I don't think it's that smart.  I don't have the source,
> but I looked into this previously.

Its not re-nogotiation of the MAC address, but of an IP address to use 
in the network.  IP addresses allow devices to have their packets routed 
via the IP portion of TCP/IP.  MAC addresses only identify the 
underlying hardware of a device.  While the MAC address is encoded into 
your TCP/IP packets, it is not used for routing per se.  It may be used 
by switches or bridges to limit unnecessary traffic on subnets, but does 
not enter into TCP/IP configurations beyond that.

What *should* occur is that your PAP2 should request an IP address on a 
broadcast to the DHCP server on (or through) the wl-330g.  When it is 
successful, the PAP2 will configure itself much like your eth0 ethernet 
card does in your computer when it is connected instead.  This process 
causes the proper routes to be set up in order that the TCP/IP packets 
are delivered to their intended locations.  If it doesn't work, you 
might have to put a network sniffer on the line to figure out why not 
(which would complicate an intentionally simple hardware setup!).  At 
least if you try this through a Linux computer, you could run some 
sniffing software under Linux and look at the packets at both eth0 and 
eth1, but that would require a fair expertise with TCP/IP to understand 
what's going on....

It all comes down to the capabilities built-in to the wl-330g, the PAP2, 
and whether or not they will play with each other.  You should be able 
to determine this by reading the manuals that come with each device.

Sorry that this doesn't plag and play....  If it doesn't its not Linux's 
fault!   B^)

-- 
Kevin J. Cummings
kjchome at rcn.com
cummings at kjchome.homeip.net
cummings at kjc386.framingham.ma.us




More information about the fedora-list mailing list