Date   

Build fails : arm-none-eabi-gcc.exe: error: unrecognized argument in option '-mabi=lp64'.

Hanumesha Ks <hanumesha.ks@...>
 

Hi Zephyr Users,

 

I tried to execute following command,  

\zephyrproject\zephyr>west build -b qemu_cortex_a53 -d build\hello_world samples\hello_world

by v2.3.0 release on Windows-10  with gcc-arm-none-eabi-9-2019-q4-major-win32

but my build fails with error arm-none-eabi-gcc.exe: error: unrecognized argument in option '-mabi=lp64'.

 

Build fails screenshot pasted below.

 

 

As per the gcc AArch64 “-mabi” Permissible values are  -mabi=ilp32 and -mabi=lp64 more info in below link.

https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options

 

Please guide me to resolve this issue ?

 

Best Regards

Hanumesha KS

Software engineer

NXP – Bangalore  

 

 

 


Re: Flash two firmware in flash and jump from one address to another #flash #nrf52480

Nikos Karamolegkos
 

Hello, after all I am flashing the base firmware (first app) into 0x0 address and then using the CONFIG_FLASH_LOAD_OFFSET=0x20000 to the proj.conf  of the second app I am flashing the second firmware in the 0x20000 address. Therefore, when I press a button from the first app I can jump to the second firmware. The only issue now is that I would like to update the start address to 0x20000 before the "jump" (in this way if I press reset the second app will boot). I have looked to the flash configs of zephyr but I have not found something useful. Any ideas?


Re: Direct ISR support on ARC

Justin Huang
 

Thank you Ruud for sharing and sorry for replying late.
You nail it: I was checking Zephyr 2.0.0. I will get the latest copy and give it a try.

Many thanks again,
Justin


From: users@... <users@...> on behalf of Ruud Derwig <ruud.derwig@...>
Sent: Monday, August 31, 2020 2:19 AM
To: Justin Huang <justin.y.huang@...>; users@... <users@...>
Subject: Re: [Zephyr-users] Direct ISR support on ARC
 

Hi Justin,

 

What version are you using? ARC support for direct interrupts was added in v2.1

(and note that Z_ARCH_IRQ_DIRECT_CONNECT was renamed to ARCH_IRQ_DIRECT_CONNECT).

 

Regards,

 

Ruud.

 

From: users@... <users@...> On Behalf Of Justin Huang
Sent: Saturday, August 29, 2020 2:45 AM
To: users@...
Subject: [Zephyr-users] Direct ISR support on ARC

 

Hi,

 

It appears to me that there is no support of 'direct ISR' by Zepher for the ARC processors: I do not see the definition of Z_ARCH_IRQ_DIRECT_CONNECT in the irq.h for ARC. 

Could someone please share why it is not supported?

 

Thanks,
Justin


Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Henrik Brix Andersen
 

Hi all,

This problem is due to a change in the device initialisation:
https://github.com/zephyrproject-rtos/zephyr/pull/28198

Regards,
Brix
--
Henrik Brix Andersen

On 9 Sep 2020, at 16.27, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:

Hi Helge,

Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
board pinmux init: PRE_KERNEL_1
gpio init: POST_KERNEL
So, what seems strange also is that it had effect in v2.3.0.

Anyway, the problem still stands.

I don't see a particular reason you wouldn't not be allowed to make this call.
So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
I can't tell if there is a reason it is not the case already.

BR
Erwan



On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@nortekgroup.com> wrote:
Hi.

I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.

I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:

static int pinmux_stm32_init(const struct device *port)
{
ARG_UNUSED(port);
stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

const struct device *porti = device_get_binding("GPIOI");
gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

return 0;
}

This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.

During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.

Questions:
1. Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2. If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)

Thanks,
Helge



Requesting Bug list for ZephyrProject release 1.14.0

Harish KothandaRaman <harish.kothandaraman@...>
 

Hello,

This is Harish Working for NupulseCV an medical device manufacturer. 
We have used the Zephyr project  (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development. 
As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.
For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

We were able to find the list of current issues in Zephyr OS from the following gitHub link.
But it would be really helpful for us to understand what were the pending issues for  nRF project for Zephyr OS v1.14.0.

Thanks in anticipation.

Regards
Harish K



Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Erwan Gouriou
 

Hi Helge,

Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
board pinmux init: PRE_KERNEL_1
gpio init: POST_KERNEL
So, what seems strange also is that it had effect in v2.3.0.

Anyway, the problem still stands.

I don't see a particular reason you wouldn't not be allowed to make this call.
So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
I can't tell if there is a reason it is not the case already.

BR
Erwan



On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@...> wrote:
Hi.

I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.

I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:

static int pinmux_stm32_init(const struct device *port)
{
    ARG_UNUSED(port);
    stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

    const struct device *porti = device_get_binding("GPIOI");
    gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
    gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

    return 0;
}

This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.

During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.

Questions:
1.  Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2.  If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)

Thanks,
Helge



Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Lubos, Robert
 

I just meant that OpenThread uses mbedTLS as it’s crypto library, for instance:
https://github.com/openthread/openthread/blob/master/src/core/crypto/sha256.cpp#L41

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: Wednesday, September 9, 2020 10:50
To: users@...
Subject: Re: [Zephyr-users] LWM2M client to nrf582540-DK #nrf52840 #networking

 

Perfect. I will prepare the configuration for the contribution. I made the changes you proposed and worked (I set MAX_PACKET_SIZE to 1024). Just to be clear by what do you mean by "OT use mbedTLS internally"?


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Nikos Karamolegkos
 

Perfect. I will prepare the configuration for the contribution. I made the changes you proposed and worked (I set MAX_PACKET_SIZE to 1024). Just to be clear by what do you mean by "OT use mbedTLS internally"?


v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Helge Juul
 

Hi.

I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.

I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:

static int pinmux_stm32_init(const struct device *port)
{
    ARG_UNUSED(port);
    stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

    const struct device *porti = device_get_binding("GPIOI");
    gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
    gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

    return 0;
}

This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.

During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.

Questions:
1. Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2. If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)

Thanks,
Helge


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Lubos, Robert
 

Hi Nikos,

 

Contributions are always welcome, would be also good to contribute the overlay-ot.conf to the lwm2m_client sample, once you have configuration that is proven to work. We even have an outstanding issue opened for that:
https://github.com/zephyrproject-rtos/zephyr/issues/18601

 

As for the issues reported, the first one (CONFIG_LWM2M_COAP_BLOCK_SIZE) looks to me like a bug, as this value is used to determine maximum supported packet size:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/lwm2m/lwm2m_object.h#L133

Given that currently we only support block transfer for FW updates, it doesn’t seem like valid approach. As a workaround, you can modify `MAX_PACKET_SIZE` to some higher value and see if it helps.

 

The Kconfig error can be fixed by explicitly enabling TLS support in overlay-dtls.conf (CONFIG_MBEDTLS_TLS_VERSION_1_2=y). TLS is by default disabled for OpenThread to save RAM/ROM when not needed (OT uses mbedTLS internally). The sample relied on a default config, hence it didn’t work with OT enabled. Other Kconfig warnings can be disabled by overwriting the defaults from `prj.conf` in `overlay-ot.conf` (OT makes no use of IPv4).

As for DTLS testing, you may also need to increase mbedTLS heap size (CONFIG_MBEDTLS_HEAP_SIZE=8192), to make sure it’s enough for both, OpenThread and LwM2M.

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: Tuesday, September 8, 2020 13:47
To: users@...
Subject: Re: [Zephyr-users] LWM2M client to nrf582540-DK #nrf52840 #networking

 

Thanks Robert, with your help I managed to make the OTBR work (I can make a documentation as contribution for the project if you are interested). Although, the device is registered to the leshan server as it should, I have two problems. The first one is that I can not change the CONFIG_LWM2M_COAP_BLOCK_SIZE to 64 (or 128) because I am getting the following error <err> net_lwm2m_rd_client: Registration err: -12 which I saw in API that corresponds to * Not enough core */. The second problem is that I can not build the lwm2m sample when I use the overlay-dtls.conf to enable communication over DTLS in the openthread network. The description of error is that error: Aborting due to Kconfig warnings the warnings are about the NET_IF_UNICAST_IPV4_ADDR_COUNT, NET_IF_MCAST_IPV4_ADDR_COUNT, TEST_RANDOM_GENERATOR and NET_SOCKETS_ENABLE_DTLS parameteres. I tried to comment in some of them but again I have problems. My build command is west build -p auto -b nrf52840dk_nrf52840 samples/net/lwm2m_client/ -d build_lwm2m -- -DCONF_FILE="prj.conf overlay-ot.conf overlay-dtls.conf"


Do you have any ideas?


API meeting: agenda

Carles Cufi
 


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Nikos Karamolegkos
 

Thanks Robert, with your help I managed to make the OTBR work (I can make a documentation as contribution for the project if you are interested). Although, the device is registered to the leshan server as it should, I have two problems. The first one is that I can not change the CONFIG_LWM2M_COAP_BLOCK_SIZE to 64 (or 128) because I am getting the following error <err> net_lwm2m_rd_client: Registration err: -12 which I saw in API that corresponds to * Not enough core */. The second problem is that I can not build the lwm2m sample when I use the overlay-dtls.conf to enable communication over DTLS in the openthread network. The description of error is that error: Aborting due to Kconfig warnings the warnings are about the NET_IF_UNICAST_IPV4_ADDR_COUNT, NET_IF_MCAST_IPV4_ADDR_COUNT, TEST_RANDOM_GENERATOR and NET_SOCKETS_ENABLE_DTLS parameteres. I tried to comment in some of them but again I have problems. My build command is west build -p auto -b nrf52840dk_nrf52840 samples/net/lwm2m_client/ -d build_lwm2m -- -DCONF_FILE="prj.conf overlay-ot.conf overlay-dtls.conf"


Do you have any ideas?


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Lubos, Robert
 

Hi Nikos,

 

If you use CONF_FILE option, you need to specify both, prj.conf and the overlay: “-- -DCONF_FILE="prj.conf overlay-usb-nrf-br.conf"”.

There’s also an OVERLAY_CONFIG option, where you can specify only the overlay file: “-- -DOVERLAY_CONFIG= overlay-usb-nrf-br.conf”.

 

Regarding OTBR, I’m sorry but I don’t have a working setup right now to test. For sure it’s critical that you provide the OTBR with the same channel/panid/network key as other Thread devices in your network.

The easiest way to determine whether you are connected to other devices is to use OT CLI component (OPENTHREAD_SHELL needs to be enabled, it is by default) and check children/router tables:

  • “ot role” to determine whether you are a router (leader in specific case) or a child
  • “ot child table” to see if you have any children in router role
  • “ot router table” to see if there are any other routers in your network
  • “ot parent” to see information about a parent router in child role

 

I haven’t worked with OTBR for some time, but I’m not sure if using “Join” option will work unless you have a commissioner in your network. I think that safer option would be to let the border router form the network (https://openthread.io/guides/border-router/web-gui#form_a_thread_network ) and then let your other device join it. Just make sure to use the same network parameters, as mentioned earlier.

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: Friday, September 4, 2020 13:05
To: users@...
Subject: Re: [Zephyr-users] LWM2M client to nrf582540-DK #nrf52840 #networking

 

I am a bit lost.  I am trying to compile the OpenThread NCP sample in order to connect the nrf52840 dk with the raspberry which will be running the openthread border router docker image. In order to compile the sample I am running west build -b nrf52840dk_nrf52840 samples/net/openthread/ncp/ -- -DCONF_FILE="overlay-usb-nrf-br.conf" but I have to add CONFIG_UART_INTERRUPT_DRIVEN=y in the overlay file (otherwise I have errors). Is this a bug? Nevertheless, finally, when I am using the pre compiled image from openthread site for the nrf52840-dk and at the same time I have a node running the LWM2M sample with the default overlay-ot.conf file (from the echo client) I can see the network in the OTBR GUI. I am trying to join the network from the OTBR but I don't know how to continue (or to check if the procedure is successful)  . Is the OTBR configured ok? Have anybody experience running the the LWM2M client over OT using the border router? I will appreciate some help.


Re: Debug probes and setup #debugging #gdb #nrf52480 #ztest #bluetoothmesh

Carles Cufi
 

Hi Erik,

 

FYI, pyocd is Zephyr-aware and Nordic’s J-Link OBs can be reflashed with pyocd-compatible firmware:

https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52-DK/Download#infotabs

 

Also:

https://twitter.com/SEGGERMicro/status/1298893256323932161?s=20

 

Carles

 

From: users@... <users@...> On Behalf Of Erik via lists.zephyrproject.org
Sent: 04 September 2020 18:31
To: users@...
Subject: [Zephyr-users] Debug probes and setup #bluetooth #debugging #gdb #nrf52480 #ztest #bluetoothmesh

 

Hi,
We are looking for direction on how best to improve our (multi-threaded) debugging capability.

Current setup:              host ---NRF52_dev_board (onboard jLink) -- custom Nordic-SoC board

where host is macOS and Win10 and our Bluetooth application can run either on dev or custom board.
We launch GDB debugging using west and for terminal output on macOS use separate JLinkRTTClient attaching to GDB (couldn't get regular terminal to work)

We understand JLink isn't ZephyrOS aware and per OpenOCD's most recent manual, neither is OpenOCD, so believe we need to run alt 
GDB server compiled with such support. We are hoping for a good out-of-box setup.
- Are there ways to stay with current setup and still see everything going on and step through code?
- Would debugging from within Docker Desktop, running below Docker image be possible/best path to align with what most people do?
  https://github.com/zephyrproject-rtos/docker-image
- Purchase a different HW probe (which one?) and use OpenOCD?
- If also want to debug/test Bluetooth app in QEMU, would we be forced to run on a Linux native host/dual boot, or can one emulate Bluetooth
   even if run in Docker image?

Would appreciate feedback on what works, and also paths to avoid.

  Erik


Debug probes and setup #debugging #gdb #nrf52480 #ztest #bluetoothmesh

Erik
 

Hi,
We are looking for direction on how best to improve our (multi-threaded) debugging capability.

Current setup:              host ---NRF52_dev_board (onboard jLink) -- custom Nordic-SoC board

where host is macOS and Win10 and our Bluetooth application can run either on dev or custom board.
We launch GDB debugging using west and for terminal output on macOS use separate JLinkRTTClient attaching to GDB (couldn't get regular terminal to work)

We understand JLink isn't ZephyrOS aware and per OpenOCD's most recent manual, neither is OpenOCD, so believe we need to run alt 
GDB server compiled with such support. We are hoping for a good out-of-box setup.
- Are there ways to stay with current setup and still see everything going on and step through code?
- Would debugging from within Docker Desktop, running below Docker image be possible/best path to align with what most people do?
  https://github.com/zephyrproject-rtos/docker-image
- Purchase a different HW probe (which one?) and use OpenOCD?
- If also want to debug/test Bluetooth app in QEMU, would we be forced to run on a Linux native host/dual boot, or can one emulate Bluetooth
   even if run in Docker image?

Would appreciate feedback on what works, and also paths to avoid.

  Erik


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Nikos Karamolegkos
 

I am a bit lost.  I am trying to compile the OpenThread NCP sample in order to connect the nrf52840 dk with the raspberry which will be running the openthread border router docker image. In order to compile the sample I am running west build -b nrf52840dk_nrf52840 samples/net/openthread/ncp/ -- -DCONF_FILE="overlay-usb-nrf-br.conf" but I have to add CONFIG_UART_INTERRUPT_DRIVEN=y in the overlay file (otherwise I have errors). Is this a bug? Nevertheless, finally, when I am using the pre compiled image from openthread site for the nrf52840-dk and at the same time I have a node running the LWM2M sample with the default overlay-ot.conf file (from the echo client) I can see the network in the OTBR GUI. I am trying to join the network from the OTBR but I don't know how to continue (or to check if the procedure is successful)  . Is the OTBR configured ok? Have anybody experience running the the LWM2M client over OT using the border router? I will appreciate some help.


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Nikos Karamolegkos
 

I have a bunch of this type errors " #error "CONFIG_UART_INTERRUPT_DRIVEN must be set for CDC ACM driver", "error: 'const struct uart_driver_api' has no member named 'fifo_fill'
  999 |  .fifo_fill = cdc_acm_fifo_fill"


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Lubos, Robert
 

Hi,

 

I’ve just checked current master, and building with "overlay-usb-nrf-br.conf" worked fine for me. Perhaps you need to clear your build directory?

 

Anyway, unless I miss something, it should be ok to use pre-built NCP app.

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: Wednesday, September 2, 2020 10:24
To: users@...
Subject: Re: [Zephyr-users] LWM2M client to nrf582540-DK #nrf52840 #networking

 

I am following this https://openthread.io/certification/border-router/device-setup tutorial. So I will USB. However, when I am trying to use "overlay-usb-nrf-br.conf" I have some errors while compiling the zephyr sample (maybe some dependencies are missing - I will check it -). For now I am using the pre-built nRF52840 firmware image (https://openthread.io/platforms/co-processor/firmware#flash_the_nrf52840). Is this problem? In general, the procedure is really simple but I have not managed to make it work


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Nikos Karamolegkos
 

I am following this https://openthread.io/certification/border-router/device-setup tutorial. So I will USB. However, when I am trying to use "overlay-usb-nrf-br.conf" I have some errors while compiling the zephyr sample (maybe some dependencies are missing - I will check it -). For now I am using the pre-built nRF52840 firmware image (https://openthread.io/platforms/co-processor/firmware#flash_the_nrf52840). Is this problem? In general, the procedure is really simple but I have not managed to make it work


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Lubos, Robert
 

Hi Nikos,

 

The project file selection depends on whether you want to use USB CDC or UART for the communication, by default UART is used, applying ` overlay-usb-nrf-br.conf` will switch to USB (you’ll need to use the “nRF USB” port on your DK).

 

As for the Border Router itself, you can either setup a RPi, or use a Docker image provided by OpenThread community and run it on any Linux host.

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: Wednesday, September 2, 2020 09:52
To: users@...
Subject: Re: [Zephyr-users] LWM2M client to nrf582540-DK #nrf52840 #networking

 

Thank you Robert, so the idea is to flash this https://docs.zephyrproject.org/latest/samples/net/openthread/ncp/README.html on my nrf52840-dk and then using the openthread border router implementation on a raspberry to build a OpenThread Border Router (OTBR)? If yes, do I need the overlay-usb-nrf-br.conf file or just the simple proj.conf?

Regards,
Nikos

On 8/17/20 5:58 PM, Lubos, Robert wrote:

Hi Nikos,

 

Unfortunately, we don’t have a step-by-step guide for the scenario you describe, but I can provide you with some guidelines.

 

OpenThread has a reference implementation of border router, which can be run on a Linux host under docker (OpenThread is a protocol that enables IP over 802.15.4):

https://openthread.io/guides/border-router/docker

 

The `lwm2m_client` does not support OpenThread out-of-the box, but it can be easily added, see this comment:

https://github.com/zephyrproject-rtos/zephyr/issues/24840#issuecomment-624717991

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: Wednesday, August 5, 2020 11:32
To: users@...
Subject: [Zephyr-users] LWM2M client to nrf582540-DK #nrf52840 #networking

 

Hi all,

I have two nrf582540-dk modules and I would like to run the lwm2m client example of the link using the leshan server. How could I implement this using real device? How my 802.15.4 device will communicate with the server running on my PC? Is there any border router? 

I really need this. Can someone point me in the right direction?

Thank you,
Nikos

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)

481 - 500 of 2694