1. Your wired ethernet card is using 192.168.1.11
2. Your Atheros card is being assigned 192.168.1.3
The wired NIC is first in the binding order and thus first in the routing table.
Your packets for the local subnet will never go out the Atheros card, but the
wired NIC.
Have you done any testing by hard disabling all network devices in the system
except the Atheros card?
shows 4 network devices, 3 of which are actively sending/receiving packets, one
of which is on the same subnet as the wireless device you can't seem to get working.
Additionally the Atheros shows 0/70 link quality and a S/N of 1:1. It can't be
connected to the AP with those numbers--they can't be any worse. The driver
shows no association, and that makes sense looking at those RF numbers.
Curiously, given the transceiver can't discern anything from the AP RF signals,
you still managed to get a dhcp ack with an assignment of 192.1681.3. How is
that possible when you don't even have a radio link to the AP?
Is all of the data shown in WICD.info.gz from the same point in time?
--
Stan
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 03:11 PM
"Wayne
Stan Hoeppner wrote:
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 8:56 AM:
1. Your wired ethernet card is using 192.168.1.11
2. Your Atheros card is being assigned 192.168.1.3
The wired NIC is first in the binding order and thus first in the routing table.
Your packets for the local subnet will never go out the Atheros card, but the
wired NIC.
Have you done any testing by hard disabling all network devices in the system
except the Atheros card?
Just tried that and can't get a positive response out of dhclient. No
offers. Remember though I am not using wicd right now. I am trying to
do without the managers. This way I I don't get any system freeze up's
and sadly no dhcp offers either.
shows 4 network devices, 3 of which are actively sending/receiving packets, one
of which is on the same subnet as the wireless device you can't seem to get working.
Additionally the Atheros shows 0/70 link quality and a S/N of 1:1. It can't be
connected to the AP with those numbers--they can't be any worse. The driver
shows no association, and that makes sense looking at those RF numbers.
Curiously, given the transceiver can't discern anything from the AP RF signals,
you still managed to get a dhcp ack with an assignment of 192.1681.3. How is
that possible when you don't even have a radio link to the AP?
That iwconfig was 'after' I removed wicd from the system. Guess that
I should not have included that as it was not related to the other data.
You were right, I am giving you a moving target to troubleshoot and that
ain't good.
Is all of the data shown in WICD.info.gz from the same point in time?
Yes All except the last reference to iwconfig.
OK, I will go back to the wicd setup and then put ALL of the data you
requested from 'that' setup into a new WICD file. I will then STAY at
that setup for at least a day or two.
Sorry for the bother.
Wayne
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 03:43 PM
"Wayne
Stan Hoeppner wrote:
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 8:56 AM:
1. Your wired ethernet card is using 192.168.1.11
2. Your Atheros card is being assigned 192.168.1.3
The wired NIC is first in the binding order and thus first in the routing table.
Your packets for the local subnet will never go out the Atheros card, but the
wired NIC.
Have you done any testing by hard disabling all network devices in the system
except the Atheros card?
shows 4 network devices, 3 of which are actively sending/receiving packets, one
of which is on the same subnet as the wireless device you can't seem to get working.
Additionally the Atheros shows 0/70 link quality and a S/N of 1:1. It can't be
connected to the AP with those numbers--they can't be any worse. The driver
shows no association, and that makes sense looking at those RF numbers.
Curiously, given the transceiver can't discern anything from the AP RF signals,
you still managed to get a dhcp ack with an assignment of 192.1681.3. How is
that possible when you don't even have a radio link to the AP?
Is all of the data shown in WICD.info.gz from the same point in time?
Current settings of all info is on the site WICD2 is the file. No
changes will be made here for 2 days.
Wayne
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 04:09 PM
"Wayne
Stan Hoeppner wrote:
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 8:56 AM:
1. Your wired ethernet card is using 192.168.1.11
2. Your Atheros card is being assigned 192.168.1.3
The wired NIC is first in the binding order and thus first in the routing table.
Your packets for the local subnet will never go out the Atheros card, but the
wired NIC.
Have you done any testing by hard disabling all network devices in the system
except the Atheros card?
shows 4 network devices, 3 of which are actively sending/receiving packets, one
of which is on the same subnet as the wireless device you can't seem to get working.
Additionally the Atheros shows 0/70 link quality and a S/N of 1:1. It can't be
connected to the AP with those numbers--they can't be any worse. The driver
shows no association, and that makes sense looking at those RF numbers.
Curiously, given the transceiver can't discern anything from the AP RF signals,
you still managed to get a dhcp ack with an assignment of 192.1681.3. How is
that possible when you don't even have a radio link to the AP?
Is all of the data shown in WICD.info.gz from the same point in time?
--
Stan
Note that I added a wicd.png to the mix. When I went back to grb that
snapshot the ip address had changed from 192.168.1.4 to 1.5. At that
time the XP box showed that the users went from 3 to 2.
This is NUTS!!
Wayne
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 06:12 PM
Stan Hoeppner
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 10:43 AM:
> Current settings of all info is on the site WICD2 is the file. No
> changes will be made here for 2 days.
The requested URL /~huntbrittany/linux/WICD2.info.gz was not found on this server.
The requested URL /~huntbrittany/linux/WICD2 was not found on this server.
Where oh where did you hide it?
--
Stan
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 06:43 PM
"Wayne
Stan Hoeppner wrote:
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 10:43 AM:
Current settings of all info is on the site WICD2 is the file. No
changes will be made here for 2 days.
The requested URL /~huntbrittany/linux/WICD2.info.gz was not found on this server.
The requested URL /~huntbrittany/linux/WICD2 was not found on this server.
Where oh where did you hide it?
right here <http://www.intergate.com/~huntbrittany/linux/wicd2.png>
That's the pic of wcid with the different ip address
I had to close gftp & load it again before I could find th .png file to
move to the web page.
Cache problem?? I'm connected to the page now and they are all there.
Wayne
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 07:00 PM
"Wayne
Stan Hoeppner wrote:
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 10:43 AM:
Current settings of all info is on the site WICD2 is the file. No
changes will be made here for 2 days.
The requested URL /~huntbrittany/linux/WICD2.info.gz was not found on this server.
The requested URL /~huntbrittany/linux/WICD2 was not found on this server.
Where oh where did you hide it?
Just realized I forgot the interfaces file
# The loopback network interface
auto lo
iface lo inet loopback
up route add -net 127.0.0.0 netmask 255.0.0.0 dev lo
down route del -net 127.0.0.0 netmask 255.0.0.0 dev lo
This shows that your Atheros is communicating with the AP up to layer 3. Are
you able to ping 192.168.1.1? If not, can you ping 192.168.1.1 from the Windows
PC? I.e, does the MiFi 2200 have a firewall that discards ICMP echo packets?
If the Windows PC can ping and get a response...
did a CD come with the MiFi 2200? Did you install software from that CD onto
the Windows machines? If so, is it possible that such software has some extra
"phantom" layer of junk that allows the Windows machines to properly communicate
with the AP, which you don't have available to install on Linux? If so, you
need to figure out what that Windows software is providing and duplicate the
function on Linux.
The above output from ifconfig shows that you have IP connectivity with the MiFi
2200 AP. The effort now is to identify why the MiFi isn't apparently processing
your packets.
--
Stan
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 07:57 PM
"Wayne
Stan Hoeppner wrote:
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 1:43 PM:
This shows that your Atheros is communicating with the AP up to layer 3. Are
you able to ping 192.168.1.1?
root@dj:/home/wtopa# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.111 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.124 ms
64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.105 ms
--- 192.168.1.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.105/0.113/0.124/0.011 ms
root@dj:/home/wtopa# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
Yes
I.e, does the MiFi 2200 have a firewall that discards ICMP echo packets?
Not that I have found
If the Windows PC can ping and get a response...
did a CD come with the MiFi 2200?
NO
Did you install software from that CD onto
the Windows machines?
No the mifi copied a program to the HD to be used, every 3 months, to
reinitialize the MiFi.
If so, is it possible that such software has some extra
"phantom" layer of junk that allows the Windows machines to properly communicate
with the AP, which you don't have available to install on Linux? If so, you
need to figure out what that Windows software is providing and duplicate the
function on Linux.
With this outfit (Novatelwireless) anything is possible.
Do you know id XP has an equivalent command to route? That might be
informative.
The above output from ifconfig shows that you have IP connectivity with the MiFi
2200 AP. The effort now is to identify why the MiFi isn't apparently processing
your packets.
I am wondering what should be talking to the 192.168.1.1 interface. It
seems to me
that I'm missing a route but a route to what.
Museing, when when my Wife's XP box is connected to the MiFi she can
ping the XP laptop I am using but I can not ping her from my xp., it
times out.
My XP and my Wife's XP and my Linux box can all ping 192.168.1.3. My box
gets "Connection refused when telnet 192.168.1.3". Both XP's get a
"could not open an connection to port 23". So because we are all on the
local lan they can still get to linux via the lan but when I try to ping
my T40 laptop I get
root@dj:/home/wtopa# ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
I think I am missing something but don't know what other then a missing
route statement.
Wayne
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
01-01-2010, 09:05 PM
Stan Hoeppner
Wayne <linuxtwo@gmail.com> put forth on 1/1/2010 2:57 PM:
> I think I am missing something but don't know what other then a missing
> route statement.
It's not a route issue because the PCs are all on the same class C subnet (or
should be). I looked at a previous route table you posted and it was fine.
Speaking of which, what is your subnet mask for the ath0 interface? For that
matter, what is the subnet mask on all the machines' wireless ethernet
interfaces? And, most importantly, what is the subnet mask on the wireless
ethernet interface on the MiFi 2200? They all need to be correct and they
should all match. I would "assume" the subnet mask programmed into the MiFi
2200 is the correct one, and should thus be used on all the PCs.
--
Stan
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
