HECnet

hecnet@lists.dfupdate.se

15589 discussions

by bqt＠softjar.se

On 2012-06-08 08:39, Boyanich, Alastair wrote: Hi Johnny, Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite C compilers as they're quite anal and chatty warning wise. Yeah. gcc is stupid. They added -Wall several years ago, but apparently people got upset by it's anal reporting, so they dumbed it down. So -Wall does not turn on all warnings anymore. And I just don't have the enery right now to figure out what more switches I should throw on it to actually make it complain about everything... Sounds good. New code arrives I'll check it out. :) The new code is already accessible. Same place as always... Johnny Al. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Friday, 8 June 2012 4:35 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] New bridge.c feedback On 2012-06-08 01:30, Boyanich, Alastair wrote: Hi Johnny, Yes. It seems to want<strings.h> 6.5.24 and above (or 6.5.29f in my case) was aiming at SUSv3 compliance away from base XPG4 so things were moved to strings.h (http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) .. it's also in the 3c index man page, you were right. Excellent. Included strings.h as well now. Not a problem on the systems here. We'll see if it hits problems for anyone else. So, compiles on IRIX 6.5.29 if the header is included. Worth gating it in via #ifdef ? I'm also a fan of enum types. Binary emitted is ~298kb. Also, your welcome to an account on the system if you wish to poke/play around, it's accessible over ssh and the general internet (it's my daily shell/hacking on code box). -Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal. See below. Even better. Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 158 The parameter "data" was never referenced. int lookup(struct sockaddr_in *sa, char *data) ^ Yeah. I noticed that one too. I don't remember why data was in there in the first place, since I'm not using it. Might as well drop it. cc-1506 cc: REMARK File = bridge.c, Line = 460 There is an implicit conversion from "unsigned long" to "long"; rounding, sign extension, or loss of accuracy may result. delta = timedelta(bridge[index].lasttime); ^ Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "r" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ That one is because dump_nomatch is a function I wrote for debugging help. The body of the function is normally empty, since it's inside a #if Need to think a little about how/if I'll get rid of that warning... cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "d" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ Same story... cc-1185 cc: WARNING File = bridge.c, Line = 579 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ That one should already have been fixed... cc-1171 cc: WARNING File = bridge.c, Line = 685 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Also alredy fixed... cc-1498 cc: REMARK File = bridge.c, Line = 709 There is no prototype for the call to read_conf. read_conf(); ^ Think I fixed that. However, this is a little messy, since I'm doing things slightly unconventional. read_conf() is called both in the normal main program, and is also the signal handling function for SIGHUP. However, signal functions actually takes one argument. By setting up a prototype, I had to include one argument here, which is unused (I totally don't care about it), so now you might get a warning about an unused parameter. But prototypes are a good thing, so the unused parameter warning is better to have. cc-1209 cc: REMARK File = bridge.c, Line = 715 The controlling expression is constant. while(1) { ^ Yes. That's how you get an infinite loop. :-) Thanks for the feedback. See what happens with the fixed code... Johnny

13 years, 8 months

New bridge.c feedback

by Alastair.Boyanich＠au.fujitsu.com

Hi Johnny, Your welcome. Yes, it's pretty chatty. MIPSPro and DECC are my favourite C compilers as they're quite anal and chatty warning wise. Sounds good. New code arrives I'll check it out. :) Al. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Friday, 8 June 2012 4:35 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] New bridge.c feedback On 2012-06-08 01:30, Boyanich, Alastair wrote: Hi Johnny, Yes. It seems to want<strings.h> 6.5.24 and above (or 6.5.29f in my case) was aiming at SUSv3 compliance away from base XPG4 so things were moved to strings.h (http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) .. it's also in the 3c index man page, you were right. Excellent. Included strings.h as well now. Not a problem on the systems here. We'll see if it hits problems for anyone else. So, compiles on IRIX 6.5.29 if the header is included. Worth gating it in via #ifdef ? I'm also a fan of enum types. Binary emitted is ~298kb. Also, your welcome to an account on the system if you wish to poke/play around, it's accessible over ssh and the general internet (it's my daily shell/hacking on code box). -Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal. See below. Even better. Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 158 The parameter "data" was never referenced. int lookup(struct sockaddr_in *sa, char *data) ^ Yeah. I noticed that one too. I don't remember why data was in there in the first place, since I'm not using it. Might as well drop it. cc-1506 cc: REMARK File = bridge.c, Line = 460 There is an implicit conversion from "unsigned long" to "long"; rounding, sign extension, or loss of accuracy may result. delta = timedelta(bridge[index].lasttime); ^ Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "r" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ That one is because dump_nomatch is a function I wrote for debugging help. The body of the function is normally empty, since it's inside a #if Need to think a little about how/if I'll get rid of that warning... cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "d" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ Same story... cc-1185 cc: WARNING File = bridge.c, Line = 579 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ That one should already have been fixed... cc-1171 cc: WARNING File = bridge.c, Line = 685 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Also alredy fixed... cc-1498 cc: REMARK File = bridge.c, Line = 709 There is no prototype for the call to read_conf. read_conf(); ^ Think I fixed that. However, this is a little messy, since I'm doing things slightly unconventional. read_conf() is called both in the normal main program, and is also the signal handling function for SIGHUP. However, signal functions actually takes one argument. By setting up a prototype, I had to include one argument here, which is unused (I totally don't care about it), so now you might get a warning about an unused parameter. But prototypes are a good thing, so the unused parameter warning is better to have. cc-1209 cc: REMARK File = bridge.c, Line = 715 The controlling expression is constant. while(1) { ^ Yes. That's how you get an infinite loop. :-) Thanks for the feedback. See what happens with the fixed code... Johnny

13 years, 8 months

New bridge.c feedback

by bqt＠softjar.se

On 2012-06-08 01:30, Boyanich, Alastair wrote: Hi Johnny, Yes. It seems to want<strings.h> 6.5.24 and above (or 6.5.29f in my case) was aiming at SUSv3 compliance away from base XPG4 so things were moved to strings.h (http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) .. it's also in the 3c index man page, you were right. Excellent. Included strings.h as well now. Not a problem on the systems here. We'll see if it hits problems for anyone else. So, compiles on IRIX 6.5.29 if the header is included. Worth gating it in via #ifdef ? I'm also a fan of enum types. Binary emitted is ~298kb. Also, your welcome to an account on the system if you wish to poke/play around, it's accessible over ssh and the general internet (it's my daily shell/hacking on code box). -Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal. See below. Even better. Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 158 The parameter "data" was never referenced. int lookup(struct sockaddr_in *sa, char *data) ^ Yeah. I noticed that one too. I don't remember why data was in there in the first place, since I'm not using it. Might as well drop it. cc-1506 cc: REMARK File = bridge.c, Line = 460 There is an implicit conversion from "unsigned long" to "long"; rounding, sign extension, or loss of accuracy may result. delta = timedelta(bridge[index].lasttime); ^ Thanks. cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "r" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ That one is because dump_nomatch is a function I wrote for debugging help. The body of the function is normally empty, since it's inside a #if Need to think a little about how/if I'll get rid of that warning... cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "d" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ Same story... cc-1185 cc: WARNING File = bridge.c, Line = 579 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ That one should already have been fixed... cc-1171 cc: WARNING File = bridge.c, Line = 685 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Also alredy fixed... cc-1498 cc: REMARK File = bridge.c, Line = 709 There is no prototype for the call to read_conf. read_conf(); ^ Think I fixed that. However, this is a little messy, since I'm doing things slightly unconventional. read_conf() is called both in the normal main program, and is also the signal handling function for SIGHUP. However, signal functions actually takes one argument. By setting up a prototype, I had to include one argument here, which is unused (I totally don't care about it), so now you might get a warning about an unused parameter. But prototypes are a good thing, so the unused parameter warning is better to have. cc-1209 cc: REMARK File = bridge.c, Line = 715 The controlling expression is constant. while(1) { ^ Yes. That's how you get an infinite loop. :-) Thanks for the feedback. See what happens with the fixed code... Johnny

13 years, 8 months

Introducing myself... and my little network

by roll＠Stupi.SE

I've got also some emulated PDP10 which I've not networked (yet). I'm having trouble plugging into DECNET a TOPS20/Panda machine... If someone could point me to any docs I would appreciate it a lot. Does Ethernet-Multicast get set up correclty on your host? I'm trying too to DECNETize a TOPS10 running on a KLH10 simulated machine; this one kinda works... I get the adjacency up messages but I can't talk to the machine (neither FROM the machine). The only docs I've found are for the 7.03 version of the monitor, but I've got 7.04. Again, any pointers to docs will be appreciated. There is no real change to DECnet 703a/7.04, the changes are 7.01/7.02. I don't think your problems are in the PDP10 code, it's KLH/Host_Networking. Can the T10 box talk to itself? -P

13 years, 8 months

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-07 23:12, Rob Jarratt wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Mark Benson Sent: 07 June 2012 07:27 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Multinet Tunnel Connections to SG1:: Now, you have due permission to beat me with a dried haddock if I'm being naive (I'm not a programmer, just a user observing a conversation that's 50% over my head) but... Wouldn't a kernel-agnostic DECnet implementation be a better shot? I mean if you can skim DECnet packets using libpcap (which is kernel agnostic as far as I can tell, hell it even works on Windows :)) and use that to handle DECnet for the bridge or SimH what's stopping it being used for a full DECnet comms package? It might not be very *fast* and it's sure as hell not secure but it'd work, right? With the fast pace of kernel change and the dropping of kernel support (and OSs like Ubuntu update the kernel regularly which will break things) for DECnet in the 3.x kernel it may be that kernel-based support is no longer practicable on modern Linux. Just a thought... This is such a big thread that it breached my attention span limit, so apologies if I miss something. This was exactly my plan, and I intend to give it a go, but no promises on when I will have something. I think it would be running a user-mode program running as root, use promiscuous mode, and on linux/unix run as a daemon, while on Windows it would run as a service. Being user mode it would be possible to run it on multiple platforms with ease. I am no DECnet expert, so I don't fully understand why I would need some kind of other interface to the routing function, I got a bit lost when people started talking about needing sockets to talk to the daemon. I think I would probably just use a config file to drive it, rather than provide some kind of command interface. Not sure if this would break something? Welcome to the world of confusion. No, you would not need an interface to a routing function. The problem is that people are not talking about a routing function. You went down the same path I was going... :-) What people are talking about now is a full blown DECnet implementation. Then you need an API for all the user land programs who might want to talk DECnet, and then you need an interface to it. Johnny

13 years, 8 months

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 07:21, Peter Lothberg wrote: On 06/07/2012 02:26 AM, Mark Benson wrote: It's a good idea, but I'm not sure it can be done. We need to change the MAC address on the interface...can that be done outside the kernel? This should be possible, OSI-IP requred this function to, but in addition to that you need to get the MAC-level multicast packets in both directions. Changing the MAC address outside of the kernel? Depends on the kernel. Linux have an API to do this. Some other Unixes does not. In fact, some Unixes have no capabilities for doing so even in the kernel, although if your code is in the kernel you can definitely do such a thing yourself. Problem is how to interface it to userland... (If I remember right, there is an ioctl() to do it in Linux... You do need to be root, obviously...) Johnny

13 years, 8 months

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-08 01:13, Dave McGuire wrote: On 06/07/2012 08:16 AM, Johnny Billquist wrote: Any program that needs access to raw ethernet packets needs to run as root. Promiscuous mode or not. Promiscuous mode itself has little to do with this. So if you want to run anything like a bridge or a router, you will need to run it as root. Promiscuous mode is basically just allowing you to share the same interface as the system is otherwise using, instead of having to dedicate a separate ethernet interface for this. Maybe you're just putting this another way, but promiscuous mode is correctly defined a bit differently than this. When an Ethernet controller is placed into promiscuous mode, its on-chip MAC address filters, which normally either select or ignore inbound packets based on their MAC address, are disabled. ALL packets are received by the hardware and passed to the Ethernet driver in the OS, rather than only the ones destined for that specific interface as defined by its MAC address. I'm reasonably certain that you know this but were just explaining it in a more abstract way...? Yes. Well, actually I wasn't describing it in a more abstract way, but in a way more in terms of why you need promiscuous mode instead of what it actually does on the interface. But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out. If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device. And to make a correction to your text, when not in promiscuous mode, your ethernet controller will filter out packets that do not have your MAC address, and packets that don't have the multicast bit set (possibly you can also get it to filter more specific on multicast ethernet packets, but multicast is a separate story from unicast packets on ethernet controllers anyway). Johnny

13 years, 8 months

netowrk flapping....

by roll＠Stupi.SE

NCP> %%%%%%%%%%% OPCOM 8-JUN-2012 07:07:16.01 %%%%%%%%%%% Message from user DECNET on STUPI DECnet event 4.18, adjacency down

13 years, 8 months

Introducing myself... and my little network

by roll＠Stupi.SE

I will set it aside if I find it, and make sure to image it. Image all your TK50's with distribution stuff on drop Al K a copy. -P

13 years, 8 months

Multinet Tunnel Connections to SG1::

by roll＠Stupi.SE

On 06/07/2012 02:26 AM, Mark Benson wrote: It's a good idea, but I'm not sure it can be done. We need to change the MAC address on the interface...can that be done outside the kernel? This should be possible, OSI-IP requred this function to, but in addition to that you need to get the MAC-level multicast packets in both directions. -P

13 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet