Need a new set of eyes please.

Jimmy W.

Heres the setup: propnic, 4 position dip switch, I want to be able to set the mac and IP based on the dip switch settings(personal use only, not going to license some mac addresses). Maybe I am missing something, but my my mind this makes sense, compiles, but does not work....

 
  DIRA[noparse][[/noparse]20..23] := %0000
  Address := INA[noparse][[/noparse]20..23]
  Case Address
    0:  ip_addr [noparse][[/noparse] 3 ] := 70
        eth_mac [noparse][[/noparse] 5 ] := $01
    1:  ip_addr := 71
        eth_mac := $02
    2:  ip_addr := 72
        eth_mac := $03
    3:  ip_addr := 73
        eth_mac := $04
    4:  ip_addr := 74
        eth_mac := $05
    5:  ip_addr := 75
        eth_mac := $06
    6:  ip_addr := 76
        eth_mac := $07
    7:  ip_addr := 77
        eth_mac := $08
    8:  ip_addr := 78
        eth_mac := $09
    9:  ip_addr := 79
        eth_mac := $10
    10: ip_addr := 80
        eth_mac := $11
    11: ip_addr := 81
        eth_mac := $12
    12: ip_addr := 82
        eth_mac := $13
    13: ip_addr := 83
        eth_mac := $14
    14: ip_addr := 84
        eth_mac := $15
    15: ip_addr := 85
        eth_mac := $16

  cog:=ser.start(i_cs,i_sck,i_si,i_so,i_int,xtalout,@eth_mac,@ip_addr)    ' Start tcp socket drver
  ser.listen(port)                                ' listen for tcp connections on port  
repeat
  time.Pause1ms(10000)
  !outa[noparse][[/noparse]0]
  ser.str(string(CR,LF,"*SENSOR:"))
  ser.dec(Address)
  ser.str(string(",RH:42,TEMP:79,DEW:46*",CR,LF))
  !outA[noparse][[/noparse]10]
  outA[noparse][[/noparse]8] := ser.isConnected

DAT
        eth_mac         BYTE    $96, $11, $22, $33, $44, $01
        ip_addr         BYTE    192, 168, 1, 70
        ip_broadcast    BYTE    192, 168, 1, 255  
        ip_gateway      BYTE    192, 168, 1, 1   
        ip_dns          BYTE    192, 168, 1, 1    
        port            Byte    23                  

The dips are connected to input on 1 side, and 3.3v through a 100 ohm resistor on the other side, if the dips are all set to 0 I can connect to 192.168.1.70, any other settings and all other ip's fail


What am I missing?

Jimmy

.. It keeps killing my brackets... All of the instances above are bracketed but I am to lazy to add spaces to all of them as I did the first line

Harrison.

You need to have pulldown resistors on the prop side with your setup. Floating input pins can lead to spurious results, thus leading to random ip settings being set.

Also, make sure you check 'driver_socket.spin' for the correct ordering of the ip configuration block (the ordering of the values must be exactly the same). The ip_broadcast value has been replaced with ip_subnet in recent releases. Subnet is extremely important if you are planning on using client mode to connect to hosts outside of your local subnet.

Jimmy W.

Harrison. said...
You need to have pulldown resistors on the prop side with your setup. Floating input pins can lead to spurious results, thus leading to random ip settings being set.

Funny you should say that, I was actually replacing the dips with a pin setup after I posted, thinking that could be it, I also added a bit of serial debugging code, I telnet in and I see ADDRESS:15<cr><lf>ADDRESS:15<cr><lf>.... so it is seeing the correct jumpers(I set them all to high), but no connection on 192,168,1,85, I set them all to low and I get ADDRESS:0<cr><lf> and a connection is able to be established on 192,168,1,70 I really dont understand what is happening

also, I updated the driver and did not realize they changed this, updated the code to reflect a subnet mask instead, thanks, but still no go

Jimmy

Propability

·Try hard coding the other address one by one in your dat section··to see if you can connect to them. It might be in the way you are trying to modify the addresses .

Harrison.

Try Propability's suggestion. I've seen people change the ip addresses and mac addresses on the fly before so I am pretty sure it works.

Also, I just noticed you use '$96, $11, $22, $33, $44, $01' as your mac address. I would highly recommend you keep the most significant byte $10 (the 'Private' OUI) because it won't conflict with assigned OUIs. The most significant byte ($96 in your case) has special meaning.

The $96 in your MAC address means: 'locally administered address, multicast mac address'. You definately don't want multicast, and locally administered could cause confusion in the future. So again, use $10, and you won't run into any issues regarding packet switching inside your subnet.

Take a look at en.wikipedia.org/wiki/MAC_address#Address_details for more information.

Harrison

Jimmy W.

Hard Coding them works, and for my application I cannot use the private 10, for some reason an AMX controller doesn't like to keep a stable connection if i use this.
0000000X
X: uni = 0, multi = 1
000000X0
X: Global = 0, Local = 1

96 is 10010110 - local admin, unicast
if for some reason I wanted to claim this was a globally unique MAC I would tell it that it is 94 is 10010100 - Global admin, unicast, but I wont lie [noparse]:)[/noparse]

AMX holds a solid connection when I originally found this bug and changed mac addresses , so I have been using this mac range for a while now

anyone else have any on the fly ip addr / mac addr code that they have lying around so I can compare notes?

Propability

OK so you know what the object needs to see in the way of the parameters or the values passed to it. Write a dummy object to display all the parameters as if it was the other object -then see if you are really passing what you think are the correct ones. You might try a simple routine to start with - just a simple display the parameter one.



Pete

Harrison.

Jimmy W. said...
Hard Coding them works, and for my application I cannot use the private 10, for some reason an AMX controller doesn't like to keep a stable connection if i use this.
0000000X
X: uni = 0, multi = 1
000000X0
X: Global = 0, Local = 1

96 is 10010110 - local admin, unicast
if for some reason I wanted to claim this was a globally unique MAC I would tell it that it is 94 is 10010100 - Global admin, unicast, but I wont lie [noparse]:)[/noparse]

AMX holds a solid connection when I originally found this bug and changed mac addresses , so I have been using this mac range for a while now

anyone else have any on the fly ip addr / mac addr code that they have lying around so I can compare notes?

You're totally right. I somehow read the bits backwards then forwards. I really shouldn't be posting when I'm tired...

Which version of the stack are you using? There may have been some weird bug in one of the older versions that I didn't catch till later. Very old versions didn't correctly stop the low level asm driver, which would cause problems if you were restarting the stack with new ip/mac parameters.

Post Edited (Harrison.) : 5/19/2008 2:31:58 AM GMT

Jimmy W.

I was going to let this fade off into the sunset but I figured I owed everyone an answer to this mystery, near, and in the code that changed the IP/mac, there were some non visible unicode chars that seemed to be messing everything up, found this out after i retyped the whole file line for line then ran a diff on the new (working) file


BEWARE THE UNICODE [noparse]:)[/noparse]


Jimmy

Cluso99

Your instruction

Address := INA[noparse][[/noparse]20..23]

places p20 in as the most significant bit (reverses order). I think you meant to use

Address := INA[noparse][[/noparse]23..20]

Jimmy W.

nope, its meant to be that way, that way when you look at the board in its final orientation it makes sense, MSB left, LSB right

Jimmy