Problems connecting through a switch
Birkemose
I am not sure if this is the right place, but as some of the answers
sounds like they were written by skilled people, I take my chances.
Otherwise I would be happy if You could point me to a more appropriate
newsgroups.
Heres is my problem.
I have a PC Windows application, that connects to some controller
hardware, using TCP.
One controller, one PC, works fine. The PC ( 192.168.128.1 ) connects
and communicates fine with a controller ( 192.168.128.129 )
Now I want to connect two controllers to my PC, and thus inserts a
switch. My two controllers are 192.168.128.129, and 192.169.128.130
First I connect to 129. That works well. Then I connect to 130. That
also works well.
When I then try to connect to 129 again, there is no connection. Ping
reports no target.
I must manually reset the switch to be able to connect to 129 again.
It is like I dont close the connection through the switch properly ( I
know very little about TCP ). Problem is, I have tried anything I can
think of. With no luck.
My PC application does as follows
1) When launching PC application
WSAStartup( ...
2) When connecting to a controller
socket( ...
connect( ...
3) When communicating ( this might be for several hours )
send( ...
recv( ...
4) When disconnecting ( before connecting to a new controller )
closesocket( ...
5) When PC application closes
WSACleanup
Does anybody know what I am missing?
TIA
Birkemose
Jorgen Grahn
> Hi all
>
> I am not sure if this is the right place, but as some of the answers
> sounds like they were written by skilled people, I take my chances.
> Otherwise I would be happy if You could point me to a more appropriate
> newsgroups.
>
> Heres is my problem.
> I have a PC Windows application, that connects to some controller
> hardware, using TCP.
> One controller, one PC, works fine. The PC ( 192.168.128.1 ) connects
> and communicates fine with a controller ( 192.168.128.129 )
>
> Now I want to connect two controllers to my PC, and thus inserts a
> switch. My two controllers are 192.168.128.129, and 192.169.128.130
>
> First I connect to 129. That works well. Then I connect to 130. That
> also works well.
> When I then try to connect to 129 again, there is no connection. Ping
> reports no target.
> I must manually reset the switch to be able to connect to 129 again.
>
> It is like I dont close the connection through the switch properly ( I
> know very little about TCP ).
You know more that the switch does, if it is a normal switch.
> Problem is, I have tried anything I can
> think of. With no luck.
> My PC application does as follows
[...]
I can't see how it can matter what your application does -- if you
have to reset the switch, it seems to me that the switch must be
broken. Or possibly your two "controllers"; maybe they are configured
with the same IP address or something, making the switch confused
about who is who.
You should be able to trigger this by just using ping. It's IP traffic
like any other IP traffic; the switch should see no difference between
ping and your application.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
David Schwartz
> First I connect to 129. That works well. Then I connect to 130. That
> also works well.
> When I then try to connect to 129 again, there is no connection. Ping
> reports no target.
> I must manually reset the switch to be able to connect to 129 again.
It sounds like the controllers are horribly broken. My money is on the
two controllers having the same MAC address.
DS
David Schwartz
> It sounds like the controllers are horribly broken. My money is on the
> two controllers having the same MAC address.
Sorry to respond to myself, but I should point out that you can
troubleshoot this with the following process:
1) Ping one controller. Do 'arp -an' and look at the MAC address for
its IP address.
2) Reboot the switch and ping the other controller. Do 'arp -an' and
look at the MAC address for its IP address.
3) If the two MAC addresses are the same, the controllers are horribly
broken. Every Ethernet device is supposed to have its own unique
factory-assigned MAC address. (Or it could be pilot error -- if
someone manually configured a MAC address and then carelessly copied
the configuration of one controller to the other -- including the MAC
address.)
DS
Birkemose
Thanks a lot for the input. Helped me a lot.
I tried resetting the switch, and just using ping. Same problem
ping 192.168.128.129 works
ping 192.168.128.130 works
ping 192.168.128.129 times out until I reset the switch
So the problem is not in my Windows app, but must be in the
controller.
The controller is an Atmel at91sam7x256, using Keil uVision RTC
package with TCP. I set the TCP address when booting, but know nothing
of any MAC address.
Will read up on this.
Anyway, your responses have narrowed down the possibilities, and I can
now tell my boss, that its not "MY" PC software that is to blame ;)
Birkemose
Thanks for Your thoughts on this.
I wi
Rick Jones
> Thanks a lot for the input. Helped me a lot.
> I tried resetting the switch, and just using ping. Same problem
> ping 192.168.128.129 works
> ping 192.168.128.130 works
> ping 192.168.128.129 times out until I reset the switch
What was the result of looking at the ARP tables on your system? Did
it show unique MAC addresses for both controllers IP addresses?
Looking at the ARP tables was rather the main point of David's
posting.
rick jones
--
the road to hell is paved with business decisions...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
David Schwartz
> Hi guys
>
> Thanks a lot for the input. Helped me a lot.
> I tried resetting the switch, and just using ping. Same problem
>
> ping 192.168.128.129 works
> ping 192.168.128.130 works
> ping 192.168.128.129 times out until I reset the switch
>
> So the problem is not in my Windows app, but must be in the
> controller.
How do you figure?
> The controller is an Atmel at91sam7x256, using Keil uVision RTC
> package with TCP. I set the TCP address when booting, but know nothing
> of any MAC address.
Well then that may be your problem right there. How is the MAC address
supposed to be set?
> Will read up on this.
Umm, yeah, you better do that. It might be that it's your
responsibility to set the MAC address and you're not doing that.
> Anyway, your responses have narrowed down the possibilities, and I can
> now tell my boss, that its not "MY" PC software that is to blame ;)
What configures the controller?
DS
Birkemose
I am unfamiliar with ARP, but if I use ARP -a, I get a list of
addresses, but none of them are 192.168.128s
Forgive me if I know little about these things.
@David
I figure that the problem is NOT in my Windows application, since PING
experiences the same problem. I would expect PING to work.
The controller is initialized by a proffesional TCP package by Keil /
Atmel. I have no idea if I need to provide a MAC address, but I will
do some reading / phonecalling on this tomorrow.
/Birkemose
On 10 Nov., 19:21, Rick Jones <rick.jon...@hp.com> wrote:
glen herrmannsfeldt
> On Nov 10, 7:38?am, Birkemose <lars.birkem...@gmail.com> wrote:
(snip)
> It sounds like the controllers are horribly broken. My money is on the
> two controllers having the same MAC address.
That is my first thought, too, though....
Ping the first host, the ARP entry is added on the PC and the
switch adds it to the forwarding table.
Ping the second host, ARP adds it, switch changes the table
when the reply comes back. ARP doesn't remove the first entry.
(It could be more than one IP address on the same host.)
Ping the first host, the ARP entry is still there, switch forward
to the second host.
Unless the first host sends out anything, or the switch entry
times out, yes, it seems that is what would happen.
-- glen
glen herrmannsfeldt
> I am unfamiliar with ARP, but if I use ARP -a, I get a list of
> addresses, but none of them are 192.168.128s
> Forgive me if I know little about these things.
> experiences the same problem. I would expect PING to work.
> The controller is initialized by a proffesional TCP package by Keil /
> Atmel. I have no idea if I need to provide a MAC address, but I will
> do some reading / phonecalling on this tomorrow.
If it is ethernet (you never mentioned that) then it needs a MAC
address, otherwise sometimes known as an ethernet address.
Normally they are globally unique 48 bit numbers, usually
stored in ROM on the host. If you clone the host, you must
change the MAC address. For IP to work, it really only needs
to be unique on the subnet, but that is exactly the problem
you have.
If the whole thing is on one FPGA (just a guess) then you somehow
have to get a new MAC address in there.
Post the output of the arp -a command on the PC.
The output if netstat -r would also help.
-- glen
David Schwartz
> I am unfamiliar with ARP, but if I use ARP -a, I get a list of
> addresses, but none of them are 192.168.128s
> Forgive me if I know little about these things.
Why don't you follow the procedure I outlined? Ping one controller, do
an 'arp -an'. Restart the switch, ping the other controller, do an
'arp -an'. That should allow you to note the MAC address of both
controllers. If they're both the same, then the fault is with whoever
or whatever is responsible for ensuring the controllers have unique
MAC addresses. Since we don't know who that is (and apparently, you
don't either), we can't say who is at fault.
DS
Rick Jones
> I am unfamiliar with ARP, but if I use ARP -a, I get a list of
> addresses, but none of them are 192.168.128s Forgive me if I know
> little about these things.
I cannot claim familiarity with Windows arp myself, but if the arp -a
output is all "names" and not all IP addresses you may need to add
(I'm guessing) a -n to that command line to prevent it from
translating IP addresses back to hostnames.
rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
glen herrmannsfeldt
> I cannot claim familiarity with Windows arp myself, but if the arp -a
> output is all "names" and not all IP addresses you may need to add
> (I'm guessing) a -n to that command line to prevent it from
> translating IP addresses back to hostnames.
It seems that it doesn't have that -n, and always gives
numerical answers. It does have -N (case insitive) to specify
the interface.
-- glen
Char Jackson
<rick....@hp.com> wrote:
>Birkemose <lars.bi...@gmail.com> wrote:
>> I am unfamiliar with ARP, but if I use ARP -a, I get a list of
>> addresses, but none of them are 192.168.128s Forgive me if I know
>> little about these things.
>
>I cannot claim familiarity with Windows arp myself, but if the arp -a
>output is all "names" and not all IP addresses you may need to add
>(I'm guessing) a -n to that command line to prevent it from
>translating IP addresses back to hostnames.
>
>rick jones
It seems to display IP addresses, as expected.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
D:\>arp /?
Displays and modifies the IP-to-Physical address translation tables
used by address resolution protocol (ARP).
ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]
-a Displays current ARP entries by interrogating the
current protocol data. If inet_addr is specified, the
IP and Physical addresses for only the specified
computer are displayed. If more than one network
interface uses ARP, entries for each ARP table are
displayed.
-g Same as -a.
inet_addr Specifies an internet address.
-N if_addr Displays the ARP entries for the network interface
specified by if_addr.
-d Deletes the host specified by inet_addr. inet_addr may
be wildcarded with * to delete all hosts.
-s Adds the host and associates the Internet address
inet_addr with the Physical address eth_addr. The
Physical address is given as 6 hexadecimal bytes
separated by hyphens. The entry is permanent.
eth_addr Specifies a physical address.
if_addr If present, this specifies the Internet address of the
interface whose address translation table should be
modified. If not present, the first applicable
interface will be used.
Example:
> arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Adds a static
entry.
> arp -a .... Displays the arp
table.
D:\>arp -a
Interface: 192.168.5.10 --- 0x2
Internet Address Physical Address Type
192.168.5.1 00-18-f8-f9-6a-92 dynamic
192.168.5.16 00-50-8d-91-70-df dynamic
D:\>
Birkemose
Well, I tried using ARP, but there is no -an switch in my version of
ARP. ( Windows 7 Evaluation )
Trying ARP -a gives me this list. ( No 192.168.128.129 as you might
notice, even if I can ping it )
Interface: 10.211.55.3 --- 0xb
Internet Address Physical Address Type
10.211.55.1 00-1c-42-00-00-18 dynamic
10.211.55.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static
Anyway.
As most of you guys stated, the problem was with the MAC address.
The TCP software from Keil hardcoded the same MAC address into the
ethernet controller, but after "hacking" into the driver, I was able
to use the dipswitch we use for setting the IP address, to also set
the MAC address, and voila ... it worked.
Thanks for Your input on this, and for guiding me in the right
direction.
/Birkemose
On 11 Nov., 08:36, Char Jackson <n...@none.invalid> wrote:
> On Wed, 11 Nov 2009 01:22:02 +0000 (UTC), Rick Jones
>
> <rick.jon...@hp.com> wrote:
Martijn Lievaart
> Post the output of the arp -a command on the PC. The output if netstat
> -r would also help.
To be more precise:
- ping ip1
- arp -a
- ping ip2
- arp -a
post that here.
M4
Barry Margolin
<c92e226a-03e4-4382...@w19g2000yqk.googlegroups.com>,
Birkemose <lars.bi...@gmail.com> wrote:
> @David
>
> Well, I tried using ARP, but there is no -an switch in my version of
> ARP. ( Windows 7 Evaluation )
> Trying ARP -a gives me this list. ( No 192.168.128.129 as you might
> notice, even if I can ping it )
The controllers appear to be on a different network from you. Your PC
is on the 10.211.55.0/24 network, but the controllers are on
192.168.128.0/24. So the PC sends to the controllers through a router,
and you need to look at *its* ARP table.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***